Section edit links do not show
Closed, ResolvedPublic

Description

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.


Version: 1.18.x
Severity: normal

bzimport added a project: MediaWiki-Page-editing.Via ConduitNov 21 2014, 11:51 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz31445.
MarkAHershberger created this task.Via LegacyOct 6 2011, 11:16 PM
Reedy added a comment.Via ConduitOct 6 2011, 11:26 PM

(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...

brion added a comment.Via ConduitOct 6 2011, 11:50 PM

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!

brion added a comment.Via ConduitOct 7 2011, 1:02 AM

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.

Platonides added a comment.Via ConduitOct 7 2011, 7:08 PM

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.

brion added a comment.Via ConduitOct 7 2011, 7:13 PM

What sort of "issues with printable version"?

Platonides added a comment.Via ConduitOct 7 2011, 7:20 PM

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

brion added a comment.Via ConduitOct 7 2011, 7:40 PM

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.

Platonides added a comment.Via ConduitOct 7 2011, 8:50 PM

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

brion added a comment.Via ConduitOct 7 2011, 9:04 PM

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

Platonides added a comment.Via ConduitOct 7 2011, 9:30 PM

Solved in r99252 & r99254

MarkAHershberger added a comment.Via ConduitOct 12 2011, 8:57 PM

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

MarkAHershberger added a comment.Via ConduitOct 15 2011, 10:03 PM

tagging bugs for Marcus to look at

Add Comment