I reviewed the dashboard filters to phpversion: 8.3.26, looked at top errors, and then checked whether they also occurred on PHP 8.1. Many errors related to Parsoid seem to occur only on PHP 8.3, but I think that's because all of Parsoid traffic is served by PHP 8.3 servers now (per T405955#11346217). After excluding them (-parsoid in the search field), I haven't noticed anything that would be unique to PHP 8.3.

Oh, that's probably because all Parsoid traffic is served by PHP 8.3 now? (T405955#11346217) Ignore me then :)

All of the logged errors have occurred on PHP 8.3.

(Private discussion in WMF Slack: https://wikimedia.slack.com/archives/C01R06P8D1B/p1762531636993549)

The messages are actually used in two different places:

• In the JavaScript popup shown in your screenshot
  
• In the no-JavaScript message shown if you visit Special:UserLogout directly
  

The second one actually parses the wikitext in this message. So it seems to me that not parsing the wikitext in the first one was probably unintended, either it was just overlooked or maybe it was omitted because parsing wikitext in JS has limitations.

This was caused by the security patch for T406664, we've worked out a better patch and it should be deployed after the weekend.

Thanks, I updated the Tech News note to use that page, and linked it in a few others places on MW.org.

I can reproduce this if I enable "Turn on the ability to display IP addresses of temporary accounts" in my preferences, but not otherwise. That feature is a part of the CheckUser extension.

The error message has been present at a very low rate for a while, but all of the errors logged in today's spike have the same user-agent. I think this is unlikely to be normal human traffic.

Thanks @camilojdiaz!

I don't remember how I originally came up with the preset years ago, and I don't seem to have left any notes about it: https://github.com/MatmaRex/patchdemo/commit/bb9c74d0e5bab0fd2871dde5414173402722aeb7. I may have copied them from Special:Version on one of the wikis, maybe MediaWiki.org. And I haven't maintained it since then, and I don't think anyone did, so that would explain many of the missing extensions.

It's not actually clear to me what we should pass as performer instead of null. The code of AuthManager::autoCreateUser() itself mostly uses an anonymous user as performer when null is given. Some of the patches proposed here pass the user to be created instead, which may be an unintended change in behavior. @Tgr Any advice?

In T399199#11330999, @Tgr wrote:

Proposed Tech News message:

• The JWT issuer field in OAuth 2 access tokens for SUL wikis has been changed to https://meta.wikimedia.org. Old access tokens will continue working.
• The JWT subject field in OAuth 2 access tokens will soon change from <user id> to mw:<identity type>:<user id> where <identity type> is typically CentralAuth: (for SUL wikis) or local:<wiki id> (for other wikis). This is to avoid conflicts between different user ID types, and to make OAuth 2 access tokens and the sessionJwt cookie more consistent. Old access tokens will continue to work.

In T369454#11341180, @thiemowmde wrote:

@STei-WMF, yes, this is ready. Maybe something like this?

Wikivoyage wikis can use colored map markers in the article text (see https://www.mediawiki.org/wiki/Help:Extension:Kartographer#Markers_and_counters). These will now be shown with their correctly matching black or white text color, instead of always white. Local hacks that worked around the problem can be removed.

The limit we went with for now is 100 custom userjs- options. There aren't any users on Wikimedia wikis who currently have more options than this. The limit is configurable using $wgUserJsPrefLimit.

@Nikerabbit Can you confirm that this resolves the issue for you?

…or it could be caused by the hook defined directly in configuration here: https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/c901262a58781743f53ea8792c9de2c5467a4d9e/wmf-config/CommonSettings.php#2669

Similar functionality, but with many differences in the details, has been implemented in T405861: Add support for generating static SVG images via Scribunto.

The relevant code has been removed from Flow in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Flow/+/924478. This bug is probably no longer possible.

I added it to https://meta.wikimedia.org/wiki/Tech/News/2025/46 using the wording proposed a long while ago by @JJMC89:

In T407497#11341333, @Sgs wrote:

I think the particular text and interface we would want to modify is created in includes/EditPage/EditPage.php#2892

Thanks, added to https://meta.wikimedia.org/wiki/Tech/News/2025/46

Reproducible by just doing mw.Title.newFromText('constructor:foo').getPrefixedText().

In T391491#11285700, @camilojdiaz wrote:

I took a stab at addressing this. Please let me know if I missed something :-)

We should probably put this in Tech News. I feel like this regularly comes up on village pumps, sometimes people think the issue has something to do with edit conflicts. The change also makes it easier to preview changes on other skins/languages (T24029, T155097). And it may also have some effect on gadgets that act on the edit form, although I hope that is unlikely.

This is probably the same bug as T248796.

This is fixed on Wikimedia wikis now.

Yes, thanks for spotting that.

Oops, sorry we missed this bug report @JaydenKieran. It certainly would have saved me a headache if I had known about it before T403519. As you can see we now have a better triage mechanism with the MediaWiki-Platform-Team tag, so this shouldn't happen again.

Deployment to Wikimedia wikis scheduled for Monday: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20251103T1400

Hi @LAMurakami, thanks for the bug report. Based on what you wrote, I think MediaWiki is working correctly here, and your styles are not applying due to CSS selector specificity. For example, current versions of Vector include a CSS rule like .mw-heading h2 { color: inherit; }, which is taking precedence over your rule h2 { color: #9b4703; }, because it uses a class selector.

In T408733#11328312, @Nux wrote:

I seem to have more then 500 but almost all of them from core, only 20 from gadgets.

{
let all = Object.keys(mw.user.options.values);
let user = all.filter(v=>v.startsWith('userjs'));
console.log({all, user})
}

I'm sorry that this didn't get investigated in 2021 when you filed the bug, but it is impossible to investigate now unless you can reproduce it again. Any logs we could have used to debug it have been purged 4 years ago.

Declining based on the discussion from 2016, it seems that this isn't wanted.

Discussed previously: T69959, T220802, T395283

I think this is the same issue as T50956: Can't override optional message in all languages with local customisation.

It looks like this was fixed for Special:CreateAccount at some point. The uselang= parameter is now preserved after form submission on that page.

This was probably caused by e7eecbd9e3f19e7a404abea620f3e0f567b1d697 / T268492.

I agree that the guideline is a bit impractical. Ideally, I suppose, extensions would keep their module count that low, but unless you have a very limited scope, it is difficult to do that without causing maintenance issues for yourself.

20 or 30 seems way too low, at that point you can't really use more than one gadget/user-script that uses these without worrying that one of them will break because it can't save its options. enwiki may not use them much, but e.g. on plwiki there are several gadgets that use custom preferences, and my own account has 43 of them set.

Adding some limit makes sense to me. Have you ran some queries already to find out what is a normal number of preferences for a user to have?

The link target comes from the action=upload API response, .imageinfo.descriptionurl: https://gerrit.wikimedia.org/g/mediawiki/extensions/UploadWizard/+/683bba9f4f384213f3d297f12c2caff379e904dc/resources/ui/steps/uw.ui.Thanks.js#154

(I also found T264493, which suggests a slightly different solution, but it depends on rewriting the entire filter editing interface.)

It may be more intuitive if this interface used a combobox field (a text input with autocompletion) instead of separate dropdown and text fields. This change feels like an improvement over the current state though, thanks for working on it.

I see, thanks!

Same as T290282?