| GPSLeo | |
| May 22 2025, 12:30 PM |
| F60459299: wle-de error.PNG | |
| May 24 2025, 2:29 PM |
| F60377965: Screenshot_20250522_142329.png | |
| May 22 2025, 12:30 PM |
Steps to replicate the issue (include links if applicable):
What happens?:
Drop down fields show div elements around the content intended to be displayed.
What should have happened instead?:
The div elements should be parsed as HTML elements and not be visible.
Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):
Other information (browser name/version, screenshots, etc.):
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | matmarex | T395196 Use ParserOptions::isMessage() instead of ParserOptions::getInterfaceMessage() in DiscussionTools | |||
| Resolved | matmarex | T395589 Review uses of ParserOptions::setInterfaceMessage(), add setIsMessage() to them if appropriate | |||
| Resolved | BUG REPORT | matmarex | T395023 UploadWizard campaigns field text parsing broken |
From using git bisect & trying to figure things out locally, it seems like this might be a regression from 223e85ac860c07f4c29965f2aa5f46bb89fb4754 in mediawiki/core (https://gerrit.wikimedia.org/r/1143497), which was merged for T393601: Sidebar donate link targets are always in English.
Given that this is a UBN! ticket, and given that it hasn't seen any activity in the last few days, I'm gonna be bold and CC some of the people/teams involved there, plus CTT as the stewards of the Parser component: @tstarling, @cscott; Community-Tech, Content-Transform-Team.
I can reproduce the problem, but I don't think it's related to 223e85ac860c07f4c29965f2aa5f46bb89fb4754. I switched my MediaWiki to the commit before that, and this bug still happens.
@matmarex Are you sure that isn't related to caching? /genq
I ask because this was a bit of a nightmare to bisect initially, as MW seemed to cache the working version of the page while I was switching through commits. However, when I set the following config settings, I recall being consistently able to reproduce when (e.g.) checking out the REL1_44 branch and applying that commit.
$wgMainCacheType = CACHE_NONE; $wgParserCacheType = CACHE_NONE;
Yes, you were right, I've just rediscovered that as I started working on a patch and testing it.
Change #1152069 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/extensions/UploadWizard@master] Campaign: Ensure `<div class="mw-parser-output">` wrapper is removed
There is more cleanup that could probably be done in the Campaign code, but since nobody particularly wants to touch this component, I went with the simplest change possible.
Change #1152069 merged by jenkins-bot:
[mediawiki/extensions/UploadWizard@master] Campaign: Ensure `<div class="mw-parser-output">` wrapper is removed
Change #1152080 had a related patch set uploaded (by C. Scott Ananian; author: Bartosz Dziewoński):
[mediawiki/extensions/UploadWizard@wmf/1.45.0-wmf.3] Campaign: Ensure `<div class="mw-parser-output">` wrapper is removed
Yes, thanks for scheduling it, I was planning to do so as well.
By the way this bug also appears in MediaUploader (a fork of UploadWizard), I'll send the same patch there.
Change #1152106 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/extensions/MediaUploader@master] ConfigParser: Ensure `<div class="mw-parser-output">` wrapper is removed
Change #1152080 merged by jenkins-bot:
[mediawiki/extensions/UploadWizard@wmf/1.45.0-wmf.3] Campaign: Ensure `<div class="mw-parser-output">` wrapper is removed
Mentioned in SAL (#wikimedia-operations) [2025-05-29T20:40:45Z] <cscott@deploy1003> Started scap sync-world: Backport for [[gerrit:1152080|Campaign: Ensure <div class="mw-parser-output"> wrapper is removed (T395023)]]
Mentioned in SAL (#wikimedia-operations) [2025-05-29T20:42:38Z] <cscott@deploy1003> cscott: Backport for [[gerrit:1152080|Campaign: Ensure <div class="mw-parser-output"> wrapper is removed (T395023)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.
Couldn't test that this was fixed on the testservers, probably because of the caching issue mentioned above in T395023#10867569 but proceeding with the sync regardless. Hopefully the cache issue will resolve itself.
Tested on https://commons.wikimedia.org/wiki/Campaign:wle-de which shows a <div... in the page title (window title), and then once you click through with an upload and get to the "describe" page, more <div ... in the "any other information you want to include" drop downs.
Mentioned in SAL (#wikimedia-operations) [2025-05-29T20:55:46Z] <cscott@deploy1003> Finished scap sync-world: Backport for [[gerrit:1152080|Campaign: Ensure <div class="mw-parser-output"> wrapper is removed (T395023)]] (duration: 15m 01s)
Using an obscure uselang setting suffices to bust the cache; I verified that https://commons.wikimedia.org/wiki/Campaign:wle-de?uselang=es is correct in production now.
Change #1152106 merged by Jforrester:
[mediawiki/extensions/MediaUploader@master] ConfigParser: Ensure `<div class="mw-parser-output">` wrapper is removed
