Wikipedia: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.
|
|||
This page has archives. Sections older than 30 days may be automatically archived by Lowercase sigmabot III when more than 3 sections are present. |
1 interface-protected edit request | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Updated as needed. Last updated: 18:45, 25 December 2024 (UTC) |
Possible blackout of en.wikipedia
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.
Interface administrators; there is a now open RfC at this location requesting community input on a blackout protest over the ANI case in India and the WMF's response to it. Should the RfC conclude in favor, Interface Administrators will need to implement the result. This RfC is likely following an WP:IAR route and will possibly conclude within 24-48 hours if it snowball closes. --Hammersoft (talk) 17:54, 14 November 2024 (UTC)
- Blackouts require the database to be locked, which is not something interface admins can bring about. Implementation via interface changes alone would be a terrible idea as it opens up the site to vandalism through mobile apps, people editing with CSS adjustments or with javascript disabled, and so on, while patrollers are unable to access the site or use any JS-powered anti-vandalism tools – SD0001 (talk) 18:55, 14 November 2024 (UTC)
- ^ This. I've been considering technical implementations we could potentially do on our end since seeing that RfC, but without a database lock there's fundamentally nothing we can do to actually prevent a determined bad actor from editing Wikipedia. Writ Keeper ⚇♔ 18:59, 14 November 2024 (UTC)
- An alternate option would be a "click-through" blackout where pages would still be accessible behind the banner. Would that be technically possible? Chaotic Enby (talk · contribs) 19:13, 14 November 2024 (UTC)
- Is that what people are actually voting to support? Is the expectation that you have to click through on every page load, or just the first visit to Wikipedia in that session? we should not be solutioning this *after* people are voting on it. Writ Keeper ⚇♔ 19:30, 14 November 2024 (UTC)
- Iff folx do go down this route, could we please ensure theres an ID/class assigned to the banner so it can be easily hidden via some user CSS and/or implement a cookie so you only have to hide it once? When the mass of vandals find out how they can easily bypass this, it'll be really annoying for the patrollers to deal with the fallout if they have to close the banner every time. TNTPublic (talk) 19:35, 14 November 2024 (UTC)
- Is that what people are actually voting to support? Is the expectation that you have to click through on every page load, or just the first visit to Wikipedia in that session? we should not be solutioning this *after* people are voting on it. Writ Keeper ⚇♔ 19:30, 14 November 2024 (UTC)
- An alternate option would be a "click-through" blackout where pages would still be accessible behind the banner. Would that be technically possible? Chaotic Enby (talk · contribs) 19:13, 14 November 2024 (UTC)
- I don't know if it's possible to determine user permissions via JS but if it is, could it just use that to determine if it loads the blackout js vs a banner? LakesideMinersCome Talk To Me! 19:15, 14 November 2024 (UTC)
- Any JS-based solution would be easily circumvented by simply disabling browser JS, or by editing via the API. Writ Keeper ⚇♔ 19:26, 14 November 2024 (UTC)
- While still allowing for people with the perms to edit without added effort LakesideMinersCome Talk To Me! 19:54, 14 November 2024 (UTC)
- Any JS-based solution would be easily circumvented by simply disabling browser JS, or by editing via the API. Writ Keeper ⚇♔ 19:26, 14 November 2024 (UTC)
- This is probably hopelessly naïve, and is definitely a plan of last resort, but could we run a bot that reverts all edits within the 48/72 hour period? I see no reason why a bot would need JS enabled. Sincerely, Dilettante 20:04, 14 November 2024 (UTC)
- Not naive at all. * Pppery * it has begun... 20:07, 14 November 2024 (UTC)
- Or an edit filter that blocks all edits (I believe such has accidentally been created before). Sincerely, Dilettante 21:03, 14 November 2024 (UTC)
- The edit filter extension has some failsafes to automatically disable filters with a high rate of matches. They might (or might not) interfere here. * Pppery * it has begun... 21:11, 14 November 2024 (UTC)
- ^ This. I've been considering technical implementations we could potentially do on our end since seeing that RfC, but without a database lock there's fundamentally nothing we can do to actually prevent a determined bad actor from editing Wikipedia. Writ Keeper ⚇♔ 18:59, 14 November 2024 (UTC)
- I suppose one solution, should the motion pass, would be to formally request the WMF to lock the database? Requires a hell of a lot of gumption! ~~ AirshipJungleman29 (talk) 19:30, 14 November 2024 (UTC)
- There are several volunteers who have the technical ability to lock the database. It's probably best not to rely on them, though, and assume we can't do anything not accomplishable on-wiki. For comparison the SOPA/PIPA blackout involved both a config change to disable write access server-side and a centralnotice, but all the code (still available on Meta as m:MediaWiki:Centralnotice-template-blackout, although it's bitrotted enough to no longer work as written) actually did was add some CSS and JS, both of which Iadmins were capable of doing locally. * Pppery * it has begun... 19:50, 14 November 2024 (UTC)
- Just a note, from something that went very wrong on another project: we should absolutely not consider anything that "logs out" the user. — xaosflux Talk 19:36, 14 November 2024 (UTC)
- I, am morbidly curious. LakesideMinersCome Talk To Me! 19:55, 14 November 2024 (UTC)
- Short answer is that we don't have accounts here - if you log out here you log out across the entire WMF production system. — xaosflux Talk 19:58, 14 November 2024 (UTC)
- I think technically the global session is stored in a different cookie (centralauth_Session versus enwikiSession). So it is in theory possible to log out from here without logging out globally. But I'm not volunteering to write such a script (nor do I see it as necessary at all) * Pppery * it has begun... 20:01, 14 November 2024 (UTC)
- That's why it was a short answer :) But in general, it can cause big problems in a sloppy way. — xaosflux Talk 20:25, 14 November 2024 (UTC)
- I think technically the global session is stored in a different cookie (centralauth_Session versus enwikiSession). So it is in theory possible to log out from here without logging out globally. But I'm not volunteering to write such a script (nor do I see it as necessary at all) * Pppery * it has begun... 20:01, 14 November 2024 (UTC)
- (edit conflict) m:Steward requests/Miscellaneous/2023-12#Arabic Wikipedia protest forced logout script. * Pppery * it has begun... 19:58, 14 November 2024 (UTC)
- Short answer is that we don't have accounts here - if you log out here you log out across the entire WMF production system. — xaosflux Talk 19:58, 14 November 2024 (UTC)
- I, am morbidly curious. LakesideMinersCome Talk To Me! 19:55, 14 November 2024 (UTC)
- FYI, the blackout RFC was closed recently without achieving consensus. –Novem Linguae (talk) 21:25, 16 November 2024 (UTC)
Suggested edits to DisamAssist
Its creator User:Qwertyytrewqqwerty hasn't been around for over 6 years, but the tool is used very widely. Last year in July, I suggested a minor change to the code as per Wikipedia:Categorizing redirects#How to categorize a redirect, which remains unimplemented. Can an INTADMIN please take a look? Thanks! —CX Zoom[he/him] (let's talk • {C•X}) 22:33, 1 December 2024 (UTC)
- I'm not inspired to implement that change - Wikipedia:Categorizing redirects#How to categorize a redirect is worded in such a way as to imply {{Redirect category shell}} is optional, and I've always thought it was silly for a single rcat. The current momentum is against me right now, but I don't think there a strong enough agreement it should be done to justify the unusual action of editing another user's script. * Pppery * it has begun... 22:41, 1 December 2024 (UTC)
- CX Zoom, your best bet is probably forking the code. — Qwerfjkltalk 17:29, 2 December 2024 (UTC)
Request to delete common code files
Hey Interface admins,
Recently, my alt account was renamed to BunnypranavClone from AWBunny. Can the old common.js and common.css files be deleted at Special:PrefixIndex/User:AWBunny/. Thanks! ~/Bunnypranav:<ping> 10:41, 7 December 2024 (UTC)
- @Bunnypranav: You should tag the pages with
{{db-user}}
. --Redrose64 🌹 (talk) 12:48, 7 December 2024 (UTC) - @Redrose64: I can't, code files can only be edited by that user or IA, and as the user is renamed I can't login into AWBunny (old name). So I cannot edit the .js file to tag it. ~/Bunnypranav:<ping> 13:05, 7 December 2024 (UTC)
- In the future, I think you can use Twinkle and it'll detect that the main page isn't editable, and will instead place the speedy tag on the talk page. –Novem Linguae (talk) 02:03, 8 December 2024 (UTC)
- Done – SD0001 (talk) 13:19, 7 December 2024 (UTC)
- Thanks. Will follow the twinkle advice Novem. ~/Bunnypranav:<ping> 05:36, 8 December 2024 (UTC)
- @Bunnypranav: A question. When the AWBunny account was renamed BunnypranavClone by FlightTime (talk · contribs), why did they leave these subpages behind? They should have been moved along with the primary user page. --Redrose64 🌹 (talk) 08:54, 8 December 2024 (UTC)
- They were moved, with a redirect left behind. I want a redirect from the main userpage, but do not need the redirect from the common.js and .css files of old account, hence requested deletion ~/Bunnypranav:<ping> 08:56, 8 December 2024 (UTC)
- @Bunnypranav: A question. When the AWBunny account was renamed BunnypranavClone by FlightTime (talk · contribs), why did they leave these subpages behind? They should have been moved along with the primary user page. --Redrose64 🌹 (talk) 08:54, 8 December 2024 (UTC)
- Thanks. Will follow the twinkle advice Novem. ~/Bunnypranav:<ping> 05:36, 8 December 2024 (UTC)