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

Enhanced editnotice loader

I worked on a module that would serve as an enhanced editnotice loader for Wikipedia. See testwiki:Module:Editnotice_load and Module:Editnotice load (which is an exact copy). Features include category editnotices, better group notices, and editnotices by page ID (which would reduce the need to move pages around).

I want to get further feedback on this loader before it inevitably gets implemented. Please check out the testwiki. It should be backwards compatible with the way we do things, but I would like checks for this first.

If this is to be implemented, there will need to be a couple of changes made, including to:

Template:Editnotice load (would need to be replaced with {{#invoke:editnotice load|main}})
Template:Editnotice load/notext (would need to redirect to Template:Editnotice load, or should call {{editnotice load}} but with the parameter "notext=yes")
Template:Editnotice/notice (would need to be updated to match that on testwiki)
MediaWiki:Noarticletext-nopermission (should be updated with the following addendum: {{#invoke:editnotice load|protectionEditnotice}})
MediaWiki:Protectedpagetext (would need to be updated to match that on testwiki)
MediaWiki:Cascadeprotected (would need to be updated to match that on testwiki)
Template:Editnotices/Group/Template:Editnotices (would need to be updated to match that on testwiki)
MediaWiki:Titleblacklist-custom-editnotice (would need to be updated to match that on testwiki)

This would make the editnotice loader much more robust.

Immediately, in preparation for this, I would consider adding the following category editnotices templates:

Template:Editnotices/Category/Disambiguation pages

Anything else? Awesome Aasim 19:06, 9 September 2024 (UTC)[reply]

Some documentation on how it works from a user's perspective would be helpful, in order to understand the context and how it would be used in practice, including how security restrictions are enforced. On a side note, I'm not sure that its deployment is "inevitable". isaacl (talk) 22:03, 9 September 2024 (UTC)[reply]

I have some testcases on testwiki. For best results, view when logged out and inspect the HTML when logged in.

testwiki:Taylor Swift should be a good example of me getting category editnotices working. testwiki:Protected title and testwiki:Protected title2 show the protection editnotice on both the create screen and on the "does not exist" screen when a title is protected from creation for other reasons.

testwiki:Special:EditPage/A should show the page notice from testwiki:Template:Editnotices/PageID/54370 (which is for A). You can also see I renamed previous "page notice"s to "title notice"s because the way page notices are bound to currently are actually to titles, not pages. The new "page notice" will remain bound to a specific page because it uses PageID. There will be no need to update the title notices for pages that exist. On the other hand, for pages that don't exist, the title notice will need to be kept up to date. Awesome Aasim 04:01, 10 September 2024 (UTC)[reply]

I can't tell from the article page how to use the feature: where the edit notice lives, how will access be limited, and so forth. Thus it's hard to evaluate the feature without knowing the maintenance cost. isaacl (talk) 09:58, 10 September 2024 (UTC)[reply]

The editnotices live in the same pseudo-space: Template:Editnotices/. See testwiki:Module:Editnotice load/config.

I also moved the editnotice links to a collapsible box because the number of creatable editnotices has gotten relatively high after adding category notices. Awesome Aasim 13:16, 10 September 2024 (UTC)[reply]

OK, I see there's now a link above the edit notice point to its location, so category-based notices are grouped under a "Category" subpage. What are the enhancements for the group-based notices? isaacl (talk) 18:33, 10 September 2024 (UTC)[reply]

There is less ambiguity in how they are handled. For example, on testwiki:Template:A/B/C/D/E, there are five different group editnotices that can be created. So if there is a page where it is desirable that the group Template:A/B needs one group notice, and Template:A/B/C needs another group notice, and Template:A/B/D needs another group notice, that can now be done; there will be one common group notice and two separate group notices for subpages. Awesome Aasim 19:21, 11 September 2024 (UTC)[reply]

I would suggest to phase the rollout into stages, and creating a test plan to ensure nothing regressed. Editing this many interface pages and fully protected templates at once sounds like too much work for an admin to volunteer to. For instance, the specific category editnotices you mention can be left for later as we already have a decent system to handle those categories.
Immediately, in preparation for this, I would consider adding the following category editnotices templates this cannot be done immediately as they also need to be removed from Module:Mainspace editnotice, else they would show up twice when the rest of the changes are deployed. – SD0001 (talk) 08:01, 10 September 2024 (UTC)[reply]

I actually think this might be something that is better done all in one go. Removing the two category editnotices from Module:Mainspace editnotice should be kind of a no-brainer after the rollout. The way that the module currently does these checks, checking the unparsed wikitext, currently sucks.

Do you have an idea for a Scribunto test runner for Module:Editnotice load to ensure that everything works with demo editnotices? Awesome Aasim 16:53, 13 September 2024 (UTC)[reply]

I haven't noticed any bugs or regressions yet, if someone could take a second look at my code maybe then we will be able to identify potential problems. Awesome Aasim 12:52, 2 October 2024 (UTC)[reply]

I submitted an edit request. I think this is something that could be botted by an admin opening up 8 edit windows and then saving all of the proposed changes at once. I have done this before, it gets annoying when you get rate limited but it is not impossible. Awesome Aasim 20:05, 8 October 2024 (UTC)[reply]

Earwigs copyvio tool is down

What it says on the tin. The Earwig is aware of this. Whenever anyone tries to use the tool, they get this message most of the time: An error occurred while using the search engine (Google Error: HTTP Error 429: Too Many Requests). Note: there is a daily limit on the number of search queries the tool is allowed to make. You may repeat the check without using the search engine.

Obviously, there's a bit of tomfoolery around hitting the limit, which is apparently shared by all users of Wikipedia. There was some discussion in the WMF section of the pump a few weeks back about what the WMF can do about it. I'm mostly interested in what we can do in the meantime while it gets fixed. I dream of horses (Hoofprints) (Neigh at me) 00:56, 29 September 2024 (UTC)[reply]

You could do your own search engine search for snippets of text from the article. One sentence from each paragraph should give an indication of problems. And you can tick the box on the tool to limit the check. Graeme Bartlett (talk) 05:49, 29 September 2024 (UTC)[reply]

This is the message I get every time I try to use Earwig check tool since early 2024. It's always over the limit. I've asked Earwig about it multiple times and I think the problem is that bots can use it and they are causing it to hit its daily limit pretty early in the day. I wish bots could get booted of so that regular editors would have access to the tool but I have yet to see any change. I don't even try to use it any more. Liz ^{Read! Talk!} 22:43, 29 September 2024 (UTC)[reply]

It does work for me quite often, probably as I am in a different time zone. You may have to await the end of the "day", and try again. Graeme Bartlett (talk) 22:47, 29 September 2024 (UTC)[reply]

@Liz: There's a message from Chlod saying The Right People are aware and working on a way to authenticate. I'm sure that'll boot the bots off.

@Graeme Bartlett: I was thinking more of an alternative tool that we can use instead? Like, how does CopyPatrol work? I dream of horses (Hoofprints) (Neigh at me) 04:57, 2 October 2024 (UTC)[reply]

Perhaps the bot behind this tool is what is exhausting Google? I don't know/ https://meta.wikimedia.org/wiki/CopyPatrol It also uses turnitin, and you can tick that box on earwig. But its findings show less than Google search. Graeme Bartlett (talk) 06:07, 2 October 2024 (UTC)[reply]

There is some documentation that indicates that a bot is going through recent changes and marking the likely copyright cases to copypatrol. Looking at a single page, surfacing results for that page like that is less traffic than letting several users query that same page. I would say Copypatrol should be used for english wikipedia and other supported projects, but earwigs tool when copypatrol does not support the project. Snævar (talk) 01:15, 3 October 2024 (UTC)[reply]

@Graeme Bartlett and @Snævar: CopyPatrol uses TurnItIn, not google (unlike Earwig, which uses both Google and TurnItIn). Probably why it shows less (which is a bit of a problem), but perhaps it is a stop gap measure. My main concern about CopyPatrol is that it's more useful for individual edits and not an entire article. I dream of horses (Hoofprints) (Neigh at me) 22:07, 3 October 2024 (UTC)[reply]

Sigh... Where is this guesswork coming from? meta:CopyPatrol says it uss User:EranBot that uses both google trough Earwin and Turnitin. Read both links. Could you stop this guesswork nonesence and stick to facts? You are starting to annoy me. Also if you put an diff into earwigs tool it checks the whole article, not just the diff in question. Do not just repeat nonesence when proven otherwise. Snævar (talk) 09:37, 8 October 2024 (UTC)[reply]

Help Escalating security issue with Webauthn

Tracked in Phabricator
Task T358771

With the help of WMF staff we identified a critical issue with webauthn that is likely locking users out of their accounts. The issue prevents webauthn activated on a device from being used on another device, or between browser sessions. This means users can be activating webauthn , intending to secure their account, and end up losing access to wikipedia. Because relatively few users activate this feature in the short term, the issue may not be getting the attention it deserves. It will also discourage future users from activating webauthn, which is a critical security feature to protect the community.

Please help me find the appropriate contact with WMF technical staff to help get the fix merged. It's a one-line fix from upstream repository so it should be low risk. Tonymetz 💬 16:50, 3 October 2024 (UTC)[reply]

I guess that would be us, the Platform Team. I'll raise it with the team and we'll have a look. Matma Rex talk 19:30, 3 October 2024 (UTC)[reply]

Thanks for the note, webauthn has multiple known issues and is certainly in the "experimental" role. As far as our contributors and readers here at the English Wikipedia go: webauthn shouldn't be used by anyone for anything important. Technical reports in phabricator are of course welcome. — xaosflux ^Talk 00:09, 5 October 2024 (UTC)[reply]

thanks for the context. On the ticket , Reddy mentioned it was completed by a contractor and hasn't been supported. To whom could I appeal to have it turned off? I believe it's locking people out, so it's a liability. Tonymetz 💬 18:00, 7 October 2024 (UTC)[reply]

I think that would also be us. There's already a task: T376021 that lists some problems and suggests turning it off as one possible solution. I think that's currently waiting on some decisions about the new login system (code name "SUL3", see T348388 for some details), which may either let us fix it instead of disabling it, or force us to disable it, depending on which approach we end up going with. Matma Rex talk 01:10, 10 October 2024 (UTC)[reply]

thanks for sharing the context and I'm glad to hear that the concern is being addressed. Thanks again for the updates on that. Tonymetz 💬 02:58, 11 October 2024 (UTC)[reply]

"Add A Fact" LLM browser extension

After reading [1] and the post and ensuing discussion here, I don't think this browser extension is ready for article talk pace on en.wiki. I'm not exactly sure where to voice a concern about this, so please move this feedback if appropriate. @Chemipanda, Ita140188, and Avatar317: VQuakr (talk) 20:04, 3 October 2024 (UTC)[reply]

@VQuakr Feedback should probably go to meta:Talk:Future_Audiences/Experiment:Add_a_Fact. --Ahecht (TALK
PAGE) 21:05, 3 October 2024 (UTC)[reply]

That would be fine for feedback to them; I guess here I'm more looking to see if there's agreement this shouldn't be used on en.wiki yet. VQuakr (talk) 21:20, 3 October 2024 (UTC)[reply]

@VQuakr For reference, here is a list of all the edits made using this tool: https://hashtags.wmcloud.org/?query=addafact&project=en.wikipedia.org&startdate=&enddate=&search_type=or&user= 86.23.109.101 (talk) 21:59, 3 October 2024 (UTC)[reply]

That is a helpful link, thanks!! I glanced at ~10 random ones, and they all looked fine; They were a sentence directly copied from the source with the text listed in the quote parameter for the cite. Maybe Chemipanda didn't use it properly (highlighted the title) or is running an outdated browser version? Editors should at least look at their generated posts to see whether they are normal/valid/coherent and revert them if not; this tool is still experimental.

If this were to work as promised, I see this as more helpful than people simply posting new sources in the Talk pages. (which is always helpful). ---Avatar317 ^(talk) 22:39, 3 October 2024 (UTC)[reply]

@Avatar317 Yes, Looking through the edits my impression is that most of them are fine.

According to the page on meta the person using the tool has to select which part of the source to use, so the "adding the title of a paper rather than it's content" is user error, rather than an issue with the tool. There is still the issue of using the wikipedia page in the citation template that needs to be investigated though. 86.23.109.101 (talk) 11:54, 4 October 2024 (UTC)[reply]

I asked a developer and they suggested that the original error was likely due to the user switching browser-tabs while the extension is scanning the page. Quiddity (WMF) (talk) 00:38, 8 October 2024 (UTC)[reply]

Thanks everyone for the insight and especially @Quiddity (WMF): for the follow up! VQuakr (talk) 04:44, 8 October 2024 (UTC)[reply]

I dislike the visual changes to Mobile Wikipedia

I havent used the community pool before so Im sorry if this isnt in the right village. mobile wikipedia starting today as for some reason started auto directing me to en.m.wikipedia.org instead of the regular en.wikipedia.org. even if i directly remove the ".m" or "m.", it will just autodirect to it again. I really hate it, and find it unbearable to use and love the regular english language wikipedia much more. I dont know what is causing this problem. I havent seen anyone discussing this on either the wikipedia subreddit (where usually any updates are discussed) or on Wikipedia:News. I greatly appreciate any help with this, thank you! 92.236.211.53 (talk) 13:55, 4 October 2024 (UTC)[reply]

Use the "Desktop" link at the bottom of mobile pages to request the desktop version. PrimeHunter (talk) 14:00, 4 October 2024 (UTC)[reply]

Thank you for your quick response! I already tried this and it unfortunately results in it providing the literal desktop version of the website, resulting in large amounts of negative space and awkward text placement next to images due to website trying to work for the horizontal mobile. the site worked perfectly for mobile prior. is this happening on your phone too? 92.236.211.53 (talk) 14:07, 4 October 2024 (UTC)[reply]

im typing from desktop as i also learned today that my phone's ip (this same ip) was caught up in a rangeblock to block a specific user(but is now resolved?). i thought just now that this might be whats causing this but i just made account on mobile and it still autodirects to en.m.wikipedia. i have no idea what to do 92.236.211.53 (talk) 14:28, 4 October 2024 (UTC)[reply]

Device name:Pixel 6a

Model:Pixel 6a

Android version:12

I wish this information perhaps helps in finding out how to reverse this. I sent this from my mobile. 92.236.211.53 (talk) 16:48, 4 October 2024 (UTC)[reply]

The behavior you're experiencing is how it has always worked. The "workaround" Primehunter provided is working how it has always worked. There isn't a way to "fix it". The closest thing you can do is have an account, change the account's skin preference, and then use the "use desktop" link when you are logged in and end up on the mobile website. Perhaps this is sufficient for you. Izno (talk) 18:31, 4 October 2024 (UTC)[reply]

I went back through screenshots I took and saw that you and Primehunter were right, it has always been "en.m.wikipedia". I think there's been an update to mobile Wikipedia's base, light colour scheme that caused the add-on I was using, darkreader to render it differently.

I do notice that the text on tables is larger, and colours are in my opinion not working well together either in the official dark mode or using my add-on on light mode.

Current, disliked Wikipedia (lightmode+darkreader) from today: https://imgur.com/a/wnNflgF

Correct Wikipedia, just darkmode with no add-ons, also today:https://imgur.com/a/4xdBsow

Previous mobile Wikipedia colour scheme (lightmode+darkreader), from 28th of April: https://imgur.com/a/up24a8G

Is there anyway to go back to how it was previously because I really do prefer how it was literally just yesterday? I'm sincerely sorry for the misunderstandings 92.236.211.53 (talk) 19:33, 4 October 2024 (UTC)[reply]

What specifically do you dislike about the "current" version? Izno (talk) 00:09, 5 October 2024 (UTC)[reply]

There is a higher contrast between the letters and the dark background, the purple that lists clicked-on links is a lighter purple so you have to strain your eyes more to discern it, the text on tables is larger than it needs to be while the text on the rest of the articles is currently still at their previous very good and readable size (shown in the imgur comparison linked above), and I dont get how that happened.

I dont know how else to describe it, but it looks like there is a white or blue filter over the articles that makes my eyes hurt. I can make another imgur comparison if that would help explain what im reffering to (just two image links this time tho). 92.236.211.53 (talk) 15:35, 6 October 2024 (UTC)[reply]

If you create an account or add ?useskin=timeless, then the desktop version is more mobile friendly a bit. Gryllida (talk, e-mail) 07:29, 7 October 2024 (UTC)[reply]

Ive made an account and it hasn't reverted the UI to how it previously was sorry.

?useskin=timeless is working very well thank you. It's a hassle to paste it to the URL for each new article I click on since it resets to the awful default on every new link or page loaded or when the editl is opened. Is there anyway to make it the default, since it will also be bad for when I'm reading with mobile data, having to load the site twice. Thank you very much regardless! 92.236.211.53 (talk) 20:11, 9 October 2024 (UTC)[reply]

Yes. You can make it the default by creating an account, logging in with it, then going to your Preferences, and under "Appearance" select the Timeless skin, then Save. But that's what Izno told you five days ago. — JohnFromPinckney (talk / edits) 21:03, 9 October 2024 (UTC)[reply]

Sorry for the late reply. I've logged into this account and and selected timeless in appearance but despite that it's still not automatically going through! Also. I apologize to inzo, I don't think I understood what they are saying then. AssanEcho (talk) 20:37, 12 October 2024 (UTC)[reply]

Is AutoEd safe

I installed the script and all of its modules, is it safe or not? Electrou (formerly Susbush) (talk) 19:00, 4 October 2024 (UTC)[reply]

You're responsible equally for all the edits made with automated tools, if that's what you're asking. You still have to check to make sure your edits are correct and not disruptive. Remsense ‥ 论 19:04, 4 October 2024 (UTC)[reply]

The original poster is probably referring to the message that begins "Code that you insert on this page could contain malicious content capable of compromising your account ..." at MediaWiki:Userjsdangerous. To answer the original question, yes, it is safe. Graham87 (talk) 02:05, 5 October 2024 (UTC)[reply]

You can never be sure of that about user scripts (hence the warning). AutoEd and its modules are in the Wikipedia namespace and protected, which means they can be compromised if any admin's account is compromised. Nardog (talk) 02:12, 5 October 2024 (UTC)[reply]

Yes, but the message @Graham87 linked to ends, If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump., which is what directed the OP here.

It's kind of pointless to do that if the answer is always going to be, "Weeeelll... you can never be completely certain..." — that's not helpful. The user was already warned, and while it's true that you never can be completely certain, the AutoEd code is currently safe. And since it's used by many Wikipedians, it will screw over a much larger portion of the community than just @Electrou in the unlikely event that it becomes unsafe, so it's probably not worth personally fretting over. FeRDNYC (talk) 17:35, 8 October 2024 (UTC)[reply]

Most scripts are either in the MediaWiki namespace where js pages can only be edited by interface administrators, or in userspace where they can only be edited by the user and interface administrators. AutoEd is in the Wikipedia namespace for some reason. The pages are fully protected but all administrators can edit them so it's less protected than most scripts. There are currently 847 administrators but only 10 interface administrators and it's a more trusted position. Apart from the risk of malice, ordinary administrators may also know less about JavaScript and security (including securing their account), and accidentally do something unsafe. PrimeHunter (talk) 20:46, 8 October 2024 (UTC)[reply]

Problem to sort data

There is problem in this list (section "Minimum wages by country" and "Minimum wages by country (other countries)") to sort data by "Net (EUR)" and "Net (PPP)". What to do? Eurohunter (talk) 15:07, 6 October 2024 (UTC)[reply]

What is the problem? It seems to work for me. – Ammarpad (talk) 17:07, 6 October 2024 (UTC)[reply]

@Eurohunter you have described everything BUT the 'problem'. Never assume that others are seeing or experiencing the same thing as you, and make full and extensive descriptions of the problem that you are encountering. —TheDJ (talk • contribs) 19:04, 6 October 2024 (UTC)[reply]

@@Ammarpad: @TheDJ: Sort it by lowest or highest value, a few times. Eurohunter (talk) 20:35, 6 October 2024 (UTC)[reply]

@Eurohunter: I did and see no issue. WHAT IS THE PROBLEM? It's hard to help when you refuse to reveal what you think is wrong. PrimeHunter (talk) 21:26, 6 October 2024 (UTC)[reply]

The third click on EUR sort buttons takes you back to the initial sorting, which is a sorting by country name. It is not a bug, it is a feature. Uwappa (talk) 09:35, 7 October 2024 (UTC)[reply]

@TheDJ: @PrimeHunter: @Uwappa: Looks like I was wrong, but just noticed it's impossible to sort by "Gross (EUR)". Eurohunter (talk) 16:55, 7 October 2024 (UTC)[reply]

@Eurohunter: The "Gross (EUR)" column has an image before the number. You can for example use data-sort-value at Help:Sortable tables#Specifying a sort key for a cell. PrimeHunter (talk) 17:08, 7 October 2024 (UTC)[reply]

The column header has the attribute data-sort-type="number" but the data cells in that column all begin with either {{steady}}, {{increase}} or {{decrease}}, none of which are numeric. --Redrose64 🌹 (talk) 18:21, 7 October 2024 (UTC)[reply]

youtu.be blacklist

When I share a youtube video with a timestamp I get a link like this:

https://youtu.be/Zl8BIUx8QW0?feature=shared&t=1

but when I try to post that on wikipedia it says the link is on a spam blacklist. I can't find it on meta:Spam blacklist or on MediaWiki:Spam-blacklist.

And it wouldn't even make sense to block it anyway because I can change the link to:

https://www.youtube.com/watch?v=Zl8BIUx8QW0#t=1

and suddenly it is allowed. Polygnotus (talk) 21:24, 6 October 2024 (UTC)[reply]

Shorteners are categorically rejected. This one is rejected at meta:Spam blacklist \byoutu\.be\b. Izno (talk) 21:29, 6 October 2024 (UTC)[reply]

Thank you. The spam blacklist is intended to blacklist spam, and shouldn't be hijacked by people with an irrational hatred for url shorteners. Polygnotus (talk) 21:36, 6 October 2024 (UTC)[reply]

URL shorteners are used to introduce spam, and aren't always particularly stable addresses, and they can lead to hijacked sites, which are much more dangerous than spam. These reasons for banning them are categorically rational, contrary to your hyperbole. No, they will remain banned. Whether specifically youtu.be should have an exception is perhaps a worthy question, but as you said, the expansion is trivial, so just use the full URL instead. Izno (talk) 21:48, 6 October 2024 (UTC)[reply]

Yes. Shirley there Izno reason not to use the full URL. E Eng 23:07, 7 October 2024 (UTC)[reply]

@Izno: I know what URL shorteners are. This particular URL shortener cannot be used for malicious purposes because it only redirects to youtube. So it is obviously irrational to block all url shorteners. It is rational to block attack vectors while leaving domain aliases unblocked. This kinda stuff should be decided on a case-by-case basis (e.g. block bit.ly and tinyurl but not youtu.be). I can use the full url, but others do not know how to do that. Polygnotus (talk) 22:00, 6 October 2024 (UTC)[reply]

If someone doesn't know what a URL is or how to copy and paste it, they definitely shouldn't be adding external links to articles. Thebiguglyalien (talk) 06:27, 7 October 2024 (UTC)[reply]

@Thebiguglyalien: If someone says something truly ridiculous, it is often wise to re-read it in its context. Polygnotus (talk) 06:30, 7 October 2024 (UTC)[reply]

URL shorterners are blacklisted for good reasons. They can be used to circumvent blacklisting of their target. MediaWiki:Spam-blacklist blacklists several specific videos at youtube.com, e.g. the entry \byoutube\.com\/watch\?v=W0a6L7hbD7U\b. We don't want spammers to use a youtu.be redirect instead. And there are other problems with URL shorternes, e.g. that they can be shut down and break all links. If you don't think YouTube's owner Google would do such a thing then think again. They are shutting down their URL Shortener goo.gl.[2] PrimeHunter (talk) 21:55, 6 October 2024 (UTC)[reply]

Gotta love https://killedbygoogle.com/ Polygnotus (talk) 22:00, 6 October 2024 (UTC)[reply]

I actually agree that youtu.be shouldn't be blacklisted. The solution to PrimeHunter's concern would be to just blacklist the string W0a6L7hbD7U instead - the blacklist doesn't have to point to the full URL. But despite being a Meta admin and thus having the technical power to action this I don't have the social power to do it myself. * Pppery * _{it has begun...} 02:26, 7 October 2024 (UTC)[reply]

@Pppery: Thanks! The discussion continues at meta:Talk:Spam_blacklist#youtu.be. Another advantage of blocking W0a6L7hbD7U is that it would work for both the youtu.be/%id% and /watch?v=%id% format. Polygnotus (talk) 02:33, 7 October 2024 (UTC)[reply]

The key point here, which was (indirectly) mentioned by the OP, is that https://youtu.be/video_id links are provided by YouTube itself directly from their UI whenever a "Share" link is requested for a video. They are, in a certain sense, even more of a permalink than the actual https://www.youtube.com/watch?v=video_id page they redirect to.

And while it's true Google could terminate support for https://youtu.be/ tomorrow, they could also redesign YouTube tomorrow so that the https://www.youtube.com/watch page is no longer functional, replaced by https://www.youtube.com/view or some other nonsense, which the https://youtu.be/ redirects get updated to point to.

Do I think that will happen? Absolutely not; I just think it's of equal unlikelihood (...ow) that anything will happen to https://youtu.be/, as that would break like a quarter of the entire frickin' internet.

The simple fact is, when requesting links to YouTube videos from YouTube itself, users are provided with https://youtu.be/ links, which IMHO we shouldn't make it unreasonably difficult to make use of.

Especially considering, if a user is viewing a video in the YouTube mobile app (which accounts for a very significant percentage of YouTube traffic, at a level that shames our own mobile app's laughable 2%-3% of monthly pageviews), the short URL is the only URL they can retrieve. The app doesn't expose https://www.youtube.com/watch?v=video_id URLs anywhere. FeRDNYC (talk) 18:03, 8 October 2024 (UTC)[reply]

Linking to invidious instance could be better, it loads faster and does not track the user as much. Gryllida (talk, e-mail) 07:26, 7 October 2024 (UTC)[reply]

See Principle of least astonishment. Polygnotus (talk) 07:28, 7 October 2024 (UTC)[reply]

The two issues appear to be the general issue with url shorteners, and spamming of the shortened url.

Although this is a url shortener it's doesn't have the issues inherent in most shorteners. The only end point is a youtube video, so the usual concerns that it could link to anything do not apply here. Whether you use .com or .be you can't link to anything but a youtube video (correct me if that's wrong).

The spam issue is separate, and blacklisting individual videos is a poor option unless it's in a very particular situation. But the .com version could be spammed as well. I don't know how long ago the spamming and blacklisting were, but maybe unblacklisting as a test would be useful. If the past issues reappear it could be reapplied. I can see reasons why the .be link would be easier to spam, but beans. -- LCU ActivelyDisinterested «@» °∆t° 18:59, 8 October 2024 (UTC)[reply]

While it doesn't directly - it does procedurally. In many use cases using the youtube "share button" generates a shortener that also includes a tracker, which we don't want. And 'someone else can go back and remove trackers later' isn't a strong argument - bad edits that can easily be avoided (by just using the actual link) are much more desirable. — xaosflux ^Talk 10:29, 10 October 2024 (UTC)[reply]

@Xaosflux: In GDPR countries that tracking parameter is omitted. Polygnotus (talk) 10:37, 10 October 2024 (UTC)[reply]

Sometimes sure, and in the rest of the world it's not. — xaosflux ^Talk 10:49, 10 October 2024 (UTC)[reply]

I would propose to develop a mechanism to expand the shortened URL to its full form. For example, either

write a bot that automatically expands certain short URL patterns upon user publishing an edit, and if the expanded URL hits the spam blacklist, revert the edit. There are already external Spam blacklist search tools [3]. Or,
integrate the short URL expansion mechanism into MediaWiki, automatically expand shortened URLs upon publishing. If the expanded URL hits blacklist then disallow the edit.

Milky Defer 08:23, 10 October 2024 (UTC)[reply]

Oh great, it is in idea lab. Milky Defer 08:29, 10 October 2024 (UTC)[reply]

Link for those curious: Wikipedia:Village_pump_(idea_lab)#URL_expansion_bots Polygnotus (talk) 08:31, 10 October 2024 (UTC)[reply]

Lua to generate information about a page

Hello, does lua template have the capability to get information like

page contributors
last date of edit to page

for a provided page name? If so, please send me an example? Thank you. Gryllida (talk, e-mail) 07:23, 7 October 2024 (UTC)[reply]

@Gryllida: You don't need Lua for the second one, it is available as a variable. If you only need the last contributor, that also is available in the same way. --Redrose64 🌹 (talk) 09:40, 7 October 2024 (UTC)[reply]

Need this info for page and for page talk so I think variable will not work. Need a list of contributors not only last one. I can get this information using js but would prefer to avoid it. if possible. Thanks. Gryllida (talk, e-mail) 14:16, 7 October 2024 (UTC)[reply]

Why do you think that a variable wouldn't work? Consider the article London - we can do this:

{{REVISIONTIMESTAMP:London}} → 20241006081446
{{#time: H:i, j F Y (e)|{{REVISIONTIMESTAMP:London}}}} → 08:14, 6 October 2024 (UTC)
{{REVISIONTIMESTAMP:Talk:London}} → 20240908185015
{{#time: H:i, j F Y (e)|{{REVISIONTIMESTAMP:Talk:London}}}} → 18:50, 8 September 2024 (UTC)

If either London or Talk:London get edited, the above examples will change when this page is next edited or WP:PURGEd. --Redrose64 🌹 (talk) 16:04, 7 October 2024 (UTC)[reply]

This is fabulous Thanks. I will go try to use it in my template now. Just need the nicks of contributors now if possible. Gryllida (talk, e-mail) 22:59, 7 October 2024 (UTC)[reply]

No, Lua (Scribunto) does not have access to page history. One option would be to have a bot periodically build a list of contributors and update a page somewhere that a module could read. Or, have a JavaScript gadget which can use the API. All that is tricky. Johnuniq (talk) 00:41, 8 October 2024 (UTC)[reply]

Js is ok,I can write. I was hoping for Lua. Why not? Can it be implemented for Lua to have such access? Thanks for your insight. 🙂 Gryllida (talk, e-mail) 10:28, 8 October 2024 (UTC)[reply]

Part of the answer to that question is likely something vaguely along the lines of, "just as we expect of all wikipedians, Scribunto is here to create an encyclopedia, and no part of that goal ever requires access to edit history."

(Which... is actually kind of true. There are plenty of behind-the-scenes tasks/goals that could benefit from page history access, but none of them would ever directly affect article content.) While there are plenty of conceivable ways in which it would be useful to have history access (or other functionality) in Scribunto, the focus has primarily been on providing functional equivalents to what's achievable with template coding, but without the template-coding nightmares involved in building any sort of complex logic.

Templates similarly have no access to page history.

Another factor is that the results of Module {{#invoke:}} calls, like template transclusions, are meant to be cacheable. 'Dynamic' code that relies on making an external resource query, meaning it potentially changes each time the module is invoked, is a bad fit with the caching model. Lua results should ideally be fairly static unless a dependency is edited or the code is invoked with different parameters.

Not to say that these things couldn't, potentially, be implemented. They just haven't been, and adding them would be a significant development effort, it's not a matter of flipping a switch or inserting a line of code somewhere. In fact there's a Phabricator tracking bug (T50176) for bugs requesting new Lua functionality — it's a long list. Things like MediaWiki API query access, access to Category lists, Namespace indexes, etc. are already there. It doesn't look like edit history access has ever been directly requested. (But API queries would provide one potential path, since page history info is accessible via the API.)

It's important to note that none of those requests are actively being worked on, though. They're just that: Requests. Unfulfilled requests, with no predicted timeline for completion beyond "...probably never?" FeRDNYC (talk) 21:52, 8 October 2024 (UTC)[reply]

i wanted list of article authors to inquire about edit to the article, e.g. send @ pings on talk. Gryllida (talk, e-mail) 03:35, 9 October 2024 (UTC)[reply]

Your best bet will be to use xtools to generate a list of people who edited the article by using this link: [4] NightWolf1223 <Howl at me•My hunts> 03:41, 9 October 2024 (UTC)[reply]

Bug in Template:Infobox musical artist

The parameter "associated_acts" doesn't work, see Orelsan. --BigBullfrog (talk) 08:19, 7 October 2024 (UTC)[reply]

@BigBullfrog: Well, no, because it's deprecated to the point of removal. See Template talk:Infobox musical artist/Archive 16#Associated acts confusion and Category:Pages using infobox musical artist with associated acts. --Redrose64 🌹 (talk) 09:51, 7 October 2024 (UTC)[reply]

Oh I see, thanks. --BigBullfrog (talk) 01:09, 8 October 2024 (UTC)[reply]

Table

How to make this table look like this one? I don't see any parameters which could be used. Eurohunter (talk) 20:52, 7 October 2024 (UTC)[reply]

What do you mean "look like"? They look roughly the same to me, except for some styling applied by |namestyle=, |headingstyle=, |class=, and similar. – Jonesey95 (talk) 21:24, 7 October 2024 (UTC)[reply]

I'm gonna dissent from @Jonesey95's claim as those boxes look pretty significantly different to me, but I agree it's mostly a question of styling, all of which is done by parameters that most assuredly are there and being used — most of what's involved in making Template:Politics of Yemen look more like Template:Politics of Uzbekistan would involve removing the ugly style nightmare that's been imposed on the former. Places I'd start:

Lose the border: 1px double #8C959A from all of the style parameters where it's used (titlestyle, headingstyle, and listtitlestyle), because that just looks like trash.
Just remove |style=border 4px double var(--background-color-inverted, #101418); completely. (What is this obsession with double-lined borders?)
Use {{Politics sidebar title}} to set the |title= parameter, rather than hardcoding separate |title=, |image=, |namestyle=, |titlestyle=, etc. Specifically, you'd probably want this:
```
|title={{Politics sidebar title|country=Yemen|image=Emblem of Yemen (2).svg|size=125px|title=Yemen}}
```
replacing not only |title= itself but also those other three parameters.
Consider getting rid of the |headingstyle= and |listtitlestyle= entirely, as well. Beyond the border styling, all they do is set specific (and ugly) color parameters that ruin the look of the sidebar because content boxes of unequal dimensions are revealed. That makes for a very "ransom-note" kind of effect where different-sized yellow rectangles and red rectangles are slapped all over the place.
Finally, if you don't want the contents of each expandable heading to be presented as just a wrapped horizontal line of text, remove hlist from the |bodyclass= parameter, as that's what makes them format that way.
(If you do that, you might consider using the {{hlist}} template to create horizontal lists out of some of the links in specific lists, like Template:Politics of Uzbekistan does in the |list6= contents.)

FeRDNYC (talk) 22:34, 8 October 2024 (UTC)[reply]

Global.css not affecting mobile

My global.css appears to not be working on mobile web (Firefox Nightly on Android) all of a sudden - the changes just aren't applied. It works fine on desktop. Is this a known issue? Suntooooth, it/he (talk/contribs) 21:57, 7 October 2024 (UTC)[reply]

Suntooooth, could you please test in non-nightly version of Firefox for Android? —⁠andrybak (talk) 09:01, 8 October 2024 (UTC)[reply]

Just tried it, still not working. Suntooooth, it/he (talk/contribs) 13:30, 8 October 2024 (UTC)[reply]

Something that may be related - there are also some icons in the interface that aren't showing up on mobile (Firefox Nightly and Firefox). The two I've noticed are the "watch" icon on pages I'm watching, and the red alert circle that displays in the top bar if there's notifications. Suntooooth, it/he (talk/contribs) 13:43, 8 October 2024 (UTC)[reply]

The icon issue is being discussed at Wikipedia:Village pump (technical)#Watchlist icon issue on Mobile. See also phab:T376359, phab:T376414. —⁠andrybak (talk) 13:59, 8 October 2024 (UTC)[reply]

Got it, thanks! :] Suntooooth, it/he (talk/contribs) 14:07, 8 October 2024 (UTC)[reply]

Tech News: 2024-41

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

Weekly highlight

Communities can now request installation of Automoderator on their wiki. Automoderator is an automated anti-vandalism tool that reverts bad edits based on scores from the new "Revert Risk" machine learning model. You can read details about the necessary steps for installation and configuration. [5]

Updates for editors

Translators in wikis where the mobile experience of Content Translation is available, can now customize their articles suggestion list from 41 filtering options when using the tool. This topic-based article suggestion feature makes it easy for translators to self-discover relevant articles based on their area of interest and translate them. You can try it with your mobile device. [6]
View all 12 community-submitted tasks that were resolved last week.

Updates for technical contributors

It is now possible for <syntaxhighlight> code blocks to offer readers a "Copy" button if the copy=1 attribute is set on the tag. Thanks to SD0001 for these improvements. [7]
Customized copyright footer messages on all wikis will be updated. The new versions will use wikitext markup instead of requiring editing raw HTML. [8]
Later this month, temporary accounts will be rolled out on several pilot wikis. The final list of the wikis will be published in the second half of the month. If you maintain any tools, bots, or gadgets on these 11 wikis, and your software is using data about IP addresses or is available for logged-out users, please check if it needs to be updated to work with temporary accounts. Guidance on how to update the code is available.
Rate limiting has been enabled for the code review tools Gerrit and GitLab to address ongoing issues caused by malicious traffic and scraping. Clients that open too many concurrent connections will be restricted for a few minutes. This rate limiting is managed through nftables firewall rules. For more details, see Wikitech's pages on Firewall, GitLab limits and Gerrit operations.
Five new wikis have been created:
- a Wikipedia in Komering (w:kge:) [9]
- a Wikipedia in Mooré (m:mos:) [10]
- a Wiktionary in Madurese (wikt:mad:) [11]
- a Wikiquote in Gorontalo (q:gor:) [12]
- a Wikinews in Shan (n:shn:) [13]

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

MediaWiki message delivery 23:38, 7 October 2024 (UTC)[reply]

Refill down

Tracked in Phabricator
Task T369439

This is not a new issue (see previous discussions here and here for example), and I don't frequent the technical pump often, but the extremely valuable Refill tool has been non-functional for months (years?). Any updates? And, if it's broken/abandoned for good, is there a similar tool that can quickly convert bare URLs into formatted citations, and/or combine duplicate citations? Furthermore, is there a clear list of handy editing tools somewhere on Wikipedia? I've been a regular editor for well over a decade, so if there is one, I've overlooked or forgotten about it. There are a lot of problems on Wikipedia: prioritizing tools, and making them easily visible to editors who don't have a computer science degree, should be a top priority. Cheers, --Animalparty! (talk) 00:29, 8 October 2024 (UTC)[reply]

https://refill.toolforge.org/ng for some reason. – Muboshgu (talk) 00:39, 8 October 2024 (UTC)[reply]

I use reFill2 and something called RefRenamer but I don't know the link. Johnjbarton (talk) 00:42, 8 October 2024 (UTC)[reply]

User:Nardog/RefRenamer? Polygnotus (talk) 01:58, 8 October 2024 (UTC)[reply]

how to add geojson map to Infobox protected area

I'm trying to add https://commons.wikimedia.org/wiki/Data:Coconino_National_Forest.map to Coconino National Forest but it is unclear to me how to do so. I tried:

| image_map       = {{maplink-road|from=Coconino National Forest.map}}

But it's not showing up. I also tried to delete the old `map` entry and then adding this:

| map       = {{maplink-road|from=Coconino National Forest.map}}

But that got me this error:

Lua error in Module:Location_map at line 526: "?'\"`UNIQ--mapframe-0000000E-QINU`\"'?" is not a valid name for a location map definition.

Any ideas? TerraFrost (talk) 10:35, 8 October 2024 (UTC)[reply]

I previously struggled with a maplink situation where the answer was to wait a few days for Kartographer to sort itself out. CMD (talk) 12:32, 8 October 2024 (UTC)[reply]

The template's documentation suggests using embedded=. The map probably still needs a caption, but it's in the article. – Jonesey95 (talk) 14:31, 8 October 2024 (UTC)[reply]

Sticky table headers placement issue for short/nested tables

It looks like someone tweaked the CSS for the sticky table headers — which can be enabled with the fourth checkbox at Special:Preferences#mw-htmlform-gadget-section-test — so that (if your browser also satisfies a @media screen and (min-width: 1000px) media query) it applies a top: 3.125rem offset to table headers when one is stickied, to prevent the sticky header from either covering or sliding under the also-sticky TOC button.

Nice idea, in theory. Problem is, on pages containing nested and/or short tables that don't exceed the height of the screen, the stickiness can kick in at unexpected times, particularly when there are multiple tables. And when that happens, all of the tables' headers jump down a distance of 3.125rem, potentially covering their first data row.

I first noticed this at Module:Sports results, in the documentation. The "What it looks like" areas of those docs all contain short tables. If you have the sticky headers gadget enabled, then no matter where you scroll on that page, each table's header row will be shoved down to cover the first data row below it.

That's a problem, as it obscures content, and the only way to make it visible is to defeat the CSS rule applying top: 3.125rem. FeRDNYC (talk) 16:16, 8 October 2024 (UTC)[reply]

Actually, it looks like this only affects nested tables, and it may be sufficient to augment the existing CSS rule:

@media screen and (min-width: 1000px) {
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header > thead {
    top: 3.125rem;
  }
}

with a second one overriding the offset in nested tables:

@media screen and (min-width: 1000px) {
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter .jquery-tablesorter > thead,
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter .mw-sticky-header > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header .mw-sticky-header > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header .jquery-tablesorter > thead {
    top: 0;
  }
}

FeRDNYC (talk) 16:57, 8 October 2024 (UTC)[reply]

...Smaller issue, the nested table headings then end up passing on top of the sticky outer table headers when they cross, instead of underneath them. Looks like some z-index tweaking might also be needed. FeRDNYC (talk) 17:01, 8 October 2024 (UTC)[reply]

Ohh, now I see. The offset isn't to avoid the floating TOC button, but rather the full-width version of the .vector-sticky-header. But the weird thing is, that CSS doesn't kick in until @media screen and (min-width: 1120px), so there's this weird 120px limbo range of browser widths where the table headings are ducking under nothing at all. FeRDNYC (talk) 22:53, 8 October 2024 (UTC)[reply]

Those values change sometimes. I'll make an edit request. —TheDJ (talk • contribs) 08:16, 9 October 2024 (UTC)[reply]

@TheDJ Nice, thanks!

The nested table issue is still a problem, though, whether the breakpoints are synced up or not. When a table's sticky-header activates and the top: 3.125rem; offset kicks in for its header rows, the header rows of all tables nested inside that table will also move down to obscure their own content, unless the offset is defeated for nested tables with something like my second CSS block above. FeRDNYC (talk) 09:18, 9 October 2024 (UTC)[reply]

Yes, this is almost impossible to bypass. Sticky headers are relative to their scrolling context. So every time you introduce a new scrolling context (as done here at Module:Sports_results#L-277), you have to cancel out the offset of the main context. This is part of the reason why the sticky headers are not the default behavior. It is not really possible to make it work predictably in any and all contexts right now. If you want to override this specific situation, you need to make an override for this gadget's behavior in Module:Sports_results/styles.css. —TheDJ (talk • contribs) 11:11, 9 October 2024 (UTC)[reply]

@FeRDNYC: The offset isn't a problem with the change request at MediaWiki talk:Gadget-StickyTableHeaders.css#Interface-protected edit request on 10 September 2024, which adjusts "top" to 0 if the table is wrapped in an "overflow" style. Basically nothing is sticky at Module:Sports results/doc, which is better than unreadable content. Jroberson108 (talk) 05:55, 11 October 2024 (UTC)[reply]

Database error, write duration exceeded

Just got the following error message dropping three See-alsos from a Draft, in this edit:

Database error
To avoid creating high replication lag, this transaction was aborted because the write duration (5.3958411216736) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead.

[bf82d77e-9cdf-4b96-a5b2-5ac9cab8969a] 2024-10-03 15:00:40: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"

The edit seems to have gone through fine, despite the message. Could this happen if I inadvertently hit Publish twice or something? I don't have any recollection of doing so, and I really don't know what happened. Everything is fine on my end, I don't need any action, just reporting this in case it's a first sign of something going on that needs to be watched. Mathglot (talk) 15:11, 3 October 2024 (UTC)[reply]

*I unarchived this to reply*. @Mathglot: Sorry I didn't see this earlier, but your description reminded me of a recurring (possible) bug affecting the abusefilter - I checked and it does seem like your edit is related: your edit triggered the monitoring filter 9 times separately from the edit.

I'm unsure how active @Suffusion of Yellow is, the testing filter ("possible abusefilter bug") was added to help debug things from Wikipedia:Edit_filter_noticeboard/Archive_12#Filter_1253:_False_positive_ratio, where @ToBeFree created phab:T348237, about it.

I'm just noting this here, and pinging, in case either this Database error helps with the phab-reported abuse filter problem (or the other way around). – 2804:F14:80E1:2001:2DF4:42B2:8C4D:C416 (talk) 18:22, 8 October 2024 (UTC)[reply]

Thanks for the ping and Mathglot for the report – I have now added this as a comment to the year-old task. ~ ToBeFree (talk) 19:44, 8 October 2024 (UTC)[reply]

Keep getting logged out

Tracked in Phabricator
Task T372702

Over the past few weeks I've been occasionally getting logged out unexpectedly, despite ticking the "remember me" option every time. Most recently it's happened twice in the past ~24 hours. It always happens when I've been idle for a while, but only on the order of hours not days. I'm not aware that I've changed any of my settings recently. Thryduulf (talk) 20:15, 8 October 2024 (UTC)[reply]

Me too. I believe there is a phab ticket covering this issue. Let me go find it real quick NightWolf1223 <Howl at me•My hunts> 20:55, 8 October 2024 (UTC)[reply]

I've had the same issue for a week or so, I just rather lazily assumed it would get fixed at some point. -- LCU ActivelyDisinterested «@» °∆t° 21:08, 8 October 2024 (UTC)[reply]

Probably the same problem as T372702. Matma Rex talk 16:16, 9 October 2024 (UTC)[reply]

I don't know if this sequence of actions has a trigger in it.

explicitly log out on one machine (this invalidates all login cookies on all devices)
log in to en.wp on a different device, selecting "Keep me logged in (for up to one year)". I now have a fresh new login cookie
Microsoft informs me that updates require installation, so I finish what I am doing ...
... close Firefox, go for "Start"→"Power"→"Update and restart", wait an age. Make coffee. Clear a pile of snailmail. Open Firefox ...
... and back to my watchlist. One edit adds an image to an article, which I am suspicious about, so:
visit Commons. It says I am not logged in and should reload the page. In my experience, this never works, but following a different commons link does; so I go to the page history. I am now shown as logged in.
Still on Commons, I follow a link to en.wp - I am not logged in
Return to commons, visit another page, still logged in
go to Meta - I am logged in there
try en.wp again - not logged in

Why might en.wp stop recognising my login cookie when commons and meta are perfectly happy with it? --Redrose64 🌹 (talk) 20:17, 9 October 2024 (UTC)[reply]

Not getting automatically logged in on some wikis sounds like some sort of anti-tracking protection in your browser. Commons and Meta share the same parent domain with login.wikimedia.org where the central session cookie is stored so browser restrictions on cross-wiki cookie access are more relaxed.

Does clicking on the login link at the top of the page on enwiki help? That should work in Firefox. Tgr (WMF) (talk) 18:26, 10 October 2024 (UTC)[reply]

@Tgr (WMF): I think you missed something - my proper login (asking me to enter name and password) was on English Wikipedia. When I went to Commons and logged in there, I became logged out on Wikipedia, but remained logged in on Commons. --Redrose64 🌹 (talk) 20:16, 10 October 2024 (UTC)[reply]

Yeah the logged out part is the bug Matma Rex linked. I'm just saying Commons and Meta login being more "sticky" on some browsers is expected - your enwiki session somehow went missing, your central session on login.wikimedia.org remained, and then other wikimedia.org wikis can recover the session from there but wikis on other domains can't. Tgr (WMF) (talk) 21:31, 10 October 2024 (UTC)[reply]

OK it's not random but it is replicable:

On en.wp, log in (full login using Special:UserLogin, with Username/Password)
Click this link: commons: - observe that you are logged in
Use the browser's "back" button to return to en.wp
Press F5 to reload the page - observe that you are not logged in
Click this link: commons: - observe that you are still logged in at Commons

This also causes loss of session data and more than one lost edit. --Redrose64 🌹 (talk) 21:54, 10 October 2024 (UTC)[reply]

@Redrose64 I cannot reproduce this behavior. RoySmith (talk) 00:49, 12 October 2024 (UTC)[reply]

I'm not sure how this could be connected, but I've noticed recently (a few weeks?) that sometimes when I go back to my watchlist after looking at/editing a linked page, I get an earlier version of the watchlist. I've just assumed it has something to do with caching, as clearing the cache brings up the most recent version of the watchlist. Donald Albury 19:50, 12 October 2024 (UTC)[reply]

Permalink notice not styled

Tracked in Phabricator
Task T376848

The message "This is an old revision of this page" or "This is the current revision of this page" at the top of a permalink has the cdx-message--warning class but is not styled unless the skin is Vector 2022 (example). Is there a Phab task for this? Nardog (talk) 06:26, 9 October 2024 (UTC)[reply]

There were several tasks about missing warning box styling in various places, but I don't think there was a task about this particular one. Please file it. :) Matma Rex talk 16:15, 9 October 2024 (UTC)[reply]

@Matma Rex: Done. Please add appropriate tags; I didn't file it earlier mainly because I didn't know what tags to use. Nardog (talk) 23:06, 9 October 2024 (UTC)[reply]

Works in Special:ExpandTemplates but fails in regular page?

As I am climbing the bumpy learning curve for templates I hit another road block. This code (with extra double curlies on the outside) evaluates when I use Special:ExpandTemplates but just sits there in a page like this:

{{
common:−4, +4,
notable:+4,^[1]
predicted:
}}

My goal was to have a database layer accept the name of a formatter and a selector, then return a template with that formatter and the selected data. It works in ExpandTemplates, but where it counts. Any hints? (^[2])

Johnjbarton (talk) 21:43, 9 October 2024 (UTC)[reply]

Oh, I unchecked Remove comments on the ExpandTemplates and the result is different. Still in the dark though. Johnjbarton (talk) 21:51, 9 October 2024 (UTC)[reply]

This is a known, and annoying, but in ExpandTemplates, which half-parses the text and then parses it fully. How the ordinary parser works is that if a template outputs wikitext that wikitext doesn't get parsed again. If you really want to run through the parser multiple times you can use {{expand wikitext}}, so

{{expand wikitext|{{ {{User:Johnjbarton/sandbox/Infobox element/symbol-to-oxidation-state-data|os-formatter=User:Johnjbarton/sandbox/Infobox element/symbol-to-oxidation-state-echo|symbol=C}} }}

-> (example removed since template changes made it obsolete). While I've done that in the past it's kind of hacky.

You also need to put a space between the two sets of curly brackets, or else the parser gets confused. {{{{1}}}} is parsed as { {{{1}}} } (take the value of a parameter and wrap it in curly brackets), not {{ {{1}} }} (evaluate Template:1 and then evaluate the result of it as the name of another template). * Pppery * _{it has begun...} 22:22, 9 October 2024 (UTC)[reply]

Also if you were to put the opening curly braces in User:Johnjbarton/sandbox/Infobox element/symbol-to-oxidation-state-data itself, then that would work. (this is similar to how {{country data United States}}) et al. work. * Pppery * _{it has begun...} 22:36, 9 October 2024 (UTC)[reply]

Ok great thanks! These are the kinds of things I need to learn:

"How the ordinary parser works is that if a template outputs wikitext that wikitext doesn't get parsed again."

I was able to base my prototype on {{country data United States}} by changing the design of the "data". This kind of system is much easier to use with good examples. Johnjbarton (talk) 02:39, 10 October 2024 (UTC)[reply]

You're welcome. Also, I misspoke - a better way of phrasing it is "How the ordinary parser works is that if a template outputs template calls those template calls don't get parsed again" - other wikitext like wikilinks, refs, etc. is of course parsed. There's a very long manual on how the parser works at mw:Help:Template and even more stuff at mw:Manual:Advanced templates if you want to really enter the weeds. * Pppery * _{it has begun...} 04:51, 10 October 2024 (UTC)[reply]

References

^ "Carbon: Binary compounds". Retrieved 2007-12-06.
^ ignore ref

Alternative to normal talkpage notification

Something I've been thinking about:

A lot of new people don't seem to see talkpage messages. The cause is not really important here; it may be a case of banner blindness, or our (mobile) interface is not clear enough, or whatever.

Would it be a good idea to implement a special message notification, perhaps one that:

is hard to ignore
can perhaps only be sent by an admin
requires confirmation of receipt to dismiss (so it is on every page you visit until you click a button)
takes up most if not all of the screen
would still appear on the talkpage as a normal message so others can see them as well
comes with a short explanation that someone is trying to reach them, translated in many languages

To prevent abuse in case of hijacked admin accounts we could restrict each message to only one recipient, and limit the amount you can send to 1 per minute. And perhaps it should only be possible to send such messages to people who are not extendedconfirmed. To prevent people receiving too many of these messages, perhaps limit them to, for example, 1 per hour per recipient.

Ideally those You may be blocked from editing without further warning the next time you... warnings would be sent via this alternative method of talkpage notification.

A potential downside is that its, in some cases, easier to give someone WP:ROPE and then not have to deal with them for the duration of their block.

I think that at least some people keep doing what they are doing, without ever noticing a growing list of messages on their talkpage of people trying to steer them in the right direction. Has such a feature been considered?

Polygnotus (talk) 02:51, 10 October 2024 (UTC)[reply]

Hot cat not working and visual editor not as easy

I was setting up the article at Gábor_Bálint and wanted to add the "category:Hungarian linguists" and it did not work because that category does not exist. I finally found "category:Linguists from Hungary" and I usually do not like this inconsistency (and especially do not see why American and English are special nationalities) so I added {{Category redirect|Linguists from Hungary}} at the wrong category. Now hot cat usually uses that and helpfully replaces the category if I typed "Hungarian linguists". Strangely hot cat does not seem to work at all today and the visual editor for categories does not have this automatic feature to suggest preferred category names. Perhaps someone knows a better way of explaining this or adding a suggestion for the visual editor folks. PS:hot cat now working!! Shyamal (talk) 12:48, 10 October 2024 (UTC)[reply]

Adding section after closed discussions

I added a new section using the "*" tab with this edit: https://en.wikipedia.org/w/index.php?title=Talk:Fishing_cat&curid=7607570&diff=1250477244&oldid=1250369650

The new section is included within the closed discussion. I might be able to fix it in this case, but it seems to be a bug. — Jts1882 | talk 19:03, 10 October 2024 (UTC)[reply]

It's not really a bug; the person who closed the GA review section forgot to match their {{atop}} template with an {{abot}} template, which means the "close" box didn't end. I've fixed it. Writ Keeper ⚇♔ 19:10, 10 October 2024 (UTC)[reply]

Thank-you. I knew there was a problem but couldn't identify it. It's too easy to cast blame on bugs. — Jts1882 | talk 19:18, 10 October 2024 (UTC)[reply]

Problem with {{cite web}}

There appears to be a problem with {{cite web}} and related templates on some pages - see, for example, Beroidae, where all the references display "Lua error in Module:Citation/CS1/Configuration at line 2083: attempt to index a boolean value." rather than the reference. The references are displayed correctly in preview mode, with no template errors shown in the editor. I'm using Firefox with the Monobook skin. Tevildo (talk) 22:25, 10 October 2024 (UTC)[reply]

I WP:NULLEDITed the page and the error went away. No idea of the cause. * Pppery * _{it has begun...} 22:35, 10 October 2024 (UTC)[reply]

This is usually caused when the Citation Style 1 module components used by the cite templates are updated and are out of sync for a few moments. Some pages are re-rendered and cached during that short time, and they can throw errors when new code tries to call older code and fails in some way. With so many millions of pages, it is inevitable that at least a few pages will be affected. Null-editing affected articles re-renders them with all of the updated module components. – Jonesey95 (talk) 00:45, 11 October 2024 (UTC)[reply]

Thanks for the answers, I'll try that if I come across this issue again. Tevildo (talk) 15:50, 11 October 2024 (UTC)[reply]

Matching tags in strings?

I need to create a series of ref tags from wikitext with refs. I'll settle for a very specific pattern of text removed. I tried things like: {{#invoke:string|replace|source=−4,<ref name="cn"/> −2,<ref name="cn"/>|pattern=[−+]%d,<.-><|replace=<|plain=false}} but the left angle bracket never matches. I think the match is being performed on a source or pattern after it has been converted to Help:strip markers. Thus the angle bracket is not in the source during the match. Is there a way around this? Johnjbarton (talk) 23:15, 10 October 2024 (UTC)[reply]

Because <ref /> tags are replaced with stripmarkers before Module:String ever sees |source=:

{{#invoke:string|replace|source=−4,<ref name="cn"/> −2,<ref name="cn"/>|pattern=[−+]%d,<.-><|replace=<|plain=false}}

−4,'"`UNIQ--ref-00000057-QINU`"' −2,'"`UNIQ--ref-00000058-QINU`"'

no <ref /> tags to match.

—Trappist the monk (talk) 00:40, 11 October 2024 (UTC)[reply]

Thanks, very helpful. On the plus side the issue I was concerned about, finding my digit-strings like ",9" inside refs, can't actually happen:

{{#invoke:string|replace|source=−4,<ref name="has9">,9</ref> −2,<ref name="cn"/>|pattern=[−+]%d,<.-><|replace=<|plain=false}}

−4,'"`UNIQ--ref-0000005B-QINU`"' −2,'"`UNIQ--ref-0000005C-QINU`"'

On the minus side, templates can't manipulate contents of ref tags I guess. Johnjbarton (talk) 01:55, 11 October 2024 (UTC)[reply]

References

^ ^a ^b ^c ^d Cite error: The named reference cn was invoked but never defined (see the help page).

Talk:Battle of Helena

See Talk:Battle of Helena#In appropriate photo when viewing in app. Any idea what's going on with the issue the IP just reported? There were some image vandalism issues over a year ago. There's no infobox image in the article so I don't know what would be causing that. I am unable to really look into this because I am at work and do not want to replicate the reported issue. Hog Farm _Talk 16:29, 11 October 2024 (UTC)[reply]

@Hog Farm the article was vandalized at some point (see the edit summary at Special:Permalink/1163371835) and while the vandalism was removed, it's likely that some resource the app is using didn't update their cache correctly. --Ahecht (TALK
PAGE) 19:53, 11 October 2024 (UTC)[reply]

SuggestBot - is it running?

Hi, I submitted a request 20:32, 10 October 2024 (UTC) here, and awaiting a response of suggested articles wikitable. At User talk:SuggestBot I did include @Nettrom, the bot operator. Regards, JoeNMLC (talk) 21:41, 11 October 2024 (UTC)[reply]

It appears not - the recent contribs to User talk pages show that it typically runs twice a day, at 11:24 and 23:24 (UTC), but today's 11:24 run was missed. Have you contacted the botop directly? --Redrose64 🌹 (talk) 21:55, 11 October 2024 (UTC)[reply]

Thanks Redrose64 - I did just now leave a message on Nettrom's talk page. JoeNMLC (talk) 00:10, 12 October 2024 (UTC)[reply]

Well its contribs show that it's making edits (permalink to contributions at time of writing). It seems to be taking its time. At least it's still carrying on the fourth-longest daily editing streak of any user here (I'm at #5 of out of all human editors). Graham87 (talk) 02:44, 12 October 2024 (UTC)[reply]

Done at 11:26, 12 October 2024 (UTC). Cheers! JoeNMLC (talk) 11:50, 12 October 2024 (UTC)[reply]

Queries

Hey, all,

Just a minor query but I hope someone will know. When I use to visit Wikipedia:Arbitration/Requests/Enforcement or WP:ANI, in the top right corner of a discussion, there was a link to "Archive" the discussion. Instead, now, there is a link to "Subscribe". So, is there an easy way to archive discussions other than cutting and pasting them into an archive page? It used to be easy to do this but now I don't see a way to do this. Is it because of a skin or some setting I have opted into or was this a change to discussion format? There also use to be a Reply link on talk page discussions and I no longer see that link either.

Thanks for any explanation anyone can provide. Liz ^{Read! Talk!} 06:06, 12 October 2024 (UTC)[reply]

I had this issue recently and I was told to update / use a new user script. Let me hunt that down for you. Ktin (talk) 06:25, 12 October 2024 (UTC)[reply]

See this post Wikipedia:Village_pump_(technical)/Archive_214#User_Scripts_and_Template_Substitution. I ended up using User:Elli/OneClickArchiver and this works for me. Ktin (talk) 06:29, 12 October 2024 (UTC)[reply]

@Liz In User:Liz/common.js you are loading User:Technical 13/Scripts/OneClickArchiver.js on line 36. That particular version of the one click archiver was deleted in 2023 because it was broken and Technical 13 is arbcom blocked and unable to fix it. You'll need to replace it with an alternative, see Wikipedia:One click archiving for a list of maintained versions. 86.23.109.101 (talk) 17:11, 12 October 2024 (UTC)[reply]

[1] "Carbon: Binary compounds". Retrieved 2007-12-06.

[cn-2] re ref

[cn-3] Cite error: The named reference cn was invoked but never defined (see the help page).

[1]

[2]