Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• Jump to bottom
• New topic
• All village pumps

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for 5 days.

« Archives, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228

Un-hidable(?) new UI decoration taking up lots of screenspace

"synthesizer-idle-light.webp" is randomly appearing in a new right-hand pane of some pages, knocking about 20% off the window width available for content. It's where one of the UI menus had been until I hid it a long time ago. There were many discussions, resulting in consensus that we should allow articles to fill the full screen-width by collapsing or hiding various panes and the TOC. This thing has no close button or explanation what it is, and clicking on it also does nothing useful except change it to a slightly different image. Please make it go away (or a simple "[x hide]" button on it). DMacks (talk) 03:04, 24 February 2026 (UTC)

Does it always appear on the same random pages? Or does it randomly appear and disappear even on the same page/article? – Scyrme (talk) 03:12, 24 February 2026 (UTC)

DMacks, please link to example pages. Take a screen shot if you can. Let us know what browser, skin, and view (mobile or desktop) you are using. Does it happen when you are logged out? Does it happen in a different browser? – Jonesey95 (talk) 03:18, 24 February 2026 (UTC)

if I am not mistaken, the initial idea was to have the globe appear really at random, but it apparently was a performance issue so it is now limited to just 2,500 articles at the most. The WMF team has narrowed down to a predefined list of 2,100+ articles leaving 300+ slots for local projects to determine which other articles to put up. Of course, we can also override the predefined list in whole or in part and curate the full 2,500 articles to show. – robertsky (talk) 16:13, 24 February 2026 (UTC)

@DMacks: If it's always appearing on the same pages, it may be related to "birthday mode". Does it still appear after toggling birthday mode off in your preferences? Or did you already do that? – Scyrme (talk) 03:18, 24 February 2026 (UTC)

I'm fairly certain it's just birthday mode now. I was confused because you quoted .webp (static image) instead of .webm (animation). You can toggle it off in the "Appearance" tab of your user preferences. – Scyrme (talk) 03:30, 24 February 2026 (UTC)

It seems consistently on Ney but consistently not on other pages I've visited lately. Desktop-mode on a desktop computer running firefox, vector 2022 skin. Does not appear when I'm in private-browsing non-logged-in mode. Looks like it is indeed birthday mode, and the pref toggle turns it off. Given that clicking on it does nothing useful, the only way I could even see what to call the image was by browser right-clicking "open image in new tab" and copying the filename. So now I merely emphasize that it's a problem there's no way to know what it means (why doesn't it link somewhere?) or where to turn it off (contrary to closure statement at Wikipedia:Village pump (proposals)#requests for comment on enabling the 25th anniversary birthday mode). DMacks (talk) 03:35, 24 February 2026 (UTC)

There's also a toggle to enable/disable it on Wikipedia's welcoming portal. It would probably be a good idea if the mascot animations linked somewhere, like the link I posted earlier as that page explains why it's there and how to toggle it off if you'd rather not have it. Doing it that way would likely be easier to implement than adding a toggle switch to every page it appears. – Scyrme (talk) 03:47, 24 February 2026 (UTC)

Sure. Anything that lets me know something about it would be an improvement. DMacks (talk) 03:54, 24 February 2026 (UTC)

I just noticed it can also be disabled from any page just from the same menu/sidebar that controls light/dark mode, so there actually is a toggle on every page already. – Scyrme (talk) 03:54, 24 February 2026 (UTC)

There's also a "Learn more about Birthday mode" link under the toggle in the same menu/sidebar. Still a bit confusing if you have the settings hidden as a menu rather than docked to the sidebar. I didn't immediately think to look there. – Scyrme (talk) 03:58, 24 February 2026 (UTC)

I see just an empty sidebar. IIRC Birthday mode is on. ~2026-12471-74 (talk) 08:34, 25 February 2026 (UTC)

Many images display a “broken file” symbol instead, but that is something else (and might be why I can’t see it) ~2026-12471-74 (talk) 08:40, 25 February 2026 (UTC)

If anyone needs articles for testing where the baby globe appears: Animal, Paul Thomas Anderson, Chloé Zhao, 79th British Academy Film Awards, Sun, Venus, Earth, Mars, Computer science, Ney, Music, The arts, Journalism. —⁠andrybak (talk) 04:39, 24 February 2026 (UTC)

@DMacks: meta:Wikipedia 25/Easter egg experiments. You can turn it off for yourself Special:Preferences#mw-prefsection-rendering by unchecking the cryptic "Birthday mode (Baby Globe)". The list of pages it appears on is configured at Special:CommunityConfiguration/WP25EasterEggs.

Any admin could turn off the "Enable by default" option, and while I don't want to be the one to throw that switch, we shouldn't be enabling it by default unless those annoying animations also included a link to the preferences section to turn them off, and the preference was clearly labeled as something like "Display animated globe mascots on select pages". --Ahecht (TALK
PAGE) 15:11, 24 February 2026 (UTC)

Note that S Marshall's close at Wikipedia:Village pump (proposals)#requests for comment on enabling the 25th anniversary birthday mode was that there was consensus to enable this feature by default if there is a prominent button to disable it, preferably on every page where birthday mode affects the user experience. Since the latter didn't happen (just a cryptic checkbox buried in preferences), we should consider not enabling it by default. --Ahecht (TALK
PAGE) 15:24, 24 February 2026 (UTC)

Also pinging @Robertsky who implemented Special:Diff/1338834608/1340087942. --Ahecht (TALK
PAGE) 15:27, 24 February 2026 (UTC)

If there's no button to switch it off then this should be disabled instantly.—S Marshall T/C 15:29, 24 February 2026 (UTC)

The button to disable it is on every page, in the Appearance menu. – robertsky (talk) 15:51, 24 February 2026 (UTC)

A key is that it's if you have such a menu. And if you don't, you don't know you need to find it for this situation. DMacks (talk) 17:35, 24 February 2026 (UTC)

The menu is there. On Vector 2022 skin, the Appearance menu accessible from the glasses/eyewear icon next to your username in the top menu bar by default, unless you have the Appearance menu already opened in the sidebar. – robertsky (talk) 18:34, 24 February 2026 (UTC)

Right. I know I have that menu hidden there, but we're still in "you don't know you need to find it". Is this a site appearance thing? A new functional feature in general? Something specific to the one page where I see it? DMacks (talk) 18:57, 24 February 2026 (UTC)

I would say that off the bat, most readers (as there are many more anon readers than power users like us) would know where to look for the button to hide the baby globe and the learn more page as well as the Appearance menu is in the sidebar by default, and that's immediate below the baby globe image in the sidebar if it is appearing. It can't get anymore prominent than that.

Your personal experience indicates otherwise, which is why my ping below supporting the idea of have [x hide] button. To further refine that idea, the [x hide] or even a learn more link button should be around the baby globe only when the Appearance menu is hidden. – robertsky (talk) 19:17, 24 February 2026 (UTC)

I have more than twenty years of Wikipedia experience, and it took me about me about ten minutes to find it. Until presented with very convincing evidence to the contrary, such as a design research with multiple diverse people who aren't experienced editors, and who were able to easily find how to disable it, I will assume that it is hard for most people to find how to hide it.

The current situation is nowhere near the consensus of "place a reasonably prominent button to disable it".

It's unreasonable to place an unrelated (!) and animated (!!!) thingie on lots of articles in the first place, but if anyone at the WMF really wanted to put it there, it should at least be easy to hide. It isn't. Amir E. Aharoni (talk) 00:16, 26 February 2026 (UTC)

"I did find the notice...It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard'"

This needs to be removed immediately until a solution that clearly tells the user how to disable it is part of it. Masem (t) 02:02, 26 February 2026 (UTC)

@Robertsky Ahh yes, the button labeled "Birthday mode (Baby Globe)", which in no way says "Turn off this distracting animated cartoon that's taking up a large portion of my page". If I hadn't seen this conversation, there's no way I'd know what the heck that means. --Ahecht (TALK
PAGE) 15:56, 25 February 2026 (UTC)

The [x hide] idea might be a good thing to implement though. Pinging @CDekock-WMF. – robertsky (talk) 16:02, 24 February 2026 (UTC)

Why isn't the video even clickable? It should have linked to a landing page somewhere. When I saw the video there on its own, I thought my computer was hacked. ~2026-12306-86 (talk) 02:35, 25 February 2026 (UTC)

Hello @Robertsky, thanks for the ping! Unfortunately, changes to Birthday mode aren't possible due to the limited-time nature of the feature. Since Baby Globe will only be visible on a small number of pages for one month, it’s not something we can prioritize for any further iterations. CDekock-WMF (talk) 12:15, 25 February 2026 (UTC)

@CDekock-WMF Maybe a minor modification could fix the concerns voiced here. Here's what I get in mobile view with Vector 2022:

There's a bold blue link to the settings where I can turn off the globe with one click. Nice! As far as I can tell, everyone here would be happy with this.

But here's what I get in desktop view with Vector 2022:

No link, no indication how I can turn this off. :-(

Anyway, that's what I got a few minutes ago. Now I don't see the globe anymore, just empty space. What happened?

— Chrisahn (talk) 13:01, 25 February 2026 (UTC)

Now I see the globe again. Maybe my network was flaky. — Chrisahn (talk) 13:05, 25 February 2026 (UTC)

Mobile view is Minerva, not Vector 2022. The link to turn it off in Vector 2022 is under the "Appearence" menu, which is uncollapsed by default but is collapsed in your view (under the glasses icon). There's a switch that lets you disable birthday mode directly on the page without having to open preferences. SuperPianoMan9167 (talk) 13:21, 25 February 2026 (UTC)

I know how to turn it off. That's not the point. The RFC that decided to enable this on the English Wikipedia said it should only be enabled if there is a prominent button to turn it off. That hasn't been done. That's the point. — Chrisahn (talk) 17:05, 25 February 2026 (UTC)

@CDekock-WMF any qualms from the development team if a volunteer steps in and muck around the extension to bring the idea using with phab:T418428 then? I don't mind rolling up my sleeves over the weekend on this. – robertsky (talk) 06:46, 26 February 2026 (UTC)

Wow, @Robertsky, what an offer! Thank you! Let me check in with the team on whether there are any reasons not to do things this way around. I'll get back to you later today. CDekock-WMF (talk) 10:06, 26 February 2026 (UTC)

Hello again @Robertsky, apologies for our delay in responding here. Thank you again for the offer to collaborate on this and improve the feature! We have been doing some work in the background to make sure we can support any code contributions from editors on this. We now have an engineer on standby to help review tweaks you may want to make. CDekock-WMF (talk) 16:03, 3 March 2026 (UTC)

• Turn this off. Please disable this feature until there's a reasonably prominent button to disable it on every page where it affects the user experience. Not hidden in a menu. On the page. Turn it off. Please turn it off.—S Marshall T/C 12:02, 25 February 2026 (UTC)

  I'd like to apologise wholeheartedly to the community for my role in this. :( I'm appalled.—S Marshall T/C 12:27, 25 February 2026 (UTC)

  @S Marshall: Perhaps you can go to Special:CommunityConfiguration/WP25EasterEggs and turn it off ("Default state for Birthday mode" to "Disabled") directly? (I thought only intadmins could, but now I see Robertsky is not one.) Nardog (talk) 13:20, 25 February 2026 (UTC)

  @Nardog It's any admin, not just intadmins, but S Marshall is not an admin. --Ahecht (TALK
  PAGE) 15:57, 25 February 2026 (UTC)

  The button to turn it off is only hidden in a menu if you have the "Appearance" menu collapsed. Otherwise, it's very prominent. SuperPianoMan9167 (talk) 14:10, 25 February 2026 (UTC)

  The cryptically labeled "Birthday mode (Baby Globe)", which I'd have to follow a link to find out what it means? It should be, at the very minimum, indicate that "Baby Globe" is an animated figure -- I'd have no idea what that means otherwise. --Ahecht (TALK
  PAGE) 15:59, 25 February 2026 (UTC)

This thing is completely unacceptable. It's extremely distracting. It's literal torture for me to see an unrelated animated thing and try to read something at the same time.

It took me about ten minutes to find how to disable it deep in the sidebar, and I've been writing on Wikipedia for more than twenty years, and programming MediaWiki for fifteen. I cannot imagine what do less experienced readers go through.

I've just reported https://phabricator.wikimedia.org/T418428 . If it's not addressed by tomorrow, I plan to use my sysop rigts to force-disable it for everyone in Common.css. Can anyone give me a reason not to do it? --Amir E. Aharoni (talk) 23:53, 25 February 2026 (UTC)

Yes. Force-disabling it for everyone would violate the explicit consensus of the Wikipedia community to have the feature on by default. SuperPianoMan9167 (talk) 00:47, 26 February 2026 (UTC)

The consensus summary says that there must be a "reasonably prominent button to disable it". There is no such button. There is a button, but it's nowhere near being "reasonably prominent". So the consensus was violated by whoever enabled the button, not by who will disable it. Amir E. Aharoni (talk) 01:17, 26 February 2026 (UTC)

Every logged out user who views it (who are the vast majority of users) has a prominent button to remove it by default, and they are the 99%. That it took you 10 minutes to remove it is, accordingly, not going to be the average experience, even if it took that long for every logged in editor to find the "goodbye" button.

I'm not a fan of someone who has sysop rights threatening to remove it by CSS when there is a plausible consensus quite established that says it should be enabled.

Moreover, for someone who has been a MediaWiki developer for 15 years, it is shocking to find you entirely missed the deployment of the interface administrator user right close to a decade ago, which you do not hold. I would oppose your stated reason for requesting that right, should you choose to do so in the meantime.

If you are so firmly against it, you should instead use your knowledge as a developer to submit a patch to disable it and see if you can convince another developer to +2 that patch. Izno (talk) 01:52, 26 February 2026 (UTC)

Also, would it be possible to hack in a more prominent button to disable the feature by editing common.js and common.css? SuperPianoMan9167 (talk) 00:53, 26 February 2026 (UTC)

Definitely possible, but the time and the effort to do this should be invested by the people who want to show the animation and not by the people who don't want to see it. Amir E. Aharoni (talk) 01:18, 26 February 2026 (UTC)

A good reason might be that abusing admin tools to overrule consensus would probably get you desysopped, but don't let that stop you. -- asilvering (talk) 02:22, 26 February 2026 (UTC)

The editor who closed the discussion establishing the consensus has clearly stated that this feature is not implemented according to consensus (the close was "implement if X..." but the situation is "not X"). A good-faith read is that whoever enabled it did not realize that the effect would be against consensus, since they just turned on what someone else had implemented. WMF has stated that they will not change the implementation so that it "is X". Therefore we currently have a situation that is not consensus (it even looks contrary to consensus), and turning it off would not contravene the close statement. DMacks (talk) 02:57, 26 February 2026 (UTC)

A good-faith read is that whoever enabled it did not realize that the effect would be against consensus, since they just turned on what someone else had implemented. For what's it is worth, the effect in my opinion remains within the consensus, the button is prominent for most readers. My ask for enhancement was a request for enhancement for what I frankly think are edge cases like your experience. I thought that was pretty telling with my refinement of your [x hide] idea. I am of course miffed at the idea not being taken up by WMF staff, but they have priorities and also as what Izno alluded to, any volunteer developer can also submit a patch, and I would be one of the first to help clear and deploy it as long as the patch works within expectations.

A telling sign that most readers are not experiencing what you are experiencing is to look at WP:Help desk and WP:Teahouse where non-registered readers asks for help mostly, where the only two threads about the baby globe by TAs thus far were apparently, "Where can I find the baby globe?" (sic 1, sic 2). In previous major roll outs, like Vector 2022, going off from my recollection, the two venues got significantly way more complaints and queries about the change from anons than at this village pump, so much so that there was/were template reply/replies by experienced editors tending to the two venues. – robertsky (talk) 06:43, 26 February 2026 (UTC)

@Amire80, @DMacks To a non-logged in user on basically any non-tablet device there is a large toggle directly below to turn it off. This is very much consistent with community consensus. (See this image of how it looks to non-logged in users) On mobile there is a link to the appropriate section in settings to turn of the globe. The fact that we have a million tools and have reorganized our interfaces in different ways is not necessarily "WMF implemented something in a manner not in consensus", but rather "in a few cases logged in editors have the link to disable farther away than expected". Sohom (talk) 16:44, 2 March 2026 (UTC)

It's a time limited function that can be switched off by users (yes, it did take me some time because I hid the appearances menu some time ago). As as it's only going to be around for 7–8 weeks then let's just let it run it's course but people can offer whatever feedback they want to the developers about waht features and/or the associated documentation should contain. Nthep (talk) 09:06, 26 February 2026 (UTC)

Looking for help trying to find something

Singapore has some sort of flashing icon or figure at the beginning of the article can't figure out where it's coming from. Moxy🍁 03:03, 25 February 2026 (UTC)

I don't see it. If others don't see it either, you might want to consider uploading a video and linking to it here so we can see what you're seeing. –Novem Linguae (talk) 03:06, 25 February 2026 (UTC)

Birthday mascot. DMacks (talk) 03:15, 25 February 2026 (UTC)

I clicked on the thingy how do I get to stop? Who the hell thought this little child icon.... Why the hell would we make our readers scroll even more before the article begins... Do these developers not take into account basic accessibility concerns? Moxy🍁 03:20, 25 February 2026 (UTC)

See #Un-hidable(?) new UI decoration taking up lots of screenspace, wherein we learn they didn't even implement it in the way that was consensus for approval to implement it at all. DMacks (talk) 03:24, 25 February 2026 (UTC)

ohhhh. ...Wikipedia:CONTENTEDITOR nightmare.

Preferences → Appearance → Birthday mode → Birthday mode (Baby Globe)

Celebrate 25 years of Wikipedia with a cute reading companion}} Moxy🍁 03:34, 25 February 2026 (UTC)

Globe icon or animation

Hey folks. A little while ago, a globe icon or animation started appearing on the right side of some articles. I'm using a Windows desktop PC. In Firefox it's a big icon, in Chrome it's an animation. It only appears on some articles -- Dune: Part Two is a random example. I think this is what's being displayed. When I click on it nothing seems to happen. It's taking up valuable real estate on the screen, forcing the rest of the article into a smaller space, but I don't see a way to hide it. Yes, I'm so confused. What's going on? — Mudwater ^(Talk) 02:25, 2 March 2026 (UTC)

I'm seeing this as well, on Bryson Tiller. This is a useless nuisance and needs to be removed, ASAP. Stefen 𝕋ower ^{Huddle • Handiwerk} 02:31, 2 March 2026 (UTC)

And I should mention the animation I'm seeing is similar but not quite the same. Stefen 𝕋ower ^{Huddle • Handiwerk} 02:38, 2 March 2026 (UTC)

See the birthday mode discussion above. The gist is that this huge image was implemented in a way that went against the consensus here on the English Wikipedia that it be easy to disable or hide. It is clear that in some display modes, it is not easy to do so. You can go to Preferences > Appearance and uncheck "Birthday mode". – Jonesey95 (talk) 02:49, 2 March 2026 (UTC)

Preferences > Appearance and uncheck "Birthday mode" Thanks, I was wondering how to disable that dumb thing. Some1 (talk) 03:02, 2 March 2026 (UTC)

Thanks! — Mudwater ^(Talk) 03:43, 2 March 2026 (UTC)

Thanks all. Also, I think this calls for a /smdh. Stefen 𝕋ower ^{Huddle • Handiwerk} 04:22, 2 March 2026 (UTC)

Additional note: This is explained here -- though it took me a while to find it. — Mudwater ^(Talk) 12:07, 2 March 2026 (UTC)

• There is a basic concept that the developers appear to not have heard of. It's called consent. They should not randomly add things to the pages I read without my consent. Opt-in, not opt-out. At the very least, they should make the control for opting out part of the bloat they are stuffing down my throat, not an obscure setting in my preferences. Now I have to check my preferences regularly to see what else they decided to do to me without asking for my permission. :( --Guy Macon (talk) 16:13, 6 March 2026 (UTC)

  There was consent. It wasn't the developers who decided this feature should be opt-out. It was the community. SuperPianoMan9167 (talk) 16:43, 6 March 2026 (UTC)

Do i need approval from someone before i upload my user script?

Hello! i've been making a not so original user script that identifies common spelling errors. Im almost finished with it so im wondering how to upload it for wikipedia to use and if i need approval from someone first. Thanks! 203N7HN6 (talk) 07:57, 27 February 2026 (UTC)

No. See WP:USERSCRIPT for more details on what is or isn't permissible, but a spellchecking script shouldn't be very controversial, assuming it is used intelligently. Headbomb {t · c · p · b} 08:10, 27 February 2026 (UTC)

thanks! 203N7HN6 (talk) 08:22, 27 February 2026 (UTC)

@203N7HN6 See User:Polygnotus/Scripts/SourcerySpell.js for inspiration. It uses Hunspell. Polygnotus (talk) 11:45, 27 February 2026 (UTC)

im actually kind of new to js so im not sure how to implement other sofwtare in my code ehe 203N7HN6 (talk) 16:04, 27 February 2026 (UTC)

By the way, this (User:203N7HN6/Spellchecker.js#L-42) destroys all event listeners on the page content (breaks WP:Popups, WP:Media Viewer, etc.)

var bodyContent = document.getElementById('bodyContent');
// ...
bodyContent.innerHTML = highlightedHTML;

You could do mw.hook('wikipage.content').fire($("#bodyContent"));, but I'm sure this doesn't fix all other side effects that I can't think of right now. Better to just not replace the entirety of bodyContent's html. — DVRTed (Talk) 13:27, 27 February 2026 (UTC)

ill try to fix it when im available and try to contact you. thanks! 203N7HN6 (talk) 14:43, 27 February 2026 (UTC)

im fairly new to writing js in wp and would appreciate it if you could tell me what im doing wrong (PS: im using my current knowledge and inspect element to write stuff alongside with references from other scripts) 203N7HN6 (talk) 20:29, 27 February 2026 (UTC)

Oh, you're supposed to update the html and fire the hook afterwards. Try this (line 41):

bodyContent.innerHTML = highlightedHTML; 
mw.hook('wikipage.content').fire($("#bodyContent"));

— DVRTed (Talk) 20:43, 27 February 2026 (UTC)

ok thanks! 203N7HN6 (talk) 13:49, 28 February 2026 (UTC)

@203N7HN6, @203N7HN6.. no please don't do either. Use DOM manipulation, not replacing all contents by setting innerHTML. It can break all kinds of expectations of the software. .innerHTML should only be used to create NEW content, not to replace content. —TheDJ (talk • contribs) 08:00, 2 March 2026 (UTC)

@TheDJ You pinged 203 twice I think you meant to ping @DVRTed:. Polygnotus (talk) 08:11, 2 March 2026 (UTC)

I'm sure this doesn't fix all other side effects [...] Better to just not replace the entirety of bodyContent's html. I don't see a reason to ping me... lol. — DVRTed (Talk) 09:48, 2 March 2026 (UTC)

TreeWalker and createTreeWalker(). Polygnotus (talk) 09:12, 2 March 2026 (UTC)

Alignment issue with Tree chart

Hi everyone, some elements in the family tree under the Family and descendants section aren't perfectly centered. If anyone with more experience could help fix the alignment, I would be very grateful. Thanks! RiadS99 (talk) 01:06, 28 February 2026 (UTC)

I'm not very experienced, but it seems like the way you formatted the tables seems a bit messy and overutilizing '|' (vertical bar). Rhinocratt
c 13:51, 3 March 2026 (UTC)

Padding bug

Hello. I encountered a rather strange bug on Wikipedia when I tried to create padding in tables using NBSPs. So I've created a test template {{Padding bug}} and you can compare the results here:

This is the full code of my test template:

{| class="wikitable"
|-
| {{{1|}}} 
| {{{2|}}} 
| {{{3|}}} 
|}

Code used in article:

{{Padding bug|A|B|C}}

This output is correct:

A

B

C

Code used in article:

{{Padding bug
|A
|B
|C
}}

This output is incorrect:

A

B

C

Is there any way to fix this? Can you help me solve this mystery? Thanks, Maiō T. (talk) 08:40, 1 March 2026 (UTC)

There is no whitespace trimming of unnamed parameters. For example, the first parameter is two characters: A and a newline. Using 1=A (a named parameter) would trim any whitespace. Johnuniq (talk) 09:49, 1 March 2026 (UTC)

No, Johnuniq. This template is really crazy. Look at this next example:

Code:

{{Padding bug
|1=A
|2=B
|C
}}

Output:

C

B

Maiō T. (talk) 10:30, 1 March 2026 (UTC)

C is the first unnamed parameter according to MediaWiki and overwrites 1=A since only the last assignment of the same parameter counts. I would prefer if the counting continued after the explicit numbers and C becomes the third unnamed in your code but that's not how it works. C has an unstripped newline and it only takes one to force a taller row. The B cell only has B since the newline was stripped. The C cell is also vertically centered but has two lines, one with C and one blank. A common scenario is that the first unnamed parameter contains an equals sign so you have to add 1= to avoid it being interpreted as a named parameter. Then all the following unnamed parameters are forced to also use explicit numbers. It's rather annoying. PrimeHunter (talk) 12:05, 1 March 2026 (UTC)

Okay PrimeHunter. In other words, when creating a template, it is forbidden to add anything after the {{{1|}}} to avoid displaying a new line in the cell. Am I right? Maiō T. (talk) 15:46, 1 March 2026 (UTC)

Whitespace handling in MediaWiki is complicated but in a template like {{Padding bug}} I do suggest to omit   around the parameters. Use CSS instead (see Help:Table#Cell content indenting and padding) if you want more cellpadding Then MediaWiki's table code will ignore some forms of whitespace in the caller. The two "Code used in article" in your original post will both give the first result. PrimeHunter (talk) 17:49, 1 March 2026 (UTC)

Maiō T.: The template is doing what you tell it to do. In the second example that you have marked "incorrect", you are telling it: parameter 1 should be the letter A and then a new line. If you want the template to trim that new line away, wrap the parameters in {{trim}} in the template, as I have done in the sandbox:

Code:

{{Padding bug/sandbox
|A
|B
|C
}}

Output:

A

B

C

I hope that helps. – Jonesey95 (talk) 18:26, 1 March 2026 (UTC)

Wow!!! Thank you both, PrimeHunter and Jonesey95. You have been a great help. Two great options for fooling that bug. 😉 Maiō T. (talk) 20:20, 1 March 2026 (UTC)

Can't add link to a userspace draft

As you may be able to see from my spam blacklist log, I was trying to add a link, djdave [dot] xyz, to a userspace draft. However it kept getting disallowed? It said xyz was the link that was flagged, so I removed it, and it worked, but when I look at the spam blacklist, I can't see an entry for all .xyz sites or just djdave [dot] xyz. I was directed to MediaWiki talk:Spam whitelist but the instructions there are confusing. Could I have some help? TheTechie^[she/they] | talk? 23:21, 1 March 2026 (UTC)

It appears to have been added in Special:Diff/961623463 after MediaWiki talk:Spam-blacklist/archives/June 2020#h-the whole .xyz TLD-.xyz TLD-2020-05-19T18:41:00.000Z. If you want that site whitelisted, MediaWiki talk:Spam-whitelist is the place to request it. Looking at the instructions there and a glance at the history, as long as you include the relevant information (the specific link, the specific articles you want to use the link on, and why you want it whitelisted), it looks like people will engage with it even if you don't get the formatting exactly right. Anomie⚔ 00:20, 2 March 2026 (UTC)

Cyberbot not archiving RFPP...

I see Cyberbot is still working, but it hasn't archived WP:RFPP for quite some time - there's getting to be quite the backlog of processed requests, especially in the "Current requests for edits to a protected page" section, despite multiple entries having the "archive immediately" tag added to them. What's up? - The Bushranger _{One ping only} 01:23, 2 March 2026 (UTC)

categorylinks view in enwiki_p on enwiki.analytics.db.svc.wikimedia.cloud

Is it my imagination or has the cl_to column just vanished from the categorylinks view in the analytics database? It's still there for enwiki.web.db.svc.wikimedia.cloud. Sean.hoyland (talk) 17:37, 2 March 2026 (UTC)

Not your imagination; it had been deprecated for a while. phab:T299951. —Cryptic 17:43, 2 March 2026 (UTC)

Interesting. Thanks. Now I'm realizing that I don't really understand the relationships between page, category and categorylinks in a world without the cl_to column... Sean.hoyland (talk) 18:14, 2 March 2026 (UTC)

The titles that were in cl_to are now in the linktarget table, with cl_target_id as a foreign key to the appropriate row. See Special:Diff/1341322401 for a practical migration example. —Cryptic 18:26, 2 March 2026 (UTC)

Ah. Thanks very much. It also solves the mystery of what cl_target_id was pointing at... Sean.hoyland (talk) 04:08, 3 March 2026 (UTC)

The removal was also announced on the cloud-announce mailing list. Anomie⚔ 03:44, 3 March 2026 (UTC)

I guess over 50 database reports will stop working in the coming days. – DreamRimmer ■ 19:03, 3 March 2026 (UTC)

User:Cryptic has been fixing them. They fixed a few of mine. Thanks, Cryptic! – Jonesey95 (talk) 20:42, 3 March 2026 (UTC)

The {{database report}}-based ones are easy to find, since they show up in Category:SDZeroBot database report failures. I've only been taking care of queries I've worked on before, though, plus actual subpages of WP:Database reports - I figure the ones in userspace will be dealt with by their creators, if their owners are still paying attention to them. What's going to be more problematic are the bespoke bot reports and one-off queries on Quarry and such.

On that note, Jonesey95, could you do something about User:Jonesey95/Polluted categories? It's been the only page in the failures category for a long time now other than the recent flood, and the way it's set up it's basically never going to complete in anywhere near the bot's max time limit. —Cryptic 01:24, 4 March 2026 (UTC)

Blanked. Thanks for the reminder. That was a failed experiment to try to help Bearcat by creating a daily report. – Jonesey95 (talk) 02:21, 4 March 2026 (UTC)

Indeed. If I recall correctly, the regular report broke sometime last year or the year before (don't recall exactly) but its maintainer happened to be away from Wikipedia on vacation, so that report was created as a temporary workaround until they got back and could fix whatever had gone wrong with the regular one. Bearcat (talk) 02:51, 4 March 2026 (UTC)

At least 20 reports from HaleBot will break soon. I have pinged the operators below to see if they have time to fix the queries. I can help update the configuration on the report subpages, but the remote versions will also need to be updated. – DreamRimmer ■ 02:53, 4 March 2026 (UTC)

HaleBot has code that, in theory, keeps it from running when the report page transcludes {{database report}}, but I haven't tried migrating any more queries after it went ahead and overwrote Wikipedia:Database reports/Empty categories. (Though I see now there's a current attempt to steal it back again.) —Cryptic 03:07, 4 March 2026 (UTC)

@Cryptic: sorry! That report is a bit special and was bypassing the skip code. I'm fixing that now, it shouldn't affect any other reports.

Ideally at this point the only reports HaleBot continues to run are those that SDZeroBot can't because they're too complex or take too long. Legoktm (talk) 03:29, 4 March 2026 (UTC)

Category cleanup report issue

The Wikipedia:Database reports/Polluted categories report for categories with userspace content in them, which is supposed to run daily, appears to have failed to run yesterday. I know that the comparable Wikipedia:Database reports/Polluted categories (2) for categories with draftspace content was also temporarily borked yesterday due to an SQL thing, although it now seems to have been fixed — but because the reports are structured differently, I don't know if the user report failed because of the same issue or not.

So could somebody with more expertise in this kind of thing look into what happened and get it fixed so that the report runs properly today? Thanks. Bearcat (talk) 16:55, 3 March 2026 (UTC)

The cl_to column was removed from the categorylinks table. The query needs to be updated to use cl_target_id with linktarget. cc @Dbeef and @Legoktm – DreamRimmer ■ 17:07, 3 March 2026 (UTC)

Thanks for the ping, I'm starting to take a look... Legoktm (talk) 03:19, 4 March 2026 (UTC)

I fixed a number of reports, mostly by converting them to use the on-wiki template. I can probably get to the rest tomorrow. Legoktm (talk) 05:02, 4 March 2026 (UTC)

OK, All the reports managed by HaleBot should be fixed now. Legoktm (talk) 03:54, 5 March 2026 (UTC)

Tech News: 2026-10

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Weekly highlight

• Wikipedia 25 Birthday mode is now live on Betawi, Breton, Chinese, Czech, Dutch, English, French, Gorontalo, Indonesian, Italian, Luxembourgish, Madurese, Sicilian, Spanish, Thai, and Vietnamese Wikipedias! This limited-time campaign feature celebrates 25 years of Wikipedia with a birthday mascot, Baby Globe. When turned on, Baby Globe is shown on ~2,500 articles, waiting to be discovered by readers. Communities can choose to turn Birthday mode on by getting consensus from their community and asking an admin to enable the feature and customize it via community configuration on the local wiki.

Updates for editors

• Sub-referencing, a new feature to re-use references with different details has been released to Swedish Wikipedia, Polish Wikipedia and a couple of other wikis. You can try the feature on these projects or on testwiki and betawiki. Learnings from the first pilot wiki German Wikipedia have been published in a report. Reach out to the Wikimedia Deutschland team if you are interested in becoming a pilot wiki.
• Paste Check will become available at all Wikipedias this week. The feature prompts newcomers who are pasting text they are not likely to have written into VisualEditor to consider whether doing so risks a copyright violation. Paste Check tags all edits where it is shown for potential review. Local administrators can configure various aspects of the feature via Special:EditChecks. Research across 22 wikis found that Paste Check resulted in an 18% decrease in relative reverted-edits compared to the control group. Translators can help to localize this and related features.
• The Reader Experience team will be standardizing the user menu in the top right for all mobile users so that it is closer to the desktop experience. Currently this user menu is only visible to users with Advanced Mobile Controls (AMC) turned on. The only change is that a couple buttons previously in the left-side menu will move to the top right for users who do not have AMC turned on. This change is expected to go out March 9 and seeks to improve the user interface. [1]
• Starting in the week of March 2, the emails sent out when an email address was added, removed, or changed for an account will switch to a substantially nicer and clearer HTML email from the prior plaintext one. [2]
• Notifications are currently limited to 2,000 historic entries per user, and extend back to 2013 when the feature was released. This is going to be changed to only store Notifications from the last 5 years, but up to 10,000 of them. This will help with long-term infrastructure health and help to prevent more recent notifications from disappearing too soon. [3]
• The Global Watchlist which lets you view your watchlists from multiple wikis on a single page continues to see improvements. The latest update improves label usage experience. The extension now allows activating the language fallback system for Wikidata items without labels in the viewed language, and showing those labels in the user’s preferred Wikidata language if no uselang= URL parameter is provided. [4][5]
• The Wikipedia Android team has started a beta test of hybrid search on Greek Wikipedia. Hybrid search capabilities can handle both semantic and keyword queries enabling readers to find what they’re looking for directly on Wikipedia more easily.
• For security reasons, members of certain user groups are required to have two-factor authentication (2FA) enabled. Currently, 2FA is required to use the group, but not to be a member of it. Given that this model still has some vulnerabilities, the situation will gradually change in March. Members of these groups will be unable to disable last 2FA method on their account, and it will be impossible to add users without 2FA to these groups. Users will still be able to add new authentication methods or remove them, as long as at least one method is continuously enabled. In the second half of March, users without 2FA will be removed from these groups. This applies to: CentralNotice administrators, checkusers, interface administrators, suppressors, Wikidata staff, Wikifunctions staff, WMF Office IT and WMF Trust & Safety. Nothing will change for other users. See the linked task for deployment schedule. [6]
• View all 27 community-submitted tasks that were resolved last week. For example, the issue preventing users from creating an instance in Wikibase.cloud has now been fixed. [7]

Updates for technical contributors

• To help ensure fair use of infrastructure, over the next month the Wikimedia Foundation will implement global API rate limits across our APIs. In early March, stricter limits will be applied to unidentified requests from outside Toolforge/WMCS and API requests that are made from web browsers. In April, higher limits will be applied to identified traffic. These limits are intentionally set as high as possible to minimise impact on the community. Bots running in Toolforge/WMCS or with the bot user right on any wiki should not be affected for now. However, all developers are advised to follow updated best practices. For more information, see Wikimedia APIs/Rate limits.
• The Wikidata Query Service Linked Data Fragment (LDF) endpoint will be decommissioned in February. This endpoint served limited traffic, which was successfully migrated to other data access methods that were better suited to support existing use cases. The hardware used to support the LDF endpoint will be reallocated to support the ongoing backend migration efforts. [8]
• The new Parsoid parser continues to be deployed to additional wikis, improving platform sustainability and making it easier to introduce new reading and editing features. Parsoid is now the default parser on 488 WMF wikis (268 Wikipedias), now covering more than 10% of all Wikipedia page views.
• The process and criteria for requesting exceptional access to the high volume feed of the Wikimedia Enterprise APIs (at no cost for mission-aligned usecases), have now been published. This is to provide more thorough and clearer documentation for users.
• Tech Blog, the blog dedicated to the Wikimedia technical community will be migrating to Diff, the community news and event blog. The migration should be complete in April 2026, after which new posts will be accepted for publishing. Readers will be able to access posts – old and new – on the landing page at https://diff.wikimedia.org/techblog.
• Detailed code updates later this week: MediaWiki

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 17:49, 2 March 2026 (UTC)

requesting exceptional access should link to m:Special:MyLanguage/Wikimedia Enterprise#Access. — Qwerfjkltalk 18:56, 2 March 2026 (UTC)

Problem with bots' reporting

Is there a problem with toolforge? The bots I reply on, like Hale Bot and DreamRimmer Bot II have not been updating their reports. Thanks for checking. Liz ^{Read! Talk!} 19:15, 2 March 2026 (UTC)

Please request assistance from the bot operators. I suspect, like #categorylinks view in enwiki_p on enwiki.analytics.db.svc.wikimedia.cloud, that these bots rely on categorylinks in this way, but you will need to ask them to verify. Izno (talk) 19:48, 2 March 2026 (UTC)

It didn't seem like a bot problem but a system problem. This is where I come with these questions because editors here know how to create tickets reporting bugs or making inquiries. Sorry if it this displays technological ignorance on my part but I really don't understand how these aspects of the project work and you all seem to be able to look into issues more adeptly than I can. I'm just surprised that I'm often the only person reporting problems when they seem like issues that involve the functioning of bots or scripts that many, many editors rely on.

Also, I did post inquirites on the User talk pages of the bot operators. I just also usually come here as well. Liz ^{Read! Talk!} 04:30, 3 March 2026 (UTC)

All pages using template:plain image with caption with "image override" parameter

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Could someone create such list? sapphaline (talk) 21:29, 2 March 2026 (UTC)

@Sapphaline Maybe this? Ponor (talk) 21:40, 2 March 2026 (UTC)

I also need pages using this parameter unnamed. sapphaline (talk) 21:42, 2 March 2026 (UTC)

It is basically impossible to find such instances. If you want them, you will have to add TemplateData and then use bambot. Izno (talk) 22:21, 2 March 2026 (UTC)

There's under a thousand transclusions (less than half that in mainspace, if it matters). That's not trivial to look through manually, but still feasible. —Cryptic 22:30, 2 March 2026 (UTC)

---

Fortunately there were no instances of pages using this parameter unnamed, and the only mainspace page which used it named was Chloroplast. sapphaline (talk) 07:53, 3 March 2026 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Mobile diff errors

This is the second time within a week that I've misjudged someone's edit because the diff in mobile view was wrong. Take a look at this edit to Malaysian Malay in both desktop and mobile views. Desktop view clearly shows that one ancestor2 infobox parameter was replaced by another, and the source code at the revision created by that edit confirms that there's only one ancestor2 parameter.

But I was reviewing my watchlist on my phone, and what the mobile view of the diff showed was an extra ancestor2 parameter being added while leaving the one that was already there in place. Based on that, I reverted the edit as an error, explained in my edit summary along with a suggestion that the other editor might want to "Try again?" But right after that it occurred to me to check what the actual source code had been and I found that the diff lied to me and that the edit had been fine, so I restored it. Largoplazo (talk) 23:10, 2 March 2026 (UTC)

This is some flavor of phab:T349335. Izno (talk) 23:15, 2 March 2026 (UTC)

@Largoplazo: The mobile diff is supposed to show an indicator that a paragraph was moved. It's an inline diff and shows the paragraph at both the before and after location. So does a two-column desktop diff but there it's shown in a before and after column. I can see hover text "Paragraph was moved. Click to jump to new location." for the indicator on a blank line and click it but not see the actual indicator. I think the only error is that the indicator is invisible. I can toggle "Inline" in the desktop diff to see an inline diff where an indicator is visible as arrows. wikEdDiff at Special:Preferences#mw-prefsection-gadgets gives a better diff. Sometimes it gives a worse diff but the normal diff is still shown and wikEdDiff just adds an option to see an alternative diff. I recommend it. PrimeHunter (talk) 19:02, 3 March 2026 (UTC)

Or w:de:Benutzer:Schnark/js/diff (for alternative diff). — Qwerfjkltalk 12:31, 4 March 2026 (UTC)

Search prefix in InputBox doesn't work on mobile web on iPhone

I don't know if this issue is related the InputBox extension or the MediaWiki software, but the prefix parameter is ignored on the mobile web version of Wikipedia when <inputbox> is used to create a search form. When I enter something into the text field and press Enter, the form acts as if I'm doing a search in the article space. This affects the iOS version of Safari on my iPhone, but there are no issues on the iPad. Ixfd64 (talk) 11:53, 3 March 2026 (UTC)

sounds a bit like phab:T402078? Johannnes89 (talk) 13:43, 3 March 2026 (UTC)

Thanks for linking the ticket. So it's a MediaWiki issue, then. Ixfd64 (talk) 18:19, 3 March 2026 (UTC)

Article doesn't collapse in mobile view

The article 2022 European Curling Championships doesn't collapse in mobile view. I've tried to figure out why, but with no luck. It seems that this edit somehow is to blame (when I go through the revision history, it's from this revision onwards the collapse function won't work), though the edit looks completely normal. I've used my sandbox to try to find the solution, and it seems to have something to do with adding more nation templates, like {{CZE}}, to the page. Is there an upper limit to how many templates av this type that can be included in an article before problems like this one are caused?

I've earlier tried to get help with this subject on my own talk page, see User talk:Marima#Help me!. I hope someone more tech savvy than I can help me find the solution! Marima (talk) 12:01, 3 March 2026 (UTC)

IIRC, once there are sufficient images on the page, the mobile site turns off its collapsing. Those templates like {{CZE}} each add a flag image. Anomie⚔ 13:35, 3 March 2026 (UTC)

Yes, this would be the cause of it. Izno (talk) 17:57, 3 March 2026 (UTC)

The limit is 1000 images: phab:T232690. 2022 European Curling Championships currently has 1057 so it's not far off. File:Font Awesome 5 solid hammer.svg occurs 183 times so changing this indicator to a character would more than solve it. Maybe men and women should have separate articles anyway for length reasons. PrimeHunter (talk) 18:27, 3 March 2026 (UTC)

I replaced the image with "🔨". --Ahecht (TALK
PAGE) 19:21, 3 March 2026 (UTC)

Big thanks for the explanation and the measure taken! Marima (talk) 22:18, 3 March 2026 (UTC)

Ellman's

I have no idea what's going on here. Even after the nominator withdrew, the AFD for Ellman's was put back on the page by a bot. Ten Pound Hammer • ^{(What did I screw up now?)} 19:12, 3 March 2026 (UTC)

It's because they didn't remove the template that says {{REMOVE THIS TEMPLATE WHEN CLOSING THIS AfD}}. I fixed it. SuperPianoMan9167 (talk) 20:09, 3 March 2026 (UTC)

Mobile twinkle

Hello there, I'm a mobile editor on Wikipedia. I would like to use twinkle mobile and it isn't working. I currently use a very watered down version of twinkle as a gadget. Thank you for your time. Dafootballguy (talk) 23:28, 3 March 2026 (UTC)

I would suggest leaving a message at User talk:Plantaest/TwinkleMobile. SuperPianoMan9167 (talk) 23:48, 3 March 2026 (UTC)

Can I have my IP unbanned please?

I had my IP banned for inventing a crawler to download Vital articles level 4 as text files, with the intention to print it and bind books. I have read different opinions on spiders on different pages, from don't use them at all to use them on off-hours with a sleep between queries of 60s. I would be totally fine with doing this and I didn't realise this would be a problem as I didn't see the guidelines before being banned. I'm sorry for any trouble this may have caused and I didn't realise I was doing something wrong. If Wikipedia is 100% against spiders maybe you would release the Vital articles as their own downloadable packages? Nellas Galadhon (talk) 01:54, 4 March 2026 (UTC)

We did not do that. The WMF might have, see mw:Wikimedia APIs/Rate limits. Please correct the issues that are likely present in your downloading script as a result of the change in API rate limits and then if that doesn't fix the problem get in contact with the WMF using phab:. Izno (talk) 02:42, 4 March 2026 (UTC)

@Nellas Galadhon Also see https://meta.wikimedia.org/wiki/Wikimedia_Enterprise#Access --Ahecht (TALK
PAGE) 17:58, 4 March 2026 (UTC)

@Nellas Galadhon When making automated requests to the web site or APIs, please always make sure to follow the Robot policy. Note in particular the requirement to set a compliant User-Agent header to help avoid being blocked. It's not clear from your message what the error is, but I suspect it might just be that.

@Izno The API rate limits have not yet gone into affect, the first phase will be rolled out end of next week. JTweed-WMF (talk) 14:46, 5 March 2026 (UTC)

Thanks for your help.I only really discovered the robotic agreement once I started having error by then.It may have been too late.I'll try to implement what you suggested ~2026-14281-92 (talk) 14:52, 5 March 2026 (UTC)

@JTweed-WMF Ok, I linked the wrong help page and I know the other exists. Maybe you should ensure those are well connected. Izno (talk) 17:18, 5 March 2026 (UTC)

OpenStreetMaps automatically added to the battle infobox on every page with co-ords defined

Hi, I've asked about this over on WP:MILHIST but possibly folk here can give a better answer, particularly as the OpenStreetMap project appears to be dead.

At some point in the last year or so OpenStreetMaps appeared in all of the battle-infoboxes. You can see an example of this at Battle of Jutland, and it's very typical - totally uniformative and useless since what it shows is a close-up map of an empty stretch of sea. The land versions are little better since the maps are modern (with modern location-names and boundaries) and always at the wrong scale to give you any idea of what the battle was. Most of these pages have far more informative maps on them already.

However, the maps were not added through ordinary editing. They appear to be added automatically by some kind of plug-in or gadget. There is nothing in the page that can be edited to remove them without removing the co-ordinates that they are based on. The only solution appears to be just deleting the co-ordinates from the infobox.

Is there no way of opting pages out of this without just removing the co-ordinates?

It is also passing strange that, were anyone to propose adding that map to the infobox in the Battle of Jutland article, editors would rebel against the whole idea, but that map and tens of thousands more just as uninformative could be added to tens of thousands of articles with (as far as I am aware, correct me if I am wrong) little or no discussion. FOARP (talk) 11:39, 4 March 2026 (UTC)

These map frames are causing issues in other places as well. See Template talk:Infobox civilian attack#Mapframe appearing by default, Wikipedia:Village pump (miscellaneous)/Archive 86#Automatic map generation from Wikidata, Template talk:Infobox settlement#Unreliable maps automatically imported from OpenStreetMap. I don't know when they started being added and what discussions led to it. CMD (talk) 12:28, 4 March 2026 (UTC)

From the look of it: not discussed at all? And 95%+ of the time they're useless, but taking up prime real-estate on the page.

I've tried looking at Template:Infobox military conflict, and if I've understood it correctly showing the mapframe should be default no? That's how I read the documentation anyway. Adding |mapframe= no to Battle of Jutland's infobox removes the silly map.

But it's defaulting to yes across tens of thousands of articles and that should end ASAP. FOARP (talk) 13:37, 4 March 2026 (UTC)

Pinging @Joy (on a completely no-blame basis) as it looks like it might be their edits to Module:Infobox military conflict last October which have generated the |mapframe=onbydefault behaviour. Nthep (talk) 14:03, 4 March 2026 (UTC)

Yes, if you're talking about Module talk:Infobox military conflict#mapframe implementation. We had a similar discussion about the default zoom on sea locations already, and I actually tried to fix it already in this template, but because of this specific Lua implementation in that particular template, I didn't figure out how to do it. I'll attend to the article mentioned above now.

Is there a Lua-related noticeboard where one could ask for help? --Joy (talk) 14:09, 4 March 2026 (UTC)

Hmm, on a more general note, this template and this use case is actually pretty odd from the get-go. Usually the infobox templates have an image parameter for descriptive pictures, and a map parameter for maps. In this case, however, a map is attached as an image, so the code that autodetects whether to make a mapframe thumbnail from coordinates can't detect that. We should implement a map_image (or similar) parameter to improve this situation. This should be discussed at Template talk:Infobox military conflict. In the meantime I see FOARP has found that talk page 15 minutes ago, so I'll move over there. --Joy (talk) 14:15, 4 March 2026 (UTC)

Joy, this feature needs to be switched off by default ASAP until a consensus in favour of including them is decided. Not just for Battle of Jutland, but for all military conflict articles because in very, very few cases are these maps actually helpful. The zoom-level is only one of the many problems with them. FOARP (talk) 14:16, 4 March 2026 (UTC)

We can certainly revert the addition.

At the same, we could also observe that the feature has been live since October 2025, and you found 1 bad example after 4.5 months. Maybe the insistence that something needs to be done as soon as possible is not necessarily the best course of action. We could also try to analyze the available information further, and find more examples that actually demonstrate the extent of the issue, which should help us assess the risks here better.

For example, at https://bambots.brucemyers.com/TemplateParam.php?wiki=enwiki&template=Infobox+military+conflict we can currently see:

• 5,795 detected mapframe-coordinates parameters - this is mapped from coordinates automatically, so that sounds like the overall usage right now
• 34 detected mapframe parameters - usually interventions to enable or disable, where we further see:
  • CEM-36-Huguang-2433.jpg (1) - random bug?
  • This victory had the effect of breaking up the Hindu confederation (1) - random bug?
  • Yes (1) - explicit enabling
  • n0 (1) - attempt to disable that went awry?
  • no (12) - explicit disabling
  • yes (18) - explicit enabling
• 8 mapframe-marker (7 monument, 1 battle)
• 7 mapframe-zoom
• 7 mapframe-area_km2 - this can also be zoom/scale tuning
• 2 mapframe-caption
• 2 mapframe-frame-height (=250)
• 2 mapframe-frame-width (=180)
• 1 mapframe-wikidata (=yes)

So comparing 34 to 5795, we've had about 0.5% intervention rate of some sort. This could mean that nobody knows how to edit these things so we don't see much (iceberg effect), or it could mean that there wasn't a pressing need for interventions, or something inbetween.

The use of other options being comparable to the 34 seems to indicate that at least some editors have used these options for good. The ratio of explicitly disabled to explicitly enabled ones (13 vs 19) is not really in favor of the idea of there being a huge issue that requires urgent mass disabling. Of course, likewise there's the possibility of the iceberg effect as mentioned above.

I recommend we continue analyzing this in more depth at the infobox talk page, and really try to figure it out. --Joy (talk) 14:44, 4 March 2026 (UTC)

I found out about this because of an editor complaining in a comment that was posted soon after this feature went live. What people lacked was sufficient knowledge to know where even to complain about the issue - it's the iceberg effect. FOARP (talk) 14:51, 4 March 2026 (UTC)

I don't think this is straightforward evidence for that, both because that complaint indicated a variety of other issues (slow to display? Apple products?), and was by @Malchemist, an editor of fifteen years here. While we can and should appreciate others like ourselves :) we are not necessarily indicative of the general readership by default. A hundred thousand readers were there since, so even if iceberg ratio is 1000 : 1 this could well still be fine.

Likewise, if the solution was to actually remove the coordinates, not just the mapframe, because the location just wasn't right, then the mapframe merely made an existing issue more obvious, it didn't really introduce a fresh one. In that sense, mapframe thumbnails can be a useful tool to keep the base information proper.

At the same time, there's possibly a bit more nuance still - maybe if we better honored the resolution implied by the formatting of those coordinates, 49°1′N 3°23′E, (WP:OPCOORD), with a derived mapframe zoom that would better match that precision, maybe the context wouldn't be so bad by default. Comparison below:

For the average reader who doesn't really know where the Marne river valley might be, this basic illustration of it being east of Paris seems like a generally useful default. Unlike with Chateau-Thierry, which isn't even mentioned in the battle article, only in another map caption. --Joy (talk) 16:13, 4 March 2026 (UTC)

Hi Joy, I hope you don’t mind me saying this, but I am getting the strong impression that neither my concerns nor those my fellow editors in the Milhist space are entirely being listened to. Multiple editors here and at the template page have now told you that we don’t want these maps, that were added without discussion to thousands of articles, against what the documentation in the template says.

Please revert this addition ASAP. FOARP (talk) 21:37, 4 March 2026 (UTC)

I'm listening, but you're not apparently listening to me (at least I'm not seeing much other than blanket assertions in response), and seem to be intent on insisting something is done ASAP (Likewise here) Are you upset about this? What is the reason for this apparent urgency? Besides, you have the same permissions as I do, why wouldn't you just undo the change yourself, instead of poking me in the eye about it like this? --Joy (talk) 08:14, 5 March 2026 (UTC)

Could you please explain how exactly to do it? I honestly don't know how, otherwise I wouldn't be asking you. FOARP (talk) 09:06, 5 March 2026 (UTC)

The changes are in the history of Module Infobox military conflict, I had added a single block of code, it should be safe to just take it out. You can also test it first in Module:Infobox military conflict/sandbox. --Joy (talk) 09:20, 5 March 2026 (UTC)

Many thanks. Hopefully my inexpert deletion has not caused any problems.

As a word of advice, making sweeping changes to many thousands of pages is not something that should be done lightly and if I were you I would definitely at least drop a comment on to the relevant talk-page discussing what it is you want to do, and wait to see what the response is, before doing something like this again. FOARP (talk) 10:13, 5 March 2026 (UTC)

I think that's an issue also exacerbated by the weird division of talk between the two namespaces in that case. --Joy (talk) 13:09, 5 March 2026 (UTC)

Would a merge fix that? FOARP (talk) 13:19, 5 March 2026 (UTC)

I think we should do that, I can't imagine that there'd ever be a huge amount of discussions that would be so annoying to either audience to make it not worth it. --Joy (talk) 13:28, 5 March 2026 (UTC)

I should also mention one more thing with regard to iceberg effect - mapframes are much more common these days, and more and more readers are accustomed to them, and are aware of the fact one can click them, and then zoom in and zoom out (either by clicking, or by scrolling, or by pinching). Even in the worst case scenario where a reader encounters an ugly bland blue or white box, they might be aware that they can fiddle with the box, get in, zoom out, and get the geographical context information, which may or may not be useful, but it's typically not harmful. That is also why I would tend not to be alarmed in this situation. --Joy (talk) 14:51, 4 March 2026 (UTC)

Barely any mapframe maps in the first 50 at Special:WhatLinksHere/Template:Infobox_military_conflict. In 2026, I'd rather see people complain about unzoomable location maps or other static maps with tiny unreadable labels. Ponor (talk) 15:00, 4 March 2026 (UTC)

I found 10 mapframe maps in those 50. The infobox is used in 23,810 articles so that's an estimated 5,000 maps. PrimeHunter (talk) 22:18, 4 March 2026 (UTC)

I didn't find any mapframe maps improperly used in my sample. I thought there should be a few more, where there were no maps shown at all: I would like to see where the main battle of the Morean War was (maybe there's a museum), zoom in and out to see what towns are around today, etc. Ponor (talk) 10:05, 5 March 2026 (UTC)

I have no objection to adding mapframes where helpful. I believe this can still be achieved by changing the mapframe attribute to “yes”.

But in this case there was already a long-standing consensus that they should not be on by default documented in the template documentation. That consensus still appears to be valid based on the feed back here, at WP:MILHIST, and on the template talk-page. FOARP (talk) 12:00, 5 March 2026 (UTC)

These modern maps are confusing and misleading in historic articles and should not be used, IMO. Donner60 (talk) 03:37, 5 March 2026 (UTC)

Image thumbnails often failing to load

Tracked in Phabricator
Task T418323

This may have begun about a week ago or so. It's not always, but I see it regularly: in any page with images some thumbnails load, others fail to. Refreshing the page usually causes them to load, or requesting the browser to reload one that failed. I've been checking VPT from time to time for someone reporting the same problem but failed to identify a related thread, so thought I'd post this one. Thanks, ~2026-10830-00 (talk) 13:44, 4 March 2026 (UTC)

Please could you link to an example article where you are seeing a problem? I tried checking a few articles which have many images, e.g. List of paintings by Thomas Cole, but I cannot reproduce this bug. [Examples/links almost always help in bug-reports!] Thanks. Quiddity (WMF) (talk) 21:07, 4 March 2026 (UTC)

This could be the same problem as T418323. Matma Rex talk 22:40, 4 March 2026 (UTC)

This has been happening for at least a week. In articles but also in CentralNotice banners. Here's an example from 2026 Winter Olympics just now: <https://i.imgur.com/li1042k.png>. It's HTTP 429 Too Many Requests errors from URL such as <https://upload.wikimedia.org/wikipedia/commons/thumb/2/29/Flag_of_Eritrea.svg/60px-Flag_of_Eritrea.svg.png>. I'm running Google Chrome Version 144.0.7559.110, but this is almost certainly not a browser or ISP issue. This is some change that Wikimedia Foundation Inc. made to its media server configuration. Possibly related to phabricator:T414805. --MZMcBride (talk) 22:50, 4 March 2026 (UTC)

Yes, I would expect it to be 414805. Izno (talk) 23:32, 4 March 2026 (UTC)

But 60px is a standard thumbnail width, so it can't be that. Ladsgroup, who's been working on that task, also says that's not it. Matma Rex talk 10:11, 5 March 2026 (UTC)

It would be really helpful if someone could get a trending graph of HTTP 429s from upload.wikimedia.org over the past X days. --MZMcBride (talk) 22:58, 4 March 2026 (UTC)

I figured out where to find this, and added it to this dashboard: https://grafana.wikimedia.org/d/000000034/media. The number of 429s has been increasing over the last 3 weeks or so; note that the lines on this graph have different scales, so it's a steady 40k/sec of HTTP 200 responses, and recently up to 8k/sec of HTTP 429 responses. Looks like some tweaks are being made (T418323#11677204). Matma Rex talk 12:15, 5 March 2026 (UTC)

I had assumed that it was a slow connection. In the last month, I've used Wikipedia on three different devices using at least five different ISPs with widely varying load times. --Redrose64 🌹 (talk) 23:33, 4 March 2026 (UTC)

Thanks for looking into this, I'm glad that the source of the issue was found. ~2026-10830-00 (talk) 18:01, 5 March 2026 (UTC)

Today's outage — user scripts are disabled

Meta-Wiki is compromised. DO NOT ACCESS it with JavaScript enabled or without [?&]safemode=1. Nardog (talk) 15:31, 5 March 2026 (UTC)

The issue is being looked into. See the status page for updates. ~Oshwah~^{(talk) (contribs)} 17:10, 5 March 2026 (UTC)

Wikimedia sites were in read-only mode after the incident. Editing is back but user scripts appear to be disabled. A hacker apparently used a compromised account to load sitewide JavaScript at meta. The script made malicious edits with the accounts of users who visited meta with JavaScript enabled. PrimeHunter (talk) 17:12, 5 March 2026 (UTC)

Another hacker with Russian as their language of choice, I see. Cremastra (talk · contribs) 17:17, 5 March 2026 (UTC)

I can confirm that the user scripts that I load in my personal .js file appear to be disabled here on the English Wikipedia. This seems like an outage that would merit a sitewide notice of some kind. Maybe it's enough to have a topic here on VPT. – Jonesey95 (talk) 17:18, 5 March 2026 (UTC)

Yeah, it seems as if someone force-enabled safe mode for all sites when this happened. SuperPianoMan9167 (talk) 17:21, 5 March 2026 (UTC)

I'd say they're rightfully more concerned about the attack than user experience at the moment. FaviFake (talk) 17:22, 5 March 2026 (UTC)

+5,000,000,000 Security is way more important than me being able to look at WP:VPT with #F0FFF0 as the background color. mdm.bla 17:23, 5 March 2026 (UTC)

Someone added a watchlist notice in the meantime. --Joy (talk) 18:15, 5 March 2026 (UTC)

It does make me think that custom JavaScript should go through some approval process like device drivers for operating systems, and anything not on a whitelist of verified, tested and approved code doesn't run at all. Ritchie333 ^{(talk) (cont)} 17:14, 5 March 2026 (UTC)

I think a maybe simpler intervention would be that code from someone's userspace cannot take any actions that author could not take. For example, if a page mover writes a userscript in their userspace and I install it, and their script is then compromised, they might be able to mess with my page-moving ability, but they couldn't do anything worse. If someone wants a script to be exempt from these requirement, get an intadmin to move it into MediaWiki space and then it'll only be editable by intadmins. theleekycauldron (talk • she/her) 21:29, 5 March 2026 (UTC)

That would be impossible to enforce technically. Socially, we could have a rule like "admins are prohibited from importing scripts from non-admins" but I suspect that would lead to a lot of copy-pasting, which, for the reasons discussed here, might be worse. Suffusion of Yellow (talk) 21:51, 5 March 2026 (UTC)

I think it's not unreasonable to want a software change ot get a workable solution here, but hopefully there's a workable solution that doesn't require that. theleekycauldron (talk • she/her) 22:09, 5 March 2026 (UTC)

There isn't a software change that can "selectively" control what a script can and cannot do. As far as the browser knows, a "user" script is just another part of the site, and can do whatever it wants. You either import it or you don't. I suppose you could run the script in an iframe sandbox, but then it would live in its own little world, unable to even interact with the page. Suffusion of Yellow (talk) 22:24, 5 March 2026 (UTC)

The software can disallow editing site-wide javascript without reauthenticating, which should prevent a script from doing so non-interactively (especially since intadmins have 2FA enabled). --Ahecht (TALK
PAGE) 23:11, 5 March 2026 (UTC)

Yeah, but there's no way to say "Scripts from User:Trusted are allowed to do this, but scripts from User:LessTrusted can only do that..." Suffusion of Yellow (talk) 23:29, 5 March 2026 (UTC)

I mean, my understanding is that the browser knows the source of the import, and has to make an API call to take an action on behalf of the user; can't the API backend do a permissions check based on the permissions of the author of the source (i.e. whichever user is hosting the subpage of the userscript)? theleekycauldron (talk • she/her) 23:13, 5 March 2026 (UTC)

The API backend has no idea which script is performing the request, unless it provides that information voluntarily (e.g. with Api-User-Agent). Which is good practice in case of an accidental DoS, but obviously a malicious script can just provide fake information. Suffusion of Yellow (talk) 23:35, 5 March 2026 (UTC)

(this would not extend to blocks, but an intadmin should have an option to disable all userscripts a person has authored in blocking them.) theleekycauldron (talk • she/her) 21:31, 5 March 2026 (UTC)

See also MEGATHREAD Wikimedia wikis locked / Accounts compromised FaviFake (talk) 17:19, 5 March 2026 (UTC)

The malicious code has since been deleted. Some discussion at T419143. According to @MBH, @SBassett (WMF) added the script, causing this whole thing.

I have a copy of the code, if someone wants to take a look I can send it their way. JayCubby 17:25, 5 March 2026 (UTC)

Wait. What exactly happened? Did someone hack Meta-Wiki? VidanaliK (talk to me) (contributions) 17:25, 5 March 2026 (UTC)

we have to send someone to the WP:STOCKS for this, but who? ltbdl (operate) 17:25, 5 March 2026 (UTC)

Are you sure it was a well-intentioned Wikipedian that accidentally inserted "malicious code"? VidanaliK (talk to me) (contributions) 17:27, 5 March 2026 (UTC)

It seems more likely the account was hacked. It loaded a malware script stored at the Russian Wikipedia. There was no apparent reason to think it would be a good idea to load the script sitewide at meta. I don't know how the account was compromised but being hacked (even with a high-permission account) is not usually grounds for the stocks. Maybe if they had a ridiculously easy password. PrimeHunter (talk) 17:41, 5 March 2026 (UTC)

Actually, they may have loaded the script deliberately in their personal js and then the script used the account to change sitewide js. PrimeHunter (talk) 17:44, 5 March 2026 (UTC)

Nope, it seems he was testing userjs loads and he just imported a ton of random scripts, see [9] FaviFake (talk) 17:49, 5 March 2026 (UTC)

I'm definitely glad the wiki was in read-only mode by the time I logged on. Wait, if I had the "Keep me logged in for one year" might something have happened? What did the code even do? VidanaliK (talk to me) (contributions) 17:47, 5 March 2026 (UTC)

"What did the code even do?" - here's the user script and here's what was inserted into hacked users' common.js. Unfortunately I can't fully explain the user script, but in the second script the only relevant lines are 1-5, everything other than that is just a filler. sapphaline (talk) 18:00, 5 March 2026 (UTC)

Ahecht responded here. VidanaliK (talk to me) (contributions) 18:02, 5 March 2026 (UTC)

Scott Bassett (User:SBassett (WMF), the WMF's "Staff Security Engineer" JayCubby 17:27, 5 March 2026 (UTC)

 Done, see Wikipedia:Village stocks#Scott Bassett for the Закрываем проект award mdm.bla 17:51, 5 March 2026 (UTC)

So this is why I was logged out? Οἶδα (talk) 17:29, 5 March 2026 (UTC)

In 2023, vandal attacks was made against two Russian-language alternative wiki projects, Wikireality and Cyclopedia. In 2024, ruwiki user Ololoshka562 created a page ru:user:Ololoshka562/test.js documenting the script used in these attacks. It was inactive next 1.5 years. Today, sbassett massively loaded other users' scripts into his global.js on meta, maybe for testing global API limits: [10]. In one edit, he loaded Ololoshka's script: [11] and ran it. Source: https://phabricator.wikimedia.org/T419143 FaviFake (talk) 17:31, 5 March 2026 (UTC)

More info about previous attack is on n:ru:Википедия по ошибке сотрудников фонда Викимедиа была взломана хакерами MBH (talk) 17:36, 5 March 2026 (UTC)

So it was basically putting "Cyclopedia" onto every page on Wikipedia? What was Cyclopedia? How did they get access to SBassets account? VidanaliK (talk to me) (contributions) 17:57, 5 March 2026 (UTC)

It was a complete accident. SBasset was randomly importing user scripts, probably for testing, and just so happened to load a malicious one. SuperPianoMan9167 (talk) 17:59, 5 March 2026 (UTC)

• Wait.. was this a Chernobyl where the testing of a potential fault caused it to go critical? -- GreenC 17:54, 5 March 2026 (UTC)

FWIW that page has now been oversighted and the account globally locked. JavaHurricane 18:52, 5 March 2026 (UTC)

I linked to the scripts' source codes earlier in this discussion, if anyone is interested. sapphaline (talk) 18:57, 5 March 2026 (UTC)

@FaviFake I don't buy that Ololoshka562 was just documenting the script used in these attacks, as the script had a hardcoded check to not run from accounts with the username "Ololoshka562". --Ahecht (TALK
PAGE) 19:37, 5 March 2026 (UTC)

How would they know that this would be the end result? Did they know their script would be loaded? I'm not too sure. It feels more like a coincidence that script ended up being run rather than an intentional attack. Cutlass^Ciera 19:43, 5 March 2026 (UTC)

Maybe, but the script was modified so that if it were run, it would never run on the account that uploaded it. It wasn't a simple "here's a script someone else wrote on another wiki" situation. --Ahecht (TALK
PAGE) 23:13, 5 March 2026 (UTC)

So this is why it was in "read-only mode"? VidanaliK (talk to me) (contributions) 17:32, 5 March 2026 (UTC)

Yes, they shut wikipedia down to prevent the malicious javascript from spreading. FaviFake (talk) 17:35, 5 March 2026 (UTC)

The malicious code would also WP:NUKE all of the user's contributions as many pages as possible on each page load, so it was set to read-only to prevent further damage. --Ahecht (TALK
PAGE) 17:58, 5 March 2026 (UTC)

Possibly useful context: User:NYKevin/Interface administrators and trusting trust. --NYKevin 17:39, 5 March 2026 (UTC)

However, you can put arbitrary JavaScript code on that page, and it will run on every page load when you are logged in. Since the attacker can force you to take actions without being aware of it, they can install malicious JavaScript on your personal common.js page, and continue to manipulate your account even after the attack has been removed from the sitewide JavaScript. There's nothing stopping an attacker from doing this to literally everyone who has ever been impersonated. Or, if that's too obvious, they could do it to a very small selection of high-privilege accounts, and hope that the community does not notice.

concerning... Οἶδα (talk) 17:47, 5 March 2026 (UTC)

Does this factor into why I cannot load external images for my user styles? I liked browsing Wikipedia with Sonic Riders images in the background. ❤︎PrincessPandaWiki (talk | contribs) 17:49, 5 March 2026 (UTC)

Yup, see https://www.wikimediastatus.net/. Monitoring - A fix has been implemented and we are monitoring the results. Some editing functionality will still be disabled. FaviFake (talk) 17:51, 5 March 2026 (UTC)

Can someone explain what the Scott Bassett-uploaded code was doing? Wait, was that the code that shut down editing for an hour? VidanaliK (talk to me) (contributions) 17:54, 5 March 2026 (UTC)

@VidanaliK It would install itself in both the user's common.js as well as the site-wide common.js, and then WP:NUKE the user's contributions. This means that all users visiting the site would get infected, and any attempts to remove it from the site's common.js would automatically get reverted by users that still have it in their personal common.js. --Ahecht (TALK
PAGE) 18:01, 5 March 2026 (UTC)

So it would basically delete every single person's contributions if they logged on with JS enabled, and make it impossible to remove the script? Is that why the edit summaries were Закрываем проект (Closing the project)? VidanaliK (talk to me) (contributions) 18:04, 5 March 2026 (UTC)

@VidanaliK: Actually, I read it wrong. It would just do a blank Nuke in namespaces 0, 1, 2, and 3 on every page load, which would delete 500 random pages from each namespace. --Ahecht (TALK
PAGE) 18:11, 5 March 2026 (UTC)

So would it do that over and over again for a bunch of admins? VidanaliK (talk to me) (contributions) 18:11, 5 March 2026 (UTC)

Wait, what are namespaces 1 and 3? I don't see that on WP:NAMESPACE. VidanaliK (talk to me) (contributions) 18:12, 5 March 2026 (UTC)

They're in the floating table (1 = "Talk", 3 = "User talk"). sapphaline (talk) 18:13, 5 March 2026 (UTC)

Odd-numbered namespaces are for talk pages. 1 is Talk: and 3 is User talk:. mdm.bla 18:14, 5 March 2026 (UTC)

Wait, so after only 15,000 page loads every page on the English Wikipedia would be gone... VidanaliK (talk to me) (contributions) 18:15, 5 March 2026 (UTC)

The code as dormant for 1.5 years until he started massively adding userscripts to his global.js page to test its limits. One of these edits imported the malicious code and it worked because he had enough privileges. See Wikipedia:Village stocks § Scott Bassett for the Закрываем проект award FaviFake (talk) 18:03, 5 March 2026 (UTC)

The meta version of MediaWiki:Common.js was edited to load a malicious script which made bad edits from the accounts of innocent users. MediaWiki:Common.js automatically runs for all users of the wiki with JavaScript enabled which is nearly all users. All wikis were put in read-only mode by the Wikimedia Foundation to prevent spreading and investigate what was happening. MediaWiki:Common.js can be edited by a limited number of trusted users, some with global permissions for all Wikimedia wikis, and local Wikipedia:Interface administrators (we have 15). Normal administrators cannot edit it (they could years ago). PrimeHunter (talk) 18:07, 5 March 2026 (UTC)

A good argument for the next "please enable Javascript" debate, it seems... ~2026-10830-00 (talk) 17:57, 5 March 2026 (UTC)

For the time being, I'd recommend to install Greasemonkey and import everything there. Unfortunately scripts which rely on jquery won't work with this approach. sapphaline (talk) 18:17, 5 March 2026 (UTC)

I was wondering why the gadgets like DYK Check, Cite Unseen, etc. are not working. Just came to know this, sad! M. Billoo 18:23, 5 March 2026 (UTC)

Can't wait for the mainstream media to mention the incident. Ahri Boy (talk) 18:26, 5 March 2026 (UTC)

"Wikipedia gets hacked by administrator!" Pretty much every outlet criticising Wikipedia for all the world's problems (plus the teachers for which it is heresy to even say the word "Wikipedia") is going to have a field day with this. The question is, how do they get their reports? Do they go to a page called Village pump (technical) searching for the tiniest incident of something weird happening with Media-Wiki? VidanaliK (talk to me) (contributions) 18:31, 5 March 2026 (UTC)

Yes, they do. They also do it with all other village pumps, ANI, Wikipedia:Requests for comment/All, etc. sapphaline (talk) 18:34, 5 March 2026 (UTC)

They'll find out when the WMF puts out a statement, which I'm sure they will do. Most media doesn't troll projectspace. voorts (talk/contributions) 18:35, 5 March 2026 (UTC)

At least Reddit thread covered the incident. I guess only time will tell mainstream media will disseminate statement from the WMF. Ahri Boy (talk) 03:09, 6 March 2026 (UTC)

tiniest incident

? This was a major outage! FaviFake (talk) 18:35, 5 March 2026 (UTC)

It could be a fun story for the general public. The media may omit some details like the WMF/Wikipedia/meta distinction: A security engineer working for Wikipedia decided to run a large number of random unexamined scripts to see what would happen. He found out. He did it with his high-permission account which could infect every user if a single of the random scripts was bad. It was. PrimeHunter (talk) 18:46, 5 March 2026 (UTC)

This is better:

On Thursday a Wikimedia security engineer ran several scripts on the Wikimedia server without examining the code to check for malware. One of the scripts was a malicious program originating on the Russian-language Wikipedia, which when installed caused the accounts of all administrators on Wikipedia, Wikisource, Wiktionary, and several other projects to mass-delete pages. This resulted in Wikipedia being frozen for several hours as other security engineers tried to patch the issue. VidanaliK (talk to me) (contributions) 20:06, 5 March 2026 (UTC)

Any post to WMF or the media should have arguments with it like best practices for whitehat testing. Snævar (talk) 21:54, 5 March 2026 (UTC)

FYI phab:T419154 for the site scripts disabled thing, it's being tracked - plan is to get it back soon. — xaosflux ^Talk 18:37, 5 March 2026 (UTC)

We really need something like bot passwords for the web interface. You don't stay logged in to your machine as root all the time, do you? Yet there's no choice but to do that here. Suffusion of Yellow (talk) 18:55, 5 March 2026 (UTC)

Yeah, I'm also baffled by how Scott Bassett just ran these scripts on their main account with all rights without any second thought. sapphaline (talk) 18:57, 5 March 2026 (UTC)

Perhaps highly-privileged accounts with interface administrator permissions should have mandatory Always Safe Mode enabled.

I personally have a few userscripts that I use (and I've made sure to copy them to my own userspace now). But it doesn't seem unreasonable to encourage using a separate account for those routine tasks where scripts can save a lot of time. If today is a day where you do need to juggle chainsaws and other scary tools, it would seem wise to use a safe mode account. Mlkj (talk) 19:16, 5 March 2026 (UTC)

and I've made sure to copy them to my own userspace now: That only protects you if the script's owner is the compromised account. Doesn't help if an intadmin (or crat or steward ...) is compromised. But if there's an unintentional security problem with script (XSS, etc.), your copy won't get fixed if it's discovered. If the script has only one component (e.g. foo.js doesn't load foo-core.js) you can use a Subresource Integrity check instead of copying it. Suffusion of Yellow (talk) 19:26, 5 March 2026 (UTC)

Oh, looked at your userspace, I see the script in question is just a few lines long. Yeah, then it's probably better to just review and copy it. Suffusion of Yellow (talk) 19:28, 5 March 2026 (UTC)

The problem with forced safemode for intadmins is that they would no longer be able to run admin scripts like these because you are not permitted to have more than one account with admin permissions. SuperPianoMan9167 (talk) 19:30, 5 March 2026 (UTC)

I like scripts, so I'm sympathetic to that. But I see there's already an exception for WMF, how about another one for the baker's dozen of interface admins out there? Mlkj (talk) 19:45, 5 March 2026 (UTC)

See T419152 RoySmith (talk) 19:00, 5 March 2026 (UTC)

Cool, another feature request that can be ignored for the next 8 years. --Ahecht (TALK
PAGE) 19:09, 5 March 2026 (UTC)

I assume this is why my .js are not loading? - FlightTime (open channel) 19:24, 5 March 2026 (UTC)

Yes. RoySmith (talk) 19:28, 5 March 2026 (UTC)

And stop testing in prod. OhanaUnited^{Talk page} 19:26, 5 March 2026 (UTC)

It's not correct to say attack scripts was created in 2023. As written on wikireality.ru/wiki/РАОрг, they (or their earlier versions) more likely created in 2013. Also, their author, wikireality.ru/wiki/Скрипты_WikiUserFS, is still not blocked: https://ru.wikipedia.org/wiki/special:CentralAuth/WikiUserFS. MBH (talk) 20:00, 5 March 2026 (UTC)

• Noting that @Rhododendrites has started a discussion at the BLP noticeboard: WP:BLPN#Wikipedia:Village stocks and this morning's incident SuperPianoMan9167 (talk) 20:06, 5 March 2026 (UTC)

Post from WMF staff member on Discord:

Hey all - as some of you have seen, we (WMF) were doing a security review of the behavior of user scripts, and unintentionally activated one that turned out to be malicious. That is what caused the page deletions you saw on the Meta log, which are getting cleaned up. We have no reason to believe any third-party entity was actively attacking us today, or that any permanent damage occurred or any breach of personal information.

We were doing this security review as part of an effort to limit the risks of exactly this kind of attack. The irony of us triggering this script while doing so is not lost on us, and we are sorry about the disruption. But the risks in this system are real. We are going to continue working on security protections for user scripts – in close consultation with the community, of course – to make this sort of thing much harder to happen in the future. FaviFake (talk) 20:14, 5 March 2026 (UTC)

That still doesn't explain why they were running random scripts from an account with intadmin permissions. --Ahecht (TALK
PAGE) 23:15, 5 March 2026 (UTC)

huh?? Weren't they doing that just to test the limit of script imports, i.e., how many mw.loader.load()s they can do before something breaks? That's not a security review as part of an effort to limit the risks of exactly this kind of attack. Sure, call it a "security review," whatever, but how exactly is that relevant to limiting "exactly this kind of attack"? — DVRTed (Talk) 02:57, 6 March 2026 (UTC)

Surely not; there is no limit to how many mw.loader.load()s you can do, other than what your computer can handle. I think the review was to see how the scripts would handle changes to the Content Security Policy that would disallow loading some external scripts, which would indeed limit this kind of attack, and which were indeed deployed today as part of the response. Matma Rex talk 03:28, 6 March 2026 (UTC)

@Matma Rex Sure. Thx. Is there a phab ticket related to these changes to CSP? meta:Wikimedia Foundation/Product and Technology/Product Safety and Integrity/March 2026 User Script Incident is way too vague and says pretty much close to nothing as to why this incident occurred, so I'm just going off of whatever random thing I find people saying about it online. — DVRTed (Talk) 04:23, 6 March 2026 (UTC)

@DVRTed There doesn't seem to be one. I'm just going by the configuration changes I saw, e.g. [12]. Matma Rex talk 14:42, 6 March 2026 (UTC)

@DVRTed See phab:T419237 and its various parent tasks. --Ahecht (TALK
PAGE) 15:37, 6 March 2026 (UTC)

@OhanaUnited, Oshwah, PrimeHunter, and Ritchie333: Pinging a few random admins from this thread. Could someone please update the watchlist notice to link to this discussion? The notice currently reads Userscripts are temporarily disabled for security reasons but does not link to anywhere to provide context. I'm sure many users will be unaware of this thread unless it's linked in the notice. Zeibgeist (talk) 21:10, 5 March 2026 (UTC)

A link from the watchlist notice would be nice, but this thread (especially at the top) is a lot of people trying to figure out what's happening rather than a concise summary of what happened and what editors might need to know. Sdkb ^talk 21:12, 5 March 2026 (UTC)

Well we've pretty much already figured out everything. Ideally there should be a link pointing to the summary of the incident, but that's been deleted from the village stocks. FaviFake (talk) 21:15, 5 March 2026 (UTC)

The watchlist notice definitely needs to link somewhere. There are already threads at WT:NPP/R and the Teahouse with people confused about their userscripts being disabled. Linking to a centralized thread where that is being discussed is better than no info at all. Adding a couple more admins @Xaosflux and Ahecht: to get an opinion on this. Zeibgeist (talk) 21:19, 5 March 2026 (UTC)

@Zeibgeist Would linking to phab:T419154 be enough? — xaosflux ^Talk 21:59, 5 March 2026 (UTC)

Thanks for the prompt response. It looks like Oshwah has it handled. Zeibgeist (talk) 22:06, 5 March 2026 (UTC)

That doesn't seem unreasonable at all; stand by... ~Oshwah~^{(talk) (contribs)} 21:49, 5 March 2026 (UTC)

Zeibgeist -  Done. ~Oshwah~^{(talk) (contribs)} 22:04, 5 March 2026 (UTC)

Excellent, thank you! That will hopefully clear up some of the confusion. Zeibgeist (talk) 22:06, 5 March 2026 (UTC)

Wait, I have an idea for patching! An edit filter preventing pages from being deleted using automatic scripts. VidanaliK (talk to me) (contributions) 22:03, 5 March 2026 (UTC)

This would be a drastic overhaul of administrator workflow. It would also only address one type of action a malicious script can take -- I would think a solution to this problem should address the root issue of a script taking control, not just preventing damage in one or more ways. Giraffer (talk) 22:14, 5 March 2026 (UTC)

Or maybe requiring administrator approval for high-stakes tasks performed by automatic scripts? VidanaliK (talk to me) (contributions) 22:15, 5 March 2026 (UTC)

On a technical level once you have a script running it's hard to know whether the user or the script took the action. It's different from the bot API, because a script just uses your own web browser on your behalf. It can silently submit any form and click any button that the user has access to, and it'll look like the user did it. Mlkj (talk) 22:32, 5 March 2026 (UTC)

You can force people to reauthenticate through a page loaded in safemode, though, and a script cannot hijack that (if implemented properly). This would probably be a bit annoying (like it'd make intadmins put in their password every time they edit a sitewide js page), but perhaps worth it. Elli (talk | contribs) 22:36, 5 March 2026 (UTC)

Yeah, it's better that people have a slight inconvenience when performing automatic actions than a malware script from Russian Wikipedia in 2013 take over the Wiki and delete thousands of pages en masse. Restoring such pages is probably going to take even longer. VidanaliK (talk to me) (contributions) 22:39, 5 March 2026 (UTC)

I assume initadmins editing a sitewide JS page is an infrequent enough event that requiring a re-authentication would not be an excessive burden.

The trick with these sorts of things is to make them painless enough that people don't invest effort to find ways around them. In the command-line world, there's the "sudo" command which requires a reauth before allowing somebody to do dangerous things. A well-configured setup will make doing the right thing easy enough that people don't mind doing it. If you make it really painful, they'll start doing things like "sudo bash" and live in that shell all day (and when you disallow that, they'll find more creative ways around it). RoySmith (talk) 22:43, 5 March 2026 (UTC)

Yes. The best attack I can see against that is the risk of reauth/2FA fatigue. Wait until the user is about to click a button that will send them to the safemode reauth page and hijack the action to be "edit common.js" instead of whatever it was, or show a phishing reauth page (e.g. steal credentials, show a fake error, then display the real reauth page).

I like this idea though. I hope it's not too much work, I feel like we really need something more around sensitive actions like these. Mlkj (talk) 22:45, 5 March 2026 (UTC)

Noting that there is a statement about this incident on Meta, see Meta:Wikimedia Foundation/Product and Technology/Product Safety and Integrity/March 2026 User Script Incident. 45dogs (they/them) (talk page) (contributions) 00:30, 6 March 2026 (UTC)

Which strikes me as corporate-speak that explains much less than is explained on this thread. - Jmabel | Talk 01:14, 6 March 2026 (UTC)

True, true. I was pissed that Reftoolbar wasn't working, and reading this live thread (before the resolution) I could bear the pain.;-) Carlstak (talk) 02:28, 6 March 2026 (UTC)

@Jmabel and Carlstak: Well, anyone can edit it, but I wouldn't go any further with it than I just did. Graham87 (talk) 03:32, 6 March 2026 (UTC)

Well, that's not very far. It may be accurate as far as it goes, but it sounds like boilerplate. Needs one of those people who love to add plots to WP movie articles to write up a summation of the thread. Carlstak (talk) 07:02, 6 March 2026 (UTC)

I subsequently got reverted anyway. Meh ... there was an edit button there. Graham87 (talk) 08:09, 6 March 2026 (UTC)

@Jmabel: It's called "need-to-know". If you need to know exactly what happened, they will have told you already. If they've not told you, you don't need to know. As with any security issue, the fewer details that are public, the less likely it is to occur again. See also WP:BEANS. --Redrose64 🌹 (talk) 09:15, 6 March 2026 (UTC)

@Redrose64: sorry, I'm not buying it. The discussion here is totally public, and black-hat types will find it and absorb it. There is no security advantage in failing to say that a "bomb" script lay around, visible, for over a year, no one in the community noticed it, and a WMf employee (one involved in security, no less) accidentally triggered it. - Jmabel | Talk 16:29, 6 March 2026 (UTC)

Syntax Highlighter broken?

The Syntax Highlighter gadget was working yesterday, but today it no longer works in Brave Web Browser. I tried it on two different systems, one running Microsoft Windows 11 and the other Linux Mint 22. The gadget still works in Firefox. I have made no changes to the settings in my Wikipedia account and the browser was not updated on either machine. What gives? — Foxtrot1296 (talk) 19:58, 5 March 2026 (UTC)

@Foxtrot1296: See the "Meta-Wiki compromised" thread above. BD2412 T 20:04, 5 March 2026 (UTC)

The Syntax Highlighter I'm assuming that Foxtrot1296 is referring to is not a user script or gadget; it's a MediaWiki extension. So the above discussion will not provide any answers. SuperPianoMan9167 (talk) 20:11, 5 March 2026 (UTC)

There are multiple syntax highlighters. Some of them are actually JS gadgets. * Pppery * _{it has begun...} 20:19, 5 March 2026 (UTC)

If the one Foxtrot is using is a gadget, it shouldn't be working in any browser at all. But since it's working in Firefox, I think they're talking about the built-in one. SuperPianoMan9167 (talk) 20:28, 5 March 2026 (UTC)

Please note that Foxtrot1296 has User:Foxtrot1296/common.js, which will not be run for the time being (for the reasons above). Foxtrot1296, if there's a gadget at Preferences → Gadgets that will perform the same function, you should enable that instead. --Redrose64 🌹 (talk) 22:22, 5 March 2026 (UTC)

Syntax Highlighter is now working again in my account. The malfunction was most likely due to the Meta-Wiki security compromise. Thanks for all your responses. — Foxtrot1296 (talk) 04:07, 6 March 2026 (UTC)

Manual archive button not working on talk pages?

Just wondering if anyone else has run into this issue. I have "User:Elli/OneClickArchiver.js" installed on my common.js but today the archiving link has gone missing from actual talk pages. - Shearonink (talk) 20:21, 5 March 2026 (UTC)

All user scripts and gadgets are currently disabled. See #Today's outage above. SuperPianoMan9167 (talk) 20:22, 5 March 2026 (UTC)

@SuperPianoMan9167: Gadgets enabled at Preferences → Gadgets are all still working for me. --Redrose64 🌹 (talk) 22:27, 5 March 2026 (UTC)

Right, I still have Edit Conflict which I used recently. VidanaliK (talk to me) (contributions) 22:30, 5 March 2026 (UTC)

That explains why Twinkle (but not TwinkleMobile) is still working for me. It seems that gadgets are working again. SuperPianoMan9167 (talk) 22:35, 5 March 2026 (UTC)

Ok, read most of the "today's outage" section. I sort of understand it but wanted to mention that the Archive functionality for talk pages (from a script installed on common.js) is still not restored/working. - Shearonink (talk) 23:16, 5 March 2026 (UTC)

That's because scripts are still disabled. Headbomb {t · c · p · b} 23:27, 5 March 2026 (UTC)

See, I had missed that tidbit. Thanks for the news. - Shearonink (talk) 23:54, 5 March 2026 (UTC)

T419154 was just updated with "Most user JS scripts should be working again". RoySmith (talk) 00:14, 6 March 2026 (UTC)

And to head off the inevitable question: no, I don't know what "most" means. RoySmith (talk) 00:14, 6 March 2026 (UTC)

Based on the config settings which were changed during the incident and haven't been reverted, it seems that it refers to the fact that the Content Security Policy for Wikimedia sites has been changed and will now prevent some scripts from external domains from being loaded. I think Scott's ill-fated testing of user scripts was actually meant to determine how many of them would be affected by these new CSP rules (as hinted in #c-FaviFake-20260305201400-Nardog-20260305153100). I would guess the security folks are not as confident as they'd like to be about this accelerated rollout, but a lot of testing has gone into it already, so… most scripts should be fine. Matma Rex talk 02:45, 6 March 2026 (UTC)

userscripts were temporarily disabled but they should work again Laura240406 (talk) 00:33, 6 March 2026 (UTC)

Thanks everybody. Yes, the archive script is working again. Huzzah! - Shearonink (talk) 00:54, 6 March 2026 (UTC)

Stats at page top

Not sure what you call this, but at the top of every page, we usually have an update on things like how many page viewers, etc. That's been missing in the last couple of days. — Maile (talk) 20:47, 5 March 2026 (UTC)

See #Today's outage. Headbomb {t · c · p · b} 21:24, 5 March 2026 (UTC)

Thanks for the info. — Maile (talk) 21:40, 5 March 2026 (UTC)

Looks like the issue has just teen taken care of. Hooray, ! — Maile (talk) 22:12, 5 March 2026 (UTC)

"Hide top contributions" no longer working?

I guess there was some kind of upgrade since Wikipedia was "read only" for a bit today. Since then I have not been able to use the "Hide top contributions" function on my history (User:Markhurd/hidetopcontrib.js - this user hasn't edited since 2017 [edit: they are deceased apparently]). I use this a lot to keep track of vandalism on particular articles. Is there a way to bring it back? I'm not a coding person so I wouldn't know how to fix it myself. ... discospinster _talk 22:32, 5 March 2026 (UTC)

discospinster, this is another side effect of the read-only issue – all users' .js/userscripts are currently disabled. The Phabricator task says they should hopefully be back soon. Perfect4th (talk) 22:39, 5 March 2026 (UTC)

(edit conflict) discospinster, userscripts are currently disabled. See Wikipedia:Village pump (technical)#Today's outage. 45dogs (they/them) (talk page) (contributions) 22:41, 5 March 2026 (UTC)

Thank you @Perfect4th: and @45dogs:, I did not know about this issue. ... discospinster _talk 22:58, 5 March 2026 (UTC)

Hello, and please don't shame me publicly for asking this if already answered above, but my anxiety impedes my understanding in such a long thread. Help me with my paranoid-ish OCD problem: is there any risk now if I was logged in when the attack took place? How do I know if everything is clean? Thanks, and I do know it is more pathological of my mind than real, but if anyone can bring relief to my mental health, I tenderly appreciate it. --CoryGlee 00:37, 6 March 2026 (UTC)

Nope, everything has been patched now! VidanaliK (talk to me) (contributions) 00:41, 6 March 2026 (UTC)

Thanks. As stupid or immature it may sound, a reaffirming word clears the dark skies of a (my) mind. LOL. CoryGlee 00:43, 6 March 2026 (UTC)

Of course! I get super paranoid sometimes too. VidanaliK (talk to me) (contributions) 00:48, 6 March 2026 (UTC)

What just happened?

Has the JS/user script vulnerability been addressed? Holy hell. I think we seriously need guardrails regarding user scripts. --- n.h.huit 04:15, 6 March 2026 (UTC)

@.nhals8 Unsurprisingly this wasn't really a userscript problem but more a PEBKAC problem. It's fixed. Polygnotus (talk) 12:42, 6 March 2026 (UTC)

A failed Interwiki link

en:Pozzato and it:Pozzato are essentially the same. The overlap isn't complate, but they're both surname pages. On attempting to create an Interwiki link in either direction, I get the error messge "Could not link pages: failed to merge corresponding Items on Wikidata. Attempted modification of the Item failed." in the en:it direction and "The save has failed. The link enwiki:Pozzato is already used by Item Q56245816. You may remove it from Q56245816 if it does not belong there or merge the Items if they are about the exact same topic. If the situation is more complex, please see Help:Sitelinks." Can anyone resolve this silly problem? I have zero interest in learning how to do this trivial piece of useful housekeeping.Narky Blert (talk) 19:44, 5 March 2026 (UTC)

I added it manually. No issue reared its head. BD2412 T 20:04, 5 March 2026 (UTC)

@Narky Blert: The English article is linked to the Wikidata item for the family name, whereas the Italian is linked to the one for the disambiguation page. Per the "different from" statement, "family name has to use a different item than disambiguation page". This mutually exclusive criterion is probably why the merge failed.

Per WP:SETNOTDAB, the English article should not be moved to the Wikidata item for the disambiguation page. The Italian article is categorised as Pagine di disambiguazione, so also seems to be at the right item. I'm unsure if the Italian Wikipedia has the same distinction between set indices and disambiguation pages. Wikipedia:Set index articles and {{Set index article}} don't appear to have versions on the Italian Wikipedia (or if they exist, they don't share a Wikidata item). – Scyrme (talk) 20:15, 5 March 2026 (UTC)

Missing talk page history?

I feel certain that there have been discussions at Turkish Roma of the terminology used to discuss the group that's the article's topic, and possibly even a prior move discussion. Following a move war that I hope I just put an end to, the article's back at Turkish Roma, where it has been since September 2022, but the talk page has nothing but WikiProject banners on it. Did something get lost somewhere during or before the move war? I can't figure out where to look. Largoplazo (talk) 23:22, 5 March 2026 (UTC)

Are you sure there were in fact any such discussions? DS (talk) 00:48, 6 March 2026 (UTC)

OK, never mind, I found what I'd been thinking of. It did include discussion of naming with respect to Turkish Roma in particular, but it was an overall more general discussion, a move discussion that's now at Talk:Romani people/Archive 13. Largoplazo (talk) 01:11, 6 March 2026 (UTC)

I'm not sure if this is what you were looking for: Talk:Turkish Romani. I used the Special:PrefixIndex/Talk:<page> on existing redirects in case some archive subpage was not moved and I didn't locate one, but have noticed this. ~2026-10830-00 (talk) 01:19, 6 March 2026 (UTC)

It appears there was a WP:HISTMERGE given the oldest revision is a move from Turkish Romanian to Turks of Romania yet the next is a move from Turkish Romanian to Turkish Romani 14 years later. Nardog (talk) 03:51, 6 March 2026 (UTC)

I noticed those long-ago moves while going through this but didn't take the time to investigate. The move from "Romanian" to "Romani" seems suspicious, unless the situation was that the article was written by someone who didn't the difference in English between Romanians and Romani and had used the wrong term, followed by someone fixing it. I'll try to take a look later if curiosity gets the better of me. Largoplazo (talk) 13:19, 6 March 2026 (UTC)

Fix self-linking

If somebody understands how to, can you please fix the "MAGA Inc." not to appear as link in this section (I tried using the {{#section}} template but didn't get it to not self-link that): Make America Great Again Inc. # "Pay-for-Access" Or does use of Template:No self link make sense here? D4n2016 AMD  RYZEN  ZEN 3 user Talk 03:02, 6 March 2026 (UTC)

{{No self link|MAGA Inc}} fixed it. PrimeHunter (talk) 03:28, 6 March 2026 (UTC)

Template-defined text colours in dark mode

I've noticed on several sidebar templates that black text becomes white in dark mode, even if the template has color:black set in its style parameters. Adding the class skin-invert inverts everything except the text, which stays white. Adding class mw-no-invert instead has no effect, and the text is still white. Adding {{black}} directly to the title/heading makes it black, but adds a white background because for some reason that template also uses background: white.

An example of such a template is {{Tibetan Buddhism sidebar}}, where the white headings are difficult to read in dark mode because the background is light.

Is there a way to fix this without throwing out their styles and making every sidebar use dark background or stripping it down to the default so dark mode works as intended? Given {{black}} somehow accomplishes making the text black when the background is white, surely this is possible? Or does it only work with white? Would this require changing something about how dark mode itself is implemented to fix? – Scyrme (talk) 08:40, 6 March 2026 (UTC)

The mw-no-invert class isn't part of the dark mode that is available in the default skins, as indicated on top of the page of the extension that uses that class. I would recommend to follow-up the instructions on mw:Recommendations for night mode compatibility on Wikimedia wikis instead. Sjoerd de Bruin (talk) 08:44, 6 March 2026 (UTC)

@Sjoerddebruin: Copying pane notheme mw-no-invert from the "good example" listed there seemed to work. However, I also found that notheme by itself worked. Do you happen to know why the other two classes are included? I'm particularly unsure what pane is for. – Scyrme (talk) 09:09, 6 March 2026 (UTC)

Using color:var(--color-base,#202122); instead of color:black often has the desired effect. – Jonesey95 (talk) 14:25, 6 March 2026 (UTC)

In addition to the styles you see in various places over here, there are styles sitting on top of everything that come with the software itself, see here. Ponor (talk) 10:30, 6 March 2026 (UTC)

Sidebars are unaffected by anything in the relevant CSS. Izno (talk) 17:19, 6 March 2026 (UTC)

{{sidebar}}s support |templatestyles= and should use that as a solution if you want to guarantee them to appear a certain way. (There is a category for someone who wants to convert styles to TemplateStyles but personally it is the lowest of any low priorities.) Izno (talk) 17:18, 6 March 2026 (UTC)

Finding more malware

Has anyone bothered search all Wikipedia's for more naughty scripts, e.g. scripts that contain the string "nuke" or "action=delete"? Also scripts with obfuscated stuff like percent encoded stuff. Polygnotus (talk) 16:35, 6 March 2026 (UTC)

There are about 40 such scripts on English Wikipedia containing the word nuke. You may consider global search if you want to review others. Izno (talk) 17:15, 6 March 2026 (UTC)

@Izno Thanks! But it looks like I can't use global search to detect percent encoded Javascript by searching for the percent encoded versions of strings commonly found in Javascript (like var and let). Do you happen to know how to do that? SQL? Looping over each endpoint using insource:? Polygnotus (talk) 17:29, 6 March 2026 (UTC)

External images still not loading for my user styles

I have custom user styles that decorates the interface with images hosted elsewhere. However, even after user scripts were re-enabled after the incident, the images are still not loading. What can be done? My user styles' code can be accessed at User:PrincessPandaWiki/common.css and User:PrincessPandaWiki/vector.css. ❤︎PrincessPandaWiki (talk | contribs) 17:06, 6 March 2026 (UTC)

Yes, these are due to the CSP that has been enabled as a result of yesterday (but which was coming regardless). Your only recourse is to request these websites be allow-listed on phab:. I do not anticipate your success given the specific domains of interest. Izno (talk) 17:11, 6 March 2026 (UTC)

Mobile site is forced

I'm on a Chromebook and can't figure out how to get the desktop version of Wikipedia. It won't let me change skins, and all my edits are tagged with "mobile edit". --FishOnSkates 17:17, 6 March 2026 (UTC)

@FishOnSkates: Click "Desktop view" at the bottom of a page. In some browsers you may have to scroll to the bottom of the page a second time to see it. PrimeHunter (talk) 17:24, 6 March 2026 (UTC)

@FishOnSkates also if you want to make it permanent on all devices detected as mobile see User:Þjarkur/NeverUseMobileVersion as an option. Cheers KylieTastic (talk) 17:36, 6 March 2026 (UTC)

Strange hashtag

Hello. I'm testing something with templates and subtemplates, #switches and #ifs, (not on en:wiki, sorry) and then when I use a parameter like this |color=#ccffcc in an article, it doesn't appear as the lightgreen cell background, but as follows:
style="background:

1. ccffcc;"

I think my code is pretty good because when I use, for example |color=green, everything is fine. Parameter |color=#ccffcc also works, but that's not the solution I want. Do you know of any trick to fool that strange hashtag? Thanks, Maiō T. (talk) 17:44, 6 March 2026 (UTC)