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.
For a listing of ongoing discussions, see the dashboard.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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?
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)[reply]
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)[reply]
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)[reply]
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 MarshallT/C 12:02, 25 February 2026 (UTC)[reply]
@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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
I have to disagree. I don’t think that is consistent with the consensus condition. It took me a long time to get rid of the damn thing. I am not a power user by any means. I was poking at random before it finally went away. Mr Serjeant Buzfuz (talk) 16:05, 8 March 2026 (UTC)[reply]
ETA: I think it would have been consistent with consensus if, for editors who had clicked that option, it meant that both the globe and the turn-off button did not show. But by splitting it, so the globe always showed, but not the turn-off button, it failed to meet the consensus, in my opinion. Mr Serjeant Buzfuz (talk) 16:43, 8 March 2026 (UTC)[reply]
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)[reply]
Baby globe is cute, a great PR campaign, and easily turned off. Open up Ursula K. Le Guin in a private/incognito browser (so that you're logged out) and you'll see how prominent and easy it is to turn it off as a reader (which is who this campaign is targeting and who Wikipedia is for). If you've hidden that menu, or didn't pay attention to the discussions about turning it on, I don't see how that's the dev's fault. With that said, I do think it would have been nice if the baby globe images themselves were clickable and linked to[1]; as that would not only explain the point, but also how to turn it on/off. If we can iron out the details a bit, I'd like to see baby globe used in the future, perhaps for other anniversaries, so I'd hate to see baby globe entirely fall by the wayside. CaptainEekEdits Ho Cap'n!⚓ 19:35, 8 March 2026 (UTC)[reply]
They are cute indeed. Unfortunately they do not move, at least on some browsers, I think, until you turn them off and on again on every current page. IKhitron (talk) 09:17, 9 March 2026 (UTC)[reply]
In response to this statement by Captain Eek:
Open up Ursula K. Le Guin in a private/incognito browser (so that you're logged out) and you'll see how prominent and easy it is to turn it off as a reader (which is who this campaign is targeting and who Wikipedia is for). If you've hidden that menu, or didn't pay attention to the discussions about turning it on, I don't see how that's the dev's fault.
But here's the closure statement, which I would say sets out the instructions to the developers:
in deference to the opposition to this idea, please place a reasonably prominent button to disable it. To the maximum extent possible this button should appear on every page where birthday mode affects the user experience
In my opinion, the developers have not complied with the instruction to have a reasonably prominent disable button "on every page where birthday mode affects the user experience". Mr Serjeant Buzfuz (talk) 01:26, 10 March 2026 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
@David10244 and Largoplazo: Yes, I meant hover text in mobile view. If you don't have a way to display hover text then try holding for a second on the blank line above | script. I get a box with a url ending with #movedpara_5_0_rhs. This indicates a paragraph was moved. Tapping on the blank line jumps to the new location of the paragraph (where colored backgrounds show that ancestor2 was changed to ancestor3). It's annoying that the indicator is missing on the blank line so you have to guess there may be something there. PrimeHunter (talk) 10:13, 7 March 2026 (UTC)[reply]
Inline diffing doesn't handle moves correctly
If you move content on a page, viewing this using the mobile web differ or the inline desktop differ doesn't display the content move. See Special:Diff/1342472377 - the moved content is duplicated with no indication that a move occurred. Nixinova T ⁄ C 03:45, 9 March 2026 (UTC)[reply]
Theres also already css classes present for both inline-moved-source and inline-moved-destination, so they can be styled/coloured distinctly. Nixinova T ⁄ C 05:20, 9 March 2026 (UTC)[reply]
@Ponor: It works and you can place it in Special:MyPage/minerva.css for yourself. For sitewide in MediaWiki:Minerva.css, somebody may complain it uses !important or say we should wait for a MediaWiki fix. The page can only be edited by interface administrators , not normal administrators like me. PrimeHunter (talk) 15:10, 9 March 2026 (UTC)[reply]
Oh yes, I was supposed to ping @Izno. Since there’s a toggle for inline diff mode on desktop, it’d be worth adding this to both CSS pages because of the confusion the bug can cause. MediaWiki fix may take another few years. Ponor (talk) 15:31, 9 March 2026 (UTC)[reply]
@Ponor: The inline diff mode on desktop does display the arrows, at least for me in the skins I tried. Are you suggesting we add sitewide CSS preemptively in case it breaks later like mobile? I don't support that. PrimeHunter (talk) 15:41, 9 March 2026 (UTC)[reply]
@PrimeHunter You're right. I only checked the above diff on my phone in desktop mode, I guess the two icons were too small to notice. This is only needed in Minerva.css. Ponor (talk) 16:07, 9 March 2026 (UTC)[reply]
Ah, my task is mostly aimed at what happens on desktop. You are missing the indicators and the solution is an adjustment in CSS on mobile, I would suggest making a new task. It may be seen to sooner rather than later.
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)[reply]
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)[reply]
@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.
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)[reply]
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)[reply]
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.
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.
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)[reply]
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)[reply]
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.
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)[reply]
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′N3°23′E / 49.017°N 3.383°E / 49.017; 3.383, (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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I have also run into this issue in infoboxes that I use, where the map is inserted automatically. There is no obvious way to prevent the map from appearing, even if the editors of the page don't think the page is value-added. Yes, in some cases, a map may be helpful, but in other cases it may not be. That should be a decision made by the editors of that page, not by a hidden technical function that is not explained anywhere for the average non-tech editor. Mr Serjeant Buzfuz (talk) 17:42, 7 March 2026 (UTC)[reply]
Do you use the source editor or the visual editor? Most templates supply the data to the visual editor that makes these sorts of things much more obvious. Sadly the source editor doesn't seem to make use of this. --Joy (talk) 17:50, 7 March 2026 (UTC)[reply]
Image thumbnails often failing to load
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)[reply]
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)[reply]
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 Rextalk12:15, 5 March 2026 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Cremastra, Another hacker with Russian as their language of choice, I see. That strongly suggests it wasn't the Russians. — Alexis Jazz (talk or ping me) 21:29, 6 March 2026 (UTC)[reply]
And did I say anything about the actual origin of the malicious script? No. I certainly don't think the Russians are bothering to hack Wikipedia. Cremastra (talk· contribs) 21:44, 6 March 2026 (UTC)[reply]
And did I say anything about you saying anything about the actual origin of the script? No. — Alexis Jazz (talk or ping me) 04:34, 7 March 2026 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
(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)[reply]
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)[reply]
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)[reply]
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)[reply]
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: [3]. In one edit, he loaded Ololoshka's script: [4] and ran it. Source: https://phabricator.wikimedia.org/T419143FaviFake (talk) 17:31, 5 March 2026 (UTC)[reply]
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)[reply]
@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)[reply]
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. CutlassCiera19:43, 5 March 2026 (UTC)[reply]
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)[reply]
The malicious code would also WP:NUKEall 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)[reply]
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.
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
I was wondering why the gadgets like DYK Check, Cite Unseen, etc. are not working. Just came to know this, sad! M.Billoo18:23, 5 March 2026 (UTC)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 Rextalk03:28, 6 March 2026 (UTC)[reply]
@Janhrach That is basically irrelevant because to an attacker a local attack is easier than dealing with CSP. This wasn't an attacker, this was just some script someone had laying around. Polygnotus (talk) 22:13, 6 March 2026 (UTC)[reply]
@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)[reply]
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. Sdkbtalk21:12, 5 March 2026 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
@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 | Talk16:29, 6 March 2026 (UTC)[reply]
Yes, the discussion here is public, but parts of it perhaps should not be. I also see a number of comments that are factually incorrect: people not in possession of the facts should not be offering opinion on what might have happened. I have made previous posts on a similar theme, they may be found in the archives at Archive 163 (12 February 2018) and Archive 206 (31 May 2023). --Redrose64 🌹 (talk) 18:59, 6 March 2026 (UTC)[reply]
Talking about beans when the top post of hacker news was exactly what happened seems a little silly. Cats out of the bag. Bawolff (talk) 01:01, 7 March 2026 (UTC)[reply]
In the need to know essay you link to, it states If you have concerns about the reasoning for something, there are procedures for questioning a decision without publicizing private information. This does not appear to be the case. Instead, the details of what happened appear to be hidden without any recourse for challenging the decision to hide these details. Instead of claiming a security issue over every issue in existence, perhaps a more transparent approach would be a better path forward. EggRoll97(talk) 06:04, 7 March 2026 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 Rextalk02:45, 6 March 2026 (UTC)[reply]
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)[reply]
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. ...discospinstertalk22:32, 5 March 2026 (UTC)[reply]
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)[reply]
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. --CoryGlee00:37, 6 March 2026 (UTC)[reply]
Has the JS/user script vulnerability been addressed? Holy hell. I think we seriously need guardrails regarding user scripts. --- n.h.huit04:15, 6 March 2026 (UTC)[reply]
If they still aren't working it's likely due to Content Security Policy (CSP) issues. It's a thing that restricts the websites your code can interact with. Are allowed wikimedia projects, toolforge, and some other things for convenience. Check if you've got any CSP errors in your console, and if you do, either try to get those external urls allowlisted or stop using them.
Thank you!! I do 99% of my editing on a tablet with no access to a console so very hard to check for console errors. That really helps! Thank you! Zackmann (Talk to me/What I been doing) 16:50, 7 March 2026 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
Thanks for the suggestion. Unfortunatey, I gave it at try in an older revision of {{Tibetan Buddhism sidebar}} from before I changed its class to override dark mode, and it had no effect on the list title headings. They were still white on yellow and hard to read. I replaced every copy of color:black in every parameter just to be sure, but it still didn't do anything. I also then tried changing #202122 to #000000, in case setting it to pure black made a difference somehow. Still no luck. – Scyrme (talk) 02:00, 7 March 2026 (UTC)[reply]
I don't understand the magic that happens that sometimes makes the above code do the right thing and sometimes not, apparently depending on the lightness or darkness of the background color. color:var(--color-base-fixed,#202122); is sometimes necessary to prevent text from turning white in dark mode. I don't know if the developers just didn't create enough test cases, or if there is something I don't understand (probably both, with the emphasis on the latter). – Jonesey95 (talk) 13:28, 7 March 2026 (UTC)[reply]
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)[reply]
{{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)[reply]
I had wondered if converting would help, but I'm not familiar enough with .css to be comfortable attempting a conversion. I'm also not sure if it'd be effective. It looked like it the styles.css approach would still just use color:black. Is it processed differently in some way? Has anyone attempt it who can confirm the conversion works for fixing this issue? – Scyrme (talk) 02:10, 7 March 2026 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
Offtopic
Which is stupid because the malicious script didn't load any external scripts except jQuery (which is included in MediaWiki anyway). sapphaline (talk) 18:43, 6 March 2026 (UTC)[reply]
The user script did not load anything from cyclowiki.org. Data from this URL was loaded in what was inserted into hacked users' common.js, but it was just a filler (the only relevant lines there were 1-5). sapphaline (talk) 21:00, 6 March 2026 (UTC)[reply]
Yes, there are. A data:image/png; URI is not a link to an image, it is an image. There's little use for a data: URI except perhaps to speed up page loads. Just upload the image, then point your CSS to upload.wikimedia.org. If uploading isn't allowed for copyright reasons, then base64 encoding obviously won't make it freely licensed. Suffusion of Yellow (talk) 19:52, 6 March 2026 (UTC)[reply]
I recently had to convert images in several of my user scripts/css to data URIs after WMF restricted the sizes of thumbnails they would serve. Seemed better than uploading "same image but 10px" copies of things. Anomie⚔08:23, 7 March 2026 (UTC)[reply]
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)[reply]
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:
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)[reply]
@Habitator terrae: It's a tracking parameter so MediaWiki knows how you came to the article. It can for example be used to make statistics about how articles are reached. I don't get it in my searches so maybe you are in a group selected for an experiment. Thanks for deactivating the link. It may tarnish an experiment if many people follow the link without coming from search. PrimeHunter (talk) 18:20, 6 March 2026 (UTC)[reply]
I've found an image on Wikimedia commons that I want to use on Wikipedia, but this image is on page 92 of a pdf and File:Transactions of the Cumberland & Westmorland Antiquarian & Archaeological Society (IA transactionsofcu08cumb).pdf&page=92 doesn't display that page. I'm assuming I could download the pdf, edit it and upload individual pages to commons. But is there a way to display the pdf at page 92 rather than the default of displaying page 1? ϢereSpielChequers08:33, 7 March 2026 (UTC)[reply]
Hi, there is a template for the infobox for decisions of the Supreme Court of Canada: Template:Infobox SCC. We're having a discussion on Wikipedia talk:Canadian Wikipedians' notice board about making changes to it, to eliminate terminology that is actually US based and substitute Canadian legal terminology. How would we go about getting changes made? The template is used on 500+ articles, so we would want to be careful about making any changes. Any help would be appreciated. Mr Serjeant Buzfuz (talk) 17:22, 7 March 2026 (UTC)[reply]
"p-namespaces" portlet menu on Vector legacy (2010)
They seem to have removed the "p-namespaces" portlet menu from the legacy Vector skin; when and why? I noticed this when I realized that one of my scripts was broken because addPortletLink failed.
This is what $('.mw-portlet').toArray().map((el)=>el.id); returns: (12)['p-personal','p-associated-pages','p-variants','p-views','p-cactions','p-navigation','p-interaction','p-tb','p-coll-print_export','p-wikibase-otherprojects','p-lang','p-dock-bottom'] — DVRTed (Talk) 17:43, 7 March 2026 (UTC)[reply]
@DVRTed: I don't know why you mention "p-namespaces". It doesn't occur in your userspace. Your addPortletLink code is:
Oh, I forgot to put the permalink and edited the script after posting here, but thanks for the links! I think "p-associated-pages" is not supported on all skins either because the docs linked above says (For namespaces and special page tabs on supported skins), so I guess it's better to use another one. Seems like quite a few userscripts that'll silently stop working on legacy Vector now: regex search (not accounting for querySelector and dynamic id). — DVRTed (Talk) 21:30, 7 March 2026 (UTC)[reply]
I recently tried to add archived sources to locations where the Wayback Machine couldn't archive them automatically, but I was prevented from finishing the edit. Is there any way to do this? Svartner (talk) 16:15, 8 March 2026 (UTC)[reply]
What were the sources? If they were news articles, sometimes you get lucky and the same articles have been widely distributed via a news agency like Reuters. Those can often be archivable via the Wayback Machine on another news website. – Scyrme (talk) 02:49, 10 March 2026 (UTC)[reply]
Is there a way to search for edit summaries (e.g., all edit summaries in the mainspace during the last month)? I'd like to have a list of diffs in which the edit summary mentions WP:ONUS (the shortcut). WhatamIdoing (talk) 03:15, 10 March 2026 (UTC)[reply]
How do I remove the title from a legendbox in {{OSM Location map}}? In its documentation, a "centred title line" which I presume refers to this, is described as "optional". Simply removing <b>Divisions</b>, from |legendBox=, in the examples at right, breaks it. — AFC Vixen 🦊 07:35, 10 March 2026 (UTC)[reply]
@AFC Vixen as the syntax for |legendBox= appears to be text, size, position [,background, text color, options] with each parameter delimited by a comma, try leaving text out but leave the delimiting comma in; so your entry would start |legendBox=, 100px ...Nthep (talk) 08:20, 10 March 2026 (UTC)[reply]
Mockup of saved articles page on desktop English Wikipedia.
We are experimenting with potential improvements to the reader experience because of declining pageviews to Wikipedia and fewer readers returning to the site. We think by strengthening the connection between existing readers and Wikipedia, we can help reverse these trends and help engage potential future editors. One way to build that relationship is by giving readers more ways to shape their reading experience. Reading lists will allow for that participation by giving logged-in readers the option to save articles they want to come back to later in a list accessible in their account. The feature is already highly utilized on the Apps, where it has contributed to improved reader retention.
The experiment went live on Arabic, Chinese, English, French, Indonesian, and Vietnamese wikis in November, where we collected data for eight weeks on mobile and desktop. The experimental feature included:
Options for logged-in readers to save articles to a private list for reading later.
Ability for logged-in readers to access their list and delete articles that are no longer relevant.
What did we find?
The feature had good engagement. Our primary success metric was the clickthrough rate (CTR) on the save article icon. CTR measures how often readers engage with the feature, helping us understand whether people notice it and choose to use it. Typical web CTR is between 1-5%, but can be much lower for features which require an active or participatory action from the user. On English Wikipedia, we observed a clickthrough rate of 0.88% for the “save” button in the reading list experiment. This aligned with our expectations for the feature. Because saving an article reflects a specific intent through participation — returning to that article later — we did not expect engagement rates comparable to more general navigation actions.
Readers create accounts, but need reading focused features to sustain them. Our experiment was intentionally limited to a fraction of all readers who are not editors so we wouldn’t interfere with existing editing and moderation workflows. As a result, very few people saw the feature, making the exposure rate of the experimental feature too low to give conclusive evidence on how reading lists on web affect user retention. This was a helpful finding for us: currently, readers who do not edit do not have much reason to have an account, since most logged-in features on Wikipedia are designed for editors. The test helped us better understand how reader-focused features may reach a distinct audience of account holders who engage with Wikipedia differently than editors. For this reason, we are trying out a beta feature before full rollout so we can learn more about user retention with this feature with a larger audience.
Reading list users are active readers. Additionally, we found that readers that engaged with the feature had much higher rates of internal referrals – that is, that is, they more frequently navigated to other pages on Wikipedia. While this relationship is correlational rather than causal, it suggests that readers who already tend to spend more time exploring Wikipedia find particular value in this feature.
What are we doing next?
Based on the results above, we believe that reading lists is a feature readers are interested in and would like to collect more data on how people use it. To do this, we are planning on releasing reading lists on the desktop and mobile websites as a beta feature for logged-in readers.
To increase exposure among readers we will enable the beta feature for all new accounts. Existing users will be able to turn reading lists on manually in the beta section of their user preferences. We will be collecting feedback via QuickSurveys on whether beta users find it to be useful.
Screenshot of reading lists beta feature setting page.
We’re planning on the following timeline:
Week of April 6: Release the feature on Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias.
April 6 - April 20: Monitor and fix any bugs.
Week of April 20: Release to all other Wikipedias.
We encourage you to try out the beta feature and give us feedback on-wiki or via the survey. Additionally, we want to hear more from you. Do you have any other ideas for reading lists based on this information? Please share your thoughts and questions here. For more info, see our project page.
To support current active readers on the wikis in their goals of learning from Wikipedia, we want to experiment with allowing readers to save articles to a list for reading later, helping them organize their knowledge while also building a practice of content curation that could pave the way for future contributions to Wikipedia.
Birthday mode (Baby Globe)
Resolved
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 18:14, 9 March 2026 (UTC) 
