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

Hiding HTML element inside a specific page

Is there a way to hide an HTML element appearing on Event:Sandbox, using inline css/js or another way? I do not want users with the eventcoordinator permission to accidentally register the event, simply because the page is prefixed with Event:

The html div that should be hidden contains css class .ext-campaignevents-eventpage-enableheader ~ 🦝 Shushugah (he/him • talk) 19:13, 19 February 2025 (UTC)[reply]

I looked at the code and it turns out only the author sees that so there's no need to do anything. * Pppery * _{it has begun...} 20:27, 19 February 2025 (UTC)[reply]

@Pppery that makes this request moot (though I am still curious how it could be achieved). This would also make collaboration with different parties more challenging, e.g someone preparing a page creation, another person registering it. I am curious about page-swapping etc... now but these are edge-cases... ~ 🦝 Shushugah (he/him • talk) 21:01, 19 February 2025 (UTC)[reply]

Probably the least unreasonable way to achieve this would be a CSS-only hidden template gadget. By design nobody other than interface admins can add custom styling for things outside .mw-parser-output, which this isn't. Or (in an alternate universe where that check didn't exist), someone could file a request on Phabricator asking for a __NOEVENT__ magic word to solve the problem at the root. * Pppery * _{it has begun...} 21:03, 19 February 2025 (UTC)[reply]

CSS provides two properties which may be used to hide content. They are the display property and the visibility: property. They accept different values, and have different effects. For example, if an element is subject to the declaration display:none, it is physically removed from the rendered page - preceding and succeeding elements are presented adjacent to one another. But when an element is subject to the declaration visibility:hidden, it is replaced with blank space. Examples: The text following this has display:none. →This text has display:none.← The text preceding this has display:none. The text following this has visibility:hidden. →This text has visibility:hidden.← The text preceding this has visibility:hidden. --Redrose64 🌹 (talk) 22:08, 19 February 2025 (UTC)[reply]

@Redrose64 this is a good solution when the html wikitext is directly inline and I can create inline styling, but in this case the HTML is injected elsehow. ~ 🦝 Shushugah (he/him • talk) 22:23, 20 February 2025 (UTC)[reply]

Where some HTML "comes from" makes no difference, in regards to CSS style rules. That's why Pppery recommended a template gadget, which would add CSS rules which apply to the entire page. --Slowking Man (talk) 22:26, 23 February 2025 (UTC)[reply]

My alt key has gone rogue

I have numerous macros set up to assist my editing and most are activated by the alt key and a letter or number. For the last several weeks pressing the alt key in an edit box selects all text and any subsequent typing replaces the whole page.

What's going on? How can I fix this? This is only a problem in the Wikipedia edit window. Thank you. SchreiberBike | ⌨ 01:06, 22 February 2025 (UTC)[reply]

What troubleshooting steps have you tried? Try logging out. Try a different web browser. Try a different computer. Have you changed any of your user Preferences in Wikipedia recently? – Jonesey95 (talk) 01:24, 22 February 2025 (UTC)[reply]

Thanks for the suggestions. It's only on my desktop. I'm using the latest Windows version of Firefox, but it doesn't happen in Chrome or the DuckDuckGo browser. If I log out it still happens. I'm not aware of any changes to Preferences. Thanks to the tech wizards. SchreiberBike | ⌨ 12:28, 22 February 2025 (UTC)[reply]

This then is definitely a problem "on your end", likely having to to with your Firefox browser profile. When you say you "have macros set up" can you elaborate please? What are these macros "coming from" so to speak—describe for us how you set them up, please, we need more details. (Remember, we can't see your screen or desktop, we have no idea how things on your system are configured, we've never used it.) Are you using a browser extension in Firefox to provide these macros, or AutoHotkey, or what? --Slowking Man (talk) 04:32, 23 February 2025 (UTC)[reply]

Thanks for the suggestions. My macro program is Macro Express; it was the hot thing when I bought it in 2006, and it's still working well. I updated that and have run several cleanup and anti-virus programs. When I turn off Macro Express the problem continues. I've tried various online edit windows and on some of them pressing alt selects all and moves the cursor to the bottom of the page, while on others it has no effect. It happens when I press the alt on the on-screen keyboard too, so I don't think it's my hardware, but I'm borrowing another keyboard later today to test that. No other key presses seem to cause problems. Thanks for your help. SchreiberBike | ⌨ 20:59, 23 February 2025 (UTC)[reply]

Ok, this is a guess: in beta prefs, do you have Improved Syntax Highlighting checked? And do you use the "native" wikitext syntax highlighting? Having both would cause you to get the new version of the highlighting software which may have clobbered your keys for its own purposes. Izno (talk) 21:07, 23 February 2025 (UTC)[reply]

Otherwise, it's likely to have been a new version of Firefox doing the same, based on your report that it doesn't happen in Chrome, so you will need to hunt down what Firefox is doing with those keys on your own and see if you can adjust some personal settings. Izno (talk) 21:08, 23 February 2025 (UTC)[reply]

Step one, then: launch a new "clean" Firefox browser profile, see if the problem continues to happen there too. If it doesn't happen under a "clean" profile, then it's something to do with the settings and extensions in your default Firefox profile, and you'll have to try fiddling them one-by-one to do a differential diagnosis of the cause. Step 1 for that: disable any and all browser extensions, see if that changes anything. --Slowking Man (talk) 22:13, 23 February 2025 (UTC)[reply]

Fixed. That was it! I'd been trying to get the TitleCase browser extension to work with keyboard commands and there was a setting to enable the alt key. I've turned that off and now I'm back to normal. Thank you all so much for helping me troubleshoot this. I should've thought of that, but I didn't. Viva la VPT. SchreiberBike | ⌨ 01:20, 24 February 2025 (UTC)[reply]

Searching in the Template namespace problem

When I search for "Rocksteady" in the Template namespace, it doesn't find {{Mad Caddies}}. If I do an insource search for "Rocksteady" in the Template namespace, it finds {{Mad Caddies}}, plus an additional eight templates. I can see no reason why the first search can't find all 15 templates. Why is that? —Bruce1ee ^talk 14:30, 22 February 2025 (UTC)[reply]

@Bruce1ee: It appears from [1] that elements with the autocollapse class is excluded from searches. It's usually collapsed on page load and usually of low relevance anyway for mainspace searches. This should probably be mentioned at mw:Help:CirrusSearch#Exclude content from the search index. PrimeHunter (talk) 16:28, 22 February 2025 (UTC)[reply]

@PrimeHunter: Thanks for that. So it's probably better to use an insource search to ensure it finds everything. —Bruce1ee ^talk 17:27, 22 February 2025 (UTC)[reply]

I would not expect {{Mad Caddies}} to be found with a plain search for "Rocksteady". That string is buried in a wikilink that is inside a template parameter value. I'm honestly surprised that the plain-text search finds as many navboxes as it does; I never trust it. Simple insource searches work pretty reliably unless they time out. – Jonesey95 (talk) 06:22, 23 February 2025 (UTC)[reply]

Plain search works on the output so it's irrelevant whether templates were used. {{NPR Texas}} is expanded by default so it doesn't have autocollapse and is found on KTTZ. A mainspace search also finds articles using it. PrimeHunter (talk) 10:02, 23 February 2025 (UTC)[reply]

We must have a different understanding of the definition of the word "works". :) – Jonesey95 (talk) 16:36, 23 February 2025 (UTC)[reply]

PIA flag showing up in search result excerpts on search engines

So I was searching "Golan Heights" using Bing and the search engine displayed the following text as the top result: https://www.bing.com/search?q=golan+heights

Golan Heights
This page is subject to the extended confirmed restriction related to the Arab-Israeli conflict. This page is subject to the extended confirmed restriction related to the Arab-Israeli conflict. The Golan Heights, or simply...

I cannot figure out where this is being inserted as it is not showing up in the source editor, but the fact that there are two of them and pushing the actual article text further is indicative that something is broken. I get this flag is needed for Abuse Filter 1341, but something needs to be done to make sure search engines are not reading the lines meant just for the filter.

Google does not have the same issue it seems, but this is something that should be fixed for all search engines. Aasim (話す（はなす）) 23:17, 22 February 2025 (UTC)[reply]

So it seems to be an issue with Module:Protection banner. Hmm... Aasim (話す（はなす）) 23:25, 22 February 2025 (UTC)[reply]

Do you still see this? I don't see that text on the bing search you linked. That said there are indeed two of them in Golan Heights (https://i.imgur.com/K3Yya6g.png), which is likely because it has 2 protection templates ({{Pp-move|small=yes}} and {{Pp-semi-indef}})- also Google does have this issue, it's just maybe rare? You can force it to search for the text in that page: [2].

I'm not planning on looking into it, just throwing out some observations. – 2804:F1...06:AD28 (::/32) (talk) 19:44, 23 February 2025 (UTC)[reply]

Awesome Aasim refers to this edit. --Redrose64 🌹 (talk) 19:52, 23 February 2025 (UTC)[reply]

Is there a way to log edits based on categories the page is in with the abuse filter? That might remove the need for this hack. Aasim (話す（はなす）) 20:07, 23 February 2025 (UTC)[reply]

Yes, this edit would do it. I would guess it's because it is marked as visibility: hidden, and in that regard it just... doesn't need to be. But either way, search crawlers are not required to observe styles applied by any CSS anywhere, so the only way to guarantee a fix for this issue is to choose not to output the text. Izno (talk) 20:11, 23 February 2025 (UTC)[reply]

Map module transfer

Hello, I am trying to transfer this map modul from the French wikipedia fr:Modèle:Géolocalisation/Scandinavie to the English wikipedia: Module:Location map/data/Scandinavia LCC map. However I can tell that the coordinates are off, because the airfields I have marked are not where they should be. The values for top, bottom, right and left on the French wikipedia differ from the values on i.e. the German, Danish, Swedish wikipedia. However, when I enter i.e. the Danish values the locations of the airfields are depicted even further away from where they are actually located. I have no tried to transfer the other information in the French module (which is the most detailed of all modules), but with no success. Could someone with more experience with map modules please have a look and check what the error is? Thank you, and thank you for your time; noclador (talk) 16:46, 23 February 2025 (UTC)[reply]

You are trying to use code from a seperate location template into an different one. It will not work. Several templates and modules have been deleted for being in use in one article.

Just use Module:Location map/data/Scandinavia. The effort to make this work is not at all worth it. Snævar (talk) 23:26, 25 February 2025 (UTC)[reply]

Huggle problem

Huggle will often place a warning on user talk pages in the incorrect section; not the current month's section. Sophisticatedevening and I left talk here: wp:Huggle/Feedback#Warning spacing bug There has not been any response. I often check and reorder warnings. Examples of misplaced warnings: [1] [2]. The default change provider XmlRcs has not been providing changes. I change to IRC or Wiki, but others don't seem to know about that solution. Is anything being done about this? Who should I ask? Thank you Adakiko (talk) 01:29, 24 February 2025 (UTC)[reply]

Extra diffs of the bug: (1 2 3) Sophisticatedevening ^(talk) 18:10, 24 February 2025 (UTC)[reply]

phab:T383968 is marked as resolved. Has that fix made it into a release yet? jlwoodwa (talk) 16:04, 25 February 2025 (UTC)[reply]

@Jlwoodwa: I am using 3.4.13 build: 4220 3.4.13. wp:Huggle/Download states that 3.4.13 is current. It would be nice if Huggle could verify that. Thank you for your reply! Adakiko (talk) 18:04, 25 February 2025 (UTC)[reply]

Default background gray color changed?

Is it just me, or is the default light gray background color suddenly much darker? I'm seeing it in the background of the left and right toolbars in Vector 2022, in the Category box at the bottom of every page, in the background of <code>...</code> tags, and in some block templates like the two at the top of #Huggle not working, above. If it's just me, never mind, but I'm pretty sure I didn't change anything. – Jonesey95 (talk) 05:34, 24 February 2025 (UTC)[reply]

@Jonesey95: Does it happen in safemode? If not then it's probably just you. There are 11 background-color in User:Jonesey95/vector-2022.css. PrimeHunter (talk) 09:55, 24 February 2025 (UTC)[reply]

In safe mode, the background color for code spans, the two templates at #Huggle not working, and the category box are still darker than I remember. Also, the unchanged parts of the page diff view have a gray background that I don't remember. The sidebars have a white background (yes, I customized those for contrast, but strangely, the background seems darker than before when I am not in safe mode). I am not complaining; I like the contrast. I just wondered if something had changed on a Sunday, an unusual time for changes. If it's not affecting anyone else, it's not a problem for me. – Jonesey95 (talk) 14:43, 24 February 2025 (UTC)[reply]

I compared directly to older versions of MediaWiki and the colors of code background or category box has not changed. It seems to be just you. Maybe you (or something automatically) changed the display color profile in your OS settings? (Or maybe you're using a different display?) Matma Rex talk 17:54, 24 February 2025 (UTC)[reply]

Bad contrast between the color of visited links and the plain text under images in dark mode

I just observed a bad contrast between the color of visited links and the plain text under images in dark mode.

This is in bright mode. Here, the hexadecimal code for the color of the visited link (Benelux) is #6960AF; and for the plain text it is #54595D.

And this is in dark mode. Here, the code for the visited link is #A29DB3; and for the plain text it is #A7A8AC.

Update: The unvisited link also had a bad contrast I think. But I forgot to screenshot it. Aminabzz (talk) 12:59, 24 February 2025 (UTC)[reply]

This seems to be related to the grayscale lines within Module:Location map/styles.css#L-53. I'd suggest asking on the talkpage there (Module talk:Location map) for help with fixing it so that it doesn't change the link-color within captions. Quiddity (WMF) (talk) 21:15, 25 February 2025 (UTC)[reply]

You are talking about the caption on the image of Benelux teams at 2024–25 UEFA Champions League#League phase. This was introduced in phab:T375994 with the code "a:where(:not([role="button"])) .cdx-mixin-link-base(); }". When a user has visited the link the link should instead be the codex link-visited color, that would fix it. The contrast now is 3:1, and needs to be 4.5:1 to meet WCAG AA. Snævar (talk) 23:04, 25 February 2025 (UTC)[reply]

As for what to do with this information, just file a phabricator bug on the web team, they did cause this issue after all. Snævar (talk) 09:40, 26 February 2025 (UTC)[reply]

Automatic Page Views count seems down

Not sure what you call this, but normally there is an automatic updated page view count at the top of each page. As of yesterday, that feature must be down. All I've been seeing is a tiny dot jiggling back and forth. Nothing else. — Maile (talk) 17:02, 24 February 2025 (UTC)[reply]

Seems to be working now. — Maile (talk) 17:27, 24 February 2025 (UTC)[reply]

For the record, it's made by the opt-in "XTools: dynamically show statistics about a page's history under the page heading" at Special:Preferences#mw-prefsection-gadgets. PrimeHunter (talk) 19:58, 24 February 2025 (UTC)[reply]

Tech News: 2025-09

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

Updates for editors

Administrators can now customize how the Babel feature creates categories using Special:CommunityConfiguration/Babel. They can rename language categories, choose whether they should be auto-created, and adjust other settings. [3]
The wikimedia.org portal has been updated – and is receiving some ongoing improvements – to modernize and improve the accessibility of our portal pages. It now has better support for mobile layouts, updated wording and links, and better language support. Additionally, all of the Wikimedia project portals, such as wikibooks.org, now support dark mode when a reader is using that system setting. [4][5][6]
One new wiki has been created: a Wiktionary in Santali (wikt:sat:) [7]
View all 30 community-submitted tasks that were resolved last week. For example, a bug was fixed that prevented clicking on search results in the web-interface for some Firefox for Android phone configurations. [8]

Meetings and events

The next Language Community Meeting is happening soon, February 28th at 14:00 UTC. This week's meeting will cover: highlights and technical updates on keyboard and tools for the Sámi languages, Translatewiki.net contributions from the Bahasa Lampung community in Indonesia, and technical Q&A. If you'd like to join, simply sign up on the wiki page.

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

MediaWiki message delivery 00:38, 25 February 2025 (UTC)[reply]

Problem with Template:RfC closure review

I introduced a line to the template that was supposed to get rid of the need to sign your posts. This was because signing at the end gave the signature in the code box and it looked horrible. So I used subst:REVISIONUSER2 to post the username of the person who deployed the template. It was supposed to be static. Unfortunately, it's dynamic. Each time someone edits, the value constantly changes. I don't want that. It's definitely a PEBKAC issue, but I can't solve it alone. What should I have written instead? Szmenderowiecki (talk) 03:56, 25 February 2025 (UTC)[reply]

@Szmenderowiecki: Please provide links to one or more of the pages where {{subst:RfC closure review}} has been used, and which now show an incorrect user name. --Redrose64 🌹 (talk) 09:05, 25 February 2025 (UTC)[reply]

You wrote {{subst:REVISIONUSER2}} but {{REVISIONUSER2}} is not coded to work with subst. Maybe it should be. PrimeHunter (talk) 09:26, 25 February 2025 (UTC)[reply]

Looks pretty simple - just needs safesubst:<noinclude /> in that template and in {{Encodefirst}}. — Qwerfjkl talk 17:37, 27 February 2025 (UTC)[reply]

Here are some diffs in the thread that provoked this question. Each link is followed by the name of the editor linked by the template:

[9] — Bluethricecreamman creates the request
[10] — GoodDay adds a comment to the request
[11] — Bluethricecreamman replies to the request
[12] — Tule-hog edits a different section
[13] — Springee replies to the request
[14] — Rsjaffe edits a different section
[15] — Springee says "hey, what's going on with the changing usernames"
[16] — Szmenderowiecki says "oops, something's wrong with the template"
[17] — Bluethricecreamman doesn't edit, but his name is now there properly, thanks to a fix by Voorts.

Redrose64, is this what you needed? Nyttend (talk) 10:33, 25 February 2025 (UTC)[reply]

Diff can't generate visually

The "Visual" comparison version of this diff (and of diffs including that edit) won't generate as expected, giving the error message:

undefined is not an object (evaluating 'attributeChanges.mw.from')

I'm on Version 16.1 of Safari Placeholderer (talk) 19:05, 25 February 2025 (UTC)[reply]

File on Phabricator. * Pppery * _{it has begun...} 19:15, 25 February 2025 (UTC)[reply]

There are many many Cannot read properties of undefined bugs open right now, phab:T317455 seems pretty close to this one, please just leave notes of another example there. In the meantime, just use the standard diff view. — xaosflux ^Talk 19:20, 25 February 2025 (UTC)[reply]
Thanks both! Placeholderer (talk) 19:51, 25 February 2025 (UTC)[reply]

Edit I didn't make

Wikipedia talk:WikiProject Spaceflight shows that I made an edit to the talk page on Feb 25 (see View History). I didn't make it - look at my contributions. What went wrong? Bubba73 ^{You talkin' to me?} 03:55, 26 February 2025 (UTC)[reply]

It shows up in https://en.wikipedia.org/wiki/Special:Contributions/Bubba73 for me. Probably you accidentally pushed the "rollback" button - I've done that many times. * Pppery * _{it has begun...} 04:30, 26 February 2025 (UTC)[reply]

Gosh, I don't remember doing it. I don't think I've even been on that page in a long time. I'm going to change my password. Bubba73 ^{You talkin' to me?} 05:02, 26 February 2025 (UTC)[reply]

@Bubba73: You were active at the time [18] and have previously been active on that page so it may be on your watchlist. You reverted a recent edit and your next edit replied to a recent post on another page you have edited before and may be watching so I guess you were using the watchlist at the time. An accidental edit sounds more likely than a hacked account. PrimeHunter (talk) 09:08, 26 February 2025 (UTC)[reply]

@Bubba73: I have, on occasion, made a rollback without intending to. I think I spotted them all at the time, but can't be certain. The circs are basically that Special:Watchlist was still loading when I clicked a "diff" link, but between me aiming the mouse pointer and actually clicking the button, the page scrolled by a line or two, moving the intended diff link away from the pointer and another link - sometimes a "rollback" link - to the same position. How does the scroll happen? At the top of the watchlist there are often some notices, which are displayed by JavaScript at a late stage in the browser's rendering. These notices push subsequent content down by at least one line each. The only cure that I know of is to wait for the page display to become stable before going for a link. --Redrose64 🌹 (talk) 19:03, 26 February 2025 (UTC)[reply]

In Preferences → Appearance → Advanced options you can enable "Show a confirmation prompt when clicking on a rollback link" to avoid mis-clicks in the future. Matma Rex talk 16:05, 26 February 2025 (UTC)[reply]

Yes, I was on at the time. I have that page on my watch list,but I don't look at it often. I have no memory of doing that reversion, or even looking at that page. I don't normally revert unless it is vandalism or a bad edit, but I must have done it by accident. I have set the "confirmation prompt" and I also changed my password, which had been the same for 6 years. Thanks, it must have been an error on my part. Bubba73 ^{You talkin' to me?} 20:02, 26 February 2025 (UTC)[reply]

Images with transparent bg behaves as white bg on Windows but correctly on other platforms

So, there are images with white elements and transparent bg that have zero contrast with the page around it. So, I sought a potential solution at Template talk:Infobox#Forcing a bg color on images with transparent bg. @Jonesey95 helped by suggesting use of |imagestyles= and it works perfectly on Mac and mobile devices but fails miserably on Windows. The transparent bg images act as if their bg were white. What's causing this? And is there a way to fix the problem I was facing in the original post that works on all platforms? Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 11:45, 26 February 2025 (UTC)[reply]

Issue w/ the User page template

i noticed that when the user page template has the color=black and rounded=yes, the rounded part of the template appears to not work

without color=black:

This is a Wikipedia user page.
This is not an encyclopedia article or the talk page for an encyclopedia article. If you find this page on any site other than Wikipedia, you are viewing a mirror site. Be aware that the page may be outdated and that the user whom this page is about may have no personal affiliation with any site other than Wikipedia. The original page is located at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical).

with color=black:

This is a Wikipedia user page.
This is not an encyclopedia article or the talk page for an encyclopedia article. If you find this page on any site other than Wikipedia, you are viewing a mirror site. Be aware that the page may be outdated and that the user whom this page is about may have no personal affiliation with any site other than Wikipedia. The original page is located at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical).

Placement of the color=black doesn't appear to change anything, and nether does the color.

is there something I'm missing? 50.86.195.178 (talk) 17:00, 26 February 2025 (UTC)[reply]

Perhaps it's because |color= is an unrecognized parameter for the template?

|border-c= and |background= are the two available color-related parameters I'm seeing. DB1729^talk 17:15, 26 February 2025 (UTC)[reply]

There was a misplaced semicolon in the code. I fixed it, which means that the error demonstrated above is no longer happening (the second box did not have rounded corners). |color= is a valid parameter; it just wasn't working:

This is a Wikipedia user page.
This is not an encyclopedia article or the talk page for an encyclopedia article. If you find this page on any site other than Wikipedia, you are viewing a mirror site. Be aware that the page may be outdated and that the user whom this page is about may have no personal affiliation with any site other than Wikipedia. The original page is located at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical).

– Jonesey95 (talk) 17:26, 26 February 2025 (UTC)[reply]

Thanks! :) 50.86.195.178 (talk) 17:48, 26 February 2025 (UTC)[reply]

Article infobox vs talk page category

How can I make a list of articles currently in Category:Medicine articles needing infoboxes, but which shouldn't be, because there's already an infobox in the article? WhatamIdoing (talk) 00:34, 27 February 2025 (UTC)[reply]

@WhatamIdoing:

– DreamRimmer (talk) 04:51, 27 February 2025 (UTC)[reply]

Thank you, @DreamRimmer! The list was so much shorter than I expected that I have just fixed them all manually. I really appreciate it. WhatamIdoing (talk) 05:16, 27 February 2025 (UTC)[reply]

Trying to install Move+

I added the exact script string from the Move+ page here, bypassed cache completely, and still, nothing is appearing. What did I do wrong? Rexophile (talk) 01:37, 27 February 2025 (UTC)[reply]

Resolved at Wikipedia:Help desk#Trying to install Move+. PrimeHunter (talk) 22:43, 27 February 2025 (UTC)[reply]

Party composition tables on Althing not working properly

On the page for Althing, the legislature of Iceland, there is this neat graphical overview of party composition of parliament since the founding of the republic. It's basically just a bunch of tables inside of a larger table. I wanted to copy this over to the Icelandic language Wikipedia (see draft under my user space there), but I have noticed that this table breaks down on narrow screens which makes it unusable on most mobile devices. I would expect it to adapt to the screen size but what happens at a certain point when you narrow down the screen is that the bars all become uneven. It's the same on all browsers I have checked. I have not found anything obvious in the table syntax but I'm no expert there. Is there a way to make it function as intended? Bjarki (talk) 10:45, 27 February 2025 (UTC)[reply]

"Prompt me when entering a blank edit summary (or the default undo summary)" not working when editing the lead section

I am having trouble with the "Prompt me when entering a blank edit summary" preference when editing the lead section of an article.

Working properly: If I go to Mid-Canada Line Site 060 Relay, click Edit at the top of the article to edit the full article (the "Edit" link between "Read" and "View history"), type a space character somewhere in the article, and then try to save, I am given a new Preview screen with a message at the top: "Reminder: You have not provided an edit summary. ..."

Working properly: If I click the [edit] link next to the References section, type a space character somewhere in the article, and then try to save, I am given a new Preview screen with a message at the top: "Reminder: You have not provided an edit summary. ..."

Not working properly: If I click the [edit] link next to the lead section (in Vector 2022, this link is above the "View history" link), type a space character somewhere in the article, and then try to save, the edit is saved. I should get the same prompt.

Please see this test edit for an example.

Can others reproduce this problem? I have the gadget "Add an [edit] link for the lead section of a page" enabled, of course. I am using Vector 2022 and the old-school editor (I do not have any of the "Editor" options enabled under Preferences - Editing - Editor). – Jonesey95 (talk) 16:43, 27 February 2025 (UTC)[reply]

The gadget adds a fake edit summary; if you just use &action=edit&section=0 you will get prompted for an edit summary. Perhaps it is better to replace the gadget by a user script that does not include a fake edit summary. —Kusma (talk) 16:54, 27 February 2025 (UTC)[reply]

This goes right back eleven years to this edit. The &summary= query string parameter is treated by the MediaWiki software as if it were a user-entered edit summary. Hand up: it was my idea, suggested on this page. --Redrose64 🌹 (talk) 19:12, 27 February 2025 (UTC)[reply]

Annoying "global contributions" in sidebar

Tracked in Phabricator
Task T385086

Is this new? I accidentally click it all the time instead of the "user contributions" line just above it, and it invariably gives an error ("Error loading data from some wikis. These results are incomplete. It may help to try again."), displays things weirdly (the Wikipedia namespace is called "Meta", so I supposedly have an edit to "Meta:Articles for deletion/Acacia Forgot" when what is meant is "Wikipedia:Articles for deletion/Acacia Forgot", and on Commons I also supposedly edited " Meta:Deletion requests/File:Tintin Tibet.jpg" instead of "Commons:Deletion requests/File:Tintin Tibet.jpg". Whose idea was it to put a very buggy version of [19] (which actually works mich better) into such a high-visibility spot, and can it please be removed again? Fram (talk) 17:02, 27 February 2025 (UTC)[reply]

I also accidentally click this a lot and usually regret it. I would prefer not to see it in the default sidebar; is there a way to turn this off via user JS/CSS? —Kusma (talk) 17:10, 27 February 2025 (UTC)[reply]

@Kusma: The link can be hidden with this in your CSS:

#t-global-contributions {display:none;}

PrimeHunter (talk) 18:55, 27 February 2025 (UTC)[reply]

@Fram: It's sort-of new (like about four weeks), see Wikipedia:Village pump (technical)/Archive 218#New button in IP contrib page, dead link. --Redrose64 🌹 (talk) 19:20, 27 February 2025 (UTC)[reply]

Thanks. So it only really works on Meta but is deployed here and elsewhere anyway, typical. For every decent rollout they still have to include such unwanted buggy stuff apparently. Fram (talk) 09:33, 28 February 2025 (UTC)[reply]

Just noticed that the "diff size" indicator (the bold green "(+215,678)") is completely wrong as well, showing the page size instead of the diff size. Please get this off enwiki again. Fram (talk) 16:49, 28 February 2025 (UTC)[reply]

That would be T385377. * Pppery * _{it has begun...} 16:53, 28 February 2025 (UTC)[reply]

Why isn't the "subscription only" icon showing up? A few questions

The main ref for Tomb of Thutmose II is to an article in a subscription-only magazine. I added that article-url-access information to the ref here but the lock icon isn't showing up. So, my questions are 1)What did I do wrong? and 2)Bibliography doesn't seem to be quite the correct heading for the Litherland citation but I can't figure out what would be better & 3)Do the linkages for Theban necropolis and Landmark of Luxor have the correct placement within the page? Thanks - Shearonink (talk) 17:19, 27 February 2025 (UTC)[reply]

You forgot the pipe (|). And it should be |url-access=.

—Trappist the monk (talk) 17:32, 27 February 2025 (UTC)[reply]

Trappist the monk Ah that pesky "l" of "html" had me fooled. Thanks! Any ideas about my other two questions? - Shearonink (talk) 17:45, 27 February 2025 (UTC)[reply]

If the page-range specified in the long-form Litherland citation is correct (the whole range), it seems odd to me that note 1 and note 3 echo that range. Shouldn't those two specify a single page or a range of fewer pages than the whole? Aslo, |date= in the long-form template should be |date=Autumn 2023.

Bibliography is a perfectly acceptable heading.

For navbox placement, see MOS:NAVLAYOUT and linked topics.

—Trappist the monk (talk) 18:03, 27 February 2025 (UTC)[reply]

As to the page ranges for cite 1 & 3, I agree, but since the reference is subscription only and I am not a subscriber I am unable to check it. - Shearonink (talk) 18:10, 27 February 2025 (UTC)[reply]

The first reference to Litherland is at this edit. You might want to consult with Editor Udimu who made the edit.

—Trappist the monk (talk) 18:24, 27 February 2025 (UTC)[reply]

-Hi there, not fully sure where the problem is. The article is from 2023 and just four pages long, page 28 to 31. This was the first publication of this tomb in print and the author suggested already that it is the tomb of king Thutmose II. Now, one year later, the media report on that.Udimu (talk) 18:34, 27 February 2025 (UTC)[reply]

We presume that you have access to the Litherland source. The issue is that references note 1 and note 3 both specify pages 28-31; the whole page range of the Litherland article. Surely it is not necessary to specify all four pages to support "The tomb of Thutmose II, discovered in 2022" (note 1) and " published in a preliminary report in the following year" (note 3). If, for some reason, all four pages are required for both of those, they can/should be combined into a single {{harvp}} reference. Otherwise, notes 1 and 3 should be fixed so that they specify only those pages in Litherland that directly support the text in our article. Am I making sense?

—Trappist the monk (talk) 18:56, 27 February 2025 (UTC)[reply]

I shortened the first note to page 28. Note 3 is a reference about the publication of the tomb, in a short report. I was not sure whether i should give the page numbers too or whether it is fine to have no page numbers at all. The full reference to the article appears in the bibliography. Please feel free to change that. Yes, i have the article in print. The journal is quite widely distributed. I am a bit surprised that no one else here, writing on Ancient Egypt does not have access to the journal. best wishesUdimu (talk) 19:15, 27 February 2025 (UTC)[reply]

Discussion at Wikipedia talk:AutoWikiBrowser/Regular expression § RegEx question

You are invited to join the discussion at Wikipedia talk:AutoWikiBrowser/Regular expression § RegEx question. Sdkb ^talk 18:39, 27 February 2025 (UTC)[reply]

Ifexist and wikitext in template parameters

The code I just added to the Template:Wikipedia Library works like what I want ...as long as the parameter is a single word and doesn't contain the wikitext formatting that I want. For example:

Access to Book is available for free through The Wikipedia Library via Partner.

Access to Name of Book is available for free through The Wikipedia Library via Name of Partner.

Access to Book is available for free through The Wikipedia Library via Partner.

{{Wikipedia Library|name=''Book''|partner=[https://wikipedialibrary.wmflabs.org/partners/80/ Partner]}}

Access to Book is available for free through The Wikipedia Library via Partner.

What am I doing wrong? WhatamIdoing (talk) 18:53, 27 February 2025 (UTC)[reply]

You cannot combine wikitext with ifexist. It must be the pagename.

Not sure about the spaces question. Izno (talk) 19:00, 27 February 2025 (UTC)[reply]

@WhatamIdoing: {{#ifexist:foo|...}} tests for existence of a wiki page called foo, not a parameter called foo. Use {{#if:{{{foo|}}}|...}} to test whether the parameter foo is set and not empty. Note the pipe right after foo. PrimeHunter (talk) 19:08, 27 February 2025 (UTC)[reply]

Thank you! (And of course it looked like it was working, since the parameter names are all simple words...) WhatamIdoing (talk) 19:27, 27 February 2025 (UTC)[reply]

Locator map showing Null Island not Western Australia

Henry Street, Fremantle shows a locator map consisting entirely of water. Zooming out it appears to be displaying the location of Null Island rather than Western Australia. There are no coordinates or explicit map call on the page that I can see. The article does transclude Template:Infobox Australian road, the documentation for which says that the locator map is automatic if the Wikidata item includes coordinates. d:Q16342680 does indeed contain coordinates (32°3'19.19"S, 115°44'39.06"E) but keen observers will spot that those are not the coordinates of Null Island. Thryduulf (talk) 22:30, 27 February 2025 (UTC)[reply]

Expand arrows in section table of contents flash black/white when loading

Tracked in Phabricator
Task T387351

Perhaps this is a THURSDAY issue. It's not a dark theme-dependent bug, as I first guessed. See screenshots.

Light theme
In dark theme

Jay Cubby 22:36, 27 February 2025 (UTC)[reply]

As The wub noted with the 'tracked' template, this is tracked at phab:T387351. And thanks to Matma Rex for refactoring the image layout, which I was just about to do! Quiddity (talk) 01:26, 28 February 2025 (UTC)[reply]

Thanks to those of you who placed the Filed in Phabricator piece and formatted the photograph nicely. I did a brief scroll but didn't see anything in the Phab Pheed. Jay Cubby 01:56, 28 February 2025 (UTC)[reply]

my IP address has been blocked

I am fairly new to WikiMedia , and my IP address was blocked a month after I joined. I am trying to submit an unblock request here: https://meta.wikimedia.org/wiki/Special:Contact/Stewards?wpSubject=%5BWizard%5D%20Block%20appeal&wpText=%2ABlock%20message%3A%20%3Cpaste%20message%20here%3E%0A%0A%2AReason%3A%20%3Cinsert%20your%20reasoning%3E&wpIncludeIP=1

I see the following message: https://utrs-beta.wmflabs.org/public/appeal/account <<Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis. The block was made by ‪Jon Kolbert‬. The reason given is Open proxy/Webhost: See the help page if you are affected . Start of block: 2023-08-27T11:16:05 Expiry of block: 2026-08-27T11:16:05 Your current IP address is 23.106.56.13. The blocked range is 23.106.48.0/20. AND Your account or IP address has been blocked. 23.106.48.0/20, you have been blocked by ‪XXBlackburnXx‬ until 15:16, 27 August 2026, because: Open proxy/Webhost: >>

I use Brave browser for WikiMedia. Is it possible, that some features of this browser change my IP?

I do not even know, what Open Proxy is. It seems, that my IP is within some previously blocked range. Could it be unblocked?

but I get the following error message: <<The following errors occurred: The hiddenip must be a valid IP address.>>

Where do I go from there? — Preceding unsigned comment added by Smilin8Budda (talk • contribs) 23:25, 27 February 2025 (UTC)[reply]

If you posted here, you are not affected by a block. 331dot (talk) 23:51, 27 February 2025 (UTC)[reply]

331dot's comment aside, you probably have the Brave VPN turned on if you are using Brave. Izno (talk) 00:19, 28 February 2025 (UTC)[reply]

Several episode lists are over the PEIS limit

As you can see in [20], starting around 19 February, a lot of List of episodes pages started going over the WP:PEIS limit. I fixed a few of them manually at first, but the timing makes me think that something in Module:Episode list or Module:Episode table was changed that made them break the pages. In fact, Module:Episode list was edited on 20 January, and while I have no way of knowing if those edits caused the problem, I think someone who knows Lua should check them out. Nickps (talk) 00:42, 28 February 2025 (UTC)[reply]

Previewing Lady Gaga with old versions of the modules mentioned still exceeds 2MB expansion size so it's not recent edits to them. Previewing the article after deleting everything except the external links section uses 892KB (42% of the limit). The article has 542 references and they use quite a lot of the expansion size. I seem to recall that an ugly trick of using #invoke to bypass the citation templates used to work but I can't find it documented anywhere. Johnuniq (talk) 02:25, 28 February 2025 (UTC)[reply]

Lady Gaga is not a list of episodes article. List of Flash Gordon comic strips, List of On Patrol: Live and On Patrol: First Shift episodes, List of CID episodes: 2010–2014 and many more from that list are the ones you should have checked.

About Lady Gaga though, I did apply the fix you're talking about here and it was reverted so I won't bother with that page again. Nickps (talk) 02:32, 28 February 2025 (UTC)[reply]

@Johnuniq: (ping since I don't know if you subscribed) Nickps (talk) 02:36, 28 February 2025 (UTC)[reply]

I've fixed Lady Gaga by using {{navboxes top}}, which brought it down to 1.7M. * Pppery * _{it has begun...} 02:39, 28 February 2025 (UTC)[reply]

Previewing List of Flash Gordon comic strips as above shows that recent edits to the two modules are not responsible. The design of {{Episode table}} is convenient and effective but it inherently uses a lot of expansion size. Using a template for each row which invokes a module, and a surrounding template which invokes another module means the table wikitext is expanded four times. I don't have time to think of a fix at the moment. I see mention in the doc of using a manual table but have not investigated. Johnuniq (talk) 02:54, 28 February 2025 (UTC)[reply]

OK, thank you for checking. I still think it's strange that all of these articles went over PEIS so close to each other. It could be that one of the dependencies of the modules was changed which caused the problem, or it may be just a coincidence. I guess I'll have to keep fixing them manually. Nickps (talk) 03:08, 28 February 2025 (UTC)[reply]

On second thought, I can actually prove that a transcluded page caused the problem. List of Forged in Fire episodes was last edited on 2 January but was added to Category:Pages where post-expand include size is exceeded on 26 February. A transcluded page being changed is the only possible explanation for this and the two previously mentioned modules are the most likely candidates. Unfortunately, that means that the change happened on one of the dependencies of these modules rather than the modules themselves which makes it basically impossible to find. Nickps (talk) 03:20, 28 February 2025 (UTC)[reply]

Regardless of why this is happening, the easy fix is to use |dontclose= on the episode table. See Template:Episode table#Parameters. * Pppery * _{it has begun...} 03:51, 28 February 2025 (UTC)[reply]

I'm aware. Still, I thought I should at least try to have the underlying issue fixed rather than just alleviate the symptoms. Nickps (talk) 03:55, 28 February 2025 (UTC)[reply]

And I got reverted. |dontclose=y is pointless if the editor base doesn't want to use it. The underlying problem should be fixed instead. Nickps (talk) 04:36, 28 February 2025 (UTC)[reply]

I suspect TAnthony was working on this change and undoing the changes in your intermediate edit was collateral damage. PrimeHunter (talk) 08:40, 28 February 2025 (UTC)[reply]

That's possible I guess. I'll have to ask him on the talk page. I might do that later. Still, this only proves my point that we should be looking for the change that caused the PEIS of these pages to go up instead of trying to fix them manually. People just don't care enough about this kind of problem. Nickps (talk) 12:03, 28 February 2025 (UTC)[reply]

Hey there, PrimeHunter is correct that my revert was unintentional. Seeing this now though, I'm new to this PEIS issue and honestly, don't understand it. Visually, Nickps's edit just added an extended space between the section heading and the table, what is the underlying issue that was fixed? And why is it applied to only one of the many tables in this list? Thanks.— TAnthony^Talk 15:58, 28 February 2025 (UTC)[reply]

I only applied it once because that was enough to fix the problem. Applying it to all the tables would probably have been better for future-proofing though. Honestly, you don't need to care about this at all if the changes in {{start date}} and {{end date}} that actually caused it get reverted. Nickps (talk) 16:25, 28 February 2025 (UTC)[reply]

It could be the changes to {{start date}} and {{end date}}, added to verify input. – Jonesey95 (talk) 14:32, 28 February 2025 (UTC)[reply]

@Jonesey95 Testing with Special:TemplateSandbox on List of Pokémon episodes (seasons 14–present) (which is still over the limit even after dontclose and using the modules), revealed that you're right. I'll request those edits be reverted. Nickps (talk) 15:07, 28 February 2025 (UTC)[reply]

The request is in Template talk:Start date#Template-protected edit request on 28 February 2025. Nickps (talk) 15:15, 28 February 2025 (UTC)[reply]

I have modified {{end date}} to use what seems like a less processor-intensive check that is used by {{start date}} (if that makes sense). I would like to see if that helps, because the validation has been helpful in unearthing template errors in 4,000+ articles. Using |dontclose= seems to make a much bigger difference; it reduced the PEIS from 2.0 to 1.3 on one article I edited. And that Pokemon article may just be trying to do too much; it was already using PEIS-reduction hacks everywhere possible, which means it is probably past time for a split. – Jonesey95 (talk) 18:00, 28 February 2025 (UTC)[reply]

@Jonesey95 The combination of using |dontclose=y and switching from {{episode list}} to {{#invoke:episode list|list}} can cut the WP:PEIS by 75%. Using {{#invoke:episode list|sublist}} can cut it even further on pages like the Pokemon example where the list is transcluded from another page. --Ahecht (TALK
PAGE) 20:05, 28 February 2025 (UTC)[reply]

@Jonesey95 The issue isn't how processor intensive it is, the issue is the amount of text it's now outputting. In this case, the current version of {{End date|1993|02|24|08|30|23|Z}} is 629b, the [[Special:Permalink/1203900750|old version] was 436b. Multiply that difference by 2 for {{#invoke:Episode list|list}}, by 2 for {{episode list}}, by 2 for {{#invoke:episode table|table}}, by 2 for {{episode table}}, and then by 2 when it's transcluded onto a "List of XXX seasons" article, and you've now increased the size of the page by 6kb for each {{end date}} template being used. --Ahecht (TALK
PAGE) 21:03, 28 February 2025 (UTC)[reply]

References not rendering properly

Tracked in Phabricator
Task T387608

Suddenly references inside the {{notelist}} started appearing as ?'"`UNIQ--ref-0000003E-QINU`"'? on 2024 Men's T20 World Cup Super 8 stage, I'm guessing WP:THURSDAY... Vestrian24Bio 07:40, 28 February 2025 (UTC)[reply]

Is the problem still there? Searching that page for "UNIQ" did not find anything. Johnuniq (talk) 07:53, 28 February 2025 (UTC)[reply]

It's the Parsoid renderer, appears fine with the legacy renderer. Vestrian24Bio 07:53, 28 February 2025 (UTC)[reply]

Vestrian24Bio 08:12, 28 February 2025 (UTC)[reply]

This is a software bug that should be reported on Phabricator. * Pppery * _{it has begun...} 19:46, 28 February 2025 (UTC)[reply]

Indeed, there has been recent work on Cite by WMDE. Izno (talk) 00:10, 1 March 2025 (UTC)[reply]

phab:T387608. Izno (talk) 00:17, 1 March 2025 (UTC)[reply]

Year in South Africa

There's been a recurring problem of late with a user creating new "YYYY in South Africa" articles for years in the 17th and 18th centuries, when it's not actually clear that "South Africa" would have been the correct name of anything at that time (as opposed to things like "Cape Colony", "Colony of Natal", and on and so forth) — but because they're using the {{Year in South Africa}} template on them, which is coded to autogenerate categories based on the year stated in the template, I'm getting constantly smacked in the face with "YYYY in South Africa" redlinks at Special:WantedCategories — but they each only have the one page in them, and are thus uncreatable in that form, leaving me with no choice but to go in to each and every page, wrap the template in {{suppress categories}} to make the redlinks go away and tag the page as uncategorized.

As always, templates really shouldn't be transcluding categories based on variables, per WP:TEMPLATECAT, but obviously it might pull other pages out of legitimate categories that do exist if this function was simply removed from the template entirely without careful preparation. So could somebody more versed in template coding than I am edit that template to ensure that at the very least it can't generate any categories that don't exist to have pages in them? Thanks. Bearcat (talk) 08:19, 28 February 2025 (UTC)[reply]

Fixed. * Pppery * _{it has begun...} 19:59, 28 February 2025 (UTC)[reply]

Body text not affected by font size CSS

In my global.css, I have a rule that slightly increases the font size and changes the default font. The font-family rule works fine, but the font-size one has stopped working within the main body. Previously the font-size rule affected the article portion of the page but not the sidebar, but now this is reversed. I think this changed within the past day (I could be wrong about that, though). I've attached a screenshot with an exaggerated font-size increase that shows clearly that the font-family rule works everywhere (the font is now Courier New, other than in the code display, which I've changed in my browser) but the font size doesn't work properly. I'm using Firefox 135.0.1 on Windows 10. Suntooooth, it/he (talk/contribs) 11:35, 28 February 2025 (UTC)[reply]

@Suntooooth: Using a type selector like body is a very low specificity, it's easily overridden by rules having selectors of even a moderate specificity. In this case, I think that it's being overridden by this rule:

.vector-body {
    font-size: 0.875rem;
    line-height: 1.6;
}

which uses a class selector. To override that, you should use a selector with a specificity that is equal to or higher than a class selector. I suggest replacing your single rule

body {
	font-family: Atkinson Hyperlegible, sans-serif;
	font-size: 1.1em;
}

with two rules:

body {
	font-family: Atkinson Hyperlegible, sans-serif;
}
div.vector-body {
	font-size: 1.1em;
}

which has a specificity higher than either a type selector or a class selector alone. --Redrose64 🌹 (talk) 19:13, 28 February 2025 (UTC)[reply]

Thank you for the suggestion - when I did my global.css I did look for an alternative way to do it but couldn't figure it out - although I'm still confused about what could've changed recently to make it affect the sidebar but not the rest of the page. It's not important to know, but I'm curious. Suntooooth, it/he (talk/contribs) 19:40, 28 February 2025 (UTC)[reply]

Every so often, changes are made to the MediaWiki software or the skins. We're sometimes told about these (see the Technical news sections on this page), but not always. Often, a change occurs that takes people by surprise, and it's rather difficult tracing exactly what changed, when and indeed why. We either live with it, or try to make a workaround. --Redrose64 🌹 (talk) 22:18, 28 February 2025 (UTC)[reply]

[Small clarification] Hundreds of changes are made to the MediaWiki software almost every week of the year! E.g. Last week's automated summary of the merged patches that week, at mw:MediaWiki 1.44/wmf.18, has ~400 merged patches. Some of those patches are tiny, and some are epic in scope. In contrast, the weekly m:Tech/News newsletter only highlights a handful of the most important/useful changes (and it's always difficult deciding what belongs). Redrose64 probably knows all of this already, but I hope the added context helps someone reading this thread. :-) Quiddity (WMF) (talk) 00:39, 1 March 2025 (UTC)[reply]

The relevant task would be something in the penumbra of phab:T363845. Izno (talk) 00:21, 1 March 2025 (UTC)[reply]

I think the change in behavior comes from this change last week: [21] which changed the CSS unit used for font size from em to rem (see Em (typography)#CSS). Since em is relative to the parent element, but rem is relative only to the root element, your overrides for body no longer had any effect. You can update your override to use html in the selector instead of body – since <html> is the root element in HTML documents, that will make it apply again. Matma Rex talk 05:58, 1 March 2025 (UTC)[reply]

Thank you! I don't know how I didn't think of using html as the selector :P Suntooooth, it/he (talk/contribs) 10:38, 1 March 2025 (UTC)[reply]

OpenStreetMap Issue in Wikipedia Article

Wikidata entry for Crescent Head https://www.wikidata.org/wiki/Q5184368 and the map border for Crescent Head https://www.openstreetmap.org/relation/6063482. Everything looks right but on the Wikipedia article it shows just blue ocean in the middle of nowhere https://en.wikipedia.org/wiki/Crescent_Head,_New_South_Wales. Thank you for your help. Dragon8870 (talk) 13:48, 28 February 2025 (UTC)[reply]

Noting that Template:Infobox Australian place and Module:Australian place map are in use here and could be affecting the output. Primefac (talk) 13:58, 28 February 2025 (UTC)[reply]

Welcome to Wikipedia! Not related to your issue, but useful to know: if you want to link to a page on Wikipedia, instead of copy-pasting the entire link you can put the article title in double square brackets (for example, typing [[Crescent Head, New South Wales]] creates a link that looks like this: Crescent Head, New South Wales). You can find a cheatsheet for similar formatting tricks at this page :] Suntooooth, it/he (talk/contribs) 15:01, 28 February 2025 (UTC)[reply]

Odd, the mapframe map displays properly if I preview a null edit of the article but goes back to solid blue if I save the null edit. It also displays properly if one clicks on the map to expand it. Deor (talk) 17:25, 28 February 2025 (UTC)[reply]

@Deor, Dragon8870: The OpenStreetMap listing was missing the Wikipedia and Wikidata tags, so I added those a few hours ago but it didn't seem to fix anything. If it's working now, it may have been a caching issue since I can't see that anything else has changed. --Ahecht (TALK
PAGE) 19:42, 28 February 2025 (UTC)[reply]

It takes a few hours as the Wiki map servers take a little while to sync from OSM. Looks good now. Regs, The Equalizer (talk) 22:21, 28 February 2025 (UTC)[reply]