Last modified: 2014-09-23 23:19: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.next (1.18.2 ?) as it breaks some extensions.
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?
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> <p>Hi </p>
s/need-review/reviewed/ per comment #2
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? =)
s/major/normal/ :)
Yes, it seems they shouldn't have been reusing the parser. What extension was it?
Two my own extensions and a non-up-to-trunk Wikilog :)
Sorry - trunk Wikilog also reuses $wgParser.
