Wikipedia:Interface administrators' noticeboard

Welcome to the interface administrators' noticeboard
This is the interface administrator noticeboard, for discussion of interface administrators and coordination of edits to the interface. Currently only interface administrators can undelete JS/CSS pages, if you have an uncontroversial undelete or deleted version retrieval request, please list it below. Any administrator can delete JS/CSS/JSON pages, for speedy deletions just use a CSD template on the page or its talk page. Individual requests for edits to interface or user JavaScript/CSS pages should continue to be made on their respective talk pages.
Click here to start a new discussion

5 interface-protected edit requests v·h
Page Tagged since Protection level Last protection log entry MediaWiki:Gadget-WatchlistBase.css (request) 2024-03-02 23:26 Site CSS page (log) MediaWiki:Gadget-watchlist-notice-core.js (request) 2024-03-02 23:26 Site JS page (log) MediaWiki:Vector-2022.css (request) 2024-05-29 01:47 Site CSS page (log) MediaWiki:Common.css (request) 2024-05-31 10:27 Site CSS page (log) Protected by Sam Korn on 2005-07-21: "As with all MW: pages, can't have vandals getting to the styles!" MediaWiki:Gadget-ImageStackPopup.js (request) 2024-06-01 11:32 Site JS page (log)
Updated as needed. Last updated: 11:34, 1 June 2024 (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. DatGuy^Talk_Contribs 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. DatGuy^Talk_Contribs 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. DatGuy^Talk_Contribs 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 (u • t • c) 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 (u • t • c) 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)

Discussion at Wikipedia:Administrators' noticeboard § Orphaned .js and .css pages in User space

 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)

 Done — xaosflux ^Talk 11:31, 22 December 2022 (UTC)

Inactive interface administrators 2022-12-28

The following interface administrator(s) are inactive:

• Nihiltres (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)

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

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