Steps to replicate the issue (include links if applicable):
What happens?:
Page has UNIQ markers instead of system messages and other interface elements
What should have happened instead?:
Page is rendered correctly
Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):
Other information (browser name/version, screenshots, etc.):
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T28213 Strip marker (UNIQ / QINU) issues (tracking) | |||
| Open | None | T388786 Follow up from Parsoid Fragment support | |||
| In Progress | BUG REPORT | MusikAnimal | T407101 CommunityRequests pages contain UNIQ markers when rendered with Parsoid |
I think this might be similar to T289545, where it says that (in 2021) "none of the extensions deployed on the Wikimedia cluster register parser functions whose return values have the "isHTML" flag set" — so maybe {{#CommunityRequests:}} is the first.
Looks like Parsoid is supposed to support isHTML these days: T279094: Support for parser functions using "isHTML"?
That task says that it's fixed in T374616, on which task @cscott says that "further work will be tracked in T388786", so I guess the basic returning of HTML works (as it does) but perhaps not all features (like handling the recursive parse of <languages />)? I'm not sure.
However, the issue with our own strip markers not being replaced looks to be separate. That might be running into the fact that we're not supposed to use ParserOutput::setExtensionData() multiple times with the same key (doing so is not yet deprecated, but will be). By the time our onParserAfterTidy() is run, the extension data we're checking for has been removed, so we don't replace the strip marker.
I've experimented with doing what the Math extension does, and saving the replacements in an instance variable (still doing the substitutions in onParserAfterTidy). The ParserOutput extension data isn't available in the same way, and at first I thought that was because it was a different ParserOutput object (which it is), but there seems also to be a difference in the order of execution.
But anyway, on further discussion with the team, it sounds like this isn't a priority at the moment.
We should probably just sit down and talk through the issues here. OTOH we're not planning on deploying to meta before the end of the fiscal year, so it does sound like this can be low priority.
See https://meta.wikimedia.org/wiki/Community_Wishlist/W392?useparsoid=1 from the task description as an example page.
We currently see strip markers in these cases:
So basically we want to count instances of a specific parser function (and also render them), replacing a strip marker with the message that includes the count. Also during an edit, we need to update our DB with the count in the LinksUpdateComplete hook.
My impression in reading the docs is that we need to:
And I guess non-Parsoid will continue to use the ParserAfterTidy hook as it is now, and both implementations can coexist peacefully?
@cscott If you could fact-check the above that'd be great. Or I'd love to chat over a video call, if you're up for it. Many thanks!
I'd suggest using appendExtensionData('<some key>', 1, MergeStrategy::SUM) to count the votes. You can keep using LinksUpdateComplete to update the DB with the sum (I don't think that's been deprecated), but the more "modern" way is to use the RevisionDataUpdates hook, I believe. It looks like you already have a RevisionDataUpdates hook *as well* so you might as well do everything in that single hook.
Parser functions in parsoid are implemented using PFragmentHandler::sourceToFragment. These are registered in the extension.json, specifically https://www.mediawiki.org/wiki/Parsoid/Internals/Module_Configuration_Schema#pFragmentHandlers . This is not documented as well as it should be; I've submitted a wikimania proposal to hold a workshop on this to nudge me to write proper tutorial documentation. But a <languages/> tag inside a WikitextPFragment should render properly.
Change #1272206 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):
[mediawiki/extensions/CommunityRequests@master] Parsoid support: pull vote counts from separate parser output cache
Change #1293756 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):
[mediawiki/extensions/CommunityRequests@master] AbstractRenderer: render languages bar directly via Ext:Translate method
Change #1272206 merged by jenkins-bot:
[mediawiki/extensions/CommunityRequests@master] Parsoid support: pull vote counts from separate parser output cache
Change #1293756 merged by jenkins-bot:
[mediawiki/extensions/CommunityRequests@master] AbstractRenderer: render languages bar directly via Ext:Translate method
Change #1295545 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):
[mediawiki/extensions/CommunityRequests@master] FocusAreaRenderer: render wish-index with recursiveTagParseFully
Change #1295545 merged by jenkins-bot:
[mediawiki/extensions/CommunityRequests@master] Renderers: render wish/wish-index contents with recursiveTagParseFully
Change #1302278 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):
[mediawiki/extensions/CommunityRequests@master] Rename parser func magic word to be CamelCased
Change #1302275 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):
[mediawiki/extensions/CommunityRequests@master] Add Parsoid support for the CommunityRequests parser functions
Change #1302278 merged by jenkins-bot:
[mediawiki/extensions/CommunityRequests@master] Rename parser func magic word to be CamelCased