Wikipedia:Village pump (technical)

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 five days.

view · edit

Frequently asked questions (see also: Wikipedia:FAQ/Technical)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218

Search text box on Timeless doesn't format correctly

So on timeless the search bar doesn't format correctly, when on the search bar specifically:

Vector works correctly however, and the search bar is correct when typing in top, only on while on a search page does the bug occurs. Des Vallee (talk) 07:18, 10 March 2025 (UTC)[reply]

I was 95% this has a task but it seems not to. Izno (talk) 05:26, 12 March 2025 (UTC)[reply]

Is this going to be fixed? I deal with it constantly and it can make it hard to see the text I typed. It also seems like a pretty easy fix. Des Vallee (talk) 09:57, 17 March 2025 (UTC)[reply]

@Izno: Des Vallee (talk) 07:54, 18 March 2025 (UTC)[reply]

You may file a task for it, see WP:Bug reports. Izno (talk) 17:35, 18 March 2025 (UTC)[reply]

Done. Des Vallee (talk) 13:18, 19 March 2025 (UTC)[reply]

Semi-protected talk pages crash

Whenever I press Add topic on a semi-protected talk page(the talk page itself is protected, not the origin page) the browser crashes with error code Aw Snap SIGSEGV. This implies that the page was trying to edit a part of restricted memory. This does not happen on non-protected pages. I am using a Chromebook model name CR1104CGA updated to the latest version, and with browser version 126.0.6478.265 It seems that the computer that you are doing this on matters a lot as other computers, and even other Chromebooks do not give the same outcome. Caleb's World11 (talk) 19:39, 14 March 2025 (UTC)[reply]

Start with the instructions at Google Support and report back. Izno (talk) 21:56, 14 March 2025 (UTC)[reply]

@Caleb's World11 I'm having the exact same issue, except it's happening pretty much everywhere, including creating pages and protected non-talk pages. Gaismagorm (talk) 12:54, 17 March 2025 (UTC)[reply]

it looks like it doesn't always crash when creating pages, but it does always crash when editing protected articles Gaismagorm (talk) 13:22, 17 March 2025 (UTC)[reply]

Issue with editing any protected pages on Chromebook.

Hello, I have been having issues with editing any protected articles on my Barla chromebook. Whenever I attempt to edit it, it gives the "oh snap" error screen, with the "SIGSEGV" error code. I have tried shutting off my Chromebook, changing Wi-Fi, signing in and then out, clearing my cache/cookies, making sure my Chromebook version is up to date, and switching from visual to source editor. None of it worked. Some options are unavailable as this chromebook is run by an administration, so some features are not available.

P.S. Yes, I know that @Caleb's World11 posted on this forum with the same issue. It appears that discussion kind of went stale, so I'm relisting this. Gaismagorm (talk) 12:50, 18 March 2025 (UTC)[reply]

Have you tried freeing up space? And a hardware reset? Polygnotus (talk) 17:41, 18 March 2025 (UTC)[reply]

I tried freeing up space, didn't work. I'm gonna procrastinate on the second one since it will be a major hassle to deal with getting everything back to order once I reset the Chromebook, since, like I said, it is administration ran. Gaismagorm (talk) 18:02, 18 March 2025 (UTC)[reply]

@Polygnotus @Caleb's World11 I found a solution. If you switch from desktop to mobile view, editing works. Gaismagorm (talk) 18:09, 18 March 2025 (UTC)[reply]

~~@Polygnotus @Caleb's World11 it seems like the issue has been resolved. My best guess was that the server maitinence fixed it.~~ Gaismagorm (talk) 15:14, 19 March 2025 (UTC)[reply]

nevermind, it's not fixed. I don't know why I thought it was. Gaismagorm (talk) 15:15, 19 March 2025 (UTC)[reply]

Wide equations no longer scrollable on mobile site

Until recently, equations that extend beyond the width of the page in the mobile browser version of Wikipedia were horizontally scrollable. However, a recent update has removed this functionality, making such equations partially unreadable unless users switch to desktop mode. This affects articles with large LaTeX-rendered formulas, breaking accessibility for mobile users.

Steps to reproduce:

1. Open a Wikipedia article with wide equations (e.g., physics/math pages) in a mobile browser (Chrome, Safari, etc.).

2. Observe that the equation does not scroll and is cut off instead.

3. Switch to desktop mode, where the full equation becomes visible.

Expected behavior: Equations should be horizontally scrollable as they were before.

Could this be reverted or fixed to restore readability for mobile users? 204.144.182.17 (talk) 22:27, 15 March 2025 (UTC)[reply]

I don't remember the past behaviour but I can confirm visiting Navier–Stokes_equations#General_continuum_equations displays cut-off equations that I can't scroll on mobile. The long ones half way down that section. Commander Keane (talk) 23:47, 15 March 2025 (UTC)[reply]

This one has been looked at in T201233, and there's a patch up for review that should help with specifically wide Math content.

There's also a more general issue with wide content that's tracked in T361737, which is going to be more pronounced on mobile since the change last week that suppressed horizontal scrolling on the main content area. DLynch (WMF) (talk) 15:24, 19 March 2025 (UTC)[reply]

Archiving a source that verifies human before opening

There is schism between the governing bodies in the sport of kabaddi, and this article: https://www.dhakatribune.com/sport/other-sports/371289/a-kabaddi-world-cup-sans-bangladesh does a good job at explaining it. Thus, it's been used at multiple kabaddi-related articles and is vital to understanding the schism. Unfortunately, it does a human-check before you're able to access it, which means that no archiving website is able to make an archive out of it. I previously tried to find a solution at Help desk but it didn't help. So, is there any trick to go around the website's restrictions? —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:47, 16 March 2025 (UTC)[reply]

You could just download it yourself, passing the human verification and then upload it to the text portion of archive.org. Snævar (talk) 19:20, 16 March 2025 (UTC)[reply]

I have no idea how that works. @Snævar: Could you help? —CX Zoom[he/him] ^{(let's talk • {C•X})} 09:44, 17 March 2025 (UTC)[reply]

1. Get an account. 2. Print as PDF 3. s:Help:Internet_Archive#Adding_files, but ignore the OCR bit. Think of the OCR bit as a troubleshooting step if you can not select text in the pdf, which also makes it non-searchable. Snævar (talk) 13:53, 22 March 2025 (UTC)[reply]

That method works, though it depends on nobody taking the file down by the request of the site owner. There are other solutions at https://webrecorder.net/developer-tools/ for technical users. Basically you create a WARC of the page, host it on any web server with some JavaScript files, and there you go it will display and you are in control of it like your own private Wayback Machine. Example setup: https://replayweb.page/docs/embedding/#self-hosting -- GreenC 15:47, 22 March 2025 (UTC)[reply]

I can’t sign on my pc

So I type my password it’s says that I didn’t do the letter thing and when I copy and paste my real password and do the letter thing it says that I don’t have the right password so I do that 5 times and then it’s says that I have to wait 5 minutes like what? Therealbubble (talk) 21:54, 16 March 2025 (UTC)[reply]

What do you mean that you cannot sign on your PC? ‹hamster717🐉› ^{(discuss anything!🐹✈️ • my contribs🌌🌠)} 23:02, 16 March 2025 (UTC)[reply]

They probably mean sign-in, log-in, enter their account... for that matter 'the letter thing' sounds like a CAPTCHA.

The page Special:Captcha says a CATPCHA may show if you try to login soon after typing your password incorrectly, so it certainly seems like you (Therealbubble) might be typing your password incorrectly - but I don't have an account, so cannot confirm that there isn't always a CAPTCHA when logging in. – 2804:F1...95:6EBB (::/32) (talk) 01:37, 17 March 2025 (UTC)[reply]

They logged in using their mobile, their edit tag says so, but they have a problem logging in on pc. Snævar (talk) 10:22, 17 March 2025 (UTC)[reply]

Recently, the login system was changed, see mw:MediaWiki Platform Team/SUL3

Check if you are allowing cookies from auth.wikimedia.org, logins go through there now. Check your password manager, if you have one, and set the password to auth.wikimedia.org. Also open up your browser console and paste the contents from there. Snævar (talk) 10:25, 17 March 2025 (UTC)[reply]

Some password managers are now more proactive in offering passwords you use on other Wikimedia sites (see recent Tech News entry). Maybe you have different passwords on different wikis, and they have now become easier to mix up accidentally.

(Generally, the login system is still in the process of being changed. Most logins still happen via the old domains, but that will change very soon.) Tgr (WMF) (talk) 21:33, 19 March 2025 (UTC)[reply]

Can no longer edit articles

Hi,

I’m having trouble editing existing Wikipedia pages. When I try to edit, I only see the "Edit source" option and not the regular "Edit" button. This issue affects all pages I’ve tried, and I can’t make any changes to existing articles.

I have 29 edits on my account, and I haven’t edited for about 7 months, but I was previously able to edit normally

Any help would be greatly appreciated. Thanks! Vickylizholmes (talk) 11:05, 17 March 2025 (UTC)[reply]

@Vickylizholmes Go to Special:Preferences#mw-prefsection-editing and set "Editing mode" to "Show me both editor tabs". --Ahecht (TALK
PAGE) 15:29, 17 March 2025 (UTC)[reply]

That worked. Thanks so much! Vickylizholmes (talk) 07:40, 22 March 2025 (UTC)[reply]

Gadget proposal: Citation Watchlist

I would like to propose adding the Citation Watchlist script as a new gadget. The purpose of Citation Watchlist is to add visual indicators in recent changes feeds, watchlists, page histories, and user contributions pages when links to certain domain names are added. These domain names are often considered unreliable sources or otherwise require closer examination; this script makes it easier to identify when and where such links are added. New lists can be added to Wikipedia:Citation Watchlist/Lists and existing lists can be updated there. If you can edit a wiki page, you can create and update a domain list.

Citation Watchlist is under active development by the nonprofit Hacks/Hackers, with support from Wikimedia Switzerland. New versions are initially tested on test.wikipedia.org, then staged on English Wikipedia for additional tests before being released, to ensure that the script does not randomly break. To run through the requirements for gadgets:

Gadgets must work if just included with no further configuration. They can be configurable via personal common.js, but must work unconfigured.
Citation Watchlist works out of the box with no further configuration required.
Gadgets must be compatible with all major browsers, i.e., they must not terminate with errors.
Citation Watchlist has been tested and confirmed to work on Google Chrome, Mozilla Firefox, Microsoft Edge, and Safari.
Gadgets should be functional in most major browsers (cross-browser compatibility). Exceptions must be clearly stated.
As stated above, Citation Watchlist works in all major browsers. Note that on mobile devices, you can't hover over indicators to get additional information, as mobile devices lack a hover action.
Duplication of gadgets should only be made if it is reasonable.
Citation Watchlist provides functionality not available in other gadgets. While there are other gadgets that deal with references and source reliability, they do not operate in the same parts of the interface as Citation Watchlist, which focuses on revision log pages: page histories, watchlists, recent changes, and user contributions.
Collections of scripts should be split if they have disparate functions.
Citation Watchlist is not a collection of disparate scripts.
Gadgets requiring permissions must be marked and must fail gracefully if the permissions aren't present.
Citation Watchlist requires no special permissions.
Gadgets only working in some skins must be marked as such if that data is available.
Citation Watchlist has been tested and confirmed to work in Vector 2022, Vector 2010, Monobook, Minerva, and Timeless.

I am happy to answer any questions you have. If you would like to make changes to the code, I recommend doing so on Test Wikipedia so changes can be properly tested before altering the experience for existing users. Harej (talk) 18:50, 17 March 2025 (UTC)[reply]

Gadgets usually require a large usage; this one is used by only about 50 people. Izno (talk) 20:28, 17 March 2025 (UTC)[reply]

Meh seems fine to me. More wondering why the url is hardcoded, when we have wgScriptPath and wgArticlePath config variables available. —TheDJ (talk • contribs) 09:18, 18 March 2025 (UTC)[reply]

Which URL are you referring to? Harej (talk) 16:06, 20 March 2025 (UTC)[reply]

Toolhub spam

https://toolhub.wikimedia.org/tools/seourltool

Why is the toolhub being spammed? Is there something that can be done? Polygnotus (talk) 02:09, 18 March 2025 (UTC)[reply]

@BDavis (WMF) can definitely help with this. – DreamRimmer (talk) 03:14, 18 March 2025 (UTC)[reply]

Thanks DreamRimmer! @Bryan can we get a rel=nofollow for those fields? Polygnotus (talk) 03:31, 18 March 2025 (UTC)[reply]

I would imagine any of the administrators listed at https://toolhub.wikimedia.org/members?groups_id=1 (such as JJMC89) should be able to help. --Ahecht (TALK
PAGE) 19:14, 18 March 2025 (UTC)[reply]

JJMC89 has been inactive for about a month and a half, so they're probably not the best person to talk to. * Pppery * _{it has begun...} 19:25, 18 March 2025 (UTC)[reply]

SStefanova (WMF) no longer works for the WMF and their account is locked, yet they are still a toolhub admin. Polygnotus (talk) 23:28, 18 March 2025 (UTC)[reply]

I deleted that particular toolinfo record. I also put admin and crat hats on @TheresNoTime after they kindly volunteered to help in Toolhub. -- BDavis (WMF) (talk) 16:18, 19 March 2025 (UTC)[reply]

From the spam page, I particularly like "Fuck writing SEO content manually—this AI powerhouse mass-produces high-ranking, viral, and clickbait-infused content at scale." I suspect Wikipedia will be seeing more of that in due course. I just indeffed RickAndMortyOnNewsbreak (talk · contribs) who has two reverted edits here plus a deleted spam user page. If anyone is in the mood, can you work out what newsbreak.com is (the spammer apparently has a webpage there) and why there are 241 links to newsbreak.com here. Johnuniq (talk) 04:02, 18 March 2025 (UTC)[reply]

(I took care of a few sleepers now also.) Izno (talk) 04:11, 18 March 2025 (UTC)[reply]

This search is probably a good one to sort out. It apparently hits a few more spammy looking names too. Izno (talk) 04:12, 18 March 2025 (UTC)[reply]

The current "templates for discussion"-warnings make some reference sections close to unreadable

The template:Unbulleted list citebundle is currently for discussion. As a result, there is a warning for every single reference where it or a related template is used, making some reference sections close to unreadable. For example, Philosophy#Citations looks something like the following to me:

1.
‹ The template below (Unbulleted list citebundle) is being considered for merging with Multiref2. See templates for discussion to help reach a consensus. ›
Pratt 2023, p. 169
Morujão, Dimas & Relvas 2021, p. 105
Mitias 2022, p. 3
2.
‹ The template below (Unbulleted list citebundle) is being considered for merging with Multiref2. See templates for discussion to help reach a consensus. ›
Hoad 1993, p. 350
Simpson 2002, Philosophy
Jacobs 2022, p. 23
3.
‹ The template below (Unbulleted list citebundle) is being considered for merging with Multiref2. See templates for discussion to help reach a consensus. ›
...

Is that the intended behavior? As far as I can tell, this affects many high-traffic articles. If there is an automatic warning message, it would make sense to have it only for one instance per page, not for every single instance. Phlsph7 (talk) 10:33, 18 March 2025 (UTC)[reply]

I've added |type=tiny to both templates, so it looks a whole lot better than before. --rchard2scout (talk) 13:03, 18 March 2025 (UTC)[reply]

@Rchard2scout: Thanks, that's much better. However, I think it's still far from ideal. Some articles have 100 or more references. Do we really need to inform all readers 100 times per page about this discussion?

I'm not even sure that we should inform readers on article pages at all. Especially in the case of this discussion, which is a rather technical matter not of interest to most general readers. Phlsph7 (talk) 13:10, 18 March 2025 (UTC)[reply]

I went ahead and disabled the warning function by setting |type=disabled, which seems to have solved the problem. Phlsph7 (talk) 15:04, 18 March 2025 (UTC)[reply]

It was the warning which alerted me to the discussion, which I then joined in. Without the warning, I would never have known. ▶ I am Grorp ◀ 16:08, 18 March 2025 (UTC)[reply]

If hundreds of warning messages appear on high-traffic articles, thousands or even hundreds of thousands of readers see them within a very short time and have no idea what they are supposed to mean. This type of issue concerns a specific group of editors, so there is no need to warn all readers repeatedly. Phlsph7 (talk) 17:25, 18 March 2025 (UTC)[reply]

The reason these tags display is because editors want them to display. We can remove that from Template:Tfd, but the price is that people may not know a template is about to be deleted. It is not about "a specific group of editors", it is about any editor who thinks they may have a reason to support or oppose that template's deletion. Izno (talk) 17:37, 18 March 2025 (UTC)[reply]

I'm not opposed to warning editors. I'm just opposed to presenting hundreds of warnings to a high volume of readers who are not affected and don't understand them. What about posting a message on the talk page of each affected article instead? Phlsph7 (talk) 17:52, 18 March 2025 (UTC)[reply]

Do you read every article's talk page before you edit it? I don't. I'd be very surprised if more than a mere handful of editors (if any) actually do.

—Trappist the monk (talk) 18:00, 18 March 2025 (UTC)[reply]

... and which would lead to thousands to millions worth of messages.... that mostly go unread. Izno (talk) 18:09, 18 March 2025 (UTC)[reply]

I'm a little surprised that I'm the only one concerned about presenting hundreds of warnings per article page to a high volume of readers who don't understand them. Is there no better alternative? Phlsph7 (talk) 18:17, 18 March 2025 (UTC)[reply]

Hundreds of messages may not be optimum, but neither is potentially deleting a popular template because no one was notified in advance. At least the message won't be displayed any longer than the discussion that is taking place (usually not more than a week). And how many readers do you think actually scroll through reference sections. ▶ I am Grorp ◀ 19:51, 18 March 2025 (UTC)[reply]

Some high-volume articles with this template have around 100000 views per month. That makes about 25000 views for one week, and this is just for one of those articles. For each of those visits, over 100 warning messages are displayed. According to https://linkcount.toolforge.org/ , the templates Multiref, Multiref2, and Unbulleted list citebundle are directly transcluded to 816, 1292, and 507 articles, respectively. Not all of them are as high-volume, but you still get a feeling for how many readers you would reach with those warning messages–they are easily in the hundreds of thousands. And we do this only to reach a handful of editors who will participate in the template discussion. I think we do a lot more damage than good here. Having about 2500 talk page messages instead would be the lesser evil. If that's not acceptable, the alternative suggestion of displaying the warning message only once per article for the first occurrence would at least do less damage. Phlsph7 (talk) 20:37, 18 March 2025 (UTC)[reply]

Which is not possible.

Having about 2500 talk page messages instead would be the lesser evil. The community is likely to disagree, and clearly today that is not how it works. Similar was done when IA bot first rolled out when it added archives. It did not take long for the community to come to the conclusion that talk page messages were clear and obvious and totally unnecessary noise. Izno (talk) 00:34, 19 March 2025 (UTC)[reply]

@Izno It is possible using CSS tricks, but undesirable because it can't distinguish between multiple messages for one template or one message each for multiple templates. As a compromise, the CSS does prevent more that one tag from appearing within the same parent element (usually a paragraph or list entry). --Ahecht (TALK
PAGE) 18:48, 19 March 2025 (UTC)[reply]

During a recent case of a disruptive RFD notice, an editor at Template talk:Redirect for discussion suggested that RFD notice be made visible only to those wish to see it, similar to CS1 errors. For some classes of TFD nominations, those which don't directly impact the average reader, it may be a potential solution. —CX Zoom[he/him] ^{(let's talk • {C•X})} 19:24, 19 March 2025 (UTC)[reply]

This has been suggested before, several times, and rejected each time. We want to increase participation in XfDs, not reduce it. Too many of them get relisted for lack of !votes. Also, if it were opt-in, it would effectively debar logged-out users from participating in XfDs - something we have almost never done. --Redrose64 🌹 (talk) 06:34, 20 March 2025 (UTC)[reply]

For RfDs on widely-used template redirects, and TfMs on widely-used templates that would not result in any meaningful change to the template being merged-to, making the notices only show up for autoconfirmed users would make sense, though. The confusion caused to tens of thousands of readers is going to outweigh any benefit from increased participation. Elli (talk | contribs) 17:25, 20 March 2025 (UTC)[reply]

During the disruptive RFD notice that I am referencing, 3 of the votes were from people annoyed at the RFD notice. 2 opposed because they though their oppose votes will get rid of the RFD notice, and 1 thought that their support vote will get rid of the RFD notice. They didn't vote on the (de-)merits of the nomination at all. It only makes the discussion more messy. This is on top of thousands of readers who have no idea what RfD or TfM is, but have to see plenty of <<See Rfd>> notices all around. —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:05, 20 March 2025 (UTC)[reply]

Problem using section: on Persian Wikipedia

I am encountering an issue using the {{#section:}} magic word on the Persian Wikipedia (fa.wikipedia.org). I am trying to transclude the section titled "پانویس‌ها: گروه‌های پیش‌تعریف‌شده" (which translates to something like "Footnotes: Predefined Groups") from the page "راهنما:پانویس‌ها" (which translates to "Help:Footnotes") into my user sandbox page: "کاربر:اربابی دوم/تمرین۳". I have confirmed that the section title is copied correctly from the source page. However, nothing is displayed in my sandbox page. Could there be a specific configuration or known issue with the {{#section:}} extension on the Persian Wikipedia that might be causing this? Any insights or suggestions for troubleshooting would be greatly appreciated. Thank you.Arbabi second (talk) 20:53, 18 March 2025 (UTC)[reply]

@اربابی دوم: You need {{#section-h:}} for a named section made with == ... ==. {{#section:}} is for labeled sections marked with special tags in the source. See more at Help:Labeled section transclusion. PrimeHunter (talk) 21:25, 18 March 2025 (UTC)[reply]

@PrimeHunter

Thank you very much, the problem is solved. Arbabi second (talk) 21:51, 18 March 2025 (UTC)[reply]

Trouble staying logged in?

Anyone else having issues today with randomly finding themselves logged out? Just had that happen a couple of times when opening pages in new tabs, and had it happen earlier once on Commons while uploading. - The Bushranger _{One ping only} 00:37, 19 March 2025 (UTC)[reply]

And just had it happen again on Wikidata, between adding variables to a page. Quite weird. - The Bushranger _{One ping only} 01:02, 19 March 2025 (UTC)[reply]

And again on Commons. Just refreshing makes it "log back in". Maybe it's something with my connection... - The Bushranger _{One ping only} 01:17, 19 March 2025 (UTC)[reply]

I've been having the same issue for several hours. I'm guessing it's either a Firefox thing or something related to the SUL work. Jay8g [V•T•E] 03:42, 19 March 2025 (UTC)[reply]

@The Bushranger If you use cookie / ad blockers, you might have to allowlist the domain auth.wikimedia.org now. —TheDJ (talk • contribs) 10:53, 19 March 2025 (UTC)[reply]

This is probably the same issue that has been reported at T389159 (and maybe the same as #I need help with my Ip address? though that's a bit vague). It's probably caused by the SUL3 changes in some way or another (sorry!). Some information that would help:

your browser (and whether you use non-standard privacy/security settings, like incognito mode, an ad filter, third-party cookie blocking in Chrome)
if you have an idea exactly when this started happening
whether you are browsing multiple wikis at the same time and the behavior seems related to that (e.g. when you visit a page on wiki 1, you get logged out on wiki 2)
whether getting logged out seems to correspond with inactivity (specifically, not doing anything on a specific wiki for 5 or 10 minutes)
whether fully logging out and logging back in helps

Thanks! Tgr (WMF) (talk) 21:50, 19 March 2025 (UTC)[reply]

Have Firefox (136.0.2), NoScript and uBlock Origin. There have been occasional, very very rare, instances of this for awhile but it happened "regularly" yesterday. Was happening mid-editing on single pages on Wikis - for instance opening a page from my Watchlist on en. in a new tab logged it out once. Another time I was logged out on Wikidata in between entering parameters on the same page back to back. Another time on Commons I was uploading an image, hit upload, sat uploading for a bit and then said "cannot upload because you're logged out". Seemed to get better later on though? Note that the first one described there I was logged out completely until I clicked "log in" - where I did not have to enter any data, it just logged me right back in - but all the other times simply refreshing the page saw me recognized as loggedin. - The Bushranger _{One ping only} 22:19, 19 March 2025 (UTC)[reply]

Can you maybe reconstruct from your edit history when exactly it started happening? Tgr (WMF) (talk) 10:21, 20 March 2025 (UTC)[reply]

This particular time it was "immediately on the first 'hist' I clicked on on my watchlist after logging in ". But it hasn't happened yesterday or today. - The Bushranger _{One ping only} 02:18, 21 March 2025 (UTC)[reply]

This happened to me yesterday afternoon/evening. I also have Firefox. Scared the dickens out of me, but seems OK now. It was very strange. I thought I had been hijacked or something. It happened right in the middle of my reading/scrolling Articles for deletion/Log/2025 March 20 — Maile (talk) 20:06, 20 March 2025 (UTC)[reply]

Exactly the same, although with GoogleChrome, yesterday and today, seemingly random. Sometimes saying I was logged out, but accepting edits, sometimes not. Martinevans123 (talk) 20:31, 20 March 2025 (UTC)[reply]

I have had this problem in the past as well. Catfurball (talk) 21:11, 20 March 2025 (UTC)[reply]

I think it might be somehow related to connection stability, as I had a foul connection the other day when it was happening. - The Bushranger _{One ping only} 02:18, 21 March 2025 (UTC)[reply]

"Beginnings"

A recent CFD discussion, Wikipedia:Categories for discussion/Log/2025 February 21#Beginnings by decade 1-1499, kiboshed "YYYY beginnings" categories for years before 1500, on the grounds that their only actual contents were "YYYY births" subcategories — however, because the beginnings category is automatically transcluded by the {{Decade births or deaths category header}} template, that's left over 200 beginnings categories sitting on the latest run of Special:WantedCategories as redlinks.

However, because "beginnings" categories do still exist from 1500 on, we don't want to completely disable that category generation, but I don't know enough about complex template coding to change this myself without messing things up. So could somebody with more skill in that area than I've got edit {{Decade births or deaths category header/core}} to make the beginnings category #ifexist? Thanks. Bearcat (talk) 16:56, 19 March 2025 (UTC)[reply]

Looking. I attempted to update that template, but something seems to have gone wrong. * Pppery * _{it has begun...} 18:11, 19 March 2025 (UTC)[reply]

Fixed now. Sorry for the mess. * Pppery * _{it has begun...} 18:13, 19 March 2025 (UTC)[reply]

Actually it looks like I broke something else there too. I've fallen into the trap where I've been doing everything too fast and making too many mistakes and I think that means I need to take a break from editing. * Pppery * _{it has begun...} 18:27, 19 March 2025 (UTC)[reply]

MediaWiki:Loginprompt ?

Should we temporarily put a note in MediaWiki:Loginprompt about the need to allow auth.wikimedia.org for logons? Seeing multiple reports. This text appears above the logon box. — xaosflux ^Talk 17:55, 19 March 2025 (UTC)[reply]

Sounds like a good idea — is there a pre-existing info page (why/how, etc.) we could link to in the message? — TheresNoTime (talk • they/them) 18:03, 19 March 2025 (UTC)[reply]

mw:SUL3 * Pppery * _{it has begun...} 18:14, 19 March 2025 (UTC)[reply]

OK, added for now, if any issues feel free to revert. — xaosflux ^Talk 19:29, 19 March 2025 (UTC)[reply]

Question about suppression of editnotice creation link

You are invited to join the discussion at User talk:Cabayi § How can I find out if Nonie Darwish is covered in any way by ARBPIA?. Sdkb ^talk 18:14, 19 March 2025 (UTC)[reply]

Hi,
A reader of the Oberon book asked me to add at the top and bottom of each page, navigation buttons similar to the "← previous" "↑ top" "next →" links of some Web based documents. A reasonable request and I've put two mock-ups in my sandbox. In Wikipedia the button templates work except for the style attribute. According to the table at the bottom of the button document style is available. Seems my syntax is wrong. Furthermore, the template is unavailable in Wikibooks?

In the div box mock-up, the text is linked; not the whole box. The person asking for navigation insisted the box be clickable. He noted "... really frustrating to click a box, only to find out that you have to click the link." I agree but couldn't make the markup work. Help to fix either of these arrangements appreciated. Thanks, ... PeterEasthope (talk) 18:31, 19 March 2025 (UTC)[reply]

You might find {{Skip to top and bottom}} useful. – Jonesey95 (talk) 04:43, 20 March 2025 (UTC)[reply]

Error message

Tracked in Phabricator
Task T389734

Just for documentation, in case it is a bigger problem:

MediaWiki internal error.

Original exception: [c946df9e-af42-4d60-87c9-0136bcf9d82d] 2025-03-19 20:28:25: Fatal exception of type "Wikimedia\RequestTimeout\EmergencyTimeoutException"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

— Vchimpanzee • talk • contributions • 20:33, 19 March 2025 (UTC)[reply]

What were you doing when this occurred? — xaosflux ^Talk 22:03, 19 March 2025 (UTC)[reply]

Xaosflux According to my contributions, leaving a talk page message for someone who asked a Teahouse question. Even though it was an old question, it looked like something the person might still want the answer to.— Vchimpanzee • talk • contributions • 14:35, 21 March 2025 (UTC)[reply]

@Xaosflux I've been getting the same error, mostly when visiting Special:MyContributions.

The most recent one (approx 5 mins ago).

MediaWiki internal error.

Original exception: [c2b93251-f505-4c5f-9026-64c87b61f28c] 2025-03-20 11:03:13: Fatal exception of type "Wikimedia\RequestTimeout\EmergencyTimeoutException"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

I think they've just moved dumps generation back to the main database Phab:T368098#10641387, I seem to recall that dumps generation was causing similar disruption in the past? 86.23.109.101 (talk) 11:11, 20 March 2025 (UTC)[reply]

I just experienced this exact error by clicking View history on this page... only this one time though.

The error happened almost instantly, not even a second, so I don't understand the "timeout" part. – 2804:F1...7F:79A0 (::/32) (talk) 18:18, 20 March 2025 (UTC)[reply]

MediaWiki internal error.

I have no idea how significant this is. Went to the history of a page I'd just edited (Ming Xia), and got this error message:

MediaWiki internal error.
Original exception: [0fce64a5-248a-4907-aaa2-f2546651ae9c] 2025-03-20 22:32:02: Fatal exception of type "Wikimedia\RequestTimeout\EmergencyTimeoutException"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

Moments later I was able to view the page history as normal. Posting here for the eyes of those who understand this sort of thing. DuncanHill (talk) 22:43, 20 March 2025 (UTC)[reply]

I'm also seeing this error, only intermittently, when clicking on another editor's contributions.-- Ponyo^{bons mots} 20:00, 21 March 2025 (UTC)[reply]
I had this message about 30 minutes ago. At first I wondered if it was because the editors edit had remained on my screen (I went to make a cuppa) but I've done that before, and for longer and never had that notice. It has only happened once, so far. Knitsey (talk) 20:04, 21 March 2025 (UTC)[reply]
Just happened again. Loggingthe message here. Clocked on an edit to view it and it came up with this...

MediaWiki internal error.

Original exception: [694e5180-5ffd-47ba-8b0e-ff44245737e2] 2025-03-21 21:13:21: Fatal exception of type "Wikimedia\RequestTimeout\EmergencyTimeoutException"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information. Knitsey (talk) 21:17, 21 March 2025 (UTC)[reply]

Me too.

MediaWiki internal error.

Original exception: [e769a451-ba7d-44c9-a141-3d95e8d86266] 2025-03-22 03:10:59: Fatal exception of type "Wikimedia\Rdbms\DBUnexpectedError"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

wbm1058 (talk) 03:17, 22 March 2025 (UTC)[reply]

I got the error when going to an editor's contributions page. I did a hard refresh of the page and got the error three or four times. I went to another browser, where I am logged out, and the page worked. When I went back to my main browser, a hard refresh of the page worked fine, showing the contributions. – Jonesey95 (talk) 12:58, 22 March 2025 (UTC)[reply]

Just had it again, this time trying to view history of List of ghost towns in Oklahoma:

MediaWiki internal error.
Original exception: [fd2a3012-a533-4401-9fc2-e2cc86e2f104] 2025-03-23 00:50:33: Fatal exception of type "Wikimedia\RequestTimeout\EmergencyTimeoutException"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

Again I clicked to reload and it cleared. DuncanHill (talk) 00:53, 23 March 2025 (UTC)[reply]

I've filed a Phabricator ticket (T389734) given the suspicious increase in the rate of these errors - I'm seeing them reported elsewhere too. Sam Walton (talk) 11:38, 23 March 2025 (UTC)[reply]

Broken archive title at Talk:2024 Spanish floods/Archives/ 1

No archive shows up in the {{talk header}} at Talk:2024 Spanish floods.

{{User:ClueBot III/ArchiveThis
| age                 =2160
| archiveprefix       =Talk:October 2024 Spain floods/Archive
| numberstart         =1
| maxarchsize         =75000
| header              ={{Archive}}
| minkeepthreads      =5
| format              = %%i
}}
<!-- Template:Setup cluebot archiving -->

I see nothing in the config that would add the 3 characters "s/ ". There was a move but no redirect, so I'm surprised at what User:ClueBot III is doing. 216.58.25.209 (talk) 21:31, 19 March 2025 (UTC)[reply]

216.58.25.209, probably the space before %%i? — Qwerfjkl talk 21:34, 19 March 2025 (UTC)[reply]

Thank you. I copied and adapted a working config from another page, and temporarily disabled it while waiting for my RMTR. I assume the 2 letters "s/" are from the wrong |archiveprefix= after the move. 216.58.25.209 (talk) 21:49, 19 March 2025 (UTC)[reply]

I've moved the archive and re-enabled the archiving. This is indeed what happens when the archiveprefix doesn't match the page title with ClueBot III. lowercase sigmabot III silently ignores such cases and Aidan9382-Bot fixes some of them. Graham87 (talk) 04:25, 20 March 2025 (UTC)[reply]

invalid returnUrlToken?

My bot just started getting an error "invalid returnUrlToken" when it tries to edit. Anybody know what this is related to? Presumably there's been a recent change to Mediawiki, because this only started happening a few days ago. —scs (talk) 03:38, 20 March 2025 (UTC)[reply]

Hmm. Per a question just above, there's a good change it has something to do with SUL3. —scs (talk) 03:43, 20 March 2025 (UTC)[reply]

Bots should generally use either OAuth or bot passwords, not the web interface for login.

@Tgr (WMF): Oh, don't I know it. (Over the years I've made several desultory attempts to use the API, like a regular botherd. Pretty sure now's the time to do that for real.)

That said, can you check what URLs your bot is hitting (including redirects)? Tgr (WMF) (talk) 10:37, 20 March 2025 (UTC)[reply]

Yup, that's my next step, when I have time to dig into it. (My bot uses a crufty old framework that I can barely remember the details of.)

Thanks very much for the pointers to OAuth and bot passwords. One of those is probably just what I need. —scs (talk) 11:53, 20 March 2025 (UTC)[reply]

Keep in mind, oauth/bot passwords are certainly a good idea, but the main change would be to use the api vs screenscraping the webui. — xaosflux ^Talk 12:46, 20 March 2025 (UTC)[reply]

FWIW returnUrlToken is used for top-level autologin, a chain of redirects when you visit Special:Userlogin. It's not SUL3 related per se but there have been some small changes to its behavior recently. As a quick workaround, you can avoid autologin by setting the CentralAuthAnonTopLevel=1 cookie or the centralAuthAutologinTried=1 URL parameter when visiting Special:Userlogin. The login UI and workflow is changing in other ways, though, and will probably break your bot soon anyway if it uses web scraping. Tgr (WMF) (talk) 12:54, 20 March 2025 (UTC)[reply]

Performance issues loading talk page sections

I'm going to preface this by saying that this is an issue I've only noticed on particularly underpowered hardware but I think it's still relevant to bring here. Loading a specific section of a talk page is often significantly slower than simply loading the talk page itself - for a random example, loading Talk:Foo might take five seconds, whereas loading Talk:Foo#Bar would take closer to twenty. I usually come about these link highlights via the inbox / notification bar - my skin is Vector Legacy 2010. On larger pages I participate in talk discussions in, this performance latency, often at least three times longer to load than just the talk page itself, becomes a major issue that often results in the "page is not responding" message in Google Chrome. I've noticed this on a few talk pages, including WP:ITNC and WP:ANI, but it appears to be common across other large talk pages, especially those in excess of 100k bytes source. My connection isn't the best, and, as stated before, my hardware isn't too good either, but the principle is that the mechanism for finding and highlighting specific sections on talk pages should be improved. I'm unsure as to the specific importance of browser version etc, but if asked I can find it. I have been unable to replicate this bug on a fake test talk page.

Using WP:ANI as an example, in a benchmark taken just now, it took about three seconds to load the noticeboard itself - but when loading a specific section (from the page history), it took a full forty seconds. During this time, the highlighted section appeared, but was not itself highlighted - i.e. the browser only loaded the specific section. The "Page unresponsive" Chrome error also appeared when the page was interacted with. Departure– (talk) 16:33, 20 March 2025 (UTC)[reply]

Chrome has a history of this; it usually takes 15-or-so minutes for my computer to stop freezing on Wikipedia tabs every morning. Not sure why, but this is a known issue. — E_F⁵ 18:05, 20 March 2025 (UTC)[reply]

I don't think that's the same issue, this is specifically concerning talk page sections taking ten times as long to load as the talk pages themselves. Departure– (talk) 18:07, 20 March 2025 (UTC)[reply]

Ah. On my chromebook my Watchlist and every other Wikipedia-related tab will freeze on reload every morning, it lasts for 10-30 minutes and is incredibly annoying. — E_F⁵ 18:08, 20 March 2025 (UTC)[reply]

Have you observed the size of the scrollbar when accessing the talk page directly? The browser only scrolls to the section once the page has loaded all the way to the section anchor, which for me is noticeable by the scrollbar getting smaller and smaller and is a similar amount of seconds as the time it takes to jump to the last section. – 2804:F1...7F:79A0 (::/32) (talk) 18:14, 20 March 2025 (UTC)[reply]

No, the scrollbar is the same size the entire time the page is loading - it always appears to cover the whole page. Scrolling while loading a section when the page is hanging reveals only the section in question and a few around it - scrolling up or down shows everything else is just white. Departure– (talk) 19:38, 20 March 2025 (UTC)[reply]

File:Magsafe3 closeup.jpg

Something weird about this file seems to cause my browser to go dark whenever I view a page containing the file. Does anyone else have this problem, and does anyone know what's causing it? Try looking at the image on MagSafe#MagSafe_3.

Thanks. 2A0E:1D47:9085:D200:C58E:8E53:4854:F5A7 (talk) 18:41, 20 March 2025 (UTC)[reply]

I'm not having any issues, are you sure it is just this image? Gaismagorm (talk) 19:37, 20 March 2025 (UTC)[reply]

Yes, it's just this image. No idea what's causing it for me though. 2A0E:1D47:9085:D200:C58E:8E53:4854:F5A7 (talk) 19:45, 20 March 2025 (UTC)[reply]

Weird, I see it too on my MacBook screen and not on my external monitor. It looks a lot like an HDR image, although I thought that thumbnails on Wikimedia sites didn't have that capability and were always reduced to standard dynamic range. @Rorschach: did you do anything unusual when editing/uploading this image? The bright reflections don't really add to the understanding of the connector so they could always just be cropped out. the wub "?!" 22:30, 20 March 2025 (UTC)[reply]

Bottom of page overflowing into footer

The bottom of the main content of pages is now overflowing into the footer so they are rendered over categories. As I create this new talk section right now, the "Welcome to the village pump" instructions banner is rendered mostly behind the section above mine (the "i" icon is on top though). I am using Monobook theme with Chrome 135.0.7049.17. Disabling the code in my common.css did not help. I had enabled some gadgets but I can't figure out what would cause this (it's not HotCat). yutsi (talk) 22:47, 20 March 2025 (UTC)[reply]

Does it happen to you in safe mode? Does it happen on all pages, or just when editing? (If the latter, which editor are you using?) DLynch (WMF) (talk) 01:00, 21 March 2025 (UTC)[reply]

It does not occur in safe mode. It happens on all pages without editing otherwise. yutsi (talk) 01:16, 21 March 2025 (UTC)[reply]

If it's not happening in safe mode, and you've already tried disabling your own common.css, the next step is probably to start turning off gadgets and seeing when it stops happening. DLynch (WMF) (talk) 01:33, 21 March 2025 (UTC)[reply]

@Yutsi and Enterprisey: It's caused by importing User:Enterprisey/hover-edit-section.js in User:Yutsi/common.js. PrimeHunter (talk) 09:55, 21 March 2025 (UTC)[reply]

edit api with oauth javascript (not nodejs) (not mediawiki js) example

Hello, https://www.mediawiki.org/wiki/API:Edit#JavaScript actually is nodejs. Could you please share with me an example, that allows to auth using OAuth and create a page with content I have in my variable in JavaScript, for client-side in-browser JavaScript without involving nodejs? It will be outside of wiki page, so I won't have access to mw.utils and the like. Could you please share a few examples? (I've asked here also hoping for faster replies here.) Gryllida (talk, e-mail) 04:27, 21 March 2025 (UTC)[reply]

@Gryllida You're in luck, because this was just recently made possible thanks to @Lucas Werkmeister's work. See the links in this comment and below, there are code examples: T322944#10590515. Matma Rex talk 16:33, 21 March 2025 (UTC)[reply]

I could only find nodejs examples there? Gryllida (talk, e-mail) 09:48, 22 March 2025 (UTC)[reply]

This example runs in the browser, you just need Node to either serve or build it (because it was easier to set up this way). Lucas Werkmeister (talk) 10:46, 22 March 2025 (UTC)[reply]

Hi Lucas

It looks too complicated for me, as I am not familiar with the corresponding libraries used nor with npm. I have code like this: (there actually is more, as user generated page content from a few other variables in my app, but this is the part I am having trouble with)

var pageName='Gryllida Test 2';
var url = 'http://test.wikipedia.org';
var content='Hello world';

What is the code to insert afterwards to get this content added to the page with this pageName on that wiki?

Regards, Gryllida (talk, e-mail) 00:44, 23 March 2025 (UTC)[reply]

infobox-label text-align:left on mobile

Previously asked at Template talk:Infobox#Labels are centered on m.wikipedia. --Redrose64 🌹 (talk) 18:36, 21 March 2025 (UTC)[reply]

In many infoboxes on en.m.wikipedia.org the left column is centered instead of being left-aligned, which leads to weird placement of normally indented/bulleted labels. Why is that? Compare m.wiki vs. desktop. What is overriding the common.css setting of .infobox-label {text-align: left}, can that be fixed? (previously asked here) Ponor (talk) 11:56, 21 March 2025 (UTC)[reply]

Common.css is not loaded on the mobile site, so the .infobox-label {text-align: left} is not there in the first place. There's a separate mobile.css for MobileFrontend, although these days people tend to prefer moving styles for specific templates to TemplateStyles. Anomie ⚔ 12:09, 21 March 2025 (UTC)[reply]

Sounds like a job for an interface admin to add

.mw-parser-output .infobox-label {text-align: left;} to MediaWiki:Minerva.css, at least until everything {{infobox}}-related is in its own TS. Thnx. Ponor (talk) 12:24, 21 March 2025 (UTC)[reply]

This would be fixed by MediaWiki talk:Common.css/to do#Infobox getting done (it's slow going) or by MediaWiki talk:Common.css/to do#Turn mobile.css/js totally off getting done, which is just waiting on phab:T375538. I can probably upload a patch to resolve that one but I will need to bug the developer I was working with on it and he said something a couple days ago that made me twitch on the point so I'm not hopping fast right now. (And haven't hopped fast in general just because I got distracted with other things and I wanted to give him time to figure out what exactly he was intending to do. He hasn't hopped fast either....) Izno (talk) 22:26, 21 March 2025 (UTC)[reply]

Ok, I gently bugged the task on Phab, I will ping him later if necessary. Izno (talk) 22:47, 21 March 2025 (UTC)[reply]

WikiProject Australia pages too wide on phone

Wikipedia:WikiProject Deletion sorting/Australia is too wide on a phone screen, requiring horizontal scrolling on both Mobile and Desktop skins.

It may be something to with the transclusion of Wikipedia:WikiProject Australia/Navigation and Wikipedia:WikiProject Australia/Tab header.

Wikipedia:WikiProject Australia/Help uses those transclusions and does behave well on Desktop, but not Mobile.

Could be an offending div somewhere and maybe a solution is conversion to using {{page tabs}}.

When the problem is found it would be interesting to do a search to find other markup breaking the phone experience across Wikipedia. Commander Keane (talk) 00:59, 23 March 2025 (UTC)[reply]

Each of the tabs in the tab header is set to a fixed width of 15em, so the tabs force the table to be wide. Someone could modify Wikipedia:WikiProject Australia/Tab header to display two rows of tabs. – Jonesey95 (talk) 15:26, 23 March 2025 (UTC)[reply]

Pagemove semiprotection

Administrators can semiprotect pages from moves, i.e. you can't move the page unless you're confirmed or autoconfirmed. What's the point? HELP:MOVE notes that you have to be autoconfirmed to move a page in the first place, so functionally, all pages have this level of protection already. Nyttend (talk) 04:03, 23 March 2025 (UTC)[reply]

@Nyttend: The move right is a MediaWiki configuration setting where the default is all registered users. We have set it to autoconfirmed/confirmed. MediaWiki could be coded to detect this and remove the option on the protect form but I don't think there is a good reason this complication. And a wiki could change the setting later. PrimeHunter (talk) 09:31, 23 March 2025 (UTC)[reply]

Even if someone were to code that, I don't think it'd take effect here because the page movers group can grant move without editsemiprotected, so it's possible that the protection would have an effect in the case of someone who's not autoconfirmed or confirmed but is a page mover. It's the same reason why semiprotection is an option in the MediaWiki namespace despite code existing since 2013 to filter out protection levels that namespace-level protection filters out, because the interface-admin group could (at a technical level) be given to an account not already confirmed or autoconfirmed. Anomie ⚔ 13:51, 23 March 2025 (UTC)[reply]

Photo preview cropping and positioning on Wikipedia app

In the Wikipedia app (iOS 18.3.1), the “preview” photo at the top of the page is often cropped, resulting the main content of image being hidden. Is there a guideline for how to set the origin point or cropping behaviour?

screenshot of the behaviour here:

[1]

Davidley (talk) 14:51, 23 March 2025 (UTC)[reply]