Last modified: 2014-09-23 23:19:39 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36687, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34687 - ParserOptions::mEditSection is not passed to ParserOutput
ParserOptions::mEditSection is not passed to ParserOutput
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-reviewed
Depends on:
Blocks: section-editing
  Show dependency treegraph
Reported: 2012-02-24 12:10 UTC by Vitaliy Filippov
Modified: 2014-09-23 23:19 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Patch to fix this problem (566 bytes, patch)
2012-02-24 12:10 UTC, Vitaliy Filippov

Description Vitaliy Filippov 2012-02-24 12:10:39 UTC
Created attachment 10089 [details]
Patch to fix this problem

There was a change in r99250 and also r100379 in MediaWiki 1.18.1 which was intended to always cache editsection link placeholders inside the parser output so they could then be added/removed when fetching the parser output from cache.

Since this change, if you just create a ParserOptions object, call $options->setEditSection(false), then parse something using these options and just call $output->getText(), you'll get editsections links in the output regardless of $options->setEditSection(false).

The fix is to always pass parser option to ParserOutput::setEditSectionTokens (don't know why it wasn't already so). The patch is attached.

I also think you should backport this change to (1.18.2 ?) as it breaks some extensions.
Comment 1 Sumana Harihareswara 2012-02-24 12:58:36 UTC
Thanks for the patch, Vitaliy! I added keywords to indicate that this bug has a patch that awaits review.

Do you know of specific extensions that got broken?
Comment 2 Platonides 2012-02-24 16:09:01 UTC
ParserOutput->mEditSectionTokens() defaults to false, and is set to true if  $this->mOptions->getEditSection() so I don't see any improvement on the reported issue with your patch (you are ignoring __NOEDITSECTION__, but as the markers are not outputed, it's probably irrelevant).

Can you provide a test for what this? I am not seeing that behavior:

$ php maintenance/eval.php 
> $popts = new ParserOptions;
> $popts->setEditSection(false);
> $output = $wgParser->parse("== Hello ==\n\nHi\n", Title::newFromText('Bug 34687'), $popts);
> echo $output->getText();
<h2> <span class="mw-headline" id="Hello"> Hello </span></h2>
Comment 3 Mark A. Hershberger 2012-02-24 16:30:42 UTC
s/need-review/reviewed/ per comment #2
Comment 4 Vitaliy Filippov 2012-02-24 16:58:07 UTC
Ok, I see... The problem shows when $wgParser is used in extensions with clearState=false. In that case, a new ParserOutput is not created and editsection flag is not reset in it...
Patching extensions so they use cloned $wgParser is probably more correct...
But anyway, if somebody will call parse() with clearState=false and $options->mEditSection=true while editsection was turned off for the original page, the result will have editsection links turned on...
So is this about parser non-reenterability again? =)
Comment 5 Vitaliy Filippov 2012-02-24 16:58:32 UTC
s/major/normal/ :)
Comment 6 Platonides 2012-02-24 17:01:46 UTC
Yes, it seems they shouldn't have been reusing the parser. What extension was it?
Comment 7 Vitaliy Filippov 2012-02-24 17:08:34 UTC
Two my own extensions and a non-up-to-trunk Wikilog :)
Comment 8 Vitaliy Filippov 2012-02-24 17:09:54 UTC
Sorry - trunk Wikilog also reuses $wgParser.

Note You need to log in before you can comment on or make changes to this bug.