Wikipedia:Interface administrators' noticeboard/Archive 3

From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3

Inactive interface administrators 2021-10-28

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


The following interface administrator(s) are inactive:

— JJMC89 bot 23:19, 28 October 2021 (UTC)

  •  Done removed and notified. — xaosflux Talk 00:21, 29 October 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Please lift the wikibreak of my main account

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Resolved

I ask that my Wikibreak on my main account, User:NotReallySoroka, be lifted. Thanks, --PasVraimentSoroka (talk) 05:53, 2 November 2021 (UTC)

 Donexaosflux Talk 10:45, 2 November 2021 (UTC)
@PasVraimentSoroka In the future, you can add the safemode=true parameter to the URL or disable JavaScript in your browser. ~~~~
User:1234qwer1234qwer4 (talk)
12:52, 2 November 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Request to end wikibreak

posting from alt account as main account is locked

Please revert the latest revision on User:Lomrjyo/common.js so I can log in again. TIA, Lomrjyo (publican) (taxes) 17:46, 19 November 2021 (UTC)

 Done looks like a math error in the setup. — xaosflux Talk 18:07, 19 November 2021 (UTC)

Change content model

 –  ― Qwerfjkltalk 08:33, 20 November 2021 (UTC)

Can an admin change the content model of User:Qwerfjkl/scripts/findlinks.js to javascript? Thanks. Also, it would be great if an admin could fix the content models of the pages listed on Wikipedia:User scripts/Snippets. ― Qwerfjkltalk 15:08, 19 November 2021 (UTC)

Oh, uh, seeing this, you might want to post at the Interface administrators' noticeboard for a faster response, most administrators do not have the technical capability to do what you are asking. Elli (talk | contribs) 05:52, 20 November 2021 (UTC)
I believe any admin can change the content model from the "Page information" link in the sidebar for the target page. I'll pass for the moment in case there is more to the issue than I'm aware of. Johnuniq (talk) 09:03, 20 November 2021 (UTC)
@Johnuniq: You must be an interface administrator to change pages to the JavaScript content model in user space (for all the reasons we have interface admins). Izno (talk) 05:34, 22 November 2021 (UTC)
Ah, it's hard to see how it could matter in this case but in general it might be an automatically executed page so it's interface admin only. Thanks. Johnuniq (talk) 06:18, 22 November 2021 (UTC)
 Done @Qwerfjkl: the model has been changed. — xaosflux Talk 16:25, 20 November 2021 (UTC)

ajaxPreview request

Per this block summary, changes to scripts under "User:Js" are to be proposed here. User:Js/ajaxPreview.js, developed by Alex Smotrov both on the English and on the Russian Wikipedia, had been left unmaintained here but was continuously developed further at ruwiki (lots of bugfixes, and use of mw.Api). Therefore, I request replacing User:Js/ajaxPreview.js#L-10 and everything below with ru:MediaWiki:Gadget-preview.js#L-9 and everything below, with the translations

  • "Страница ещё не создана — не с чем показывать разницу." → "The page has not been created yet – nothing to display the difference with."
  • "Ошибка при получении разницы версий." → "Error while getting difference between versions."
  • "Ошибка при получении преобразованного кода." → "Error while getting parsed code."
  • "Ошибка: " → "Error: ",

as well as copying ru:MediaWiki:Gadget-preview.css over to User:Js/ajaxPreview.css. ~~~~
User:1234qwer1234qwer4 (talk)
20:45, 1 November 2021 (UTC)

The Wikipedia reference search at the top of AFD not working right

Instead of just searching for things as normal, it adds in ""Articles for deletion/" before the search term.

Wikipedia:Articles_for_deletion/House_Hippo_(2nd_nomination)

All the "Find sources" links have this problem. Dream Focus 01:24, 7 November 2021 (UTC)

Possibly related to this change by @Mathglot? Doesn't seem to be related to interface pages anyway. ~~~~
User:1234qwer1234qwer4 (talk)
01:52, 7 November 2021 (UTC)
@Dream Focus: Can you describe what the problem is? I am unfamiliar with how Afd might be using this. Mathglot (talk) 02:00, 7 November 2021 (UTC)
Click the link I posted to that AFD, it like that in any AFD. Where it says "find sources" click anything on that list of links. It worked for for years, and now it doesn't search for what it is suppose to. Dream Focus 02:04, 7 November 2021 (UTC)
Checking... Mathglot (talk) 02:07, 7 November 2021 (UTC)
It should search for "House Hippo", right? Mathglot (talk) 02:10, 7 November 2021 (UTC)
Of course. Can you just revert what you did? Dream Focus 02:13, 7 November 2021 (UTC)
Stand by, it's a multi-part installation, so a rollback is complicated, a fix may be easier. Stand by... Mathglot (talk) 02:21, 7 November 2021 (UTC)
I think I just fixed half of it (dropped the "Afd" prefix; but still including the parenthetical "(2nd nomination)"; looking at that part next. Can you verify that you see a change since last time you tried it? Mathglot (talk) 02:23, 7 November 2021 (UTC)
No change. Still shows "Articles for deletion/House Hippo (2nd nomination)" instead of just "House Hippo". Dream Focus 02:25, 7 November 2021 (UTC)
Hm, checking... Mathglot (talk) 02:30, 7 November 2021 (UTC)
You might have a cached version of the page; can you purge the page and try again? Mathglot (talk) 02:35, 7 November 2021 (UTC)
Looks like it has been purged. ~~~~
User:1234qwer1234qwer4 (talk)
02:39, 7 November 2021 (UTC)
Working fine. Case closed. Dream Focus 02:40, 7 November 2021 (UTC)
Thanks for your patience and collaboration on testing this. Mathglot (talk) 02:42, 7 November 2021 (UTC)

Register "Auto-number headings"

"Auto-number headings" feature previously existed in MediaWiki core and it was removed in October 2021. I guess I'm not the only one who misses it.

There's a new possibility to register this feature as a gadget on any wiki. It's already registered e.g. on cswiki. Could you please register it on enwiki? Many thanks. --Avayak (talk) 13:51, 15 November 2021 (UTC)

Bot to update userscript from GitHub

The above BRFA was filed earlier this year but expired due to inactivity, but I found the idea interesting. Wondering if any intadmins (or admins who would be okay with getting intadmin at BN) are interested in continuing the project? I'd be happy to help out with the code for it, although the bot would have to run on your bot account since it will need intadmin perms. (courtesy ping AmandaNP, and GeneralNotability who came up with the idea and might be interested). ProcrastinatingReader (talk) 12:47, 29 October 2021 (UTC)

  • One thing I was thinking to possibly reduce the attack surface was to not just have this run on a dedicated bot account (with bot/iadmin but NOT admin) - but also pblock that account from everything but userspace. — xaosflux Talk 13:22, 29 October 2021 (UTC)
    • It doesn't stop a compromised bot account from just hacking admins via their common.js's -- but at least it is a barrier. — xaosflux Talk 13:23, 29 October 2021 (UTC)
  • +1. Would be quite useful. – SD0001 (talk) 10:32, 26 November 2021 (UTC)

Delete broken redirects

User:Nigos/glintwarn.js is a broken redirect and should be deleted by an intadmin. Once that is deleted, User:Anchorvale/glintwarn.js would then also become broken and should be deleted too. GeoffreyT2000 (talk) 18:48, 13 December 2021 (UTC)

 Donexaosflux Talk 19:04, 13 December 2021 (UTC)

Interface administrator assistance needed

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Hi, can an interface administrator please move Template:Clade gallery/styles-div.css to User:Jts1882/Clade gallery/styles-div.css? This is as a result of Wikipedia:Templates for discussion/Log/2021 December 15#Template:Clade gallery/styles-div.css. plicit 03:24, 22 December 2021 (UTC)

Was this not possible for you? I am surprised, since I'm pretty sure MediaWiki should only have a conniption if you're trying to move unsanitized css content model rather than sanitized-css content model to the user space. Izno (talk) 05:36, 22 December 2021 (UTC)
It’s intentional in MediaWiki namespace, and I suppose it’s intentional in user namespace as well—things like the withCSS URL parameter handler in MediaWiki:Common.js consider page titles ending with .css in the MediaWiki namespace safe, no matter what content model they have. Since this protection also means that only the user themselves and interface admins can edit the TemplateStyles page from now on, maybe it would have been (or would be) better to use a page title not ending in .css, since AFAIK TemplateStyles itself doesn’t consider the page title suffix (except when determining the default content model), it could load the content from, say, User:Jts1882/Clade gallery/styles-div, as long as it has sanitized-css content model. —Tacsipacsi (talk) 14:36, 22 December 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Inactive interface administrators 2021-12-28

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


The following interface administrator(s) are inactive:

— JJMC89 bot 23:18, 28 December 2021 (UTC)

 Done removed. — xaosflux Talk 22:48, 2 January 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Edit request for huggle.css pages

Hello, I have an edit request to update 113 user huggle.css pages listed here. This would be to replace the part of block-message text

you may [[Wikipedia:Appealing a block|contest it]] by adding the text <tt><nowiki>{{</nowiki>unblock|''your reason here''}}</tt> below.<!-- Template:uw-huggleblock1 -->

with

you may [[Wikipedia:Appealing a block|contest it]] by adding the text {{tlc|unblock|your reason here|italic=on}} below.<!-- Template:uw-huggleblock1 -->

This is because <tt>...</tt> tags are obsolete in HTML5 and their usage creates a Lint error. I currently have an ongoing bot task User:MalnadachBot/Task 12 to replace their existing usage in User talk pages. However individual users' huggle.css pages will have to be updated to prevent further spread of tt tags through substitution. An Int admin with AWB can do this easily. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 08:30, 3 January 2022 (UTC)

I will take a look in the morning. Izno (talk) 08:36, 3 January 2022 (UTC)
Wait, is this actually causing any problems? Don't these pages automatically refresh the next time that person loads Huggle - and if they don't load Huggle these aren't doing anything. — xaosflux Talk 15:26, 3 January 2022 (UTC)
Maybe, but it seems reasonable to knock out the middleman until Huggle refreshes. And if it does refresh and the items remain there, then we know that Huggle may need to be patched to remove the old HTML. Izno (talk) 18:27, 3 January 2022 (UTC)
That said, the template has had issues with visual editing before (particularly copy/paste) and new unblock requests might be more likely to use VE in some way (e.g. DiscussionTools under the hood), so I'm just going to swap the use of tt to code. Izno (talk) 18:30, 3 January 2022 (UTC)
And done. Izno (talk) 18:35, 3 January 2022 (UTC)

BOTN request regarding 2x redirects

Just wanted to draw attention to WP:BOTN#Double redirects for user's scripts for your review. I think I took care of everything sensibly, but take a look at the relevant links there if you haven't yet. Izno (talk) 08:40, 3 January 2022 (UTC)

Izno - I went through the list at Special:DoubleRedirects, found a couple of .js and .css pages in the user space of accounts that have since been renamed twice, and fixed those double-redirects. Other than that, all looks good to me. Everything else on that list can be fixed by non-interface admins. :-) ~Oshwah~(talk) (contribs) 08:00, 9 January 2022 (UTC)
Izno - Nevermind. I just realized that you left those double-redirects on purpose due to a rename-process that was performed out of order. I've undone those changes. Sorry about that! ~Oshwah~(talk) (contribs) 08:05, 9 January 2022 (UTC)

Tech news 2022-02

Lots of juicy stuff for gadget writers and interface admins with the recent deployment courtesy SD0001. See WP:VPT#Tech News: 2022-02. Izno (talk) 03:57, 11 January 2022 (UTC)

Some good stuff in there! Enterprisey (talk!) 23:10, 11 January 2022 (UTC)
One of the changes in there has been dismissed as insecure, phab:T29766#7611796. It seems even interface-admins can't be trusted anymore. – SD0001 (talk) 05:08, 12 January 2022 (UTC)

Request for content model change for user CSS page

Hi - I'm trying to implement a template in my userspace which will allow the use of a particular font custom for use in my signature. Unfortunately it seems that TemplateStyles requires "Sanitized CSS" content model, but CSS pages created in userspace are just the "CSS" model by default. As such, TemplateStyles throws up an error message about the content model. Would it please be possible for someone to manually convert the CSS page in my user space to Sanitized CSS? It's User:Theknightwho/Doves Type/fonts.css. Theknightwho (talk) 23:28, 12 January 2022 (UTC)

 Not done @Theknightwho: your current code contains at least one error incompatible with SCSS (Invalid or unsupported value for property src at line 3 character 8.). I created a new SCSS page for you at User:Theknightwho/Doves Type/fonts2.css which you can either build instead, or use to sandbox your changes. — xaosflux Talk 23:34, 12 January 2022 (UTC)
a particular font custom for use in my signature Please don't. Wikipedia:Signatures#NoTemplates. Nardog (talk) 23:35, 12 January 2022 (UTC)
Understood. Thanks. Theknightwho (talk) 23:38, 12 January 2022 (UTC)
Beyond not using templates, please don't make others download a font to see your signature. isaacl (talk) 23:47, 12 January 2022 (UTC)
100%; but if they want this to just use with a js to restyle their sig for only themselves, that's not so much a problem. — xaosflux Talk 23:50, 12 January 2022 (UTC)
For which it should be in their common.css or skin.css, not in a TemplateStyles page. Izno (talk) 00:53, 13 January 2022 (UTC)

Proposal to block reFill edits

Page watchers may be interested in WP:VPPRO#RfC: Block reFill tool until fixed. Izno (talk) 22:31, 21 January 2022 (UTC)

  • Thanks for the note, though I don't think there is going to be pretty much anything for intadmins to do here? — xaosflux Talk 22:57, 21 January 2022 (UTC)
    I hadn't remembered it was not local (sourced either directly to Toolforge or to the meta version), but regardless, I like to think it makes sense to attempt to reach gadget-savvy (JavaScript/CSS) editors here generally, and specifically in this case one might be able to correct the issue by fixing the script. Izno (talk) 23:02, 21 January 2022 (UTC)
    Oh for sure, and if there is a good fix that can be made on the meta script, I can make it over there, but for the most part major work is happening on toolforge, even on the meta script. — xaosflux Talk 23:05, 21 January 2022 (UTC)

Unlocking

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Can someone remove the script from User:AssumeGoodTest/common.js? I may use the account for future tests. – AssumeGoodWraith (talk | contribs) 13:09, 27 January 2022 (UTC)

Ownership link: Special:Redirect/logid/126865922. — xaosflux Talk 13:24, 27 January 2022 (UTC)
@AssumeGoodTest and AssumeGoodWraith:  Donexaosflux Talk 13:26, 27 January 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Request

There is a request at MediaWiki talk:Gadgets-definition which is categorised as a full protection request, but is actually an interface protection request, if someone would like to look at it? Cheers — Martin (MSGJ · talk) 13:15, 31 January 2022 (UTC)

Fixed the queue, someone should get to it soon. — xaosflux Talk 15:10, 31 January 2022 (UTC)

Dark mode toggle gadget

Wikipedia:Village pump (technical)#Make dark mode toggle script a gadget? appears to have consensus.

Implementation would essentially involve:

  •  Done Moving User:SD0001/dark-mode-toggle.js to MediaWiki:Gadget-dark-mode-toggle.js.
  •  Done Adding to MediaWiki:Gadgets-definition under Appearance section, perhaps just below "Use a black background with green text" as the two are similar: dark-mode-toggle [ResourceLoader | targets = desktop, mobile | dependencies = mediawiki.util, mediawiki.api, mediawiki.Uri, mediawiki.storage, es6-polyfills | skins = vector, monobook, modern, minerva, timeless] | dark-mode-toggle.js
  •  Done Creating MediaWiki:Gadget-dark-mode-toggle with [[User:Volker E. (WMF)/dark-mode|Dark mode]]: Use a light text on dark background color scheme (can be toggled on/off)
  •  Done Changing MediaWiki:Gadget-dark-mode to [[User:Volker E. (WMF)/dark-mode|Dark mode]]: Use a light text on dark background color scheme (Internal – use the [[#mw-input-wpgadget-dark-mode-toggle|toggle gadget above]] instead)

Per @MusikAnimal's comment, this marks the existing styles gadget as "internal". – SD0001 (talk) 10:09, 14 December 2021 (UTC)

@SD0001 and Volker E. (WMF): we already have dark-mode[ResourceLoader|targets=desktop,mobile|skins=vector,monobook,modern,minerva,timeless]|dark-mode.css (Use a light text on dark background color scheme) in gadgets - are both of these being kept? Is there a problem if a user enables both at the same time? — xaosflux Talk 11:45, 14 December 2021 (UTC)
The relationship between the two has been discussed in the two VPT threads. To recapitulate:
  • the existing dark-mode gadget loads just the CSS
  • toggle functionality relies on programmatically flipping on/off the CSS gadget in user preferences (so obviously the toggle can't be made part of the CSS gadget)
  • so we call the toggle gadget as the "dark mode" gadget. The CSS gadget is necessary for internal use, but can't be hidden from preferences, so we modify its description to note that it's internal (bullet 4 above).
SD0001 (talk) 12:35, 14 December 2021 (UTC)
@SD0001: why can't we mark it "hidden" like we do with other helper gadgets like Twinkle-pagestyles[hidden|skins=vector]|Twinkle-pagestyles.css? — xaosflux Talk 14:25, 14 December 2021 (UTC)
Is it so users don't get "stuck" on or off or something? @MusikAnimal: ? — xaosflux Talk 14:26, 14 December 2021 (UTC)
It's because hidden gadgets can't be enabled/disabled in user preferences, even by the API – which is how the toggle is supposed to enable or disable dark mode. – SD0001 (talk) 14:37, 14 December 2021 (UTC)
OK thanks, so users could still just use it manually if they wanted to I suppose. — xaosflux Talk 15:32, 14 December 2021 (UTC)
Great work, all! But I think there's more to be done. We talked about moving the links to #p-personal, but that can wait. More important is not having the two gadgets side by side in the list, which is rather confusing from a usability standpoint. Right now things are designed with a CSS-only gadget and then a toggle gadget, but that's purely out of technical necessity. I suspect most will want the luxury of easily toggling it on/off (especially for a dark mode that uses the invert() CSS filter which inevitably will produce some sort of visual bug). The problem is how to accommodate those who have the CSS gadget on but not the toggle.
What if we add a MediaWiki:Gadget-dark-mode.js that checks if dark-mode-toggle is enabled, and if not, enables it and loads the JS? Is that too hacky and/or weird?
Also I think we should link to Wikipedia:Dark mode from the gadget descriptions, and amend the page to document the gadget first and foremost, with the other content below it.
Then finally moving the toggle to p-personal as discussed at WP:VPT. That will require a little more care, since we need to use peer gadgets to ensure the links don't "jump" in p-personal, and that it looks good in mobile view. It can be done though, and I'll gladly take a stab when the time comes.
Once all of that is done, I feel like we'll be in a good place to start talking about enabling the gadget for all users. And that, in turn, may argue that mw:Extension:DarkMode could possibly have a second chance at deployment (since we're basically reproducing it locally in a rather hacky way)… but one step at a time :) MusikAnimal talk 06:03, 16 December 2021 (UTC)
Moving links to #p-personal - @Nardog already set that in motion, but there's still no css to avoid the "jump". Should we add the CSS as a new peer gadget, or just add it along with dark-mode CSS?
I think the confusion from having two gadgets could be solved by more tactful gadget descriptions – maybe create an "Internal" section at the bottom and move the styles gadget there?
What if we add a MediaWiki:Gadget-dark-mode.js that checks ... As Izno mentioned on VPT, the base dark-mode gadget can't contain anything other than CSS – it ceases to be render-blocking if any JS is added into it, leading to FOUCs. If you are suggesting this as a way of enabling the toggle for existing dark-mode users, how about putting some temporary code in mediawiki:group-user.js to that effect (if kept for 30 days, anyone who logs in within that time is sorted)? – SD0001 (talk) 17:42, 16 December 2021 (UTC)
Yeah I saw it was moved to p-personal. I'll try to work on the peer CSS soon. I believe dark-mode-toggle needs a peer gadget to reserve the space for the "Dark mode" text and dark-mode.css would reserve the space for "Light mode". That should work I think. I'll test it out on Test Wikipedia first.
I have moved dark-mode back to the bottom of "Testing and development" and change the description to be as you suggested, encouraging use of the toggle. I now understand why we can't have a dark-mode.js, thanks for explaining. I don't think we need to bother with adding special temporary code to Group-user.js or what have you. Those who have only the CSS gadget enabled will eventually discover the toggle gadget. MusikAnimal talk 18:21, 16 December 2021 (UTC)
This pretty much solves the jumping effect:
.skin-vector-legacy :not(#pt-darkmode) + #pt-watchlist::before,
.skin-monobook :not(#pt-darkmode) + #pt-watchlist::before {
	content: "Dark mode";
	visibility: hidden;
	margin-left: inherit;
}
The content of the pseudo-element must be hard-coded, so it won't reflect the label in mw.messages—probably a non-issue as long as the JS and CSS cross-reference each other in comments. A bigger problem is that if the dark mode is on, there will still be a slight jump because the toggle will show up as "Light mode". Come to think of it, I don't even know if the toggle should show different labels at all—it's pretty clear what a button called "Dark mode" does when you're already in the dark mode. I've found "Light mode" a bit clumsy anyway. Nardog (talk) 13:33, 17 December 2021 (UTC)
The jump while in dark mode can be removed by adding the same style with higher specificity (but with content: "Light mode") in dark-mode.css. – SD0001 (talk) 15:18, 19 December 2021 (UTC)
@Nardog @SD0001 I've got this working over at Test Wikipedia, if you want to try it out (look for "dark-mode-toggle" at testwiki:Special:Preferences#mw-prefsection-gadgets). Used both of your suggestions (thank you!). If it all looks good to you I'll get this implemented here on enwiki.
This does mean folks with only the CSS gadget will have a mysterious blank space in their p-personal; but when inquiries come in at VPT or elsewhere, we simply instruct them to enable the toggle gadget, hopefully without any complaints. MusikAnimal talk 22:54, 20 December 2021 (UTC)
It works! I don't think visibility: hidden; margin-left: inherit; is necessary in dark-mode.css though, and I would use something like body.skin-vector-legacy :not(#pt-darkmode) + #pt-watchlist::before to avoid the need for !important. Nardog (talk) 05:06, 21 December 2021 (UTC)
I had added a #p-personal to get around having to use !important, but then forgot to remove the !important, heh. Using body.skin-vector-legacy seems more greceful, anyway, so done, and same with removing the redundant properties that come with dark-mode-pagestyles.css. I'll implement this on enwiki shortly. MusikAnimal talk 05:53, 21 December 2021 (UTC)
Okay, deployed :) I'm only noticing now that there are some issues with the correct dark/light mode text being the opposite of what it should be, or the stylesheet didn't load. It doesn't always remember your preference browsing page to page, either. Or some combination of before mentioned issues. It's a JS issue unrelated to these changes. I can try to take a look but please feel free to do the same. MusikAnimal talk 06:12, 21 December 2021 (UTC)
I don't see any issue. Toggling and rapidly navigating to another page may load the old mode – which is an expected race condition as the server is sending the new page just as the user preference is changing, but not exactly a bug as the mode change is still registered and reflected on subsequent navigation. Not sure if it's worth adding a beforeunload handler to stop navigation till the API response is received ... – SD0001 (talk) 13:57, 21 December 2021 (UTC)
Yes doing more testing today, I believe it's just the race condition when toggling and changing pages, which may be more noticeable on testwiki. This probably isn't something people will experience during normal day-to-day usage, rather I found it only because I was doing rigorous testing. If we hear more complaints we can look into adding the beforeunload handler. MusikAnimal talk 17:05, 21 December 2021 (UTC)
A less intrusive way than beforeunload is to keep the preference in localStorage (or perhaps sessionStorage) on toggling, and if it doesn't match the value in mw.user.options when the script is loaded, turn it on/off according to the storage value (or double-check with the server and then turn it on/off). Nardog (talk) 03:04, 22 December 2021 (UTC)
Clever! sessionStorage would maybe make more sense here because it's only meant to carry over multiple requests in quick succession, and it'll expire on its own. If you are willing to code this up I'd be happy to help test and sync here. Which gets me thinking, is it worth giving this pair of gadgets a repository over at https://github.com/wikimedia-gadgets/ ? MusikAnimal talk 03:57, 22 December 2021 (UTC)
Thanks. I think a comment at the beginning of dark-mode-toggle.js saying the labels in the script and in the two CSSes should match would be nice. Nardog (talk) 06:17, 21 December 2021 (UTC)
Good idea.  Done MusikAnimal talk 16:52, 21 December 2021 (UTC)
@MusikAnimal and @Nardog: I've created Wikipedia:Dark mode (gadget) with instructions on setting up the gadget, for the benefit of other wikis. User:Volker E. (WMF)/dark-mode doc page was rather messy, and WP:Dark mode title was already taken for an overview. Let me know if all looks good. Then, we can put out a note in Tech News. – SD0001 (talk) 18:29, 2 January 2022 (UTC)
If this is the new documentation, it should get linked here: MediaWiki:Gadget-dark-mode-toggle. — xaosflux Talk 22:48, 2 January 2022 (UTC)
@SD0001 Thanks for creating centralized documentation! I am very fond of spreading this idea to more wikis such as through Tech News. If it catches on, perhaps that would be enough to convince whomever that the community is content with a CSS filter-based solution, and mw:Extension:DarkMode will have a chance. Assuming that won't happen, I think we should go the meta:MoreMenu route and instruct other wikis to import the gadget from here, offering a means to localize messages -- either through edit request here or perhaps sourcing a local file (JSON behind ResourceLoader is coming very soon, by the way!). Aside from the messages and the CSS tweaks which each wiki could also independently make, is there any reason for them to "copy" our gadget? I was even thinking we should move the docs and source files to Metawiki, but I don't see that as a necessity. MusikAnimal talk 06:20, 3 January 2022 (UTC)
Lol, JSON behind ResourceLoader is coming very soon, by the way! – I said that as if you didn't already know ṫhat… silly me, sorry I neglected to realize you were the author (and sorry I wasn't much help with reviewing, by the way)! This is an exciting feature I'm very much looking forward to, and I think i18n messaging would be a good use for it. MusikAnimal talk 06:26, 3 January 2022 (UTC)
@MusikAnimal For the JS toggle, you're right - it can also be dynamically loaded, especially since the i18n messages could soon be moved to a json file. But the CSS gadgets would have to be copied to avoid FOUCs. Overall, the Gadgets extension still leaves a lot to be desired. I just filed phab:T298561 for better ways to handle cross-wiki gadgets, which would remove the need to copy the CSS files – and even avoid having to do an mw.loader call for loading the JS (it could be loaded through gadget definition itself). – SD0001 (talk) 21:06, 4 January 2022 (UTC)
Now added to m:Tech/News/2022/06. – SD0001 (talk) 11:32, 30 January 2022 (UTC)
@SD0001 Sorry I've been so busy I haven't had time to come back to this; are we sure we want to encourage copy/pasting our gadget? I would strongly advise against it. If they have to copy/paste the CSS, so be it, but I imagine over time we'll want to make updates to the JS and we surely don't want to go through what I did with the multi-month (and still incomplete) effort at meta:MoreMenu/Migration.
Starting this week I'll have a little more time on my hands and am happy to help with this, including moving the localization strings to JSON if we feel that is worthwhile? MusikAnimal talk 22:16, 30 January 2022 (UTC)
Also, is it just me or does the demo link not work anymore? MusikAnimal talk 22:21, 30 January 2022 (UTC)
@MusikAnimal: looks like mw:Extension:Gadgets#supportsUrlLoad may be enforced now; so MediaWiki:Gadgets-definition would need a definition update to support it. — xaosflux Talk 11:08, 31 January 2022 (UTC)
SD0001 isn't "encourag[ing] copy/pasting our gadget", at least at Wikipedia:Dark mode (gadget)#Setting up the gadget on your wiki. Nardog (talk) 16:09, 31 January 2022 (UTC)
You're right, sorry, I see we are now suggesting loading the enwiki gadget. It was the MediaWiki:Gadget-dark-mode-toggle.js by copying the English Wikipedia versions bit that confused me. So we're not asking they load our gadget, just suggesting it, but that's still better than nothing. I withdraw my concern. If this gadget takes off and gets enabled on a lot of wikis, that may be enough to influence WMF to give mw:Extension:DarkMode another chance, in which case we'll nuke all the gadgets anyway (nullifying the need for them to source our gadget for long-term maintenance purposes). MusikAnimal talk 17:11, 31 January 2022 (UTC)
Yeah the wording had been adjusted (this edit). Feel free to adjust it further to more strongly encourage the dynamic load option – I just couldn't come up with better phrasing. Still a week for the Tech News issue to go out, so no rush! – SD0001 (talk) 18:01, 31 January 2022 (UTC)
Regarding using JSON for localisation strings – the trouble is that I don't think that approach is compatible with the idea of other wikis dynamically loading the JS file. require is undefined when loading from ?index.php&action=raw. On the other hand, if ?load.php&only=scripts URL is used, require will work but it will load in the enwiki JSON file. – SD0001 (talk) 18:05, 31 January 2022 (UTC)

supportsUrlLoad

Page watchers may be interested in MediaWiki talk:Common.js#supportsUrlLoad. Izno (talk) 20:00, 1 February 2022 (UTC)

Inactive interface administrators 2022-02-28

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


The following interface administrator(s) are inactive:

— JJMC89 bot 23:18, 28 February 2022 (UTC)

No I’m not.—CYBERPOWER (Message) 23:22, 28 February 2022 (UTC)
@Cyberpower678: The bot is correct, you have not sufficiently recently changed a page onwiki which requires the interface administrator permission. Izno (talk) 23:27, 28 February 2022 (UTC)
Izno, Hmm. The bit is still useful for what I do, though. I haven't realized I haven't touched JS pages in a while. —CYBERPOWER (Message) 23:32, 28 February 2022 (UTC)
In the interest of disclosure, I made this edit, to fulfill a request by Harej. Bureaucrats can make of that what they want. I made this edit before I was going to lose access.—CYBERPOWER (Message) 23:39, 28 February 2022 (UTC)
 Not done Cyberpower678 has now satisfied the activity requirement so I'm not going to flip it, to follow him over to WP:BN to flip it back. This is supposed to be somewhat easy come - easy go, for the editors that really need it. — xaosflux Talk 01:11, 1 March 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

OTRS transition to VRT

OTRS is now defunct and been replaced by VRT but it appears that the enwiki has not updated its systems to reflect that. I posted some questions User:Ruthven an itwiki, VRT and Commons admin I know and will repeat some of that for you here.

I was trying to add VRT permission ticket numbers to some en files, such as File:Image of Kaushik Basu.JPG, but the left side permission links don't work and no transition seems to have been made from OTRS to VRT in the templates. These functions all works fine on the common but now can only be done here manually and it seems the only templates available are the OTRS ones: {{Permission received}} or {{VRT received}} don't exist. I don't know who to contact to get that transition completed. The template {{OTRS pending}} is also still in use.

The 3 OTRS tools on the left of any en file page for locally hosted files are what I am asking about and User:B-bot's page also needs major corrections to remove all reference to OTRS.

A possible reason for this might be that: it's probably because en.wiki was using Commons' javascript. They have to rename their permission templates to Permission pending and PermissionTicket or import their own version of the gadget code. You should contact an interface Administrator on en.wiki to ask them to have the local version of the Gadget.

Hopefully someone knowledgeable will attend to this problem. ww2censor (talk) 14:38, 8 March 2022 (UTC)

Not positive, but I don't think we have an OTRS/VRT Gadget; certainly not one that's on by default, at least. I'm guessing what you're talking about is User:Technical 13/Scripts/helpOTRS.js, which you've installed on your common.js page. Writ Keeper  14:59, 8 March 2022 (UTC)
@Ww2censor I'm not seeing anything either. If you see an enwiki page that needs updating, please open an edit request on the corresponding talk page. — xaosflux Talk 15:01, 8 March 2022 (UTC)
@Xaosflux and Writ Keeper:: Thanks: the Gadget is not my suggestion but that of User:Ruthven. I have the script User:Technical 13/Scripts/helpOTRS.js installed in User:Ww2censor/common.js and on opening the actual script you refer to, it indeed only refers to OTRS, so it looks like the script needs to be revised. So who would do that? ww2censor (talk) 15:21, 8 March 2022 (UTC)
@Ww2censor That personal userscript you are importing is linked to a user that has been indefinitely banned by our Arbitration Committee since 2015, and as such in no longer maintained. I suggest you stop importing it, however feel free to fork it to your own userspace (with attribution) and update as you like. — xaosflux Talk 15:44, 8 March 2022 (UTC)
@Ww2censor I fully agree with Xaosflux: you should modify your own version of the gadget (I can help in that). I didn't know from where was coming the JS, and that you were using on en.wiki the Commons' version was just a guess. Cheers Ruthven (msg) 16:34, 8 March 2022 (UTC)
@Xaosflux, Writ Keeper, and Ruthven: Wow, I added that userscript 4 years after the user was blocked. I suppose User:Technical 13/Scripts/helpOTRS.js should be deleted or at least a not made that it does not function and should not be used. I've removed it from my common.js page for now and will see if Ruthven can help me make a new one that works with the current VRT setup. I think creating it myself is way above my pay grade, unless one of you can assist. Beside that I think new template will be needed to accompany the script. Anyway, thanks for explaining. ww2censor (talk) 22:19, 8 March 2022 (UTC)
Just FYI: the blocking had nothing to do with script writing; I certainly am not reviewing them all - but it is likely they were all at least 'safe' to use at the time, just no maintenance now. — xaosflux Talk 23:34, 8 March 2022 (UTC)

User:Спартанец/monobook.js

User:Спартанец/monobook.js is throwing a bunch of bogus speedy deletion notices, is it possible to correct it so that it doesn't? Jo-Jo Eumerus (talk) 11:53, 21 March 2022 (UTC)

 Done ~ Amory (utc) 13:04, 21 March 2022 (UTC)
User:DB/common.js seems to have the same problem. Jo-Jo Eumerus (talk) 15:37, 21 March 2022 (UTC)
 Done Jo-Jo Eumerus what a hot mess of a page, I just nowiki'd the entire thing. — xaosflux Talk 15:49, 21 March 2022 (UTC)

Unchanged JS script showing up in CAT:CSD

User:Zhaofeng Li/vada/vadaprocess.js hasn't been edited since 2014 but is showing up today in CSD. Best, Barkeep49 (talk) 14:46, 23 March 2022 (UTC)

User:Zhaofeng Li/vada/vadaprocess.js is suddenly showing up in CAT:G10, despite no changes since 2014; I'm guessing the /* <nowiki> */ could use tweaking (possibly the missing closing tag?) of some sort. Thanks. --Blablubbs (talk) 14:47, 23 March 2022 (UTC)

 Done (by User:Writ_Keeper). — xaosflux Talk 15:02, 23 March 2022 (UTC)

JS pages in Category:Foo

Category:Foo is a redirect that has recently been filling up with old .js pages (e.g. User:Garyvdm/popups.js) due to some null edits. The problem is discussed at Wikipedia:Village pump (technical)#Category redirect Foo playing up again but an interface administrator is needed to fix the text to remove them from the category. Thanks in advance. Timrollpickering (talk) 18:32, 22 March 2022 (UTC)

 Done seems to be resolved. — xaosflux Talk 10:07, 23 March 2022 (UTC)
Thanks. Could someone also take a look at the pages in Category:X1 which is supposed to be transient but also has some ancient .js pages in there. Timrollpickering (talk) 13:09, 23 March 2022 (UTC)
@Timrollpickering I went through and cleared out ones that were in script files for users that were extremely inactive. For users with more recent edits, you can contact them on their talk pages. Best regards, — xaosflux Talk 15:17, 23 March 2022 (UTC)

A few more pages have popped back into Category:Foo (is a bot doing null edits?) and there's also a similar problem with Category:VoA scripted admins. I suspect long term there will need to be a massive clean-up of these .js pages. Timrollpickering (talk) 14:00, 26 March 2022 (UTC)

Yes, there is a bot doing purges/null edits. It's mentioned in that VPT discussion after your second comment there. Izno (talk) 17:24, 26 March 2022 (UTC)

Clarify that dark-mode does not work on Special: pages

Would it be possible to add some text be added to the Dark Mode gadget toggle, mentioning the fact that it won't work on pages with the Special: prefix ? I spent quite a good chunk of time today figuring out why the Settings page was being switched to Light Mode before going through the docs and realizing that the scripts aren't loaded on Special: pages by MediaWiki itself.


P.S. Let me know, if this isn't the correct place to report this, and if I need to create a phabricator issue/report to some other forum/talk page. :) Sohom Datta (talk) 20:20, 27 March 2022 (UTC)

No, it simply doesn't work on the preferences page, not all special pages. This is due to it being onwiki JavaScript at the end of the day. Izno (talk) 20:33, 27 March 2022 (UTC)
To add: there's already a note to this effect at the top of the Gadgets tab: Gadgets will not operate on certain special pages, such as this User Preferences page. Writ Keeper  20:36, 27 March 2022 (UTC)
@Sohom data feel free to edit Wikipedia:Dark mode (gadget) with accurate information to advise people of the limits of the gadget. — xaosflux Talk 22:04, 27 March 2022 (UTC)

Inactive interface administrators 2022-03-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:18, 28 March 2022 (UTC)

 Done (removed) — xaosflux Talk 02:23, 29 March 2022 (UTC)

Gadget-markblocked.js

Hello and apologies if this is the wrong venue. I reported a bug at MediaWiki talk:Gadget-markblocked.js § Local blocks on Meta marks users as blocked elsewhere on December 2021. It looks like that page is not being monitored often so I thought I should post a note here. A fix would certainly be appreciated. Thank you, —MarcoAurelio (talk) 14:28, 18 April 2022 (UTC)

Replied there, but I don't think this is something that can/should be fixed on our version of this script. Writ Keeper  14:43, 18 April 2022 (UTC)

Content Model Modification

Hello, I would like to ask for help regarding modifying my user stylesheet's content model type from “CSS” to “Sanitized CSS”. Any reply and comment are welcome, thank you!-Taipei NativeComment 01:12, 26 April 2022 (UTC)

P.S. I understood there are a note above: ... user JavaScript/CSS pages should continue to be made on their respective talk pages. But I didn't understand how to let interface administrators notice the request since I didn't know who I should or should not ping. -Taipei NativeComment 01:21, 26 April 2022 (UTC)
@台北人 if you run in to this again, you can just drop a {{Edit interface-protected}} template on the talk with a note, we patrol those regularly. For sporadic requests, here is OK too. — xaosflux Talk 10:15, 26 April 2022 (UTC)
 Done Izno (talk) 01:23, 26 April 2022 (UTC)

Regarding XFDcloser

I stated a discussion at Wikipedia talk:XFDcloser#Time to "demote" this as a gadget and return it to being a user script? Wikipedia talk:XFDcloser#Any interface editors willing to help maintain this gadget? which may be of interest to interface administrators. The idea of more editors to maintain the XFDcloser has been suggested, which can only be done by interface administrators. Steel1943 (talk) 20:58, 28 April 2022 (UTC)

(Section name changed; link updated in response.) Steel1943 (talk) 22:41, 28 April 2022 (UTC)

Help request for Turkish Wikipedia

Vikipolimer asked me to help them make tr:MediaWiki:Gadget-XFDcloser-core-beta.js work. I don't know enough about JS to do anything but maybe someone here can help them. Jo-Jo Eumerus (talk) 17:42, 19 May 2022 (UTC)

I referred them to Wikipedia talk:XFDcloser where the usual maintainers of that gadget can help if they would like. — xaosflux Talk 18:13, 19 May 2022 (UTC)
Hi everyone, you can look here to help me with this. 𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 00:13, 23 May 2022 (UTC)

Help needed about OOUI

Hi dear community, I'm a sysop and interface admin on Turkish Wikipedia, right now I'm working on an AfD remarker gadget on the Turkish wiki for leaving opinions to candidate articles, I'm working on it about 4 days approximately but I have a problem with getting selected data with OOUI ButtonSelectWidget can you help me with this please, how can I get selected ButtonOptionWidget data? 𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 02:10, 29 May 2022 (UTC)

Hi Vikipolimer! Welcome to the Engish Wikipedia! :-) I admit that I'm not too familiar with these objects. I was able to locate this documentation page - have you seen this before? I'm sure you have, but I thought I'd at least try and give you a link or two to try and point you in the right direction. :-) ~Oshwah~(talk) (contribs) 00:43, 4 June 2022 (UTC)
Hi @Oshwah I already done my gadget :) 𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 00:51, 4 June 2022 (UTC)
Hi Vikipolimer! I see. Are you having issues with gathering specific data from ButtonOptionWidget that you're looking for? ~Oshwah~(talk) (contribs) 01:00, 4 June 2022 (UTC)
@Oshwah No not anymore, I've figured out how OOUI works finally. 𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 01:09, 4 June 2022 (UTC)
Vikipolimer - Awesome! I just wanted to make sure that your request for assistance here didn't go without a response from someone. I'm glad that you manged to get everything working. Have a great weekend, and I wish you happy editing! :-) Cheers - ~Oshwah~(talk) (contribs) 06:27, 4 June 2022 (UTC)

Code review for Gadget ER's needed

Does anyone have time to go through the requests in User:AnomieBOT/IPERTable - 3 gadgets have suggested changes, most are non-trivial. — xaosflux Talk 18:46, 3 June 2022 (UTC)

I've closed 3 of the 4 that were open.
The citation.js one is technically trivial but I am not sure how appropriate it is for a (that?) gadget to assume a keyboard shortcut. There are only so many keys and the likelihood of a link at this scope of the page is likely to clash with other gadgets or user scripts. I am unconvinced by the pointer to our local page on the point. Izno (talk) 19:44, 3 June 2022 (UTC)
Yeah, same. I've almost commented there like three times, so I suppose I should. ~ Amory (utc) 22:51, 4 June 2022 (UTC)

My bot was approved to run the replacements

  • <source><syntaxhighlight lang="">
  • </source></syntaxhighlight>
  • <source<syntaxhighlight

(task 10). Can an interface admin run the replacements on the remaining pages, mostly userspace .js and .css pages? ― Qwerfjkltalk 22:40, 10 June 2022 (UTC)

Checking on this. — xaosflux Talk 01:25, 11 June 2022 (UTC)
@Qwerfjkl I filed Wikipedia:Bots/Requests for approval/Fluxbot 8 to do it. — xaosflux Talk 01:36, 11 June 2022 (UTC)
Xaosflux, Qwerfjkl, do I understand correctly you're moving pages from Category:Pages using deprecated source tags to Category:Pages with syntax highlighting errors by using an invalid (empty) lang, like Wikipedia:Bot requests/Archive 80 (Diff ~1084326837) did? Alexis Jazz (talk or ping me) 11:24, 11 June 2022 (UTC)
@Alexis Jazz I certainly don't want to create more problems, take a look at that BRFA, it is going in the direction that these tags are useless on these pages and can just be removed. — xaosflux Talk 11:30, 11 June 2022 (UTC)
It's not moving them from one category to another though, as a source tag without the lang value set would be in both categories. -- WOSlinker (talk) 11:46, 11 June 2022 (UTC)
I stand corrected, only the reason for the page to be in Category:Pages with syntax highlighting errors will change. (empty vs. absent lang parameter) Of course, if anyone performs replacements, it should be made sure that the page actually leaves these maintenance categories. Alexis Jazz (talk or ping me) 12:33, 11 June 2022 (UTC)
@Alexis Jazz, I plan to deal with the second category at some point, but that can't be automated (mostly). ― Qwerfjkltalk 13:37, 11 June 2022 (UTC)
  • Feel free to use my BRFA as the "how should we deal with this", it may have more visibility since I linked it in from AN. — xaosflux Talk 11:57, 11 June 2022 (UTC)

Clarify process on granting INTADMIN

I've started a discussion at Wikipedia_talk:Interface_administrators#Clarify_the_right_can_be_refused to clarify the process for granting INTADMIN rights. All are invited to participate. TonyBallioni (talk) 00:52, 16 June 2022 (UTC)

Website Dark Mode Problem

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I'm not sure if this is the right place:

For the past few days, in dark mode, the left sidebar (and bottom of pages) is white background and the links are hard to see, on ALL pages.

Dark Mode Sidebar on all pages example.

I use 64-bit Firefox 102 on Ubuntu/Mint Linux. Nostep (talk) 07:46, 5 July 2022 (UTC)

@Nostep: see Wikipedia_talk:Dark_mode_(gadget) - is it better for you now? — xaosflux Talk 01:13, 6 July 2022 (UTC)
Yes. Looks like you guys got it fixed for FF. Thanks! Nostep (talk) 01:49, 6 July 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Change dependencies for Mobile

Change dependencies in MediaWiki:Request-page-protection-form.js with the below code.

$.when(), $.ready, mw.loader.using(['mediawiki.api', 'mediawiki.widgets', 'mediawiki.util', 'oojs-ui-core', 'oojs-ui-windows']).then(function()

In this way, it will work on the mobile UI as well. And also add the below code to MediaWiki:Mobile.js

:mw.loader.using( ['mediawiki.util'], function () {
:	var extraCSS = mw.util.getParamValue( 'withCSS' ),
:		extraJS = mw.util.getParamValue( 'withJS' ),
:		extraModule = mw.util.getParamValue( 'withModule' );
:	if ( extraCSS ) {
:		// WARNING: DO NOT REMOVE THIS "IF" - REQUIRED FOR SECURITY (against XSS/CSRF attacks)
:		if ( /^MediaWiki:[^&<>=%#]*\.css$/.test( extraCSS ) ) {
:			mw.loader.load( '/w/index.php?title=' + encodeURIComponent( extraCSS ) + '&action=raw&ctype=text/css', 'text/css' );
:		} else {
:			mw.notify( 'Only pages from the MediaWiki namespace are allowed.', { title: 'Invalid withCSS value' } );
:		}
:	}
:	if ( extraJS ) {
:		// WARNING: DO NOT REMOVE THIS "IF" - REQUIRED FOR SECURITY (against XSS/CSRF attacks)
:		if ( /^MediaWiki:[^&<>=%#]*\.js$/.test( extraJS ) ) {
:			mw.loader.load( '/w/index.php?title=' + encodeURIComponent( extraJS ) + '&action=raw&ctype=text/javascript' );
:		} else {
:			mw.notify( 'Only pages from the MediaWiki namespace are allowed.', { title: 'Invalid withJS value' } );
:		}
:	}
:	if ( extraModule ) {
:		if ( /^ext\.gadget\.[^,\|]+$/.test( extraModule ) ) {
:			mw.loader.load( extraModule );
:		} else {
:			mw.notify( 'Only gadget modules are allowed.', { title: 'Invalid withModule value' } );
:		}
:	}
:});
:

𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 23:28, 9 July 2022 (UTC)

We will not be adding withX any further than already is so, and certainly not to mobile.js. There is an officially-supported mechanism for ad-hoc loading of JavaScript now. We should be converting extent uses to use that system instead. See MediaWiki talk:Common.js#supportsUrlLoad.
As for the first part of the request changing the dependencies, have you actually verified the additions to the dependencies list will always work? --Izno (talk) 23:34, 9 July 2022 (UTC)
As I noted at Wikipedia_talk:Requests_for_page_protection#Change_dependencies_for_Mobile - this would also need wider discussion, not just a duplicate of the same already declined edit request. — xaosflux Talk 23:55, 9 July 2022 (UTC)
@Izno Yes, I tested it on tr:wiki, and as I said the forms all work on the mobile version. 𝗩𝗶𝗸𝗶𝗽𝗼𝗹𝗶𝗺𝗲𝗿 12:21, 10 July 2022 (UTC)

Changing content model of a user page

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Moved from WP:AN (permalink)

Please upgrade User:PerfektesChaos/js/refNames.css from CSS to Sanitized CSS. Reason: The gadget code shall be used simultaneously via <templatestyles> in doc page for consistent decoration. TIA PerfektesChaos (talk) 12:19, 15 July 2022 (UTC)

 Done @PerfektesChaos: all set. — xaosflux Talk 12:39, 15 July 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Inactive interface administrators 2022-08-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:18, 28 August 2022 (UTC)

 Donexaosflux Talk 00:27, 29 August 2022 (UTC)

Please restore my userspace js pages

I would like User:NotReallySoroka/common.js restored. Thank you. NotReallySoroka (talk) 13:26, 28 August 2022 (UTC)

@NotReallySoroka I've restored that page. I also blanked it to ensure that no unexpected scripts started running for you, you may restore prior versions via the page history. I suggest you stop asking to have that page deleted, if you don't want any scripts running just blank it as it is now. — xaosflux Talk 21:01, 28 August 2022 (UTC)
@Xaosflux: I meant to delete User:NotReallyMoniak/common.js which redirects to that page. It was a miscommunication that resulted in User:NotReallySoroka/common.js page being deleted instead. NotReallySoroka (talk) 15:23, 29 August 2022 (UTC)
All good, mostly was a tip so you didn't waste time. (I just blank my core /.js and /.css pages when I'm not using them as well). — xaosflux Talk 15:50, 29 August 2022 (UTC)
I agree with your tip, and I apologize for being confrontational in that regard. Thanks again, both for restoring the scripts, and for your tip here. NotReallySoroka (talk) 16:00, 29 August 2022 (UTC)

Removing protection on my userspace scripts

I protected some of my userspace scripts when I had the bit. On return after around 30 months of inactivity, I'd like to patch them up so they work again (changes to the vector skin in the meantime have broken them). I asked at WP:AN but admins there were unable to remove the protection and suggested interface admins may be able to. Could someone please remove protection on User:GoldenRing/wordcount.js and User:GoldenRing/generate-diffs.js? GoldenRing (talk) 15:27, 1 September 2022 (UTC)

 Doing...xaosflux Talk 16:57, 1 September 2022 (UTC)
 Done @GoldenRing: you should be good to go. — xaosflux Talk 16:58, 1 September 2022 (UTC)
@Xaosflux: Many thanks. GoldenRing (talk) 09:47, 2 September 2022 (UTC)

gadget notice

Wikipedia:EditNoticesOnMobile will be launching as a default gadget. It is limited to mobile users who are using Minerva skin. A waved approach is being done, wave one is only admins. Should something break, it can be instantly disabled via MediaWiki:Gadgets-definition. Please report any issues to Wikipedia talk:EditNoticesOnMobile. Best regards, — xaosflux Talk 23:04, 19 July 2022 (UTC)

  • Notice: this has been expanded to wave 2 today, extendedconfirmed users. — xaosflux Talk 17:59, 2 August 2022 (UTC)
    Notice, this has been expanded to wave 3 today, autoconfirmed. — xaosflux Talk 18:09, 22 August 2022 (UTC)
  • Notice, final release: on for logged out users now. — xaosflux Talk 19:00, 14 September 2022 (UTC)

Inactive interface administrators 2022-09-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:18, 28 September 2022 (UTC)

Goodness gracious, have I not made an edit in 6 months. Where has the time gone? —CYBERPOWER (Around) 23:19, 28 September 2022 (UTC)
 Donexaosflux Talk 01:33, 29 September 2022 (UTC)

I bricked my Wikipedia account

hello. can someone please revert the changes on user:allanwiki123/common.css because I was curiously testing it out and I wrote display:none and now I can’t revert it. (Redacted) 09:32, 29 October 2022 (UTC)

(Redacted), go to https://en.wikipedia.org/wiki/Special:Edit/user:AllanWiki123/common.css?safemode=1 — Qwerfjkltalk 10:18, 29 October 2022 (UTC)
 Done I cleared the script. — xaosflux Talk 14:09, 29 October 2022 (UTC)
Thanks alot! [REDACTED - Oshwah] 15:21, 29 October 2022 (UTC)

Proposal to include rangeblocks in MediaWiki:Gadget-markblocked.js

(copied from MediaWiki talk:Gadget-markblocked.js#Interface-protected edit request on 29 October 2022 following Izno's recommendation to gather consensus here)

I made a gist of a markblocked.js version that supports rangeblocks. You can see the additions here. I know of the performance hit of calling individual IPs, but I still believe it's a worth it change to make. DatGuyTalkContribs 13:37, 10 November 2022 (UTC)

@DatGuy: Do you have an on-wiki copy for us to test? Suffusion of Yellow (talk) 19:56, 10 November 2022 (UTC)
There's User:DatGuy/mark-rangeblocked.js which works in combination with Gadget-markblocked with practically the same code, but if you'd like you can copy paste the gist in its entirety onwiki and use that. DatGuyTalkContribs 19:57, 10 November 2022 (UTC)
Nevermind, just copied it to a local server. The first thing I noticed is that if there are N unique IPs on a page, N requests are sent out in parallel. That could cause a problem for some users on pages with hundreds of IPs (e.g. Special:RecentChanges with some settings). If the connection (or the server) is slow, it might max out the browser's limit and cause other scripts to start failing. This actually happened to me; see User talk:Tamzin/Archive/2#Rate limit. Can you limit the number of concurrent requests, to, say, 10? Suffusion of Yellow (talk) 20:42, 10 November 2022 (UTC)
Sure, see https://gist.github.com/DatGuy1/7dd486b19f04a1d74d870e59c015114a/revisions#diff-c4c03d9fbcd4128923be02c29723a9b7d49d86c184ba412c8cc6fa8b1ca03f17. Not sure if it's the best solution, but considering it's limited ES5 (I think that's a discussion for another day) it seems alright and most importantly it works. DatGuyTalkContribs 23:51, 10 November 2022 (UTC)
Thanks, this  Works for me. If anyone else thinks 10 connections is too many, the limit can always be lowered. Suffusion of Yellow (talk) 22:38, 11 November 2022 (UTC)
Thanks Izno for getting the discussion here, agree it needs consensus. This latest seems to work not too slow AFAICT, so I suppose would be okay. I'll try and take a deeper look at what you did later, but doing a simple copy-paste had the CSS not showing up? Might just be my testing though. ~ Amory (utc) 15:36, 12 November 2022 (UTC)
(Drive by code nit) Is there any specific reason the bklimit is set to 100 ? Wouldn't it make more sense to only get the latest block affecting the IP range (bklimit: 1) Sohom Datta (talk) 01:49, 22 November 2022 (UTC)
  • Oppose anything that makes requests in parallel. Nardog (talk) 02:11, 22 November 2022 (UTC)
    10 read-only requests at the same time is not an issue at all. The etiquette notes that sequential requests are safe but doesn't require that. Galobtter (pingó mió) 02:08, 24 November 2022 (UTC)
    Also, for me it seems that the author of that etiquette had only bots and other fully automated programs in mind. Bots doing many parallel requests can indeed be dangerous, as they often do not only many requests at one time, but they also repeat it at a high rate. This gadget, in contrast, does the requests once per page load initiated by a human; the request count per five minutes is probably the same (since it ends within five minutes anyway), so it doesn’t matter for the server – while it does matter for the user, who sees faster page load. —Tacsipacsi (talk) 15:45, 24 November 2022 (UTC)
    Worth noting, however, that over 8,000 local users use this gadget. No idea how many are active but we're clearly not talking about just one user at one time. It's probably most page loads of things like ANI, AIV, etc. Dunno that it adds up to something meaningful, but it's not nothing. ~ Amory (utc) 19:13, 27 November 2022 (UTC)
    Exactly. Would be fine as a user script but not as a default feature of a gadget. Nardog (talk) 19:22, 27 November 2022 (UTC)
    The point is that the number of requests made by the gadget does not change if they’re made in parallel, only their timing. It results in higher peaks, but given that it’s highly unlikely that all, or even a large fraction, of the users of the gadget load contributions pages at the very same time, these higher peaks are unnoticeable on the server side (no one cares about nine more requests when thousands of pages, each consisting of several – sometimes dozens of – requests, are loaded on enwiki alone every second).
    Actually, mw:ResourceLoader/Developing with ResourceLoader#Parallel execution explicitly encourages doing asynchronous requests in parallel, without exempting requests to the MediaWiki API. —Tacsipacsi (talk) 00:47, 28 November 2022 (UTC)
  • Oppose (Support this being behind some kind of feature flag/preference mechanism) - I honestly don't think the significant increase in the number of requests per page load for everyone makes sense here, especially given the comparatively niche nature of the functionality being added. -- Sohom Datta (talk) 18:22, 28 November 2022 (UTC)
Data backing up significant increase

Wrt to significant increase, here is a list of popular* discussion pages with and without the change:

Page name Before After
WP:VPP 2 13
WP:VPT 1 4
WP:VPR 5 9
WP:VPI 3 4
WP:VPW 1 2+
WP:VPM 1 4
WP:AN 3 6
WP:ANI 4 14

+ here indicates a possible bug in the change, since WP:VPW had no IP addresses when the script was run.

* These pages were mostly arbitrarily selected, feel free to run the tests for pages that you visit frequently and update the table :)

Request to remove Wikibreak script for Account

Hi! I have a wikibreak script active on my account (User:DSXG Plays) and asking if it's possible for you remove it? I accidentally set it way too long. Thanks! KyKatriza (talk) 23:24, 13 December 2022 (UTC)

KyKatriza -  Done. Welcome back! :-) ~Oshwah~(talk) (contribs) 04:19, 14 December 2022 (UTC)

 You are invited to join the discussion at Wikipedia:Administrators' noticeboard § Orphaned .js and .css pages in User space. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 14:41, 16 December 2022 (UTC)

Removal of wikibreak

Would an IA be so kind as to remove my self-imposed wikibreak from my main account's js page? Very much appreciated. Isabelle Belato 🏴‍☠️ 03:02, 22 December 2022 (UTC)

 Donexaosflux Talk 11:31, 22 December 2022 (UTC)

Inactive interface administrators 2022-12-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:18, 28 December 2022 (UTC)

 Done removed and notified. — xaosflux Talk 03:40, 29 December 2022 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.



Hello. I recently closed a requested move at Wikipedia talk:Text of Creative Commons Attribution-ShareAlike 3.0 Unported License and started an edit request (forgetting that WP:RMTR exists). However, as Xaosflux said on that talk page, other pages will need to be changed which are interface-protected. Instead of creating multiple other edit requests, I decided to bring it here to simplify the process so it can all be done at once and not create a mess. So, could you please:

There may be more pages affected, however I know absolutely nothing about the MediaWiki space so I am unaware of what these would be. Thank you, echidnaLives - talk - edits 14:33, 31 December 2022 (UTC)

information Administrator note @EchidnaLives none of this requires an int-admin, any admin can do this. (Int admnins are mostly only needed for javascript/cascading style pages). — xaosflux Talk 14:46, 31 December 2022 (UTC)
@Xaosflux Oh, sorry. I always assumed MediaWiki space was restricted to interface admins, but clearly I’ve missed something! I would move this to WP:AN, however I’m now on mobile (which is much harder to edit with) and no longer have access to my computer, so I’m going to have to leave this here for now. Once again, sorry about this mistake, clearly I need to start reading stuff more closely! echidnaLives - talk - edits 15:18, 31 December 2022 (UTC)
@EchidnaLives it is already in the FPROT queue, so an admin will get to it (might even be me!). I found those dependencies, but didn't finish checking for others so didn't do it yet. — xaosflux Talk 15:43, 31 December 2022 (UTC)
Got it, just didn’t want to leave the requester without anything for too long. I’ll close this discussion as nothing needs to be done here. Thanks, echidnaLives - talk - edits 15:56, 31 December 2022 (UTC).
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Requesting an MFD closure

Wikipedia:Miscellany for deletion/User:BrandonXLF/ReferenceExpander has been open for two weeks now. It's drawn quite a bit of participation, but nobody has edited the MFD page in the past three days. My (very involved) reading of the discussion is that there's consensus to disable User:BrandonXLF/ReferenceExpander.js until improvements are made that address the concerns of the community. Can an IA please close the discussion and, if necessary, disable the script? Apologies if this is the wrong venue for this request. — SamX [talk · contribs] 02:51, 11 June 2023 (UTC)

Script Modification

Could an int admin copy the script at User:Synoman Barris/Watchlist.js to User:Ais523/watchlistnotifier.js, made a quick change to the mediawiki id mw-content-subtitle to return functionality, the author of the script is inactive Megan B.... It’s all coming to me till the end of time 17:44, 16 June 2023 (UTC)

Is mw-content-subtitle available in other skins than whichever skin you are using? Izno (talk) 18:01, 16 June 2023 (UTC)
Tested it with the skins on my preferences and it seems to be working as expected in both vectors, Timeless and Monobook Megan B.... It’s all coming to me till the end of time 19:45, 16 June 2023 (UTC)
 Done. Izno (talk) 21:59, 16 June 2023 (UTC)
Consider using mw.util.addSubtitle() to make this skin-agnostic and less prone to breakage in the future. –Novem Linguae (talk) 19:12, 16 June 2023 (UTC)
I will look into this. Thanks for the suggestion Megan B.... It’s all coming to me till the end of time 22:14, 16 June 2023 (UTC)
For the future, please use {{edit protected}} on a relevant talk page to request an edit. Thanks! Izno (talk) 22:21, 16 June 2023 (UTC)

Could an available interface admin take a look at RM/TR? There’s a request that requires your attention. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:28, 26 June 2023 (UTC)

This appears to have been  Done by Izno. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:00, 26 June 2023 (UTC)

Removal of script calls to outdated software

We have been having some issues with AFC helper script access based on people's use of Enterprisey's old script import (see e.g. this thread). I would like to request that these 15 pages are edited to remove the last extant uses of importScript('User:Enterprisey/afch-dev.js'); so that we stop having this issue. Thanks. (please do not ping on reply) Primefac (talk) 08:54, 27 June 2023 (UTC)

@Primefac checked though those, please double check your request here. Most of those are already commented out. I commented out a couple where the user was inactive though. If the user is active, they should be contacted directly with information on how to change to the gadget. — xaosflux Talk 14:59, 27 June 2023 (UTC)
I've just gone ahead and removed the others with a pointer to the actual gadget. Izno (talk) 18:15, 27 June 2023 (UTC)

Inactive interface administrators 2023-06-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:18, 28 June 2023 (UTC)

Edit requests needing attention

Category:Wikipedia interface-protected edit requests has a backlog dating back to June. Could someone please look at them? * Pppery * it has begun... 22:19, 4 September 2023 (UTC)

I don't agree with the popups change personally and wasn't really satisfied by Nux's responses. So if someone wants to jump on that.
As for the Mobile.css change, someone else should look at that. I'm thoroughly annoyed by that interaction there. Izno (talk) 22:29, 8 September 2023 (UTC)
Hello @Izno, I appreciate your input, and I'm open to discussing this further (if you are still willing). However, I'm not entirely certain about what might have been amiss with my previous responses. I've been utilizing the method I described for over a year now, and I'm not aware of any alternative approaches. Could you please tell me what potential issues you see that may arise when implementing these changes? From my perspective, the alterations appear to be stable. I've had access to Logstash for a quite some time, and I haven't come across any entries related to these Popups changes (the changes are live on pl.wikipedia.org). I would appreciate some information on how can we resolve this so that the feature will be available on en.wiki. I would be willing to monitor Logstash for en.wiki for a period following the implementation of these changes if it would help alleviate any concerns. Nux (talk) 22:51, 8 September 2023 (UTC)
I have no particular issue with the technical implementation.
I don't see a need to provide support for your customization. Izno (talk) 23:20, 8 September 2023 (UTC)
Personally if I were an Iadmin (and I have seriously considered running for interface adminship precisely because of the size of the edit request backlog), I would probably grant both requests. * Pppery * it has begun... 01:42, 10 September 2023 (UTC)
Regarding the proposed change to the Navigation popups gadget, I think it should be up to those supporting the gadget to decide if they want to publish the gadget's utility functions. It's just asking for trouble to publish an API that no one's signed up to support. I appreciate that with the original developer long inactive, that may be a revolving cast of volunteer developers, though. isaacl (talk) 01:58, 10 September 2023 (UTC)
@Isaacl I'm a dev supporting Popups on Polish Wikipedia. And I can support fixes to the feature if they are needed. Someone just need to deploy those fixes ;). Nux (talk) 11:35, 10 September 2023 (UTC)

Adding the WP:Contents page to the mobile Wikipedia sidebar

Hi, I was hoping that someone could add the WP:Contents page to the sidebar on mobile Wikipedia. It seems like common sense since we already have it in the desktop Wikipedia. Interstellarity (talk) 13:06, 26 September 2023 (UTC)

Retired user populating deleted categories

Please could the 5 instances of "members" be changed to "participants" in User:Kyoko/userpage.css following Wikipedia:Categories_for_discussion/Log/2023_October_1#Category:WikiProject_X_members? – Fayenatic London 08:12, 22 October 2023 (UTC)

 Done. Diff. A css file is a weird spot for categories, but to each their own I guess. –Novem Linguae (talk) 15:07, 22 October 2023 (UTC)
These pages are being used to protect their user pages from modification via transclusion, to allow only themselves and what used to be admins to change it. I don't know exactly when or how the practice started.
When the user is retired or otherwise long-term absent, it is usually better to substitute/copy the contents to the user page and to blank the CSS page. This allows routine project-wide maintenance such as this request to be done. Izno (talk) 18:46, 22 October 2023 (UTC)

A mass renaming of people in hundreds of WikiProjects from "members" to "participants" has taken place. A few of the old categories are still populated because users have embedded the old category name in .css pages that can't be easily edited.

Can somebody with the right access go through the following (some categories have been deleted by the bot but still have entries) and fix the entries? Thanks in advance.

Timrollpickering (talk) 10:13, 22 October 2023 (UTC)

@Timrollpickering, I will take a look at this, but could I ask you to move this request to WP:IANB? There is already a section there on the matter of these pages having these categories, and that is the right set of users anyway to action this request. Izno (talk) 19:03, 22 October 2023 (UTC)
 Done Izno (talk) 20:40, 22 October 2023 (UTC)

OneClickArchiver old version is creating a mess

First mentioned at Wikipedia:Village pump (technical)#WP:1CA "undefined". It looks like the old version of OneClickArchiver by arbcom blocked user Technical13 (User:Technical 13/Scripts/OneClickArchiver) has a bug that is creating a mess. It keeps creating archive pages named "undefined". List of pages. It looks like several editors still use the old version of the user script instead of the better, bug fixed version User:Evad37/OneClickArchiver.

I think we should do something about this to stop the disruption. I think notifying a bunch of users and asking them to change user scripts is a bit labor intensive since it's so many users, and won't keep the problem from cropping up in the future. I think a more permanent solution would be blanking User:Technical 13/Scripts/OneClickArchiver.js, or BLARing User:Technical 13/Scripts/OneClickArchiver.js with something like importScript('User:Evad37/OneClickArchiver.js'); Thoughts? cc Awesome Aasim. –Novem Linguae (talk) 15:03, 24 October 2023 (UTC)

FWIW, User:Jo-Jo Eumerus/JS pages using old OneClickArchiver Jo-Jo Eumerus (talk) 15:30, 24 October 2023 (UTC)
@Novem Linguae How about start with mw.notify($("Warning: It seems you have a deprecated script installed. Please replace \"User:Technical 13/Scripts/OneClickArchiver.js\" with \"User:Evad37/OneClickArchiver.js\"")). Or better solution: Add an abuse filter to initially stop the creation of "undefined" archives, then tag the edit with "Possible malformed archive". There has been several years to migrate to the new script. We shouldn't be using a script that has been unmaintained for several years. Awesome Aasim 15:46, 24 October 2023 (UTC)
Here is some script code for abuse filter:
action == "edit" & page_namespace != 0 & page_title rlike ".*\\/.*undefined.*"
Might need further refinement.
Action to take: disallow, then tag with "possible malformed archive". Awesome Aasim 15:51, 24 October 2023 (UTC)
If we get everyone off the old script, we won't need an edit filter. Edit filters are resource intensive and they probably shouldn't be the first tool we pull out of our toolbag.
I don't personally like the mw.notify approach since that would bug a lot of people, when we can just do it automatically for them. But I would like to hear an experienced interface admin chime in about that. Maybe mw.notify is the necessary approach so that folks get to pick which user scripts they install and trust? –Novem Linguae (talk) 15:54, 24 October 2023 (UTC)
I would prefer to simply blank the script, I think, with a note explaining what's going on on the script's talk page (or in a comment on the script page itself). mw.notify is more of a nuisance than a viable information vector (people will just dismiss it and get annoyed, without reading it). And I also don't love the idea of redirecting to another userscript that people haven't chosen themselves. Writ Keeper  16:09, 24 October 2023 (UTC)
I've blanked it with pointers both to here and its replacement. Izno (talk) 16:46, 24 October 2023 (UTC)
Awesome. I added some comments and blanked the beta version as well.
Resolved
Novem Linguae (talk) 16:54, 24 October 2023 (UTC)
Next step is to fix those archives! Well, that was fast, as it was listed on Wikipedia:AutoWikiBrowser/Tasks#Cleanup_of_30_talk_page_archives_with_"undefined"_in_title. Now hope the undefined monster does not come back! Awesome Aasim 20:31, 24 October 2023 (UTC)

Inactive interface administrators 2023-10-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:18, 28 October 2023 (UTC)

FYI, removed :) — TheresNoTime (talk • they/them) 13:25, 31 October 2023 (UTC)
 Donexaosflux Talk 15:24, 31 October 2023 (UTC)

I've proposed a technical change to the WP:Navigation popups gadget at MediaWiki talk:Gadget-popups.js#Live_preview_refactor. The salient features of the change include:

  • Removed the custom wikitext parsing engine at wiki2html() and replaced it a call to the parsing API
  • Refactored the generateLink() to not use raw HTML manipulation

Thoughts, comments and beta-tests are welcomed. Sohom (talk) 01:02, 6 December 2023 (UTC)

MakeMobileCollapsible gadget

Wikipedia:Village pump (proposals)#RfC: Enabling collapsible templates on the mobile site has been closed by Frostly (thanks!) saying:

There is consensus to enable the gadget. Overall, there is agreement to have the feature be opt-out, albeit with slightly weaker support than implementation generally. Participants often expressed the benefits of feature parity on desktop and mobile. Some editors commented that in the long run, they would prefer a solution in MediaWiki core or skins, although they endorsed the gadget as an interim measure.

Instructions to create the gadget can be found on Wikipedia:MakeMobileCollapsible. For a deployment in waves, limit the deployment to admins initially. Add extendedconfirmed some days later, then autoconfirmed and finally everyone.Alexis Jazz (talk or ping me) 10:08, 2 November 2023 (UTC)

@Alexis Jazz I'll look at this tomorrow. Been a bit scatter brained about it a couple times now. Izno (talk) 22:02, 19 November 2023 (UTC)
It works! Kind of ugly with templates with centered content that correctly works around a button width of auto (which is ~4em wide), but that's not a big deal. I've deployed it to users to start partially to see if someone bumps into a kink and partially because it's the day before Thanksgiving and I will be AFK until Sunday. Izno (talk) 22:44, 22 November 2023 (UTC)
@Alexis Jazz @Izno Any chance of getting some CSS to enlarge the links ? It's a bit annoying and misclick friendly for me right now. (alternatively please provide a opt out, It appears that it was promised in the RFC but not implemented?) Sohom (talk) 15:00, 23 November 2023 (UTC)
Sohom Datta, you can opt out by disabling "Enables collapsing on mobile" in your mobile preferences.
You could add .mw-collapsible-toggle{font-size:larger;min-width:10em !important} (customize as desired) to Special:MyPage/minerva.css if you need larger buttons. Behind the scenes I've recently worked on a completely reworked way to handle collapsed elements, but I'm not sure where that might lead. You can try it on betacommons but it's very beta.Alexis Jazz (talk or ping me) 15:30, 23 November 2023 (UTC)
@Alexis Jazz I had no idea a different gadgets menu existed for mobile :) Thanks for this, I will test it out and add it to my minvera.css.
Wrt to the betacommons, I see what you mean, definitely going to look forward to having that as a default on mobile someday :) Sohom (talk) 15:36, 23 November 2023 (UTC)
Besides the "display", it works the same as Special:Preferences does, only showing preference if, in the skin (or mobile|desktop, or you have the appropriate user rights) that you're in, it would be an applicable preference. Izno (talk) 17:48, 23 November 2023 (UTC)
Is it a good idea to use Array.prototype.includes() in a default-on gadget? That's not part of ES5. Suffusion of Yellow (talk) 18:54, 23 November 2023 (UTC)
Indeed, that's in ES7. I realize setting requiresES6 doesn't fix that problem, but caniuse is pretty close to the set of browsers that implement ES6. I'll check to see if we have any significant mobile viewership at issue (I doubt that we do). Izno (talk) 19:00, 23 November 2023 (UTC)
Er, in fact, it was implemented in browsers before ES6 was finalized in most cases. Wonder why it didn't make ES6. Anyway, we get no views from browsers to the mobile website (ignoring the 10% unknown) that fall in the difference. So I think setting requiresES6 is reasonable and that we should encourage users with JavaScript devices old enough not to recognize the software to upgrade. (I have no issue working around it also.) Izno (talk) 19:22, 23 November 2023 (UTC)
I mean it'd be pretty easy to replace with indexof() != -1 so I don't see the harm in doing that. Galobtter (talk) 19:30, 23 November 2023 (UTC)
Actually I don't see the point of the ['enwiki'].includes(mw.config.get('wgDBname')) check for our enwiki gadget? should be always true. Galobtter (talk) 19:33, 23 November 2023 (UTC)
... yes, that works too. :) I've removed it. Izno (talk) 21:30, 23 November 2023 (UTC)
Galobtter, GMTA, I changed it to use indexOf right after reading Suffusion of Yellow's comment (and before reading yours) in my userspace. I implemented some of these newer functions in ES5 over a year ago, I should remember to check for these functions in my scripts. For a number of scripts that allows them to run on ES5 browsers, but the performance may be worse. There's a reason Array.from is capped at 2000 values.
While there are few users stuck with such browsers, when this happens in a default gadget it does result in some logspam.
Indeed, it could be omitted for enwiki. While writing my scripts I keep the possible needs of other wikis in mind. If there are other wikis that have copied the autocollapse code from enwiki, I could add their DB names to the array, so everyone could run the exact same script without local modifications.Alexis Jazz (talk or ping me) 05:05, 24 November 2023 (UTC)
Array includes() is ES6. There is no issue with using it as MediaWiki does not load JavaScript on any non-ES6 browser since earlier this year (phab:T178356). (The reason requiresES6 flag still exists is to bypass the ES5 syntax validator only.) – SD0001 (talk) 11:48, 28 November 2023 (UTC)
@Alexis Jazz@Izno There appears to be a [hide]/[show] link that has shown up on the multiple issues template (for example: Appellate_court), that superficially does not appear to do anything. Is this expected ? Sohom (talk) 23:07, 7 December 2023 (UTC)
Special case. Anyway, it does expand for me, but doesn't expand the entirety of the content it's supposed to (well, it acts like this as desktop resolution on the mobile site; mobile resolution on the mobile site does indeed cause nothing to happen). Not sure how best to deal with the problem, but it should probably be discussed at the template talk page. Izno (talk) 23:25, 7 December 2023 (UTC)

Low use template used by gadget

Need opinions on whether Template:ImageNote can be unprotected - comments welcome on my talk page where the question was raised. Jo-Jo Eumerus (talk) 08:31, 14 December 2023 (UTC)

Following up at Template talk:ImageNote. — xaosflux Talk 00:43, 29 December 2023 (UTC)

common.js revert needed

Hello, this is the Master of Hedgehogs. I am requesting that my latest edit to my common.js, which installs the wikibreak enforcer, be removed.

2601:18A:8082:5390:1D4B:D752:5AFA:AD32 (talk) 19:23, 20 January 2024 (UTC)

It says User:Master of Hedgehogs is not registered. Can you confirm the username please? –Novem Linguae (talk) 07:29, 21 January 2024 (UTC)
Ah found it. It is User:The Master of Hedgehogs.  Done. I wouldn't normally edit someone's JS file without them being logged in, but this seems zero risk to me. –Novem Linguae (talk) 07:33, 21 January 2024 (UTC)
Kind of defeats the object of a wikibreak enforcer :) — Martin (MSGJ · talk) 08:58, 21 January 2024 (UTC)

Undelete my .js subpages

Could an interface administrator please undelete User:GeoffreyT2000/common.js and User:GeoffreyT2000/twinkleoptions.js? I would like them back. GeoffreyT2000 (talk) 00:00, 27 January 2024 (UTC)

 DoneNovem Linguae (talk) 00:31, 27 January 2024 (UTC)

Inactive interface administrators 2024-01-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:18, 28 January 2024 (UTC)

 Done removed. — xaosflux Talk 16:36, 29 January 2024 (UTC)

Inactive interface administrators 2023-12-28

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


The following interface administrator(s) are inactive:

— JJMC89 bot 23:18, 28 December 2023 (UTC)

Sent a query to user... — xaosflux Talk 00:36, 29 December 2023 (UTC)
 Not done user has become active again. — xaosflux Talk 15:30, 29 December 2023 (UTC)
This trend (which has now happened twice) of asking interface administrators before removing their rights seems wrong to me. The community has deliberately set an activity policy with no notification rules - they should not be added on by fiat. This isn't just theoretical grumbling - there's a distinction between the wishful thought that someone would like to retain their rights, and actually caring enough to request them back at BN, and we've ended up on the wrong side of that divide. * Pppery * it has begun... 23:46, 29 December 2023 (UTC)
@Pppery I know I normally just pull these (see most of the requests at Wikipedia:Interface_administrators'_noticeboard/Archive_3) - but know there are some that are very likely going to go through the revolving door at BN so tried to avoid needless button pushing. Certainly wouldn't of objected if another crat had got around to removing it first though. Keep in mind, that just like editors, crats are never required to act on anything. — xaosflux Talk 23:54, 29 December 2023 (UTC)
Maybe we should increase the bot's threshold to 1 year. –Novem Linguae (talk) 00:17, 29 January 2024 (UTC)
No, 6 months is fine as is. People who aren't actively using the iadmin tools should not have them. If anything it's too long IMO. * Pppery * it has begun... 01:23, 29 January 2024 (UTC)
This does seem like gaming the system, albeit explicitly encouraged by Xaosflus! In general, I think pulling rights without any notification is rude. It would be better to get them back into active service, than losing them. But I would like to see a consistent approach - either everyone gets a notification or no one does. And I would like to see a real return to activity rather than gaming the rules — Martin (MSGJ · talk) 09:42, 29 January 2024 (UTC)
(didn't know this thread was still going) Then hopefully this allays your concerns. The thing is that there aren't actually that many intadmin actions to go around; it doesn't take much at all to miss the few that are come around and are actually actionable. If the conclusion about *that* is that we should have fewer intadmins, then like I said to Xaosflux on my talk page, I don't actually mind the bit being pulled. But it certainly does make me less inclined to actually help out with the tasks when they come up, for paperwork reasons if nothing else, so, y'know, whatever people think is in the best interest of the encyclopedia. Writ Keeper  14:59, 29 January 2024 (UTC)
this is a better example I guess for you, since any admin can delete a js page (but I agree with your point). Galobtter (talk) 15:22, 29 January 2024 (UTC)
@Galobtter: That's what I thought at first when I saw the intadmin edit request, but apparently not in the Mediawiki namespace. :) See also User_talk:Extraordinary_Writ#Mediawiki:Sandbox.js and my recent update of the IA table to reflect this. Writ Keeper  16:44, 29 January 2024 (UTC)
Interesting, good to know! Galobtter (talk) 18:14, 29 January 2024 (UTC)
I think one issue for me is that sometimes there's e.g. 8 months where nothing needs to be fixed with the gadgets I maintain, but when stuff has to be done it's better for me to do it myself than file a request (especially if many changes have to be done). The one time I got my intadmin bit pulled I asked for it back after 3 months for that reason. I'd personally favor increasing the inactivity to 1 year simply to reduce bureaucracy and since we only have 9 human intadmins right now, so there's no pressing reason to reduce the number (and probably we could do with a few more). Galobtter (talk) 15:19, 29 January 2024 (UTC)
I think there are multiple intadmins whose primary activity is to be the maintainer of a major gadget. Updates to that gadget can go more than 6 months without a deploy sometimes, so it is easy to lapse intadmin. {{IAER}}s aren't always great for updating major gadgets either. Sometimes the gadgets have custom deploy scripts that only one or two people know how to use. Anyway, I'd support boosting the inactivity threshold for intadmin to 1 year. –Novem Linguae (talk) 09:06, 30 January 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Interface edit blocked by edit filter (needs eval/implementation)

Hello all, if an interface admin can look at this EF entry and implement if appropriate, would appreciate it. It came up at the false positives page, but we can't implement any edits to interface pages over there. EggRoll97 (talk) 00:44, 20 February 2024 (UTC)

 Done Galobtter (talk) 00:59, 20 February 2024 (UTC)

Continued deployment of #MakeMobileCollapsible gadget (archived)

MediaWiki:Gadget-MakeMobileCollapsible.js has been deployed for registered users (using the minoredit right as a proxy for registered) since November (diff). That seems a long enough trial before deploying it for unregistered users (by changing minerva |rights=minoredit | to minerva | at MediaWiki:Gadgets-definition). SilverLocust 💬 06:13, 1 March 2024 (UTC)