(In reply to comment #0)

From [[WP:VPT]]:
http://en.wikipedia.org/w/index.php?oldid=454276984#Can.27t_edit_sections_of_semiprotected_articles

I now do not see an "edit" link next to the section titles of semiprotected
articles, like [[Great Famine (Ireland)]], or [[Barack Obama]], although I am
logged in.

Reporter mentions skin "if it matters" but it doesn't appear to matter. I see
edit links for the page, clicking them shows me a semi-protected warning, but I
don't see section edit links.

They're fine for me logged in...

I could definitely reproduce that when logged in a few minutes ago, on both [[Great Famine (Ireland)]] and [[Barack Obama]].

The logic calling $parserOptions->setEditSection(false) in Article seems the same as in 1.17... possibly it's getting dropped out of the parser cache key or something.

(We really shouldn't change that in the actual rendering, and should either be always adding them and then hiding them if not needed, or never add them and add them in postprocessing. :P)

https://en.wikipedia.org/wiki/Great_Famine_%28Ireland%29

logged in, no edit links
<!-- Saved in parser cache with key enwiki:pcache:idhash:14726-0!*!0!!en!4!* and timestamp 20111006191948 -->

reload, no change -- still no edit links visible.

https://en.wikipedia.org/wiki/Barack_Obama

logged in, no edit links
<!-- Saved in parser cache with key enwiki:pcache:idhash:534366-0!*!0!!en!4!* and timestamp 20111006232807 -->

reloaded, now shows with edit links:
<!-- Saved in parser cache with key enwiki:pcache:idhash:534366-0!*!0!!en!4!* and timestamp 20111006232807 -->

pcache key hasn't changed!

I'm a bit suspicious of r92703 -- this forces the editSection setting off on OutputPage's own mParserOptions on first creation. Might it be getting used sometimes for some reason?

The 'editsection' user option appears in ParserOutput's legacyOptions() -- but won't get recorded if it's not used...

Aha! r90214 removes a $this->optionUsed('editsection') which would be necessary to record the use of the setting on the ParserOptions....

... which was only added in r88988 for bug 29123, and reverted for fragmenting cache and Platonides being unable to repro the problem.

I think the proper thing to do here is actually to remove all those $parserOptions->setEditSection(false) in Article::view etc -- rather it should always turn section edit links *on*, and we should make sure they're *hidden* for people without edit permissions.

They used to be only hidden, but have been removed from the actual output for several releases, due to issues with printable version.

Note that in 1.18 they *are* added in a postprocessing step (see r81583 & related revs). That's why you're not seeing a difference in the parsercache key.

What sort of "issues with printable version"?

I had to dig a bit svn blaming, which lead me to r48544, and bug 11213.

Aha!

Looks like another possibility I mentioned on bug 11213 was to do the removal from client-side JavaScript... we could either do it that way or make sure it consistently uses that post-processing step to make sure it doesn't produce cache issues.

Looks like I can reproduce the cache corruption easily by forcing a purge/recache on a printable view:

http://stormcloud.local/trunk/index.php?title=SecEdit&printable=yes&action=purge

Next view to the page without printable also shows no edit sections.

Confirmed. There were several small bits not prepared to interact. Should be fixed by r99250.

Reopening as that fix isn't quite right yet. :)

Solved in r99252 & r99254

This fix seems to have caused Bug 31647 and reports on [[WP:VPT]]: http://en.wikipedia.org/w/index.php?diff=455150792

tagging bugs for Marcus to look at