Page MenuHomePhabricator

ParserOptions::mEditSection is not passed to ParserOutput
Open, MediumPublic

Description

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.


Version: 1.20.x
Severity: normal

Attached:

Details

Reference
bz34687

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:13 AM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz34687.
bzimport added a subscriber: Unknown Object (MLST).

sumanah wrote:

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.