In T236810#6261511, @Naypta wrote:

Hi folks, I see mLinkHolders is now private, and that Parser::replaceLinkHolders has a deprecation tag in its comment. Is there at this stage a recommended alternative for parsing linkHolders in a string that an extension has? If not, is there any other way to go about doing so, without having to re-parse the entire content within which the links are held?

Just bumping the cache version would be sufficient for the 1.39 to 1.43 upgrade, wouldn't it?

I think having two thumbnail preferences ("normal" and "large/accessible") might solve most issues, although we'd still have the complexity in core of serving HTML with two different sizes. I haven't seen a discussion of responsive images yet: in many cases even though the screen px is fixed, our HTML mentions thumbnails in 3 or so different resolutions based on the screen magnification factor.

https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment#Preparing_for_deployment says:

1. Create a production deployment tracking task within Phabricator (in the Wikimedia-Extension-setup and Wikimedia-extension-review-queue projects) to get an extension into the review queue. This task should only concern deployment itself. Any issues which block deployment should be separate subtasks (listed under "Task Graph") that block this parent task.
2. Your deployment tracking bug should point to on-wiki community consensus (and/or community support/desire) for having the extension installed on a particular wiki, if applicable.
3. Request and incorporate feedback from the following reviews. These can be included as a "checklist" within the production deployment tracking task's description, (e.g. phab:T190716) or as substasks of the production deployment tracking task. Also note that not every review listed below is a hard requirement for production deployment and that there is no specific order of reviews which need be followed.

I believe this edit fixes the problem: https://ml.wikipedia.org/w/index.php?title=%E0%B4%AB%E0%B4%B2%E0%B4%95%E0%B4%82%3AInfobox_Indian_Jurisdiction&diff=4587335&oldid=1826809

In T392775#11415755, @Tchanders wrote:

• adding mw-tempuserlink to content area links that look like user links <--- this didn't cause problems as far as we know
• adding mw-tempuserlink to content area links that look like user links <--- this violated a long-held assumption and caused disruption

I'll just note that it shouldn't be considered unusual for there to be *some* lag between PCS and the action API. Up to 15 minutes or so? So it would be helpful if this bug seems to reoccur in the future to add some measure of 'time lag' (ie, how long ago the revision reported by the action API was created) so we know if the difference is within normal expectations.

Seems to be a dup of T383004: Parsoid read views: map with citation in caption results in raw UNIQ QINU marker.

In T404461#11411552, @Aklapper wrote:

See https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment for requirements.

The above patch Add post-processing cache, disabled by default (1205194) used inconsistent labels for the parseroutputaccess_render_total metric, which caused VisualEditor CI to fail (eg https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php83/20345/console).

See T411401: Eliminate double-parse and double-postprocess in CommonsMetadata as well.

For future archeology, I'm going to copy the commit message from 206f6cbd50ee9fd8005dfb1a41e61ecac61ad4ed:

ParserOutputAccess: Add process cache within the service class

The original change in this set was DataMwAttrib: Use live DocumentFragment for html values, which uncovered various issues with serialization of attribute-embedded data-parsoid requiring follow ups. Mentioning this in case it is relevant to the investigation.

I think a "include user link classes" might be a reasonable option. It seems like "default caption" could also work, if we carefully define the "default caption" -- for example, as matching the link title either completely, excluding the namespace, or in a special page subpath. Or maybe even just a trailing substring match, as long as the character before the substring is [:/] or start-of-string.

Doing a midweek patch release at the request of editing to bring in the fix for T410826: UnexpectedValueException: Unable to decode data-mw [{"parts":[{"template":{"target":{"wt":"#ifexpr: {{#expr:{{CURRENTMONTH}} = 4}} and {{#expr:{{CURRENTDAY}} = 1}}","function":"ifexpr"},"params":{"1":{"wt":"<div class=\"usermes which is blocking Flow deprecation work.

Latest discussion is at https://en.wikipedia.org/wiki/User:Cscott/Ideas/A_Dozen_Visions_for_Wikitext/Annotations

As discussed in T392775#11406328 the Content-Transform-Team believes the correct solution is passing a boolean for 'has default link text', which would be a boolean option, for example indefaultlinktext so that the following would return appropriate link classes for [[User:cscott]]:

Test cases were https://test.wikipedia.org/wiki/User:Cscott/T408741 for group 0 and https://en.wikipedia.org/wiki/User:Cscott/T408741 for group 1/2 -- both of which had the maximum expiry time before the deploy, and then after deploy and action=purge fell down to the expected expiry times. For example:

<!-- 
NewPP limit report
Parsed by mw‐debug.codfw.pinkunicorn‐5bb9764dc8‐9h96c
Cached time: 20251125215220
Cache expiry: 1806
Reduced expiry: true
Complications: [use‐parsoid]
CPU time usage: 0.179 seconds
Real time usage: 0.185 seconds
Preprocessor visited node count: 12/1000000
Revision size: 253/2097152 bytes
Post‐expand include size: 84/2097152 bytes
Template argument size: 0/2097152 bytes
Highest expansion depth: 3/100
Expensive parser function count: 0/500
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 0/5000000 bytes
Number of Wikibase entities loaded: 0/500
-->

expiry time now 1806 seconds, which is the 15-minute minimum plus the expected random stagger.

We reviewed this today in CTT tech forum, and although it would be nice to figure out some way to make this less obviously a foot gun, the fixes look good to us.

We reviewd this in CTT Tech Forum today. We're pretty uncomfortable with link color depending on the full link text. There are a number of subtle issues there with respect to HTML and URL encodings and language variants (language conversion can alter the digits in the temp account name, have you tested this?), and this approach seems pretty fundamentally incompatible with ApiQueryInfo T410880. Link colors need to be queryable in bulk, because they are typically used in postprocessing to update link colors for an entire page at once.

Take 2 controls the cloning with a configuration variable, to make it easier to tweak as the train rolls out, if needed.

resolving this bug; follow ups in T410979: Document (and/or tweak) TOCData API representation.

Each field in the TOCData representation has a default value if it is not present; the default value for 'line' and 'anchor' is the empty string. The default value for 'linkAnchor' is 'anchor'. https://github.com/wikimedia/mediawiki-services-parsoid/blob/08d22d0c01e135ddc850fcbeb50def29904cfe4d/src/Core/SectionMetadata.php#L340

In T328605#11398553, @Anomie wrote:

You have a bug. In this API query, parsing a page with a whitespace-only section heading, the output from prop=sections correctly has line and anchor set to the empty string while the output from prop=tocdata incorrectly omits these properties entirely.

"sections": [
    {
        "toclevel": 1,
        "level": "2",
        "line": "",
        "number": "1",
        "index": "1",
        "fromtitle": "API",
        "byteoffset": 0,
        "anchor": "",
        "linkAnchor": ""
    }
],
"tocdata": {
    "sections": [
        {
            "tocLevel": 1,
            "hLevel": 2,
            "number": "1",
            "index": "1",
            "fromTitle": "API",
            "codepointOffset": 0
        }
    ],
    "extensionData": []
}

The linkAnchor also seems to be omitted in general, but that's defensible as a removal of redundancy in the new format since it's generally the same as anchor (unless % characters are involved).

A similar issue was found by @Esanders when converting Flow boards. The old HTML in the flow board was something like:

<p data-parsoid='{"dsr":[0,52,0,0]}'><span about="#mwt1" typeof="mw:Transclusion" data-parsoid='{"pi":[[{"k":"1"},{"k":"2"}]],"dsr":[0,52,null,null]}' data-mw='{"parts":[{"template":{"target":{"wt":"fullurl:User talk:cscott","function":"fullurl"},"params":{"action":{"wt":"action=edit&amp;section=new"}},"i":0}}]}'>//en.wikipedia.org/w/index.php?title=User_talk:Cscott&amp;action=edit&amp;section=new</span></p>

aka it was generated before Consider all pf arguments as positional made all parser function arguments positional, and so still has named arguments in the data-mw.

Can reproduce this by going to [[en:User:Cyberpower678]], launching VisualEditor, clicking on the {{#ifexpr}} at the top of the page, and clicking 'add new undocumented parameter' to make a new named parameter to this parser function, eg named=test. As per https://www.mediawiki.org/wiki/VisualEditor/Debugging the HTML that would be sent back in this case is:

<span typeof="mw:Transclusion" data-mw="{&quot;parts&quot;:[{&quot;template&quot;:{&quot;target&quot;:{&quot;wt&quot;:&quot;#ifexpr: {{#expr:{{CURRENTMONTH}} = 4}} and {{#expr:{{CURRENTDAY}} = 1}}&quot;,&quot;function&quot;:&quot;ifexpr&quot;},&quot;params&quot;:{&quot;1&quot;:{&quot;wt&quot;:&quot;&lt;div class=\&quot;usermessage plainlinks\&quot;&gt;You have &lt;span style=\&quot;color:#002CC8\&quot;&gt;[[User:Cyberpower678/April Fools|a new message]]&lt;/span&gt; from another user (&lt;span style=\&quot;color:#002CC8\&quot;&gt;[[User:Cyberpower678/April Fools|last change]]&lt;/span&gt;).&lt;/div&gt;&quot;},&quot;named&quot;:{&quot;wt&quot;:&quot;test&quot;}},&quot;i&quot;:0}}]}" id="mwAg"></span>

decoded, the data-mw from this span is:

{"parts":[{"template":{"target":{"wt":"#ifexpr: {{#expr:{{CURRENTMONTH}} = 4}} and {{#expr:{{CURRENTDAY}} = 1}}","function":"ifexpr"},"params":{"1":{"wt":"<div class=\\"usermessage plainlinks\\">You have <span style=\\"color:#002CC8\\">[[User:Cyberpower678/April Fools|a new message]]</span> from another user (<span style=\\"color:#002CC8\\">[[User:Cyberpower678/April Fools|last change]]</span>).</div>"},"named":{"wt":"test"}},"i":0}}]}
`

and the presence of the named argument here is sufficient to cause the exception, since all "old style" parser functions should only have numbered arguments.

Done! Thanks for the nudge.

Done! Thanks for the nudge.

Done! Thanks for the nudge.

Done! Thanks for the nudge.

Done! Thanks for the nudge.

Done! Thanks for the nudge.

Done! Thanks for the nudge.

Done! Thanks for the nudge.

Done! Thanks for the nudge.

The Skin was added to the parser options as part of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1204727 (T380516: Introduce ParserOptions type for "propagated to ParserOutput but not otherwise affecting the parse").

My current thinking is that long-term we shouldn't actually need a separate type for this, these will just be options that are not read at all during a normal parse (and thus don't appear in usedOptions) but are read/used during postprocessing, causing the usedOptions for the postprocessed output to include more options than the usedOptions for the canonical output.

Oh, then not actually related to T348722: Lint indicators and couple other extensions for using {{{..}}} in extension body when using <tag>..</tag> syntax?

I've resolved this broken markup on all pages on qu.wikipedia.org.

Possibly reported by a user as a dark-mode bug at https://www.mediawiki.org/wiki/Parsoid/Feedback#c-Cscott-20251122034700-Coolguyyo-20251116035900 ?

I've seen this twice today: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1202377 and twice on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1204727

In your example, Kategori:Halaman dengan galat skrip / https://www.wikidata.org/wiki/Q7192108 / Category:Pages with script errors is never added by Parsoid unless the legacy parser also adds that category, so that seems to be a red herring. Parsoid is doing the exact same thing as the legacy parser.

That drop down lists the language converter variants. If you want this to be only an interface language, that's the drop down in user preferences that selects the user language (including variant).

See T324431: Parsoid: displaytitle HTML now appearing in <title> element rather than page title: Parsoid puts the display title in the <title> element, the app just needs to read it from there. (It's also in the ParserOutput and in a <meta> tag I believe.)

The information is present in Parsoid output, the issue is that the Android app doesn't consult the displaytitle when creating the heading on the page.