Policy

Technical

Proposals

Idea lab

WMF

Miscellaneous

• Table of contents
• First discussion
• End of page
• New post

Shortcuts

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

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 ·  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, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

Resolved

Is there a prohibition for newer users from being able to email another user? I'm trying to assist a newer wiki user (autoconfirmed, but not yet extended confirmed) who can email some users but not someone who is blocked. I can email blocked users, though. There is nothing in WP:Emailing users describing restrictions. So I'm wondering if the newer user is [undocumented] unable to email a temporarily blocked user. Any insights?   ▶ I am Grorp ◀ 21:34, 24 June 2024 (UTC) reply

(If this is a known feature, not a bug, can someone please add it to the documentation?)   ▶ I am Grorp ◀ 21:34, 24 June 2024 (UTC) reply

Are you able to confirm that the blocked user's account can be emailed? (I'm thinking unauthenticated email or just no email)

The API documentation lists some possible errors (for the API, no idea what the UI says) and links to various generic ones ( mw:API:Emailuser#Possible errors), but I didn't notice any that seemed like what you described.

Also, are you able to ask what message they got when they tried? – 2804:F1...13:F724 ( talk) 22:05, 24 June 2024 (UTC) reply

Yes, it was the first thing I checked. I also see "Email this user" on the left margin under "Tools" for those users, and was able to successfully send a test email to one of them. The error message they had gotten was something like "You cannot email users on this Wikipedia (or en.wikipedia)", which made no sense, especially when they just turned around and successfully emailed someone else (who was not a blocked user). Users with their emails turned off, or without an email in the wiki system, don't display the "email this user" option under "Tools". However, I am an extended confirmed user (they are not), which is the only thing I could think of as an explanation for the fact they could email me (I'm not blocked), and one other not-blocked user, but could not email those other two users (one is indef blocked, the other is temp blocked). 500 edits would be a steep quota for a new user just to send an email (they have less than 100 so far) especially if there's no error message telling them that's what they need.   ▶ I am Grorp ◀ 23:46, 24 June 2024 (UTC) reply

Grorp, the other users might have "Allow emails from brand-new users" off in settings? I can't tell if brand-new means autoconfirmed or extended confirmed. —  Qwerfjkl talk 15:23, 25 June 2024 (UTC) reply

WP:Emailing users says "You can also prevent users without the autoconfirmed permissions level from emailing you by un-ticking the 'Allow emails from brand-new users' option", so that's not it because this user is autoconfirmed. I'm beginning to think 'blocked' and 'not yet extended confirmed' might be the reality of the situation. It would just be nice if someone could confirm and then fix the documentation. I think I'll post the issue to the talk page of WP:Emailing users and hope someone familiar with the behind-the-scenes-code will be able to confirm.   ▶ I am Grorp ◀ 16:52, 25 June 2024 (UTC) reply

The only similar message I can find is MediaWiki:usermaildisabledtext which says "You cannot send email to other users on this wiki". Based on a very quick look at the source ( [1] [2]) that message should only appear on a wiki where email is disabled entirely. Can you double-check that your emailer is using a WMF site, and not some third-party wiki? Suffusion of Yellow ( talk) 00:01, 26 June 2024 (UTC) reply

They were on en.wikipedia.org, and yes that is the error message they told me. But then they turned right around and emailed me thru wiki. So yes, they can send emails, just not to someone who was blocked.   ▶ I am Grorp ◀ 00:11, 26 June 2024 (UTC) reply

Their description may be inaccurate. That happens a lot with new users. PrimeHunter3 isn't even autoconfirmed but gets an email form at Special:EmailUser/Quiubennt, and that user is blocked. PrimeHunter ( talk) 00:56, 26 June 2024 (UTC) reply

+2 that. I expect this is a bad report. They can open a WP:BUG and include screenshots if it is unexpected behavior. — xaosflux ^Talk 01:10, 26 June 2024 (UTC) reply

PrimeHunter: The form shows just fine, but they get the error when they click to send the email.   ▶ I am Grorp ◀ 01:13, 26 June 2024 (UTC) reply

This could be many reasons, like hitting a throttle, an underlying IP block of some sort, etc. Troubleshooting by having you provide somewhat vague information isn't very useful. At this point, advise the third party to engage the larger community directly. — xaosflux ^Talk 10:40, 26 June 2024 (UTC) reply

"The form shows" wasn't mentioned before and I didn't want to mail a random blocked user. I have blocked my alternative accont PrimeHunter2 for a week and can reproduce the issue. PrimeHunter3 can mail my main account PrimeHunter normally but cannot mail the blocked PrimeHunter2, and it has "Allow emails from brand-new users" enabled. PrimeHunter3 gets an "Email this user" interface link on User:PrimeHunter2 and a mail form on Special:EmailUser/PrimeHunter2, but clicking "Send" gives a page which still shows the mail form and in red "You cannot send email to other users on this wiki". PrimeHunter can mail the account. Others may try for testing but I may not read the mails. PrimeHunter ( talk) 11:02, 26 June 2024 (UTC) reply

@ PrimeHunter this seems to be "unexpected" behavior, would you open a bug on it with the details? — xaosflux ^Talk 14:42, 26 June 2024 (UTC) reply

@ Xaosflux: Matma Rex later said below that it's caused by T341908 and he will make a note there. I don't have permission to view T341908 and will not open a bug without knowing what is happening. PrimeHunter ( talk) 02:35, 27 June 2024 (UTC) reply

FYI, I don't think it is the same user story, but phab:T361481 appears to be at least closely related. — xaosflux ^Talk 15:54, 26 June 2024 (UTC) reply

Primehunter: Thank you for reproducing this error. It didn't occur to me to create some alt-accounts (properly declared to avoid socking claims) in order to test this. I think I will for future instances.   ▶ I am Grorp ◀ 17:20, 26 June 2024 (UTC) reply

@ Grorp: Do you mind asking permission of this user to share their username here? It might be helpful. Suffusion of Yellow ( talk) 21:32, 26 June 2024 (UTC) reply

I asked. They said they would prefer not to be mentioned. I think with two other users having reproduced the problem, their username is not really needed.   ▶ I am Grorp ◀ 23:16, 26 June 2024 (UTC) reply

xaosflux: In that report the user wasn't yet autoconfirmed (they only had one edit), and it's not the same user as I'm working with.   ▶ I am Grorp ◀ 17:20, 26 June 2024 (UTC) reply

Oh certainly, but it could be related to a root cause. Someone should create this bug in phab with all the documentations, screenshots, etc. This doesn't appear to be an "English Wikipedia" problem, but something in software. (i.e. we can't fix it here). — xaosflux ^Talk 19:51, 26 June 2024 (UTC) reply

I can reproduce this too. I was able to email PrimeHunter2 from my main account, but not from Suffusion of Yellow alt 7. I was also able to email Suffusion of Yellow alt 8 from Suffusion of Yellow alt 7. Using WP:QQX shows that the error message is, in fact, MediaWiki:usermaildisabledtext. Suffusion of Yellow ( talk) 19:21, 26 June 2024 (UTC) reply

This is caused by private WMF config added to mitigate email abuse ( T341908). I will make a note on that task that it's affecting legitimate users. Matma Rex talk 00:23, 27 June 2024 (UTC) reply

I have a feeling that if the message were more accurate ("You cannot send email to this user" rather than "You cannot send email to other users on this wiki") then we'd document the restriction and move on. Anomie ⚔ 02:02, 27 June 2024 (UTC) reply

Perhaps, but why would an autoconfirmed user not be allowed to email a blocked user when an extendedconfirmed user can? Why the difference? If you display a generic message like "You cannot send email to this user", it is inadequate for the sender to understand why he cannot, or how to solve his problem. Either provide a better message ("You cannot send email to blocked users until you reach extended confirmed status") or simply allow them the ability to send such emails.   ▶ I am Grorp ◀ 02:08, 27 June 2024 (UTC) reply

It's a confusing message but the restriction is apparently specific to Wikimedia wikis and not coded in the general MediaWiki software so maybe they didn't have a good way to make a new message. I don't have permission to view T341908 so I don't know exactly what the restriction actually is. I wonder whether it also caused Wikipedia:Help desk/Archives/2024 January 22#Email where we never found an answer. We could make a localized version of MediaWiki:Usermaildisabledtext but what would it say when we don't know why the message is served to a user? PrimeHunter ( talk) 02:54, 27 June 2024 (UTC) reply

Presumably the same reason we protect pages to autoconfirmed and if that's not enough to extended confirmed, i.e. it's more time consuming to reach extended confirmed without scrutiny so abuse with extended confirmed accounts happens less often.

I honestly wouldn't have thought anyone would have the need to email blocked users before this - and seeing as this phab has been a thing for almost a year now without major complaints it's probably actually a rare occurrence. – 2804:F1...2D:8B49 ( talk) 03:59, 27 June 2024 (UTC) reply

• OK - so there is a temporary measure that may be causing this upstream in phab:T341908, the devs/security teams are reviewing some options. We are not able to share the details of the situation. No additional user troubleshooting is needed at this time. — xaosflux ^Talk 08:29, 27 June 2024 (UTC) reply

  The private WMF config has been removed now, as it was found to be no longer needed after discussion in the task (the abuse it protected against happened more than a year ago). Sending emails in this scenario should work again. Matma Rex talk 08:26, 2 July 2024 (UTC) reply

I was wondering, does there exist any way to quickly find pages with broken templates? This often happens with bracket imbalances, for example this edit, which was missing a closing bracket for the wikilink. This results in the template not being transcluded, with the raw template code being displayed on the page instead of the template. However, I don't know of any ways to find such instances without (a) using Google to search for the template name showing up on a mainspace article, or (b) using Wikipedia's search of the template name and comparing it with the list of articles transcluding a template. I was hoping there would be an easier way. Thanks, S.A. Julio ( talk) 21:16, 28 June 2024 (UTC) reply

Bracket imbalances are at https://checkwiki.toolforge.org/cgi-bin/checkwiki.cgi?project=enwiki&view=only&id=47 and https://checkwiki.toolforge.org/cgi-bin/checkwiki.cgi?project=enwiki&view=only&id=43 . Please mark all completed fixes as done in the tool. Missing square brackets ([) cause issues in links, while, curly brakets ({) cause issues with template transclusions. Snævar ( talk) 23:08, 28 June 2024 (UTC) reply

In addition to the above, Wikipedia:Database reports/Transclusions of non-existent templates lists calls to templates that don't exist, which can be fixed per WP:REDNOT. – Jonesey95 ( talk) 15:26, 29 June 2024 (UTC) reply

Great, thanks! S.A. Julio ( talk) 04:50, 2 July 2024 (UTC) reply

Harder to read than black.— Vchimpanzee • talk • contributions • 22:59, 28 June 2024 (UTC) reply

And it is still black on some older pages.— Vchimpanzee • talk • contributions • 23:14, 28 June 2024 (UTC) reply

As noted above, this is to signify that it's clickable. It's the same light gray shade used for section links in edit summaries. By the way, if you purge one of these older pages, the timestamps will turn into links. Nickps ( talk) 23:17, 28 June 2024 (UTC) reply

I'm not sure what, if anything, should be done about this. Perhaps an optional setting that turns the links blue? Nickps ( talk) 23:18, 28 June 2024 (UTC) reply

Thanks. I looked, but apparently not enough.— Vchimpanzee • talk • contributions • 23:19, 28 June 2024 (UTC) reply

@ Vchimpanzee:

.ext-discussiontools-init-timestamplink,
.ext-discussiontools-init-timestamplink:visited,
.ext-discussiontools-init-timestamplink:active {
  color: #72777d;
}

Put that in Special:MyPage/common.css, and change the #72777d to any valid colour specification. -- Redrose64 🌹 ( talk) 23:30, 28 June 2024 (UTC) reply

I'm not seeing a change. I chose blue.— Vchimpanzee • talk • contributions • 15:31, 29 June 2024 (UTC) reply

Weird, I tested it and it works fine for me. Perhaps WP:BYC might help? Nickps ( talk) 16:00, 29 June 2024 (UTC) reply

@ Vchimpanzee: You may need color: #72777d !important; if your skin at Special:Preferences#mw-prefsection-rendering is Vector legacy. PrimeHunter ( talk) 14:45, 1 July 2024 (UTC) reply

Not my skin.— Vchimpanzee • talk • contributions • 16:58, 1 July 2024 (UTC) reply

@ Vchimpanzee: User:Vchimpanzee/common.css is missing a closing } earlier in the page after visibility: hidden;. PrimeHunter ( talk) 22:45, 1 July 2024 (UTC) reply

Thanks. fixed. Looks good now.— Vchimpanzee • talk • contributions • 22:48, 1 July 2024 (UTC) reply

I mentioned this in a section higher up on the page, but it may be worth noting that the color contrast of the timestamp with the background, at least on a skin like Monobook, is lower than the WCAG contrast accessibility standards for text of its size. This discussion did make me realize the color is the same as sections in edit summaries, but I wonder if I never had a problem with those because I tend to skim over them, as opposed to me reading the timestamps... (Then again, I don't usually have issues with low contrast. Maybe this is the year where I start turning old...) - Purplewowies ( talk) 04:23, 29 June 2024 (UTC) reply

In Vector 2022, I'm getting #FFFFFF for my background and #757A80 for this gray text. That shows as 4.32:1 contrast ratio in the WCAG test, which is a Fail for normal-sized text. Unless I have some special CSS settings installed, which is quite likely, this seems like an accessibility failure that might be worth a site-wide workaround. [Edited to add: I see that the actual color specification is #72777D, which passes the contrast test at 4.51:1, but almost all of the pixels in the text are rendered for me in lighter shades of gray by the operating system's text smoothing function, or whatever makes it look nice in 2024. So the contrast appears to be failing in the real world rather than on paper.] – Jonesey95 ( talk) 15:48, 29 June 2024 (UTC) reply

I think the second link should be #72777D. In any case, if we decide to change the color, I think we should also change the edit summaries' section links, since they are supposed to be the same color. Other than that, I have no objections. Nickps ( talk) 16:15, 29 June 2024 (UTC) reply

Link fixed, thanks. – Jonesey95 ( talk) 16:47, 29 June 2024 (UTC) reply

Actually, scratch that, I tried the dark edit summaries and I didn't like them too much. But, as I've explained above, I think the timestamps should be changed because they don't pass the contrast test on closed XFDs. Nickps ( talk) 17:43, 4 July 2024 (UTC) reply

If I recall correctly, the color was chosen to de-emphasize the links/timestamps in relation to the text of the comment, while still highlighting them as a separate interface component. The color is a standard one from the Wikimedia Codex color palette. There is some discussion about the color at the end of T275729, with some ambivalent comments. Matma Rex talk 01:08, 30 June 2024 (UTC) reply

Really? To de-emphasise? I found the grey made the timestamp stand out much more, being a different colour from the text, which is why i hastened to implement the solution given above. Different strokes for different folks, eh? Happy days, ~ Lindsay ^{H ello} 06:07, 30 June 2024 (UTC) reply

Well, to de-emphasize it compared to regular link styling. The idea was to indicate that the timestamps do something now and that they’re not just plain text, but also not have them jump out in the same way that them being bright blue would. DLynch (WMF) ( talk) 12:38, 30 June 2024 (UTC) reply

I'm curious as to why Gray500 was chosen in particular. Apparently it was chosen [a]fter discussing with Design Systems team members but if you ask me, Gray600 was a better choice. Compare 18:06, 30 June 2024 (UTC) (Gray600) and 18:06, 30 June 2024 (UTC) (Gray500) with 18:06, 30 June 2024 (UTC) (the non codex color originally used). Gray600 would still achieve the desired style consistency since it's a Codex color while being closer to the original color and more accessible. I wish we could get some insight as to why the Design Systems team made this choice. Nickps ( talk) 18:06, 30 June 2024 (UTC) reply

Speaking solely for myself looking at it on the current monitor I'm using, I can barely see that there's a difference between Gray600 and the regular page text. Gray500 looks closer to the original color to me than Gray600 does. (The joys of subjective design issues!) DLynch (WMF) ( talk) 00:25, 1 July 2024 (UTC) reply

I definitely like Gray500 better, it de-emphasizes the timestamp much more than Gray600 (at least on my monitor). I know people don't like changes like this, but I'm reminded of something a forum webmaster once said when he redesigned the entire forum, and all the regulars were complaining: "Give it a week." As in, don't immediately go looking for a way to change things back, take a week to get used to it. If it still bothers you after a week, sure, go implement those CSS fixes, write a plugin to change things back, etc. But you will probably find that you get used to things very quickly, and won't even notice it anymore. -- rchard2scout ( talk) 07:37, 1 July 2024 (UTC) reply

I have no reason to doubt that it looks closer to you. But at the same time the delta E of Gray600 to the original color is lower than that of Gray500, so I'll defer to that instead of just saying that my subjective experience is different. Nickps ( talk) 09:05, 1 July 2024 (UTC) reply

In any case, Gray500 does not mesh well with closed Xfd discussions. While {{ subst:mfd top}} is the worst accessibility fail with a contrast ratio of 3.19:1, none of the others get above 4.5, although, to be fair, {{ subst:RM top}} gets close with a 4.33. Compare with Gray600 which has a high enough contrast against all of the closed XFD templates (I'll only provide mfd top but I tested all of them). Nickps ( talk) 17:38, 4 July 2024 (UTC) reply

This seems to me like a problem with the background color chosen for {{ subst:mfd top}}. Even the normal blue links on this background fail the test (contrast ratio 3.8), as does the red warning message (2.83). The background on {{ subst:RM top}} also fails the test (link: 3.6, warning: 3.84). Matma Rex talk 19:38, 4 July 2024 (UTC) reply

Fair point. I don't think the endless bikeshedding it would take to change that colour is worth it, considering that no one has complained about readability, so I guess things should stay as is. Nickps ( talk) 14:25, 5 July 2024 (UTC) reply

How do we disable the linking of timestamps? It isn't explained at the links provided. — Fourthords | =Λ= | 03:45, 29 June 2024 (UTC) reply

You may add

.ext-discussiontools-init-timestamplink {
	pointer-events: none;
}

to your CSS. Nardog ( talk) 03:56, 29 June 2024 (UTC) reply

You'd also want to add color: #000; inside that block to change the grey text back to black. (By the way, at least on Monobook, the color of the link is below WCAG standards. I don't know how best to bring this up, but it felt worth mentioning somewhere.) - Purplewowies ( talk) 04:18, 29 June 2024 (UTC) reply

That code seems to be very particularly coded. How best should it be added "inside that block"? — Fourthords | =Λ= | 04:25, 29 June 2024 (UTC) reply

I thought about describing what I meant and then didn't for some reason. I mean on a new line (or even the same line) inside the curly brackets, like so:

.ext-discussiontools-init-timestamplink {
	pointer-events: none;
	color: #000;
}

I should have been clearer! Sorry! (And I also think it might be better if it were a preference or gadget--it would be less confusing for people less comfortable with CSS.) - Purplewowies ( talk) 05:14, 29 June 2024 (UTC) reply

Your code has fixed this most of the way, but date-text is still generating a cursor upon hover instead of an I-beam, and despite my tinkering I can figure out how to repair that. Any suggestions? Is there any code that just disables this new beta gadget outright? — Fourthords | =Λ= | 18:18, 30 June 2024 (UTC) reply

That's impossible without JavaScript because pointer-events: none; interferes with cursor: text;. Nardog ( talk) 01:17, 1 July 2024 (UTC) reply

That's really a shame. What about just disabling the gadget's code entirely before it renders anything? Is that possible? — Fourthords | =Λ= | 04:53, 1 July 2024 (UTC) reply

It's not a gadget. It's already there when the HTML is served. I doubt they'll make it an option for either caching or mw:Just make it a user preference reasons. Nardog ( talk) 08:35, 1 July 2024 (UTC) reply

text-decoration:none too, if you use the underline-links preference. ( Like so.) — Cryptic 05:27, 29 June 2024 (UTC) reply

On Vector the text color is technically not quite black (plus this will not work with dark mode, or if the text itself has color, like the occasional green talk page quotes). I would recommend color: inherit; instead. That said, try out the feature first, you might end up liking it :) Matma Rex talk 00:42, 30 June 2024 (UTC) reply

I'd think this should obviously be a preferences toggle. Is there any reason it isn't? (By the way, your wikitext here breaks compliance with MOS:ACCESS, though I don't know how to fix it. Just a heads-up!) — Fourthords | =Λ= | 04:25, 29 June 2024 (UTC) reply

Which part of MOS:ACCESS? Nardog ( talk) 05:11, 29 June 2024 (UTC) reply

@ Nardog: Where is the pointer-events property defined? It's not in CSS Basic User Interface Module Level 4. -- Redrose64 🌹 ( talk) 09:31, 29 June 2024 (UTC) reply

It's in the editor's draft. — Cryptic 15:57, 29 June 2024 (UTC) reply

Ah, an editor's draft. These are even more fluid than a Working Draft, and it even says Editor's Drafts are works in progress inside a W3C Group and are not required to have the consensus of the Group participants. These drafts have not received formal review and are not endorsed W3C.
These drafts MUST NOT be cited as W3C standards and may or may not become W3C standards.
Software MAY implement these drafts at their own risk. Implementation is neither discouraged nor encouraged but can contribute to proposals for further action on a specification. In other words: don't rely on it. -- Redrose64 🌹 ( talk) 17:28, 29 June 2024 (UTC) reply

It may not have been formally promoted to a standard, but it has been stable and supported by browsers for over ten years. https://caniuse.com/pointer-events You can rely on it. Matma Rex talk 00:39, 30 June 2024 (UTC) reply

If it's that stable, how come it's never been in the W3C Working Draft? -- Redrose64 🌹 ( talk) 17:50, 30 June 2024 (UTC) reply

W3C's work on CSS standardization doesn't make sense to me anymore. There are a ton of properties supported for a half decade or more at working draft or earlier recommendation stage. As such, I think it's completely fair for developers (n.b. not necessarily Wikipedians) to turn to on-the-ground understanding of support for properties (i.e. caniuse.com). Asking such developers why it is what it is seems like the wrong target for your question on the point, and even unnecessarily hostile. Izno Public ( talk) 19:53, 30 June 2024 (UTC) reply

W3C's work indeed doesn't make much sense (see WHATWG). Personally, I don't know and I don't care why it's never been a "working draft". But I know that the people writing the draft specs are the same people implementing the browsers, so the browsers follow the drafts, and I follow the data that tells me whether the browsers I need to support implement the properties I want to use. Matma Rex talk 21:18, 30 June 2024 (UTC) reply

Local time gadget makes a textbox appear at the center top of my screen?

I have the "Change UTC-based times and dates, such as those used in signatures, to be relative to local time" gadget activated, and it's worked fine overall. However, I've lately noticed that if I click the timestamp on a comment on any talk page (such as WT:RFA), I'll end up with a small textbox appearing on the top of my screen. I'm running Google Chrome version 126.0.6478.127. As far as I know this is the first time this has happened, but I can't find any recent changes to the gadget's script that would cause it to act like this. EggRoll97 ^{( talk)} 07:30, 1 July 2024 (UTC) reply

@ EggRoll97 does this textbox say "link copied to clipboard"? See #Tech News: 2024-26 above, it's a change in the system to make timestamps links. Nthep ( talk) 08:01, 1 July 2024 (UTC) reply

That Tech News item is actually not related to the rollout on this wiki, so I've moved that discussion to #Time on talk pages is light gray (which already existed when that comment was made). Nardog ( talk) 08:32, 1 July 2024 (UTC) reply

Thanks, didn't know if this was related to the light gray change or was just a general issue. As far as I know this wasn't a problem before the rollout, because the timestamps just appeared in all-black and weren't clickable. EggRoll97 ^{( talk)} 12:48, 1 July 2024 (UTC) reply

@ Nthep: No, but the "link copied to clipboard" does appear when I click a timestamp link after disabling the gadget. When the gadget is enabled, it just jumps down to the comment, and creates a small textbox in the center top of the screen that allows me to type (?) in it, but it doesn't seem to actually do anything. EggRoll97 ^{( talk)} 12:46, 1 July 2024 (UTC) reply

Sounds like it's interfering with the reply tool. Nardog ( talk) 12:58, 1 July 2024 (UTC) reply

As far as I can tell, I don't have the reply tool on, nor do I have any reply links present on any pages. EggRoll97 ^{( talk)} 13:05, 1 July 2024 (UTC) reply

Looks like this issue: T368701 which will be fixed later this week. Matma Rex talk 13:23, 1 July 2024 (UTC) reply

I have stumbled upon a weird issue with getting the red outline to appear around the mapped object in infoboxes. It apparently make a difference whether one uses "|coords=" or "|coordinates=". For example, see this edit that I just made to Scottish Parliament Building. This is also the case with other infobox templates, such as infobox park (and might well be the case for all such infoboxes). Note that the red outline appears with the field or parameter "coords", but not with "coordinates", which is, or course, what the vast majority of infoboxes currently use. Is there any way to get this error fixed at its source? Abductive ( reasoning) 05:50, 1 July 2024 (UTC) reply

This is not much help regarding the issue but FYI, editing that article, then previewing it, currently shows an error at the top: Page using Template:Infobox building with unknown parameter "coords". The docs at {{ Infobox building}} show only "coordinates" as an allowed parameter although it takes {{ coord}} as its value. Johnuniq ( talk) 06:17, 1 July 2024 (UTC) reply

I just did a test where I replaced "coords" with "bonkers", which broke the infobox but somehow the map survived with the red outline. So, and I'm just guessing, "coords" has long been accepted as an alternative to "coordinates" in infoboxes, and then a change was made which breaks the red outline functionality only for the exact string "coordinates". Abductive ( reasoning) 07:13, 1 July 2024 (UTC) reply

No. Templates can have different parameters but {{ Infobox building}} hasn't been edited since April 2023. It only accepts |coordinates= while |coords= is an unknown parameter and ignored. If there is no or empty |coordinates= then the infobox automatically pulls data from the Wikidata item Scottish Parliament Building (Q2746031). That works on Scottish Parliament Building where you get a map with a red outline even with {{Infobox building}} without any parameters. If you set |coordinates= to something non-empty then you override the Wikidata pull and may get a different result. PrimeHunter ( talk) 11:18, 1 July 2024 (UTC) reply

|coordinates= should always work in any infobox that would reasonably accept latitude and longitude data, per the massive project we did at Wikipedia:Coordinates in infoboxes in 2016–2017 following a 2016 RFC to standardize on that parameter name. |coords= will work if it was retained, but most other coordinate-related parameters in infoboxes were deprecated, converted, and removed. It was a fun project. If you find an infobox that does not support |coordinates=, feel free to ping me or drop a note on my talk page, and I will fix it. – Jonesey95 ( talk) 17:23, 1 July 2024 (UTC) reply

But here's the thing; nearly all articles that have infoboxes are following the documentation that says to put the coord template after the = sign, and that apparently kills the red outline. Abductive ( reasoning) 20:19, 1 July 2024 (UTC) reply

This appears to be a problem with {{ infobox mapframe}}; I have posted a new topic on its talk page. – Jonesey95 ( talk) 21:43, 1 July 2024 (UTC) reply

I've responded with the reason there. Regards, The Equalizer ( talk) 23:11, 1 July 2024 (UTC) reply

Perfect. I have edited {{ infobox building}} to show the mapframe shape by default. – Jonesey95 ( talk) 23:29, 1 July 2024 (UTC) reply

What about Infobox park, as I mentioned above and all other infoboxes? Abductive ( reasoning) 18:52, 3 July 2024 (UTC) reply

Any affected infobox can be fixed with an edit like this one that I did at {{ infobox park}}. If you think that this problem affects many templates and that the default should be changed for all of them, I recommend that you follow up on the thread at Template talk:Infobox mapframe. – Jonesey95 ( talk) 19:06, 3 July 2024 (UTC) reply

Oh, I thought only certain editors had privileges to edit templates. I'll give it a try. Thanks. Abductive ( reasoning) 20:10, 3 July 2024 (UTC) reply

Whenever I attempt to save my settings (both on mobile and laptop) it instantly resets as soon as I leave the settings page, regardless of whether I have clicked save. Has anyone else experienced this? The main issue for me is the email settings and I am considering just removing my email address so I am not constantly receiving emails, however it does mean that if I forgot my password I will be locked out of my account. Any help would be greatly appreciated. Longhorncowfish ( talk) 20:32, 1 July 2024 (UTC) reply

Try accessing Special:Preferences and saving the preferences with JavaScript off (google how to turn it off, it depends on browser). Nardog ( talk) 02:45, 2 July 2024 (UTC) reply

Or try another browser or device. PrimeHunter ( talk) 03:23, 2 July 2024 (UTC) reply

I have tried on both iPhone and laptop and it doesn’t work :( Longhorncowfish ( talk) 01:59, 3 July 2024 (UTC) reply

I cannot do that on my current device, but I will try when possible Longhorncowfish ( talk) 02:00, 3 July 2024 (UTC) reply

This is supposed to happen at Special:Preferences#mw-prefsection-personal in desktop:

1. The Save button is grey
2. Click once in the box at "Email me when a page or a file on my watchlist is changed"
3. The box changes state between empty white and blue with checkmark.
4. The Save button is now blue
5. Click the Save button
6. The Save button is now grey
7. "Email me when a page or a file on my watchlist is changed" still has the new setting
8. If you leave preferences and come back then it still has the new setting

If it's different for you then at which step? PrimeHunter ( talk) 10:20, 3 July 2024 (UTC) reply

The button never goes gray. If I click it nothing happens Longhorncowfish ( talk) 03:35, 5 July 2024 (UTC) reply

Not even a page reload? Nardog ( talk) 06:16, 5 July 2024 (UTC) reply

I don't know what happened. If I knew how to fix the template I would. I copied it from somewhere else.— Vchimpanzee • talk • contributions • 22:26, 1 July 2024 (UTC) reply

I added the markup to close the table that your comment started. isaacl ( talk) 22:35, 1 July 2024 (UTC) reply

Thanks. I see now I shouldn't just delete the signature.— Vchimpanzee • talk • contributions • 22:37, 1 July 2024 (UTC) reply

Don't delete the |} characters, as they close the table. isaacl ( talk) 22:40, 1 July 2024 (UTC) reply

I learned that some time ago. I was thinking of another problem with that template I was unable to solve, but I forgot about that closing.— Vchimpanzee • talk • contributions • 23:10, 1 July 2024 (UTC) reply

Sure; it's just a separate issue from deleting the signature. isaacl ( talk) 00:44, 2 July 2024 (UTC) reply

MediaWiki message delivery 23:56, 1 July 2024 (UTC) reply

I'm not the most familiar with how the search on Wikipedia works, but I had a question with a recent query. This search (at the time of posting) says there should be 3,381 results, however it appears that only 3,380 pages show up in the results. I was wondering what might be causing this discrepancy (and which page is missing), I'm not sure if it has anything to do with how pages are indexed, if it's the result of page moves/deletions or something to do with cross-namespace redirects. I decided to sort the pages by creation date and return the results in increments of 5, with this page highlighting where the discrepancy occurs. I would be appreciative of any insight into this. Thanks, S.A. Julio ( talk) 05:14, 2 July 2024 (UTC) reply

Are you sure? If returning the first 3380 pages, there is still one lonely page on the next pagination (see here). — xaosflux ^Talk 10:22, 2 July 2024 (UTC) reply

I guess a new page was added after the original post but a page is still missing for me, currently at [10] which doesn't show any page for me. "previous 1" shows Pierre Sage and "next 1" shows Miroslav Vaněk. Maybe the missing page has been deleted but is still cached in the search index. I don't know whether that would actually appear like this. PrimeHunter ( talk) 11:46, 2 July 2024 (UTC) reply

Yeah, it seems to imply a page created between 2 and 4 December 2023 is missing from the results. I've never really come across this type of issue when using search before, results usually update for new/deleted pages fairly quickly. I'm not sure if this is just a quirk or if there's some other explanation. S.A. Julio ( talk) 12:40, 2 July 2024 (UTC) reply

Today's "there's always some template-autogenerated mess, every damn time" story at Special:WantedCategories is ‹The template Category link is being considered for merging.›  Category:Language articles with Linguasphere code. It's currently populated by sandbox content, not real stuff that would actually have to be filed in any maintenance queues, but once again it's being smuggled in by a module rather than being directly stated on the pages itself — so I can't just remove it, but I can't create it either as I can't determine whether it's actually needed for any real mainspace content or not.

So could somebody with more expertise in the language-codes domain than I've got either create it if it's desired, or make it go away if it's not? Thanks. Bearcat ( talk) 13:04, 2 July 2024 (UTC) reply

Pinging PK2 who made Template:Infobox language/lingualist which adds the category, and used it in [11]. @ Bearcat: If you post troublesome redlinked categories to my talk page in the future then I can look into the situation and keep most cases out of this page. PrimeHunter ( talk) 13:24, 2 July 2024 (UTC) reply

This is probably an existing problem, but nothing seems to be happening... Sangwe cooperative is an example. In desktop view it looks fine, but in mobile view I see:

Les coopératives Sangwe sur l’agenda du cabinet. Harv error: link from CITEREFLes_coop%C3%A9ratives_Sangwe_sur_l%E2%80%99agenda_du_cabinet doesn't point to any citation.

...

"Les coopératives Sangwe sur l'agenda du cabinet du gouverneur", ABP: Agence Burundaise de Presse (in French), 8 February 2024, retrieved 2024-07-02 Harv warning: There is no link pointing to this citation. The anchor is named CITEREFLes_coopératives_Sangwe_sur_l’agenda_du_cabinet.

I think this is something to do with a difference in the way special characters like é are handled. Aymatth2 ( talk) 13:55, 2 July 2024 (UTC) reply

@ Aymatth2: Others don't see this. It comes from User:Trappist the monk/HarvErrors.js which you load in User:Aymatth2/common.js. You can discuss the script with its author. PrimeHunter ( talk) 14:14, 2 July 2024 (UTC) reply

Not the fault of my script. See the phabricator bug report.

— Trappist the monk ( talk) 14:21, 2 July 2024 (UTC) reply

This is the same thing you complained about at Template talk:Sfn ( permalink). That bug report has been more-or-less ignored so don't be holding your breath for a fix.

— Trappist the monk ( talk) 14:21, 2 July 2024 (UTC) reply

Not quite the same. That one was solved by swapping to User:Trappist the monk/HarvErrors.js. This one only appears in mobile view, which I use more and more. It keeps bugging me. I want to see genuine errors, but not these bogus ones. Aymatth2 ( talk) 14:48, 2 July 2024 (UTC) reply

Umm, yeah, it is. At this edit resulting from the discussion at Template talk:Sfn §Special characters, you removed Ucucha's script from your common.js file (21:25, 23 November 2023). Twenty minutes later (21:45, 23 November 2023) you posted at the sfn talk page: That did it. All that that 'did' was remove the error checking code so it did not 'fix' anything. Nearly a month later (12:14, 21 December 2023), you added my script ( this edit).

If I look at the article of your original complaint, Collective work, in desktop view I don't see any error messages emitted by my script. In mobile view, however, I do; compare:

• desktop view: /info/en/?search=Collective_work#Notes – no errors
• mobile view: https://en.m.wikipedia.org/wiki/Collective_work#Notes – errors

For Sangwe cooperative:

• desktop view: /info/en/?search=Sangwe_cooperative#References – no errors
• mobile view: https://en.m.wikipedia.org/wiki/Sangwe_cooperative#References – errors

Because you installed my script, the error messages that 'went away' when you deleted Ucucha's script are again displayed (in slightly different format). The underlying errors in mobile view (with or without a script to highlight them) are still present in mobile view because MediaWiki is not correctly encoding the anchor links as described in the phabricator bug report.

— Trappist the monk ( talk) 15:37, 2 July 2024 (UTC) reply

O.k. I forgot the history. And it sounds like the phabricator bug report is going nowhere. I suppose we could fix it at the {{ sfn}} end by changing the link encoding to match the mobile view. 75% of page views are from mobile devices. But it is only editors like me that have the script who see it... Annoying. Aymatth2 ( talk) 17:57, 2 July 2024 (UTC) reply

I can't quite figure out why it's not working. I thought I had corrected some coding issues on June 30th (and these issues dated back to January of 2023 - see Talk:Trail of Tears#Archiving issues for this talk page) but the bot still hasn't run on the page today and it's July 2nd... I must have overlooked something but can't figure out *what*. Please help and thanks. Shearonink ( talk) 16:59, 2 July 2024 (UTC) reply

@ Shearonink: The bot seems to have slowed down a lot lately with only four edits today, 22 yesterday, and many more than that two days ago. I'll write a message on the bot operator's talk page. Otherwise, I've got nothing. Graham87 ( talk) 01:23, 3 July 2024 (UTC) reply

Ok, well at least I know it's not just my poor coding skills. I guess that's something. But only 4 edits today?...Noooooooo. Shearonink ( talk) 02:01, 3 July 2024 (UTC) reply

Graham87 Is it at all possible that User:Lowercase_sigmabot_III was somehow deactivated along with its relative User:Lowercase_sigmabot? Lowercase sigmabot was deactivated on June 29th, see Bots noticeboard. Shearonink ( talk) 02:21, 3 July 2024 (UTC) reply

@ Shearonink: Nope, that wouldn't have been what happened. Graham87 ( talk) 02:54, 3 July 2024 (UTC) reply

@ Shearonink: Lowercase sigmabot was unflagged early on 2 July (see the most recent entry here). It's not a block: all that it means is that any future edits from that account are not treated as bot edits, and so won't have the b in page histories, watchlists etc. By contrast, Lowercase sigmabot III still has its bot flag (see here). They are different accounts, with different rights. There's a current summary of similarly-named accounts here, but note that the two blocked ones were never bots - they are sockpuppets of people impersonating Σ. -- Redrose64 🌹 ( talk) 17:39, 3 July 2024 (UTC) reply

To be fair, it archives ANI and AN threads 2 times a day (unlike every other page), we haven't reached the time of the day where it would be archiving in other pages for the 3rd of July yet. That said, something could have happened at around 12:31, 2 July 2024 that stopped the bot's work halfway. – 2804:F1...7A:B4D ( talk) 02:11, 3 July 2024 (UTC) reply

It's just that I corrected the auto=archiving a couple days ago and it should have archived that page by now... - Shearonink ( talk) 02:21, 3 July 2024 (UTC) reply

Seems the bot worked fine today, it also archived things at Talk:Trail of Tears! Nothing was changed, so I guess it was just a temporary problem with the bot. – 2804:F1...1F:6F8E ( talk) 21:28, 3 July 2024 (UTC) reply

Please see MediaWiki_talk:Searchmenu-new#Remove_link_to_the_article_wizard. –  Joe ( talk) 21:19, 2 July 2024 (UTC) reply

So I toggled on the revisionjumper gadget recently and a JavaScript error was popping up whenever I try to see former revisions from a long time ago. Here's the URL to the problem I am having: https://en.wikipedia.org/?oldid=139992.

I wasn't expecting this to happen and I have practically zero knowledge how programming language works.

And I'm using Firefox on iPad (but I edit on the app too), no clue what version I'm running on. Tonkarooson ( discuss). 06:21, 3 July 2024 (UTC) reply

That gadget is hosted and managed from a sister project. Bugs may be reported here: w:de:Benutzer Diskussion:DerHexer/revisionjumper. You may want to @ping the author on that project when reporting your bug there. — xaosflux ^Talk 13:04, 3 July 2024 (UTC) reply

I uploaded File:Doctrine for the U.S. Public Health Service Commissioned Corps, January 2021.pdf to c: and there, it displays just fine, but locally, it has the generic Adobe Acrobat icon that displays when an PDF cannot render properly and where I inserted it into an article, it does not render correctly as a thumbnail. Can anyone tell me why this is going wrong and what I can do to fix it? ― Justin (koavf)❤ T☮ C☺ M☯ 08:39, 4 July 2024 (UTC) reply

It displays for me at File:Doctrine for the U.S. Public Health Service Commissioned Corps, January 2021.pdf and United States Public Health Service Commissioned Corps#Purpose. At your old revision link [12] I saw a blue link to the file page (no PDF icon) a few minutes ago but it displayed for me when I previewed the version. Now it also displays in the old revision. I guess the issue is resolved. PrimeHunter ( talk) 10:14, 4 July 2024 (UTC) reply

Samesies. Public shaming works.

Resolved

 – ― Justin (koavf)❤ T☮ C☺ M☯ 10:37, 4 July 2024 (UTC) reply

This has been a recurring issue for a while (there are a few tickets). It is a race condition of some sorts. Sometimes the page is requested before the metadata for the file has been read apparently. And then after the size is known, there is no new signal to get pages using the information to update what they know about the image. It's not fully understood what is causing this and its pretty difficult to completely analyse the problem. — TheDJ ( talk • contribs) 11:23, 4 July 2024 (UTC) reply

Hi, the height of blue border is shown after redirection for Infoboxes images are wrong. For example, after we click on this image File:Milad Tower in 2023.jpg of this article, (by the scroll button of our mouse) then the result is like this:

You can see the blue border has a wrong height. I should note that this bug is happened only for Infobox images of articles (not for ordinary images). Please inspect. Thanks, Hooman Mallahzadeh ( talk) 08:50, 4 July 2024 (UTC) reply

This is a known recent regression. Should hopefully be fixed somewhere in the next two weeks or so. — TheDJ ( talk • contribs) 09:29, 4 July 2024 (UTC) reply

@ Hooman Mallahzadeh: See Wikipedia:Village pump (technical)/Archive 213#Blue rectangle when clicking images. -- Redrose64 🌹 ( talk) 19:29, 4 July 2024 (UTC) reply

Anyone know why I can't see a table of contents on this talk page? I'm using the desktop site on mobile using my the Vector 2010 skin. If I edit the page and add __TOC__ the preview shows the table of contents correctly, but it's missing otherwise. -- LCU ActivelyDisinterested « @» ° ∆t° 13:48, 4 July 2024 (UTC) reply

Should be fixed now, I think. It was because Draft:Sources_about_whether_there_is_a_genocide_in_Gaza_or_not used a header, and it was transcluded into the collapsed box "Scholarly and expert opinions (to be extended)". Which meant that the TOC was also hiding in that collapsed box. -- rchard2scout ( talk) 14:32, 4 July 2024 (UTC) reply

Thanks looks correct now. -- LCU ActivelyDisinterested « @» ° ∆t° 16:52, 4 July 2024 (UTC) reply

Is there any way to include a running counter for equations, figures, linguistics examples, and so forth, with automatic cross-referencing? The idea being that the third equation in an article would automatically render with the label Equation 3 and that code like As shown in <eqn name = "LEM"/> would produce text like As shown in Equation 3. These numbers would automatically update if equations were added or removed from the article.

As noted by Uanfala ( talk · contribs) in a previous discussion, this seems like it should be possible since we already do it with references, but somehow the functionality has proved elusive. Does anybody have any ideas? Botterweg14 (talk) 17:58, 4 July 2024 (UTC) reply

I'm also gonna ping @ Colin M: and @ Biktor627:, who both edit in topic areas where this functionality would be useful. Botterweg14 (talk) 18:03, 4 July 2024 (UTC) reply

@ Botterweg14: Automatic numbering is not possible. See Help:Displaying a formula#Equation numbering for a system with manual numbering. PrimeHunter ( talk) 20:55, 4 July 2024 (UTC) reply

Hey, thanks for the reply. Is this something that could in principle be built by a user? Or is this really beyond what the wiki software can do in its current form? Botterweg14 (talk) 14:53, 5 July 2024 (UTC) reply

@ Botterweg14: It might be possible with a module which reads the whole page source at each location and cross-reference in order to count occurrences but it would be expensive (resource-demanding on the servers) and doesn't seem worth the cost. It wouldn't merely make rendering slower but also break some pages which are near a resource limit. PrimeHunter ( talk) 19:15, 5 July 2024 (UTC) reply

Ah, and there's no way this could be floated on top of the pre-existing architecture used by <ref>? Botterweg14 (talk) 20:57, 5 July 2024 (UTC) reply

A more specific problem is that MediaWiki is intended to work section-by-section: someone can edit a section and preview it, and that should not require the system to process the rest of the page. Johnuniq ( talk) 02:14, 6 July 2024 (UTC) reply

So, today I learned that Module redirects exist and I've been going around adding WP:RCATS to them. I've been doing this by adding the rcats to {{ Sandbox other}} per WP:CAT#T and I've updated WP:REDCAT to reflect this. The purpose of this section is twofold. One, I want the community to tell me if there are any objections to the instructions I've added to WP:REDCAT and two, I wonder if there would be any interest to update the moving process so {{ R from move}} is added to the module redirect (or, more accurately, to an WP:includeonly block in its doc page) after a move. Nickps ( talk) 22:24, 4 July 2024 (UTC) reply

The documentation you've added at WP:REDCAT is fine. But, in addition to technical feasibility, I would object to doing what you proposed with the doc page. Either the doc page didn't exist prior to the move, in which case creating a separate page just to add rcats is an unnecessary waste, or it did exist, in which case it should itself be a {{ R from move}}. * Pppery * _{it has begun...} 23:48, 4 July 2024 (UTC) reply

You make some good points. Especially the technical feasibility was the reason why I wasn't really hoping that my proposal would be accepted.

I'll note however that I personally don't agree that creating a separate page just to add rcats is an unnecessary waste. Per WP:RCAT: Normal ("hard") redirects should be placed in one of several maintenance categories specifically for redirects. Module redirects are the only case in which there is literally no other way to add categories to them ( Module:Module wikitext doesn't work after all), so I feel that creating an empty doc page is justified. Or better yet, one should create a doc page that says something like, "Redirect to [[<target>]]" since for some reason, module redirects don't provide a link to the target module. Nickps ( talk) 01:00, 5 July 2024 (UTC) reply

One more thing. Consider Module:Adjacent stations/HSL. Its doc page is redirected to its target's doc page. I didn't want to disable that redirect since having the target's documentation accesible without an extra click is useful. So I added

{{#ifeq:{{FULLPAGENAME}}|Module:Adjacent stations/HSL|{{Rcat shell|{{R from subpage}}{{R to subpage}}{{R from short name}}}}}}

to Module:Adjacent stations/Helsinki commuter rail/doc. Assuming we want to go that direction a Template that does this and also checks if the Module is still a redirect would be necessary. Nickps ( talk) 16:37, 5 July 2024 (UTC) reply

I looked at the IMAGE HELP stuff and either missed or it's lacking an option/keyword that would let me insert an image and then have the wikiText that follows just close around in, rather than leave extra whiteSpace.(did I look in the wrong place) Nuts240 ( talk) 01:42, 5 July 2024 (UTC) reply

@ Nuts240: See WP:EIS#Location, you probably want |left or |right. -- Redrose64 🌹 ( talk) 01:52, 5 July 2024 (UTC) reply

Not long ago from now, I received a notification saying that a few threads I opened on User talk:Daniel Case were deleted or archived from the talk page. I thought all was normal and that Daniel Case had archived the older messages on his user talk page. All until I started actually looking at the page that I noticed something really odd and strange has happened!

This is the current revision of the talk page, as of writing this very sentence. Scroll all the way down to the bottom of the page, and take a look at the section "Permaban" situation allegedly discussed on arbitration. That thread is from September 2023. From that point, seemingly all the threads from then until the thread left by the second latest messenger are gone! Where did they all go?! (That's a good 3/4 of the entire non-broken page's worth of content, by the way.)

The thread by User:Piyush Chekavar is not rendering correctly at all, too. It's missing a heading for the first thread, and look at the font style of the text! It's all in the code style of text (without the grey 'background'), even though there is no text formatting in the thread. A good chunk of that thread's text is missing, too!

I noticed that User:Piyush Chekavar did try to re-post the thread, maybe they thought the thread didn't publish, or that they were re-publishing it in hopes of getting it right the second time. This permalink where they make the first attempt publishing that thread is badly messed up too.

A few technical notes from me:

• The first thing I did was to go into the source code editing view, turn on the syntax highlighter, and look for any missing closing brackets, tags, etc. But there are none! The tags on the edits by User:Piyush Chekavar tell me that it was placed using the "New topic" feature, rather than published manually using plain old source code.
• The next thing I did was to go into the inspect page code function in my web browser ("inspect element"), and look for a "NewPP limit report" HTML comment near the bottom of the main code area. The last time I encountered a problem with pages not rendering correctly on Wikipedia, it was because of the post-expand include size limit being exceeded. So I checked those statistics on that broken talk page, and guess what!? None of the limits seem to be exceeded (or even 9/10 close to being so)!! Even checking the stats of the last page revision by Nyxaros before the unintentional catastrophe, it doesn't look like any of those technical limitations were dangerously close to being exceeded.
• The third thing I did was check the current raw page size, and as of now it's 588,265 bytes. The last page revision that isn't broken is 583,959 bytes in size. I've been told that the maximum raw page size for Wikipedia's engine is 2 megabytes (2,097,152 bytes?), and the Wikipedia Dramaboard Admins' Noticeboard for Incidents regularly sees page sizes in excess of 700,000 bytes with no problems like this at all.
• Even comparing the broken and non-broken page revisions' HTML code in the web browser code inspector feature, I can see that a significant quantity of 'nodes' / HTML individual paragraph blocks are missing from the broken page revision.

So what on earth is actually going on here!?!? —  AP 499D25 (talk) 13:33, 5 July 2024 (UTC) edited 13:40, 5 July 2024 (UTC) reply

There was a <code><ref></code> which swallowed up a big chunk and rendered a weird format. I have changed that now. s the problem gone? Graeme Bartlett ( talk) 13:44, 5 July 2024 (UTC) reply

Yeah, it's fixed. Sometimes it's really things as simple as that creating a seemingly epic catastrophic effect, huh?

If there's one takeaway I have from this, it's that always look around where the problem begins for a clue, maybe the culprit is right in there somewhere. —  AP 499D25 (talk) 13:58, 5 July 2024 (UTC) reply

When I was viewing the page New Mexico, I found that most of the references display a "Lua error in Module:Citation/CS1/Configuration at line 2058: attempt to index a boolean value." I did a search for the error message and found more than 300 articles with the same reference error. I'm not sure what's going on, but something appears to be broken. Johnj1995 ( talk) 15:31, 5 July 2024 (UTC) reply

A WP:NULLEDIT seems to have fixed the problem. That line of code loads data from Commons so maybe there was some issue talking to Commons when the page was rendered? * Pppery * _{it has begun...} 15:35, 5 July 2024 (UTC) reply

I currently get 240 hits on "Lua error in Module:Citation/CS1/Configuration at line". I examined the first 40 and none of them had the error. Whatever caused it, it appears to be gone. PrimeHunter ( talk) 17:12, 5 July 2024 (UTC) reply

This sort of thing sometimes pops up when the Citation Style 1 modules are updated, which happens a few times per year. (These distractions are one of the reasons for infrequent updates.) No matter how short the time between updates of each of the sub-modules, there is always a bit of time during which the sub-modules may be incompatible with each other, for example because one of them introduces new code that doesn't interact well with the older code in a different sub-module. This extremely temporary discrepancy can cause errors to pop up in at least a few pages. Null edits usually take care of the problem. – Jonesey95 ( talk) 18:18, 5 July 2024 (UTC) reply

I haven't seen a live example of the error but the above search shows it at this in Serom (state constituency):

{{cite news
| title             = Johor 14th General Election Malaysia (GE14 / PRU14)
| work              = [[The Star (Malaysia)|The Star]]
| publication-place = [[Petaling Jaya]]
| date              = 23 March 2019
| url               = https://election.thestar.com.my/johor.html
| archive-url       = https://web.archive.org/web/20180511081855/https://election.thestar.com.my/johor.html
| archive-date      = 11 May 2018
| url-status          = live
| access-date       = 16 April 2019
}}

It currently produces:

"Johor 14th General Election Malaysia (GE14 / PRU14)". The Star. Petaling Jaya. 23 March 2019. Archived from the original on 11 May 2018. Retrieved 16 April 2019.

None of the used modules and templates have been edited recently so the cause was something else this time. PrimeHunter ( talk) 18:54, 5 July 2024 (UTC) reply

Might it be possible to make the edits in such a way that this doesn't happen? All the best: Rich Farmbrough 22:38, 5 July 2024 (UTC). reply

Seems possible: Update sandbox submodules, update the main module to use the sandbox versions, update the normal submodules, change the main module to use the normal submodules again. Not sure it's worth the effort, and something worse might happen if it isn't done carefully enough. PrimeHunter ( talk) 22:57, 5 July 2024 (UTC) reply

Light mode footer appears when a software notice is shown above. [logged out]

Dark mode footer (normal behaviour) appears when software notice is dismissed and page refreshed (or notice not shown at all). [logged out]

Dark mode footer appears even when software notice is shown on Commons Main Page. [logged in]

Hi all, recently I was scrolling through the mobile version of Wikipedia as an anonymous user, and got advertised with a pop up to try the new Dark Mode feature, and came across this bug: When a software notice is shown to a logged-out user, the footer does not respect the dark mode, and continues in light mode. This happens to all pages.

But, if one dismisses the notice and refreshes the page, the footer behaves normally. Similarly opening any page without the notice also causes the footer to behave normally. When I was logged-on to Commons, I saw another software notice, but the footer behaves normally. I don't know if this bug is already reported or not. Thanks! — CX Zoom[he/him] ^{( let's talk • { C• X})} 17:47, 5 July 2024 (UTC) reply

@ CX Zoom Hi, looks like it was just an issue with that Bangla Wiktionary centralnotice banner. I've fixed it now. The banner templates were updated to fix this back in May, so hopefully we won't see any more banners with the same problem. Peter Coombe (WMF) ( talk) 23:47, 5 July 2024 (UTC) reply

Thank you very much! — CX Zoom[he/him] ^{( let's talk • { C• X})} 15:25, 6 July 2024 (UTC) reply

The page preview, which for some reason links to a different article

The article itself, which shows that the page previewer is jacked up

I was working on an article, Downtown One (which is not a redirect), when I realized that the article preview links to a completely different article, which is List of tallest buildings in Albania. A redirect from the former to the latter did exist at one point in time, but was deleted in 2023. The bug should be visible to others, if it's not just let me know, I can post an image up. This is a relatively serious bug aswell, because it basically removes the ability to visit that page, effectively eliminating the purpose of Wikipedia. I've never seen this before, so I thought I'd let yall know. (Also I attempted to report it over at Phabricator, but for some reason the ver. email link never sent). At least one person over at WP:TEAHOUSE is completely clueless as to why that happens, and honestly so am I. Thanks :) Sir MemeGod ._. ( talk - contribs - created articles) 03:32, 6 July 2024 (UTC) reply

I failed to reproduce the problem. Graeme Bartlett ( talk) 05:17, 6 July 2024 (UTC) reply

It just fixed itself. That is the weirdest thing. Sir MemeGod ._. ( talk - contribs - created articles) 05:20, 6 July 2024 (UTC) reply

Sir MemeGod ._. ( talk - contribs - created articles) 05:23, 6 July 2024 (UTC) reply

The redirect existed for 15 hours on 7 August 2023. Page Previews uses caching. I guess the cache was never updated after the deletion. I don't know whether this is normal for deleted redirects or pages. Page Previews doesn't activate on red links so it wouldn't normally affect users but it did when you recreated the page with other content. The cache was apparently updated between your first and second post, meaning between one and three hours after page creation. There are reasons for caching but 11 months is too much so I would call this a bug. PrimeHunter ( talk) 10:33, 6 July 2024 (UTC) reply

If I click on a link to WP:ANI#Pizza (but not Mars#Pizza), a popup appears in the upper-right hand corner of the browser satating the obvious, This topic could not be found. It might have been deleted, moved or renamed. [ sic Which preference or gadget has enabled this? I can't find anything that describes such in my preferences, and I don't see anything documented at WP:ANCHOR, Help:Section#Section linking, or MOS:SECTIONLINKS. Anybody know what's causing this? — Fourthords | =Λ= | 04:49, 6 July 2024 (UTC) reply

mw:Extension:DiscussionTools. Just curious, why "[sic]"? Nardog ( talk) 04:56, 6 July 2024 (UTC) reply

I don't see that specific popup listed at that link, but I'll take your word for it. As it's both new and woefully superfluous, is that something still being experimented upon (and we can wait it out), or does it need to be fixed at the project or individual-editor level? (I just used {{ sic}} to denote that the missing serial comma was original to the popup, and not a mistake on my part.) — Fourthords | =Λ= | 10:28, 6 July 2024 (UTC) reply

It's a MediaWiki feature that has existed for several weeks. The HTML is

<div class="mw-notification-area-overlay">
  <div class="mw-notification-area mw-notification-area-layout" id="mw-notification-area" style="">
    <div role="status" class="mw-notification mw-notification-noautohide mw-notification-type-warn mw-notification-visible">
      <div class="mw-notification-content">This topic could not be found. It might have been deleted, moved or renamed.</div>
    </div>
  </div>
</div>

and it's right at the end of the HTML source that is served to your browser. The same <div class="mw-notification-area-overlay">...</div> is used to contain the "Your edit was published." message that you get when you save an edit, also some other messages. -- Redrose64 🌹 ( talk) 14:09, 6 July 2024 (UTC) reply

I don't know how to remove only this message. This in your CSS removes all mw-notification-area-overlay:

.mw-notification-area-overlay {display:none;}

This in your common JavaScript only works if it runs after the popup has appeared but it normally runs before:

$('.mw-notification-area-overlay:contains("This topic could not be found")').hide()

PrimeHunter ( talk) 14:21, 6 July 2024 (UTC) reply

I've found two more messages that go in the same area - '"(page name)" and its talk page have been added to your watchlist permanently.' and '"(page name)" and its talk page have been removed from your watchlist.', so that makes four, although there may be others. @ Fourthords: I've worked out how to hide the "This topic could not be found. It might have been deleted, moved or renamed.", leaving the other three visible:

#mw-notification-area:has(div.mw-notification-noautohide.mw-notification-type-warn) {
  display: none;
}

which goes in your CSS. The selector might be overspecific. -- Redrose64 🌹 ( talk) 16:12, 6 July 2024 (UTC) reply

Oh gosh, I hadn't mean to attract so much attention and assistance; I was just expecting a point in the correct direction. Thanks so much! — Fourthords | =Λ= | 18:09, 6 July 2024 (UTC) reply

When I do not login, the search box is not visible (on my HP laptop running Windows 11, using Firefox or Brave) unless I hit ctrl and the minus key at least three times. I wouldn't be surprised if there aren't potential users who have come to Wikipedia and left after not finding a way to search. Can't this set-up be changed? (When I'm logged in, the issue does not occur.) Kdammers ( talk) 03:48, 7 July 2024 (UTC) reply