Wikipedia:Interface administrators' noticeboard/Archive 2

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

Question about repairing an userscript

There is a (now archived) bug report about User:Lingzhi2/reviewsourcecheck.js breaking the edit screen on Invisible Man. Given that Lingzhi2 hasn't been active in the past few weeks (I did ping them again, though), I wonder if it would be appropriate for an IAN to go in and fix them. Jo-Jo Eumerus (talk) 11:38, 17 April 2020 (UTC)

@Jo-Jo Eumerus: to be clear, this isn't breaking any editing in general - it is breaking something for you because you have chosen to use Lingzhi2's script - correct? You should be able to edit the article in safemode, or by not importing the faulty script. — xaosflux Talk 14:22, 17 April 2020 (UTC)
Yes, but I don't think that that means that whatever the issue should be left unresolved. Jo-Jo Eumerus (talk) 14:24, 17 April 2020 (UTC)
Looks like there are about 40 people using this, so it is quite low impact. @Jo-Jo Eumerus: do you have a specific fix in mind? If not, you could post at Wikipedia:User scripts/Requests to see if someone wants to write a fix. If it is something very minor, I think we would consider forcing the update on to Lingzhi2's personal page - if it is larger you could always fork the script. — xaosflux Talk 14:28, 17 April 2020 (UTC)
A bug-fix type fix can be proposed at User talk:Lingzhi2/reviewsourcecheck.js as an edit request, which will enqueue it for review as well. — xaosflux Talk 14:29, 17 April 2020 (UTC)
That's part of the issue - I don't really know what the correct fix is, other than TheDJ's suggestion that It seems it modifies links in a page, without considering that not all links are part of content. Jo-Jo Eumerus (talk) 15:03, 17 April 2020 (UTC)
@Jo-Jo Eumerus: the immediate fix for you is to edit User:Jo-Jo Eumerus/common.js and stop using that broken script until it is fixed. If this was a project wide gadget, we'd probably get more attention put on it, but with it being a private script used by a very little number of editors it is very low on the response priority. — xaosflux Talk 16:16, 17 April 2020 (UTC)
@Jo-Jo Eumerus, Xaosflux, and Lingzhi2: I've fixed the bug at User:Wugapodes/reviewsourcecheck.js with this change. Would a interface admin be willing to make this change if Lingzhi doesn't return soon? — Wug·a·po·des​ 20:25, 17 April 2020 (UTC)
 Done and noted at that script talk. — xaosflux Talk 21:32, 17 April 2020 (UTC)
Awesome, that works now correctly. Jo-Jo Eumerus (talk) 09:37, 18 April 2020 (UTC)

New gadget

Please implement the consensus at Wikipedia:Village_pump_(technical)/Archive_180#Gadget_proposal:_find_archived_sections_easily, which was recently archived with no opposition.

The testcases can be used to check if installation was successful.

Poke Enterprisey, who said they're happy to do the above. SD0001 (talk) 17:49, 26 April 2020 (UTC)

 Done, and the test cases seem to be working fine for me. Thanks again for writing the script! Enterprisey (talk!) 02:15, 27 April 2020 (UTC)

A WP:DRN script has been de-gadgeted and is ready to be renamed

Please see the result of MediaWiki talk:Gadget-DRN-wizard.js#Requested move 1 April 2020. This move was listed at WP:RMTR to be carried out, but a regular admin can't do it. It needs an interface admin. Judging from the comments left at MediaWiki talk:Gadget-DRN-wizard.js it seems that User:Xaosflux must be aware of the de-gadgeting of this script. I am listing this here just to get it out of the RMTR queue, not because I know what it is. EdJohnston (talk) 22:48, 18 April 2020 (UTC)

User:Xaosflux, User:Buidhe - What will this do? Robert McClenon (talk) 23:11, 18 April 2020 (UTC)
I am not involved in this except that I closed the discussion as move because it had been listed for more than two weeks without opposition, and with a reasonable move rationale. buidhe 23:13, 18 April 2020 (UTC)
So this is transparent to everyone, and there is really no need to move it at all, but apparently Pppery didn't like the name - the name doesn't matter and doesn't impact "gadgets" at all. If anyone wants to execute this they should also change MediaWiki:Gadget-DRN-wizard.css along with it. To change it, just move the pages then also update the text on these 2 pages: Wikipedia:Dispute resolution noticeboard/Header, Wikipedia:Dispute resolution noticeboard/request to point to the new page names. Redirects shouldn't be needed to be maintained. — xaosflux Talk 01:44, 19 April 2020 (UTC)
Just FYI, there is no problem doing it, just those are the steps that are needed and there should be no rush. If I have time later I may get to it. — xaosflux Talk 12:08, 20 April 2020 (UTC)
 Done non-sript-calling redirects left for reference. — xaosflux Talk 14:43, 27 April 2020 (UTC)

Equazcion's ScriptInstaller needs a fix; and whether to mass-message people to migrate away

See discussion at WT:MMS#Request for mass message delivery: May 20, 2020. Enterprisey (talk!) 19:36, 20 May 2020 (UTC)

 Done ~ Amory (u • t • c) 17:05, 7 June 2020 (UTC)

Changes to MediaWiki:Gadget-UTCLiveClock.js

There was a request (see Wikipedia talk:Gadget#UTC time gadget) to add functionality to this gadget (MediaWiki:Gadget-UTCLiveClock.js) to allow users to specify another timezone to use. Enwiki's gadget simply imports the current version on mediawiki.org (mw:MediaWiki:Gadget-UTCLiveClock.js), so I thought I should cross-post here for feedback before proceeding with adding the new functionality. Please discuss at Wikipedia:Code review/UTCLiveClock. Thanks, --DannyS712 (talk) 10:28, 11 May 2020 (UTC)

Move user script to MediaWiki namespace to load it via withJS

Moved from WP:VPT

​​Hi! As part of my work with excerpts, I developed the script at User:Sophivorus/ExcerptTree.js that builds the excerpt trees described at Wikipedia:Excerpts#Excerpt trees. Can it be moved to MediaWiki:ExcerptTree.js so that users can load it via withJS by clicking a button, similar to what I did at es:Wikipedia:Extractos#Árboles de extractos? Sophivorus (talk) 19:17, 11 May 2020 (UTC)

If you want it as a gadget it has to be moved to MediaWiki:Gadget-ExcerptTree.js. --Killarnee (T•1•2) 19:26, 11 May 2020 (UTC)
@Sophivorus, Quiddity, and Sdkb: (moved to a better forum). — xaosflux Talk 19:32, 11 May 2020 (UTC)
@Killarnee: It doesn't need to be a gadget, just needs to be in the mediawiki namespace for withJS to work DannyS712 (talk) 19:35, 11 May 2020 (UTC)
But then it works for everyone, including those who don't want it. --Killarnee (T•1•2) 19:38, 11 May 2020 (UTC)
Only if the url includes "withJS=..." (and if its a gadget it can still be loaded with withJS) DannyS712 (talk) 19:47, 11 May 2020 (UTC)
I think that making it a gadget is overkill at this point, since it's only likely to be used on one page. Sophivorus (talk) 20:14, 11 May 2020 (UTC)

Proposed fix to Mediawiki:Common.js about section-jumping behavior

I have proposed a fix to Common.js that might help with how autocollapsing boxes make the page jump around after navigating to a section header. That is, when navigating directly to a section near the bottom of AN, often times when the collapse box code and other javascript is done, the section is offscreen. This fix performs an additional jump to the section after the collapse box code. Comments are requested over there. Enterprisey (talk!) 19:25, 18 May 2020 (UTC)

Issues with D67 CSS

I've been told that this is why my heavily-customized vector.css has broken. I will admit that I did not customize it myself; rather, I got other people to do it for me, so I'm not entirely sure if this is the case. Can you verify that this change is responsible for the decreased usability and hindered workflow? Thanks. DS (talk) 05:34, 27 May 2020 (UTC)
DragonflySixtyseven, I don't see any issues regarding this particular change in User:DragonflySixtyseven/vector.css. Galobtter (pingó mió) 07:04, 27 May 2020 (UTC)
DragonflySixtyseven, I didn't think this change had gone live yet. Your particular issues are likely due to line 54, the div.vectorTabs ul > li bit. YMMV, but I'd recommend just removing that. At the very least, I'll note two things: (1) it sets the font size to 6, you should probably set it to 16 (or remove that); and (2) the float: none and width: 132px interact to make things very funky (again, I'd recommend removing it). ~ Amory (u • t • c) 09:41, 27 May 2020 (UTC)
Apparently that wasn't actually the cause of my problems: I deleted the line as recommended, and cleared my cache, and even logged out and then back in, but the sidebar is still messed up (see image). Suggestions for how to fix this would be welcome. DS (talk) 18:25, 27 May 2020 (UTC)
Cleanly separated fields on the left (pre-update); overlapping fields on the right (post-update)
Apologies, but I don't replicate that appearance with your vector.css file. Perhaps it's another script? ~ Amory (u • t • c) 17:05, 7 June 2020 (UTC)

T252467: Remove "div" qualifier from user CSS

Tracked in Phabricator
Task T252467

See phab:T252467. ~ ToBeFree (talk) 17:26, 18 May 2020 (UTC)

From the task, only MediaWiki:Gadget-wmfFR2011Style.css (is this still needed?) and MediaWiki:Gadget-Blackskin.css were identified from an interface perspective. --Izno (talk) 02:07, 19 May 2020 (UTC)
Izno, I wondered if perhaps interface administrators could implement the fix in userspace as well. But perhaps that's too invasive, even for a purely technical fix that preserves the appearance and prevents it from suddenly breaking. I personally think it should simply be done by interface administrators. ~ ToBeFree (talk) 12:46, 19 May 2020 (UTC)
There have been a few discussions here on the matter of upkeeping user styles and scripts. You can check the archives for general feeling. --Izno (talk) 12:49, 19 May 2020 (UTC)
I'm probably on the more liberal side of "make changes/fixes for people" but I dunno how much we really need to preemptively go after these. It should be pretty straightforward, and I'm willing to do it — can hardcode regex, know list of pages, etc. — but it's 1,035 pages. Some of those users are undoubtedly active, but a great number will be inactive editors or unused pages; it'd probably make more sense to filter for recently-active users, and let any issues for inactives remain.
Anyway, I'm happy to do any, none, or all of it, but given the scope it should be agreed upon beforehand, preferably by at least some of the users affected. ~ Amory (u • t • c) 14:09, 19 May 2020 (UTC)
Ah, I had especially the inactive users in mind. The active users can do this themselves, the inactive ones perhaps return in a few years and suddenly find their user CSS to have been broken (ironically, for accessibility reasons), if I understand the situation correctly. ~ ToBeFree (talk) 16:13, 19 May 2020 (UTC)
Fair. I was figuring active users would care and could consent, inactive ones wouldn't care unless and until they returned. Both reasonable ways of looking at it. I had my questions answered, which apparently dramatically lowered the number of users affected (although I don't see why div#content shouldn't be done if it's inevitable). ~ Amory (u • t • c) 09:52, 22 May 2020 (UTC)
The former was removed ages ago (see also this); we don't have a good process for handling such things, so I'd be in favor of just deleting or blanking it. I (or someone else!) can fix the latter, though I've asked a few clarifying questions since I think the request was missing some items. ~ Amory (u • t • c) 14:30, 19 May 2020 (UTC)
moved from the Village pump (technical)

Hello! I'd like to make a double-check about a change that was announced in Tech/News/2020/21.

Over-qualified CSS selectors have been changed. div#p-personal, div#p-navigation, div#p-interaction, div#p-tb, div#p-lang, div#p-namespaces or div#p-variants are now all removed of the div qualifier, as in for example it is #p-personal, #p-navigation …. This is so the skins can use HTML5 elements. If your gadgets or user styles used them you will have to update them. This only impacts the Vector skin.

On this wiki, this impacted or still impacts the following pages:

Extended content

How to proceed now? Just visit all these pages and remove div before these CSS selectors if it hasn't been removed so far. Thank you! SGrabarczuk (WMF) (talk) 11:26, 25 May 2020 (UTC)

Just a note, as the above conversation is (theoretically) still ongoing, but I 1: already fixed the one gadget page affected, and 2: #p-cactions is also affected (per my discussions on the phab). My position/offer above still stands, but I do think it would be good to discuss first. ~ Amory (u • t • c) 09:47, 27 May 2020 (UTC)
Bump in case there's any input. ~ Amory (u • t • c) 17:06, 7 June 2020 (UTC)

Vector menu tabs toggle gadget could use some love

I made some changes to MediaWiki:Gadget-MenuTabsToggle.js and MediaWiki:Gadget-MenuTabsToggle.css to account for upcoming vector changes (see edit summaries), but I'm not sure these are or were working beforehand. They were previously maintained by Edokter, but he's only made four edits since 2017. I think some of the issues stem from the fact that things are in transition right now. The script manually removes and adds the vector-menu class, but items also have the (soon-to-be-removed) vectorMenu class. Likewise, it adds/removes .vectorTabs as appropriate, but they items also have .vector-menu-tabs and .vector-menu. I don't really have the time (or desire) to fix this right now, but if that's right, it'd require some non-trivial reworking in this transition period, and then back again once things have settled. ~ Amory (u • t • c) 01:07, 9 June 2020 (UTC)

Undeletion request

Please undelete the pages listed below (but see my note about the last one). In the past, it was standard practice to block deceased users and these pages were collateral of a script run by MZMcBride in 2008 to delete orphaned user subpages of indefinitely blocked users. I have dealt with those that I could ... see Wikipedia talk:Deceased Wikipedians#Unblocked deceased users, but I can't undelete the CSS/JS pages. Here they are:

As for the last one, perhaps keeping it deleted would be best ... Rbraunwa did after all write in the edit summary "I would like to remove this, which isn't serving any purpose" (admins only) ... I'll leave that one up to the discretion of the intadmin. Thanks! Graham87 09:24, 15 June 2020 (UTC)

@Graham87: done for Dalf and Rbraunwa, Oryanw was subsequently renamed, so this is now at User:Oryanw~enwiki/monobook.js. While a few of these are fine, if there are massive amounts of deleted user skin/common script pages for users that are certainly no longer around - recovering them probably isn't going to be very useful. — xaosflux Talk 13:14, 15 June 2020 (UTC)
@Xaosflux: Thanks! Yeah, I don't anticipate finding too many of these ... after all, most people got blocked for actively doing something they shouldn't've on the site. Graham87 13:56, 15 June 2020 (UTC)
I mean, what is the reason for doing these ones? Is it just that practice changed in a decade, so if this had happened now, we wouldn't have deleted them? Not sure I see the value in undeleting pages that will never be useful. ~ Amory (u • t • c) 18:14, 15 June 2020 (UTC)
@Amorymeltzer: if this is an WP:ADMINACCT question for me, it is because an administrator that does extensive revision research asked for it. I reviewed the content to ensure there wasn't anything nefarious in there first and didn't see a good reason to deny the request. The pages were deleted under a speedy deletion rationale, and the undeletion policy allows for restoration of speedily deleted pages without debate. Now that all that is said, I think this is mostly pointless and I wouldn't want to entertain many more of these types of request without having a good reason established first. One specific item of note, we should probably run a query for any undeleted user-subpages, that are in executing script locations, that aren't actually associated with a registered user -- and delete or move them for beansy reasons. — xaosflux Talk 18:23, 15 June 2020 (UTC)
Not at all, I was just trying to ask Graham87 if there was value that I was missing. I don't think there's anything wrong with the request or action, just that as far as I can see, it's pointless. As for that query, they'd all be U2 anyway, right? ~ Amory (u • t • c) 18:27, 15 June 2020 (UTC)
Yup, U2's - mostly about getting them out of the way in case they cease to be U2's.... — xaosflux Talk 18:33, 15 June 2020 (UTC)
The way I see things is that there's no reason for a non-admin *not* to have access to these pages, so they should be undeleted by default. Speedy deletions by the deleting admin, MZMcBride, were sometimes fairly controversial at the time. Graham87 06:00, 16 June 2020 (UTC)

Request to make collapsible working on mobile version

The collapsible feature not working could be losing somewhat benefit for mobile version as some huge contents needed faster to get past and it could sometimes crash the browser. A collapsible option is actually more useful on mobile than desktop with wider screen. Looking to zhwiki: zh:Template:Collapsible_list. The Navframe makes the feature working like a charm on both mobile and desktop version. Also the toggle is better as it spans the whole bar, not for this Wiki as it's small and hard to press on. Therefore, please consider turning the Navframe (zh:MediaWiki:Gadget-NavFrame.js,zh:MediaWiki:Gadget-NavFrame.css) code existed again. Or if is there anything alternative. Thank you. — Pichnat Thong 07:40, 27 June 2020 (UTC)

We actually need to work on removing the deprecated Navframe entirely. It's on some 3.1k pages, which is a little rough to try and remove it directly. I don't know if it's suitable for botting either, which is rough. Ideas? --Izno (talk) 18:12, 27 June 2020 (UTC)
@Izno: Perhaps we could create another new Navframe (for collapsible) which is entirely not based on the old Navframe? Sorry that I'm not well at this. — Pichnat Thong 06:19, 30 June 2020 (UTC)
The replacement is the mw-collapsible class. --Izno (talk) 13:42, 30 June 2020 (UTC)

Non-free architectural work

— xaosflux Talk 11:34, 2 July 2020 (UTC)

Importing rights for interface admin

In the case of an admin, he, by default have rollbacker, autopatroller, etc. user rights by default. I would like to know whether interface admins have the import rights by default or not. Adithyak1997 (talk) 09:28, 5 July 2020 (UTC)

@Adithyak1997 here on enwiki, all interface admins are also admins, which includes the import right, but by default the interface admin group does not include import rights DannyS712 (talk) 09:31, 5 July 2020 (UTC)
They do not. The purpose of iadmin is to limit the amount of users who can edit sitewide CSS/JS and by design that group does give any other user rights. – Majavah talk · edits 09:32, 5 July 2020 (UTC)
Ok. Thank you. Adithyak1997 (talk) 09:32, 5 July 2020 (UTC)
What was said above is correct. The interface administrator user right itself does not include this ability. While one can be an interface admin on a technical level (the MediaWiki software will let you do it), by policy, all interface administrators on the English Wikipedia must be administrators in order to be eligible for the user right. Since administrators are also importers, it is implied that all interface administrators are importers. Sorry for the late chime-in, but I figured I'd validate the statements above nonetheless. :-) ~Oshwah~(talk) (contribs) 18:46, 11 July 2020 (UTC)

Move user script to MediaWiki namespace to load it via withJS

Moved from WP:VPT

​​Hi! As part of my work with excerpts, I developed the script at User:Sophivorus/ExcerptTree.js that builds the excerpt trees described at Wikipedia:Excerpts#Excerpt trees. Can it be moved to MediaWiki:ExcerptTree.js so that users can load it via withJS by clicking a button, similar to what I did at es:Wikipedia:Extractos#Árboles de extractos? Sophivorus (talk) 19:17, 11 May 2020 (UTC)

If you want it as a gadget it has to be moved to MediaWiki:Gadget-ExcerptTree.js. --Killarnee (T•1•2) 19:26, 11 May 2020 (UTC)
@Sophivorus, Quiddity, and Sdkb: (moved to a better forum). — xaosflux Talk 19:32, 11 May 2020 (UTC)
@Killarnee: It doesn't need to be a gadget, just needs to be in the mediawiki namespace for withJS to work DannyS712 (talk) 19:35, 11 May 2020 (UTC)
But then it works for everyone, including those who don't want it. --Killarnee (T•1•2) 19:38, 11 May 2020 (UTC)
Only if the url includes "withJS=..." (and if its a gadget it can still be loaded with withJS) DannyS712 (talk) 19:47, 11 May 2020 (UTC)
I think that making it a gadget is overkill at this point, since it's only likely to be used on one page. Sophivorus (talk) 20:14, 11 May 2020 (UTC)
Hi! I'm bringing this back from the archive because it seems to me at least that there's some consensus that the request is reasonable, yet it was archived without being fulfilled. Kind regards, Sophivorus (talk) 14:21, 19 July 2020 (UTC)
@Sophivorus: Its archiving was near-inevitable following its move from a page with >3K watchers to one with, err, 81!  ;) ——Serial 14:37, 19 July 2020 (UTC)
@Sophivorus: If this is soon going to be in MW space, it should work across all browsers. Can you change the use of arrow functions to normal functions for IE 11 compatibility? There's also the use of ES6 includes() function which should be replaced with indexOf(...) !== -1. Also, on line 30, you're trying to create a link without encoding the tile, which will not work for titles with special characters. Use mw.util.getUrl() here. SD0001 (talk) 13:20, 20 July 2020 (UTC)
 Done Sophivorus I've copied this to MediaWiki:ExcerptTree.js - please either watch or redirect the talk page. Regarding improvement notes above, these are certainly worth looking in to, however the script appears 'non-dangerous' as-is, and has no forced use for anyone. When/if improvements are made (suggest you make them on your own page and test first) please drop an edit request at the talk page to sync from your sandbox/personal space for updates. — xaosflux Talk 14:40, 20 July 2020 (UTC)

Request for content of deleted user JS page

A few months ago, Can I Log In requested a change to my user script. Since then, he's been restricted from activities not related to content creation, which a reply to me there would be. Since this is someone else's userspace, please don't undelete the page in place, but just provide me with the content of this diff. (I was sent here from WP:REFUND since apparently regular sysops can't see all deleted pages anymore.) —Jackmcbarn (talk) 02:34, 27 July 2020 (UTC)

 Done Welcome back! My views at the request not withstanding, I've provided what I believe is the correct content at User:Jackmcbarn/editProtectedHelper.js/CILI sandbox.js. ~ Amory (u • t • c) 09:49, 27 July 2020 (UTC)

REDWARN

Interface admins may want to be aware of this thread at AN about REDWARN. This tool is being served to Wikipedia users from an external CDN, which raises some questions about privacy and security. I don't want to say too much, but this appears to involve the same sorts of security issues that led to the implementation of the IntAdmin user right in 2018. – bradv🍁 00:29, 24 June 2020 (UTC)

Probably closer to the CSP stuff being introduced, although of course this sort of thing would and should never end up in mediawiki-space. Thanks for the note. ~ Amory (u • t • c) 00:52, 24 June 2020 (UTC)
@Bradv: thanks for the note - its a bit different, importing others scripts was not stopped with the intadmin lockdowns, but I completely agree with Amory - we would never load such an off-site script import in to a gadget or core script file. Though we allowed Enterprisey's script installer to be a gadget, it was with the condition that it must include the same type of warning seen when manually editing a page. If any user asks "is RedWarn safe" here, at AN, at VPT - I'd warn them that that as it is off-site, it is subject to change without notice, and will share private information (such as their IP address and referrer) with the external site. — xaosflux Talk 01:10, 24 June 2020 (UTC)
For posterity's sake, I believe that thread ended with Ed6767 updating RedWarn to use the WMF's internal CDN service. — Wug·a·po·des​ 20:01, 19 July 2020 (UTC)
Yes, that is the case. Everything is now hosted on redwarn.toolforge.org Ed6767 talk! 20:48, 27 July 2020 (UTC)

Removing old WP-space snippets

Watchers of this page might be interested in my attempt to start a discussion at Wikipedia talk:User scripts#Snippets section isn't useful. ~ Amory (u • t • c) 18:31, 29 July 2020 (UTC)

Preparing for removal of Javascript globals

It's been a long time coming, but at some point in the near future, doing things like wgArticleId will be disallowed, in favor of mw.config.get('wgArticleId'). The old globals have been deprecated for about half a decade, but have been available on Wikipedia alongside with a deprecation note in the console.

I think I cleaned up some lingering uses in MediaWiki-space a while ago, but searching in MW- and Wikipedia-space, pretty much the only remaining uses I can find are the old (and now unused) version of the AFCH gadget (which ​I think we should blank) and a bunch of ancient stuff at Wikipedia:User scripts/Snippets (which I think we should blank; see above section or here).

The real issue is user-space scripts. I've semi-manually searched through each of the most imported scripts with 5 or more active users, and of those there are around 75 that potentially have some issue. Activity of the "owners" varies widely — some are active, some are intermittently so, some pop in a bit here and there, and others are inactive. That is to say, messaging them all will only go so far, and it will likely fall on intadmins to mass-fix some scripts when the switch happens. I'm happy to go through the list and make the changes if folks like, but it'd be good to have some consensus that it's a good idea first. Regardless, it'd be nice to have a notification process in place — I'd suggest anyone active in the last 6 months — before anyone goes stomping around in userspace. Beyond that, is 5+ a good threshold? Many active users have abandoned monobook.js pages where a lot of these are likely to be found, so perhaps it should be higher; intadmins clearly aren't going to do everything. ~ Amory (u • t • c) 02:01, 30 July 2020 (UTC)

I don't love the idea of "fixing" personal scripts for people - especially if not asked. Deactivating them by commenting out the offending section is one thing - trying to actually maintain random user scripts is a bit of a lost cause. If the scripts actually are popular and the owners have left - we should look to either gadgetizing them or at the least making them 'community' scripts and getting them out of userspace. — xaosflux Talk 02:42, 30 July 2020 (UTC)
Anddddd insert discussion from the archives whenever this topic is broached. --Izno (talk) 04:18, 30 July 2020 (UTC)
Well, as before, I view fairly simple changes as a result of the devs flipping a switch not to be maintaining them. Moving something to MW-space would be much more of a commitment, IMO, to maintain and keep relevant. To be perfectly frank, I'm fine with (nearly) all of these scripts breaking, and would find the data on how much people notice to be useful; I just think it'd be helpful to do otherwise. I can preemptively alert semi-active folks when I get chance, regardless of this. ~ Amory (u • t • c) 09:32, 30 July 2020 (UTC)
I feel like there's two subtly different questions here, the first being "When is it acceptable for interface admins to fix other users' user scripts?", and the second being "Should users be able to expect that interface admins will indefinitely maintain inactive users' user scripts?". My answer to the first question would be "any time a change is made to the site that breaks something in one, it's okay for interface admins to fix it so it works like it used to", and my answer to the second question would be "generally not, unless/until someone submits an interface-protected edit request with the fixes, or if the script is very popular". Jackmcbarn (talk) 21:03, 30 July 2020 (UTC)
I don't see any direct problem with int-admins tweaking a personal script to maintain functionality specifically - but I don't think it is incumbent upon us to do so. — xaosflux Talk 23:57, 30 July 2020 (UTC)
Another point is that if an interface admin fixes a particular problem on a user script, others might look at the history later and decide that the fact it was last edited by an interface admin indicates the script is fully working and desirable for general use. For random scripts, that is probably not the case. I think it would be better to leave scripts broken until a need for repair is shown, and someone is able to look at the whole thing. Johnuniq (talk) 00:04, 31 July 2020 (UTC)

Request to remove pp-templates

The following pages include {{pp}} templates and are not protected. Due to they are .css and.js pages, the users are inactive and these pages appear at Category:Wikipedia pages with incorrect protection templates. Thanks. — Preceding unsigned comment added by Tbhotch (talk • contribs) 15:36, 20 September 2020 (UTC)

Done ones
Notes
@Tbhotch: some of those pages are actually protected - did you review them all? Also at least one appears to be getting used as a transclusion elsewhere. — xaosflux Talk 00:25, 21 September 2020 (UTC)
For Eteethan. It includes a "noinclude" tag, so the template is not appearing anyway (also, it should be an "includeonly" tag instead).
For GoldenRing. Protection is redundant in these pages. I don't think they are transcluded, the transcluded pages would appear at Category:Wikipedia pages with incorrect protection templates and none is. Alternatively an "includeonly" tag is to be placed. Also GR has been gone for almost a year. IDK if they will return or if they will retain their tools.
For Morgankevinj. It should include an "includeonly" tag. (CC) Tbhotch™ 14:32, 21 September 2020 (UTC)
By the way, MusikBot can't operate correctly because these pages are blocking its source code, functions (or whatever the name they receive). (CC) Tbhotch™ 19:42, 25 September 2020 (UTC)
Someone will get around to this, it seems to be a VERY low priority to maintaining the encyclopedia right now. If a bot is making errors, start by contacting the bot operator, I can't imagine that anything on-wiki would corrupt the software of a bot though... — xaosflux Talk 22:43, 25 September 2020 (UTC)
 Done Indeed this is super low priority maintenance, which is why a bot was written to do it for us. There was a permissions error that was interrupting the bot from finishing on each run, which I've now fixed. Best, — MusikAnimal talk 16:13, 26 September 2020 (UTC)
@MusikAnimal: hmmm.. I'm assuming this is for task 4: Wikipedia:Bots/Requests for approval/MusikBot II 4, of which the BRFA only lists namespace:0 as in scope - and the bot's IADMIN access was for one specific page under Wikipedia:Bots/Requests for approval/MusikBot II 2 -- have you been operating this on all sorts of namespaces? — xaosflux Talk 02:55, 27 September 2020 (UTC)
The BRFA for removing pp's is MusikBot 9, approved for all namespaces, and is running for all namespaces. BRFA MusikBot II 4 is for adding pp's which is indeed running only for ns:0. This BRFA mentioned that the pp removal code will now run under MusikBot II -- which implicitly means that that code will now have IADMIN permit? – SD0001 (talk) 17:32, 27 September 2020 (UTC)
@Xaosflux: MusikBot II 4 is about adding protection templates, which indeed only happens in the mainspace. The BRFA for removing them was MusikBot 9 and has been done in all namespaces since the beginning (~4.5 years ago). No, it was not approved to do this on user JS/CSS. I changed that because it fixed both problems here -- it kept the bot from erroring out, and it did the mundane task that sat here unattended for a week. I recognize that's a bit of a stretch, especially since it's possible some JavaScript might actually intentionally have {{pp}} or similar syntax in the code (in which case the script author should wrap the code in nowiki tags, I think), and the bot would have no way of knowing that. So I have removed this permission and instead will have the bot skip any JS/CSS pages. My apologies for not giving this more thought. Removing protection templates inherently became an admin task with MusikBot II 4, though, as the two tasks were merged. — MusikAnimal talk 17:40, 27 September 2020 (UTC)
reply-link conflict with SD0001, heh :) Each task MusikBot II has uses a different bot password, so it did not inherit IADMIN access in this case, though it did inherit editing any other fully-protected page. I'm fine with it not editing JS/CSS (seems safest) but I do need to make it not error out. Working on that now. — MusikAnimal talk 17:46, 27 September 2020 (UTC)
@MusikAnimal: OK thanks, error-detection and recovery is certainly a good idea, and I agree that userpages are likely to be odd edge cases (especially when there is wiki code in side of javascript) - and wanted to make sure they would be carefully reviewed. — xaosflux Talk 19:46, 27 September 2020 (UTC)

Inactive interface administrators 2020-09-28

The following interface administrator(s) are inactive:

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

Thanks bot, appears to be a legitimate WMF employee account (per meta:Special:Redirect/logid/37140160) so this is exempt from our normal inactivity policy as it was an WP:OFFICE action. @OVasileva (WMF): should you no longer require elevated permissions here please let us know and we can remove for you. Best regards, — xaosflux Talk 01:35, 29 September 2020 (UTC)

New gadget

Would anyone say this VPT discussion shows consensus? I'd say there's a consensus largely per WP:SILENCE and this doesn't look the sort of thing needing heavy discussion. Can an int-admin do the honours? The script would need mediawiki.util as a dependency, and the gadget description could probably say Show short descriptions in categories (can be toggled on/off) ([[User:SD0001/shortdescs-in-category|documentation]]). Thanks, – SD0001 (talk) 16:28, 28 September 2020 (UTC)

Honestly, I don't think it does. That aside, I think it would make sense to put this in the short desc gadget rather than adding a new one. --Izno (talk) 17:42, 28 September 2020 (UTC)
I'd basically agree with this assessment. ~ Amory (u • t • c) 10:34, 30 September 2020 (UTC)
Which short desc gadget - MediaWiki:Gadget-Page descriptions.js or Mediawiki:Gadget-Shortdesc-helper.js? The first is a fairly simple one and it wouldn't make sense to bloat it, the second is an editing gadget; there should be a separation of concerns between editing and viewing. Those simply wanting to see shortdescs in categories shouldn't have to install a full-fledged editing tool that shows up on every article.
Regarding consensus, I don't think adding an opt-in gadget is in any way controversial to need more discussion. WP:SILENCE applies. The only reason I suggested it is because I suspect this is a feature that's a lot more useful than the userscript installation count suggests. Anyway, I think I have done my part here and won't spend any more time pursuing this. – SD0001 (talk) 19:04, 30 September 2020 (UTC)
I honestly don't care which gadget; if you want it to see it added to both the others, that's also fine (why should it be either-or?). What I think we should avoid is having 3 gadgets where probably 1 should do, if not the 2 we add today, as a matter of avoiding option-bloat. Why should we display descriptions in categories if people can't see them outside categories? You can suggest there should be a separation of concerns, but I subsequently assert that things that look and act and feel like they go together should be accordingly packaged together, among others (see the package principles). --Izno (talk) 23:40, 30 September 2020 (UTC)
I'm planning on finishing and sending the next issue of Scripts++ this weekend, and can include a note about the discussion if you want (just let me know, or add it to Wikipedia:Scripts++/Next) DannyS712 (talk) 04:22, 1 October 2020 (UTC)

Edit request

Please delete on line 51, I cannot edit on my main account as it keeps reloading my page. It is on the page User:HeartGlow30797/StatusChanger.js.[redacted] 05:04, 1 October 2020 (UTC)

You can edit the page yourself with the javascript in your browser disabled. – SD0001 (talk) 09:01, 1 October 2020 (UTC)
Rather than disabling JavaScript in your browser (which is apparently more difficult in each new browser version), you can also use MediaWiki's safe mode: [1]. Jackmcbarn (talk) 15:26, 1 October 2020 (UTC)
I've blanked the page, you can recover from the history. — xaosflux Talk 16:38, 1 October 2020 (UTC)

Edit to a user JS page to clear a category

Please see Wikipedia:Village pump (technical)/Archive 184#js edit needed to clear renamed category. Graham87 05:49, 11 October 2020 (UTC)

 Done — xaosflux Talk 15:42, 11 October 2020 (UTC)

WikEd patch for non-breaking spaces

Hi,

Could you please apply this patch to the user script User:Cacycle/wikEd.js?

It does not change the default behavior, but adds an option that disables the replacement of non-breaking spaces with the corresponding HTML entities, which is problematic on fr.wikipedia.org. Unfortunately, having this option turned off also causes a different kind of unwanted replacements, but on frwiki, this is a better compromise. For that reason, frwiki is using a fork for a long time, but I would like to be able to switch back to the original version.

I am asking here because the author of this script, Cacycle, is mostly inactive. I already asked him twice to add this patch in 2014. Their reply was "I am right now adding real nbsp support to wikEd, please give me some time", but this did not happen.

Test:

Orlodrim (talk) 08:47, 4 October 2020 (UTC)

Orlodrim - While Cacycle's activity has recently been minimal, I would like to try and get his/her approval first. Cacycle, are you okay with us implementing this change to the .js script you wrote here? ~Oshwah~(talk) (contribs) 07:24, 9 October 2020 (UTC)
Cacycle has responded on their talk page, asking for a few days, so we should probably honor that request and put this on hold for the time being. Writ Keeper ⚇♔ 11:25, 9 October 2020 (UTC)
 Not done as Cacycle is not inactive there is no reason we would need to force a change to their personal script. @Orlodrim: if you don't like their script and want to fork it - you are more than welcome to, especially in another project - and even more so if it will be used by multiple people on another project. — xaosflux Talk 13:09, 9 October 2020 (UTC)
Sure, since he responded I can follow up with him. In this case, code duplication is a maintenance burden. Orlodrim (talk) 14:51, 9 October 2020 (UTC)
to be fair, the only reason you would need an intadmin's intervention is if the author was inactive, which would mean the script no longer receives updates, which would mean there's no maintenance burden to just forking... Writ Keeper ⚇♔ 14:59, 9 October 2020 (UTC)
Not really. As you can see in the history, there has been some maintenance done by other users on the original script and the same thing had to be done on the copy. In particular, Jon (WMF) fixed multiple problems on both copies in the last days. In other words, having a fork is costing real money. Orlodrim (talk) 15:10, 9 October 2020 (UTC)
Perhaps @Jon (WMF): can comment a bit more - it is quite unusual for WMF employees to be changing an editor's personal userscripts without a very good reason. Jon, why does the foundation need to do this? — xaosflux Talk 15:25, 9 October 2020 (UTC)
Expanding on that is that - if the foundation wants to maintain some codebase, it really shouldn't be depending on an indivudual's personal script space on a single project, we'd actually love to have more useful tools have paid staff supporting them - perhaps as extensions. — xaosflux Talk 15:39, 9 October 2020 (UTC)
Small technical changes to a very widely used gadget (regardless of where it's hosted) to fix issues which don't have any other side effects is a "very good reason" to make an edit. Suggesting otherwise falls afoul of WP:NOTBURO. – SD0001 (talk) 19:05, 9 October 2020 (UTC)
At any rate I want to reassure Jon (WMF) that xaosflux's admonishment doesn't reflect the community's views. – SD0001 (talk) 19:08, 9 October 2020 (UTC)
Not an admonishment so much - just strong questioning, unlike contributions by volunteers this is being done by an employee who by default would be making the changes "in that role" - and who only has this office level access because of that relationship. As I said above I'd LOVE for WMF to actively provide official support for more useful utilities. — xaosflux Talk 19:52, 9 October 2020 (UTC)
@Xaosflux: I assume they think it's reasonable to fix broken or error-ful scripts, which the changes made fixed (at the basic 'is this a valid program' level). I think that assumption is quite reasonable. I would guess on my part that his changes were identified as necessary by this work. I doubt very much anything else was intended by his changes. --Izno (talk) 19:19, 9 October 2020 (UTC)
Yes Izno is correct in that my motivation is the blog post here. We (WMF) are rolling out client side error logging so that we can block deployments that break things and help identify gadget errors as they occur. In future, if scripts are being hosted on wiki and run on end users I believe that they fall in the realm of production code since they show up in our client side production error logs and its fair game to edit them, until I'm told otherwise. I would suggest moving scripts onto a domain such as wmflabs.org if you want to opt out of such edits as that allows us to filter them out of this instrumentation by virtue of them running on an alternate domain.

My intention is that eventually gadget developers will be able to see and respond to errors the new instrumentation is uncovering, but for now we have a lot of historic debt that's blocking further roll out in Wikimedia projects. If we know about errors, we can do a better job of supporting end users whether they are using gadgets or user scripts. The reason staff have not done this before IMO is purely because we've had no idea about such problems. FWIW User:Cacycle/wikEd.js was one of the more error-prone gadgets which is understandable given its history and importance and my edits have restored long-broken gadgets on smaller wikis, so I don't see what I am doing as controversial. I am merely fixing syntax errors and making code more resilient, I have no intention of changing feature behaviour Jon (WMF) (talk) 01:43, 10 October 2020 (UTC)

With my volunteer hat on I would suggest French Wikipedia fork this wiki page to a local copy. This would mean any errors in it are shown on https://meta.wikimedia.org/wiki/User:Jdlrobson/User_scripts_with_client_errors Note we do not have client side error logging on English Wikipedia because of the volume of traffic that would cause and these existing gadget errors that need fixing first. Jdlrobson (talk) 01:57, 10 October 2020 (UTC)
Hi Jon (WMF), thanks for commenting here. Ignoring everything the specific case here, can I ask you about this quote, as I believe it represents a massive change:

In future, if scripts are being hosted on wiki and run on end users I believe that they fall in the realm of production code since they show up in our client side production error logs and its fair game to edit them, until I'm told otherwise. I would suggest moving scripts onto a domain such as wmflabs.org if you want to opt out of such edits as that allows us to filter them out of this instrumentation by virtue of them running on an alternate domain.

It seems to me that is saying that any JS pages in userspace will be considered "production" and if users do not want staff members to edit them at will, they should avoid the wiki entirely and instead do so on wmflabs.org, is that a correct reading of what you said? If so, is that your belief or that of the foundation? I'm a big fan of reducing errors across the board and would love to help out here, but either way, I believe that to be a dramatic change, and should be discussed more broadly than here, as I do not believe the community supports that interpretation or suggestion. ~ Amory (u • t • c) 13:45, 10 October 2020 (UTC)
I support WMF’s move to consider JS errors the same way as PHP ones (although Jon’s changes often just hid the problems, but that’s a perfect heads-up, as these changes pop up on watchlists and recent changes lists), however, I recognize script authors’ right to opt out of this. I don’t know how Logstash works, but isn’t it possible to place a special comment (e.g. // @no-wmf-maintain)? Logstash would download the script code and hide/drop those that contain it. (This isn’t possible if e.g. ResourceLoader removes all comments, but the only user code ResourceLoader loads are gadgets, which are not owned by any particular user, so this opt-out mechanism is probably not necessary there.) —Tacsipacsi (talk) 14:57, 10 October 2020 (UTC)
@Jon (WMF): I'd second what Amorymeltzer says here. This is absolutely not the community opinion or expectation, and this really should be asked of the community before it becomes standard practice. If nothing else, you should at least tell the people whose code you're changing; a talk page note for the user whose pages you are changing should be the absolute bare minimum. Writ Keeper ⚇♔ 22:12, 10 October 2020 (UTC)
I think as long as we're talking about fixing errors that are showing up in an error log (and not modifying any features), it makes sense for WMF staff (or anyone with the rights) to just make the edits, per WP:NOTBURO. If we're talking about feature changes, I agree it would need discussion and agreement on a talk page first. Kaldari (talk) 18:53, 13 October 2020 (UTC)
Agreed with Kaldari (though he should remind us that he is also a WMF staffer in his other life, so may come with a particular POV on the point ;). There's 0 reason for WMF not to fix scripts they identify as being incorrect programs. --Izno (talk) 19:05, 13 October 2020 (UTC)
I'm not strongly opposed to WMF employees doing bugfixes to user scripts in theory. I am opposed--I don't want to be responsible for anyone else's bugs in code that has my name in the title--but that's more as a personal thing than with my intadmin hat on, so it's not very strong opposition.
What I am strongly opposed to, though, is WMF employees doing so without any notification to the script author. Ideally, they would talk to the script author first, but at the very least, they should drop a notification at the author's user talk page after they've made the fix. After all, if it's something that has changed, the author should be notified so they don't keep making the same mistake. Writ Keeper ⚇♔ 20:19, 13 October 2020 (UTC)

I think that the WMF taking an interest in user scripts and gadgets, in finding, fixing, and preventing errors, is a good thing. I do agree with others above that there should be some notification/explanation for the author. Also, @Jon (WMF), an edit summary with a link to an info page (perhaps on a translatable wiki like Meta), and maybe also a mention notification, would be more helpful than just "maintenance" + type of error. - Evad37 [talk] 23:47, 13 October 2020 (UTC)

Fixing/preventing errors and common courtesy aside, I would like further explanation on whether WMF and staffers consider user script pages "production code" — thus implying a level of ownership (not to mention responsibility) not generally agreed upon by the community — and whether the official remedy is to move pages behind a more opaque wmflabs.org. That is, I'm not particularly concerned with this specific instance of buro, but the implication above is a new relationship. ~ Amory (u • t • c) 12:26, 14 October 2020 (UTC)
I've taken. As far as I can see there is no change in relationship. The high volume of fixes is only a side effect of rolling out tracking for 10 years of scripts which have not had it. My hope is that in future this tooling will be available for gadget developers and low enough that talk pages will be a suitable medium for notifying users of errors, however for now to even have the tool we need to be able to predict and keep volume low.
User:Evad37 I agree that would be helpful and had a similar idea yesterday. I have expanded meta:User:Jon_(WMF)/Edit_to_user_or_gadget_script to provide more context as clearly it was needed here. Let me know if you think anything there is badly worded or needs to be fleshed out more or less. Thanks! Jon (WMF) (talk) 15:44, 14 October 2020 (UTC)
Amorymeltzer, they are production code, because they run inside a production environment and can interfere with other production code. Which is why they are such a pain, as they are not of a production code quality. Employees have ownership over overall production quality, userscript authors over their own code. somewhere in between is a gray area. —TheDJ (talk • contribs) 15:59, 14 October 2020 (UTC)

#jump-to-nav going away

There's a few 'community' user scripts on phab:T265373 that need adjusting per the Tech News this week. I've already bugged Enterprisey since DelSort broke in Timeless and in new Vector already and there was a thread for him.--Izno (talk) 18:07, 19 October 2020 (UTC)

brokenref

The opinion of an int admin would be appreciated at Help talk:Cite errors#TemplateStyles for brokenref. --Izno (talk) 16:42, 1 November 2020 (UTC)

MediaWiki:Pagetitle

 – —⁠andrybak (talk) 17:26, 9 November 2020 (UTC)

There is a proposal to edit the page MediaWiki:Pagetitle, which seems to have some support at the village pump. How wide of a discussion do edits to the page MediaWiki:Pagetitle require? An RFC? Maybe a link at WP:CENT? —⁠andrybak (talk) 12:00, 9 November 2020 (UTC)

FWIW any sysop can make the edit, not just interface-admins. Wider discussion for more than six days would be warranted. ~ Amory (u • t • c) 15:09, 9 November 2020 (UTC)
Moved the discussion to WP:AN. —⁠andrybak (talk) 17:26, 9 November 2020 (UTC)

Request to undelete User:PorkchopGMX/common.js

Hello, I would like to request undeletion of certain revisions of User:PorkchopGMX/common.js, specifically the ones before 22:55, October 29, 2020‎. Those revisions were deleted by an admin so that I could get out of my enforced wikibreak and I would like to be able to see the full page history. PorkchopGMX (talk • contribs • Merry Christmas!) 20:14, 14 December 2020 (UTC)

 Doing... — xaosflux Talk 20:20, 14 December 2020 (UTC)
 Done @PorkchopGMX: I've restored the full page history. — xaosflux Talk 20:22, 14 December 2020 (UTC)

Inactive interface administrators 2020-12-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:19, 28 December 2020 (UTC)

Meta log entry of grant and MediaWiki-space contribs, for reference. Nothing to do, I guess, although it could be weakly argued that a temp grant of only sysop would work equally fine. Enterprisey (talk!) 23:24, 28 December 2020 (UTC)

Request to undelete User:ThatIPEditor/redwarnConfig.js

Resolved below. — xaosflux Talk 23:36, 13 January 2021 (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.

Our bot alerted us of tampering with the permission restriction system, so would appreciate a copy of this (now deleted) config file so we can check RedWarn's tamper detection system is working correctly. Thanks, ✨ Ed talk! ✨ 21:33, 13 January 2021 (UTC)

Left a copy on your talk page. Please let me know if you actually need the history restored. --Izno (talk) 22:03, 13 January 2021 (UTC)
Thanks Izno, we were able to conclude the system accurately detected permission tampering in this case. ✨ Ed talk! ✨ 22:22, 13 January 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.

Fix for logo on monobook

Editors like me using monobook are having display issues with the logo since it's a couple pixels taller than the normal one. See User:Wugapodes/monobook.css for the patch. It moves the sidebar down a tad to prevent overlap then redefines the image height. @Xaosflux, Seddon, and Seddon (WMF): — Wug·a·po·des​ 23:57, 14 January 2021 (UTC)

 Doing... — xaosflux Talk 00:23, 15 January 2021 (UTC)
 Done may take a few mins for caching to get this in. — xaosflux Talk 00:31, 15 January 2021 (UTC)

Switch logo to "Option A"

Resolved
 – Please see phab:T272526. Mz7 (talk) 01:04, 23 January 2021 (UTC)

Hello interface administrators. On Wednesday I closed a village pump discussion in favor of switching the current celebratory logo to "Option A" (i.e. File:WP20 EnWiki20 SimplifiedLogo BillionEdits.svg). Unfortunately, there appear to be technical difficulties with the process of swapping the logo from the backend—see phab:T272526. I am peripherally aware that there is a hack-y way for interface administrators to change the logo via CSS (Wugapodes mentioned such a solution at this thread). In the interest of time, could we investigate this approach? Thanks, Mz7 (talk) 01:09, 22 January 2021 (UTC)

More direct section
​Won't the issues at phab:T272526#6763575 persist? Not sure if that outweighs the other concerns, but worth considering. If I find a chunk of time this afternoon I can try some things out, but it's certainly not ideal. ~ Amory (u • t • c) 11:45, 22 January 2021 (UTC)
  • @Amorymeltzer: I'm in a time crunch situation too, I gave you intadmin on test2wiki if you have time to test though. — xaosflux Talk 11:47, 22 January 2021 (UTC)
  • Just futzing around in the browser console, it looks like: 
    #p-logo>a { background-image:none; }
#p-logo { background-image:url(https://upload.wikimedia.org/wikipedia/commons/thumb/5/55/WP20_EnWiki20_SimplifiedLogo_BillionEdits.svg/189px-WP20_EnWiki20_SimplifiedLogo_BillionEdits.svg.png);
background-size: contain;
background-repeat: no-repeat;
background-position: center;
}
    should do it. Dropped it in my common.css and it seems to do okay. Is this what we want? Writ Keeper ⚇♔ 15:33, 22 January 2021 (UTC)
    • Upon reflection, 
      #p-logo>a { background-image:url(https://upload.wikimedia.org/wikipedia/commons/thumb/5/55/WP20_EnWiki20_SimplifiedLogo_BillionEdits.svg/189px-WP20_EnWiki20_SimplifiedLogo_BillionEdits.svg.png); background-size:contain; }
      would be simpler, wouldn't it. Writ Keeper ⚇♔ 15:41, 22 January 2021 (UTC)
FYI: @Amorymeltzer and Writ Keeper: this is the hack we used last time. — xaosflux Talk 15:47, 22 January 2021 (UTC)
Yeah, that's what I went off of. ~ Amory (u • t • c) 15:50, 22 January 2021 (UTC)

Protected by AntiCompositeNumber, so I've edited MediaWiki:Common.css. Change anything if it don't work! I didn't do some of the more minor margin tweaks, but they could be done. ~ Amory (u • t • c) 16:08, 22 January 2021 (UTC)

  • Removed the text banner on MP, and the extra padding hack from monobook.css. — xaosflux Talk 16:22, 22 January 2021 (UTC)
    Sweet, thanks; missed that that was present. 17:15, 22 January 2021 (UTC) — Preceding unsigned comment added by Amorymeltzer (talk • contribs)
  • Thanks everyone for your work on this! Mz7 (talk) 20:36, 22 January 2021 (UTC)

@Xaosflux and Amorymeltzer: Please revert this immediately, m:Logo#Temporary logo variants explicitly says not to do this. Legoktm (talk) 23:13, 22 January 2021 (UTC)

  • This looks malformed on my screen. Very blurry and weirdly sized. Suggest reverting. ProcrastinatingReader (talk) 00:01, 23 January 2021 (UTC)
    • Checking on updates at phab:T272526 - only reverting this will put back the cartoon-style "option d" that was already getting a lot of complaints. — xaosflux Talk 00:42, 23 January 2021 (UTC)
      • (edit conflict) @Xaosflux: I think you've entirely missed the point here. Having an unoptimized, extra logo downloaded on every request for millions of viewers is not acceptable from a performance standpoint. This is explicitly spelled out at m:Logo#Temporary logo variants, and any interface administrator who is not going to follow the guidance provided by sysadmins should have their flag removed. There was more than enough time to fix this properly, and sysadmins were regularly engaged (see e.g. phab:T272526#6763575) when the change to "Option A" was requested. That no feedback was provided for 2 days does not suddenly make this an emergency that requires hacky CSS and forces sysadmins to quickly react to stop bad things from happening on a Friday afternoon. The requested logo wasn't even sized correctly, I had to fix it myself. Legoktm (talk) 01:11, 23 January 2021 (UTC)
        • @Legoktm: agree this could have been done better. I only noted that last delay indicator comment very recently when I saw this was already in the middle of being actively worked on via the phab ticket. — xaosflux Talk 01:23, 23 January 2021 (UTC)
        • (edit conflict)​I don't think we need to bring xaosflux into this, I'm clearly the one to discuss it with.
          I am genuinely, truly sorry for taking up your Friday and working you off schedule, I mean that. I did not take Andre's comment as severe as he may have meant it, or I would have reverted right then. There was no further comment for six hours, including while I was on IRC. Sadly, your pings here didn't work, or I'd have seen your comment when you posted it; I left the house soon after. That no other INTADMIN/GIE was notified or seemingly available is unfortunate; I'd have welcomed anyone to simply revert the edit rather than put you in the tough position you I did. I'm going to put a toddler to bed, but if you'd like, I can start a recall petition or start a discussion on BN/AN about my intadmin bit in the morning. Again, thank you for your tireless effort, and I am truly, truly sorry for requiring it of you and others. ~ Amory (u • t • c) 01:35, 23 January 2021 (UTC)
          Amorymeltzer, the recall petition is surely unnecessary. In this thread we had no less than three interface administrators, all of whom are clearly experienced and competent users, fail to realize that using the CSS hack would be problematic even as a "stopgap" temporary solution. This indicates to me that what occurred here is nothing more than an honest mistake, and while all of us here stand duly chastised by the sysadmins who had to clean up after us, I see no reason for us to turn up the temperature beyond acknowledging what happened and ensuring that it doesn't happen again. Mz7 (talk) 02:07, 23 January 2021 (UTC)
          I agree with Mz7, I don't think there was any individual failures, there was a collective process failure here. I didn't intend for my comment to suggest you (or anyone involved here) should resign, everyone was acting in good faith. I over-assumed that people would understand the performance severity, re-reading it now I can see that it's not that obvious. I do have some constructive suggestions on how to move forward that I'll post below. Legoktm (talk) 06:04, 23 January 2021 (UTC)
  • Looks like phab:T272526 has been marked as resolved. Thank you to everyone involved here, and I sincerely apologize for the trouble—I was unaware that the Meta Wiki documentation for temporary logos discourages the CSS hack. Good thing to note for the future. Mz7 (talk) 01:04, 23 January 2021 (UTC)
  • @Legoktm: as part of the after-action review here - a recurring problem with the nature of this being a volunteer driven project is that there is no service level objectives, as any volunteer is always free to stop working on anything at any time - I think we're all coming from the same place of making things as best as they can be for the readers and contributors, and I understand that system stability plays an important part in that. Any suggestions for how to improve scheduling and communication in the future? — xaosflux Talk 01:23, 23 January 2021 (UTC)
    Right. Just off the top of my head:
    • it should be clear what the logo dimensions are (a square!), trying to use a rectangle really threw everything off. Instead of being a drop-in replacement, it had to be tested, adjusted and readjusted. This is documented at mw:Manual:$wgLogos#Supported_variants. Whatever en.wp docs we have should point to that.
    • There was already a Phabricator ticket that was open, I think bumping that or asking in #wikimedia-operations on IRC should have been the first venue before trying to do a local CSS hack.
    • intadmins should be cognizant of the performance implications of adding an image to unconditionally load on every page view. logos are heavily optimized and compressed to save on readers' bandwith and then heavily cached, unlike Commons images.
    • finally, if it wasn't possible to get a fix deployed before the weekend, I think it's up to tech ambassadors to communicate that for site stability, we don't tend to do deploys over the weekend and it just has to wait, like other low impact bug fixes do. While the logo is very visible, I genuinely don't think the difference between option D and A was that urgent. Legoktm (talk) 06:04, 23 January 2021 (UTC)
  • At the risk of sounding like an asshole, I want to vent a little about this process in the hopes that articulating the pain points will improve our documentation and ideally make this process easier so that we can try to do these things more often. Most of all I wish that we had more institutional support from the WMF. This isn't to piss on those who helped me and others--I'm incredibly thankful for all the work WMF staff have put into this initiative--but at the same time most people involved in this had absolutely no clue what we were doing, and rarely did I receive support beyond links to documentation. If at any point during January 15th I had prioritized my paying job over my volunteer work, this likely would not have happened. I feel confident saying that, because look what has happened over the last week when I prioritized my paid labor. Again, this is not to piss on people who picked up the slack--every single one of you is going to get a barnstar for what truly has been an amazing community effort--but unlike you, Legoktm, the WMF hasn't paid us a dime for our contributions so it is incredibly difficult for me to feel bad that you had to do your job during work hours. Truly, I'm sorry you had to resize the logo on a Friday afternoon, I know how frustrating that is because I did it multiple times last week, provided a CSS hotfix for the monobook skin, and took the day off from my job so that I could work synchronously with the WMF deployers in order to get this up and running. This isn't meant to be a woe-is-me complaint either, this is to point out the abject failure of the WMF to support its flagship wiki in what is perhaps the simplest change a website could make on its anniversary, and to contextualize the present situation where an (off-duty) WMF employee is on the noticeboard chastising the community for doing its best in that situation. I'm sorry you were put out and had to drop what you were doing to handle this, seriously, I know how that sucks and can ruin a day, but join the fucking club, eh?
    The 20th anniversary was not a surprise and the WMF had been working on this for at least a month. The most support I got in designing the logo was a link to their resources on Meta. I got next to no feedback from the WMF or the community so I wasn't going to waste my time moving forward. When there was community interest (a day before the anniversary), I started an RfC, made live changes to the logo during the discussion, read documentation on how to implement the change, submitted a patch on Gerrit, and fixed the site CSS. To the best of my knowledge the only person who got paid to help me in any of that was James who compressed the images and deployed the patch. It's quite honestly absurd that no one from the foundation worked more closely with us to make this process go smoothly. The community would not have implemented this CSS hack if any of the dozen subscribers to Mz7's phab ticket took more initiative. This is not to shift blame, I'm one of those subscribers and certainly could have done more; hell, maybe many others were in the same boat as me with minimal time to devote. But the fact of the matter is that it was two days and multiple dev comments before anyone used the SVG I provided to fix the problem--now it seems like the only reason it happened was because we broke something while trying to work around the collective inaction. IMO, it's a good thing we lit a fire under you: for once the community actually sided with the WMF and worked to be consistent with its global branding, and when we asked that it promptly be changed after the campaign, we faced the prospect of our community consensus being ignored for nearly a week. That is the perfect recipe for further alienating the community.
    I'm sorry if this comes across as harsh, but truly this has become one of the worst initiatives I've participated in on Wikipedia, and as one of the primary actors I want to make it crystal clear that the devs are not the only people "annoyed/frustrated/disappointed" at all of this. This is one of the few times on this project that I have ever felt truly abandoned, entirely listless, in an endeavor and the cause was not the community. There was minimal support. Documentation was confusing, hard to find, and at times contradictory (e.g., the MediaWiki documentation we followed did not coincide or even apparently link to the Meta documentation). I say this out of frustration, not out of sincerity, but this has made me not want to volunteer my time or energy to benefit a WMF campaign again. I think this was a wonderful thing for the community to do, and I wish we could showcase community work in the logo spot more often for more project milestones. Sincerely, I hope to see the community come together for initiatives like this more often, I hope the WMF hires more artists to make copyleft media for projects to use, I hope the devs continue to help editors new to this process navigate it. But speaking personally I doubt I'll take point on a similar campaign in the future without significant changes to the process, it's clear the return on investment is simply too low. — Wug·a·po·des​ 03:38, 23 January 2021 (UTC)
    • Just to clarify, I wasn't working, this was my volunteer/free time too. I was reading Wikipedia and the logo was cutoff on Timeless and I went investigating. So, I basically agree with all of your complaints about the technical process around this. It's a nightmare and needs to be improved. It genuinely should not be this hard to change the logo and I'll do my best to make sure no one else has to go through the experience we both just went through. Legoktm (talk) 06:04, 23 January 2021 (UTC)
      • Thank you, and I really do mean join the club! After all, Barns aren't raised in a day...well, sometimes they are...but certainly not without splinters :) It's absurd that we had to break things to get something done. That's just not a healthy working relationship between organizations, and it especially sucks for people like you who get caught in between them. I'm glad you're excited to work on improving the documentation, I hope to spend some time compiling all of the CommunityLore I learned along the way.
        If it helps incentivize anyone to keep barn raising, I think it would be nice if we could set up Wikipedia:Requests for celebratory logos or something and start a process to request logos for a day, similar to Google doodles. We could even link directly to an article, or some kind of splash page like we did with Wikipedia:20th anniversary from the main page banner. Making it easier for the community to change the logo would also help us create opportunities for professional artists to contribute to Commons (similar to c:POTY) by advertising it as an opportunity to showcase original renditions of the Wikipedia puzzle globe. We could even try to get a grant to hire artists and get a set of images to use for the first few months while it gets off the ground.
        Even on the technical side it might help create a pipeline for recruiting MediaWiki developers and devops volunteers. Lots of main page editors are technically savy, but rarely make it farther than phabricator on their own. If we could more easily use the logo as a community space, it could provide a structured introduction to Gerrit patches and working with wikimedia-operations so that they might eventually seek sysadmin permissions to make their job here easier (and also your jobs over there). Even if not, it will increase the presence of Gerrit on enWiki and might get some new faces working on bugs. It might even help justify to MediaWikians why a more familiar code review interface would help recruit new contributors.
        So yeah, I really mean it when I say that I hope we can do this more often, and that I'm excited you're also hyped to help. I think this is one of the best opportunities we have as a global community to build something nice for our readers that showcases a bunch of our projects. As frustrating as this has been (and Lego, I'm sorry for taking it out on you), the growing pains are worth it, and when I doubt that I go read some of the hundreds of well-wishes our readers left us this week to remind myself just how much our work matters--even the silly stuff. Many of them have even started contributing! — Wug·a·po·des​ 09:08, 23 January 2021 (UTC)
  • Sorry for sounding picky, but although now less blurry I think the logo's text is still quite hard to read at a glance, at least to my eyes. For example, the "over one billion edits" is much harder to read than the "Main page, contents, current events" etc list below the logo. Partially the font and partially the text size, I guess. The sub-text should probably be the same size as the menu links below it. I suspect the size is currently a MOS:TEXTSIZE vio but I'm not 85% sure. ProcrastinatingReader (talk) 20:52, 23 January 2021 (UTC)
    The source SVG I made in Inkscape is File:WP20 EnWiki20 SimplifiedLogo BillionEdits fixed.svg, based off of what Wugapodes made earlier if someone wants to make adjustments (I think you're probably right). You can use the new logo-test tool to see how it'll look in the Wikipedia interface. Legoktm (talk) 00:37, 25 January 2021 (UTC)

importScript on mobile

Let's keep the majority of the Next Steps and Identifying The Problems at WP:VPT; I'll copy some of this there. --Izno (talk) 19:06, 26 January 2021 (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.

Watchers of this page may be interested in WP:VPT#"An attempt to load a user script has failed". --Izno (talk) 01:11, 26 January 2021 (UTC)

Could an interface admin please disable the silly mediawiki:Mobile.js while that discussion happens? Scripts, tools and templates aren’t updated but we’re bugging mobile users about this, really? The problem is still at the stages of being fixed elsewhere. This notice is highly disruptive, sticky, large, and useless. Should be quickly reverted. ProcrastinatingReader (talk) 14:07, 26 January 2021 (UTC)
  • @Jon (WMF): seems instead of just letting things silently fail, we are now annoying contributors - is this needed right now? — xaosflux Talk 15:36, 26 January 2021 (UTC)
    • Disabled new script for now - additional discussion warranted, follow up at Wikipedia:Village_pump_(technical)#"An_attempt_to_load_a_user_script_has_failed". — xaosflux Talk 15:53, 26 January 2021 (UTC)
      • @Xaosflux: It might be better to leave an empty function declaration, rather than commenting the whole thing outright--Jon said on VPT that My main goal was to suppress a large amount of errors we're seeing from mobile users trying to load incompatible scripts. How you want to deal with that I leave up to you., and I think we should at least honor the main goal of eliminating the error. Writ Keeper ⚇♔ 15:58, 26 January 2021 (UTC)
        • @Writ Keeper and Jon (WMF): not opposed to that - the disable was a quick fix, and the main current complaint is the user alert, feel free to update to disable silently (I can't test from where I am right now, thus only did a full disable). — xaosflux Talk 16:03, 26 January 2021 (UTC)
          • I did this in parallel with the request here. --Izno (talk) 16:06, 26 January 2021 (UTC)
Empty function body is fine here for making sure the errors don't flood our logs, but obviously doesn't help with getting this fixed on the long term. For most scripts, the fix is for user scripts to stop running the code on mobile. Do we know how this code even got onto mobile? On other wikis, this has been because users edited Special:MyPage/minerva.js but here it seems that people had no idea how they loaded the code in question. Perhaps we need to review the MediaWiki:Gadgets-definition - it's possible some gadgets have been marked to mobile but don't work there which is why so many people saw the error. Jon (WMF) (talk) 16:36, 26 January 2021 (UTC)
Jon (WMF), it's not gadgets:
  1. User adds script to their common.js subpage
  2. User goes to mobile page
That's all that's needed, yeah? If it never produced a (visible) error or change, no end user would have known until now. ~ Amory (u • t • c) 17:27, 26 January 2021 (UTC)
(this.) I easily suspect this occurs rampantly - mobile view is still loading wiki:User/common.js and meta:User/global.js correct? Because these get polluted by tons of copypasta all the time by users that don't really know what they are doing - often importing scripts that then import more scripts as well. — xaosflux Talk 17:44, 26 January 2021 (UTC)
Indeed, common.js was my first thought. We've even suggested it be preferred for some time now just because most people expect their scripts Just Work Wherever. (Which they should.) --Izno (talk) 18:02, 26 January 2021 (UTC)
No. Mobile does not load common.js subpage. Instead it loads Special:mypage/minerva.js (or perhaps mobile.js - I can't remember the status quo). Perhaps it's originating in global JS from meta.wiki? That does load on mobile? Jon (WMF) (talk) 18:32, 26 January 2021 (UTC)
@Jon (WMF): I put something in my User:Xaosflux/common.js and it loaded on https://en.m.wikipedia.org/wiki/Main_Page as well as https://en.wikipedia.org/wiki/Main_Page?useskin=minerva. — xaosflux Talk 18:54, 26 January 2021 (UTC)
Perhaps you are thinking about the sitelocal common.js, not the sitelocal user:common.js ? — xaosflux Talk 18:55, 26 January 2021 (UTC)
Interesting. I guess we changed this sometime recently, but I can't remember why and when! Okay, well at least that explains this. User common.js runs on mobile. I guess the correct thing for users to do is to move that to their desktop skin JS, as this code throwing errors it definitely not common to all skins. :) Jon (WMF) (talk) 19:03, 26 January 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-01-28

The following interface administrator(s) are inactive:

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

I honestly don't see why the bureaucrats have left this self-grant alone that hasn't been used in A While. Even if OV still needs it, it should be positive affirmation on the point, not a "the bot will keep posting noise". Especially now that we have temporary grants, which look like they would have been sufficient then. Do they just not know? --Izno (talk) 01:39, 29 January 2021 (UTC)
@Izno: this grant was an WP:OFFICE action, not a self-grant (c.f. meta:Special:Redirect/logid/37140160), it is a temporary grant as well - and expires in 5 months. Of course if @OVasileva (WMF): doesn't need this anymore and would like to say so here, we can easily expire it out now. — xaosflux Talk 02:36, 29 January 2021 (UTC)
That's an OFFICE (capital letters) action? Pretty sure that's not what that policy/guideline is there for. Either way, it probably shouldn't have been EN only and then we wouldn't need to care. Moreover, the pages changed don't really bear out the reason for adding the group... --Izno (talk) 02:43, 29 January 2021 (UTC)
It's a WMF action at the least, not subject to community consensus, it wasn't enwiki only (see Special:CentralAuth/OVasileva_(WMF) - sort by groups) - and I'm assuming they went with what they thought was minimal, could have just been GIE which is much further reaching and we wouldn't be talking about this. — xaosflux Talk 09:10, 29 January 2021 (UTC)

Removing legacy javascript globals from skin pages

Prior reading: phab:T72470, Wikipedia:Interface administrators' noticeboard/Archive 2#Preparing for removal of Javascript globals, and recent VPT discussion

Using the list of most imported scripts, I have now replaced the usages for all users who haven't edited in >6 months, and notified all users who have been more recently active. There are many other scripts, but these should be the majority of what matters as far as scripts go, and so they will get handled one way or another in the near feature.

The overwhelming majority of uses, however, are going to come from user's skin pages. I've made a list of what I believe are all such pages using these deprecated globals, of which around 900 are editors who have edited in the last six months. That's clearly too many to notify without using MassMessage, so I'm asking here about progressing. I can do it manually — with AWB and regex, always with visual/manual confirmation as there are occasional petty issues — but... that's a lot. Probably worth discussing in the context of WP:BOTP. I think the thing to do is sort by skinname, starting with common.js (most likely to be in use) and then go from there. These are certainly the majority of the cases, so it'll need doing, whether by us or a GIE or staffer with less fanfare. Thoughts/blessings/concerns? I'd probably start by sorting by last edit date. I also think a pre-notice/head's-up to all at VPT would be warranted before beginning. ​​​​​​​​ ~ Amory (u • t • c) 20:31, 29 January 2021 (UTC)

@Amorymeltzer: like anything we'd see at BRFA there should be a good reason why some edits should be done at all, especially in user space, what do you think the best argument for that is? — xaosflux Talk 20:38, 29 January 2021 (UTC)
Well, they'll have to at some point. phab:T72470 has no timeframe, but I think it's a chicken-egg thing: can't be turned off while the counts are high without a ton of disruption, and if nobody ever fixes them then the counts will stay high. I think the best thing to do would be a MassMessage to the users, and then reassess what still needs doing after a week or three. Either way, if it's not done, it will get done by a GIE or a staffer at some point, almost certainly without any prior notice. Call it parochial, but since we have the means, I'd rather pages get edited by local folks with some notice ahead of time. ~ Amory (u • t • c) 20:45, 29 January 2021 (UTC)
The inevitability is the best reason, IMO. The other reason is that we'll keep having discussions like the recent one whenever a random Doodad stops working or Jon overzealously lets people know things are broken. --Izno (talk) 21:18, 29 January 2021 (UTC)
I think an entirely automated change would be suspect, but if you're clever enough to get around all the ways code can be done by users... (obviously possible like at Google but those are change request based anyway meaning a 2nd pair of eyes regardless, which is not the same as here).
As I continue to say, I much prefer just-fix-it, but if you want to MM people a note, go for it. (I looked at some of the messages today; you'll need to revisit those as I expect many of those people are busy with Other Things than deprecated notices.)
(Tangential: There is one benefit to messaging, and it's that you can let people know that certain scripts have gadget forms and those people should remove the non-gadget form. Another thing we can consider is migrating the big scripts without gadgets to gadgets before we start on that.)
I agree with attack path regarding skin order. common -> vector -> monobook -> timeless, and then any others. Work on active users before inactive users (though you can warn them all at the same time regardless). I will note that many common.js/css pages are actually (old) copies of Common.js/css from before common.js/css were made to be all-skins pages, which could be blanked (in some part) instead. --Izno (talk) 21:18, 29 January 2021 (UTC)
clever enough to get around all the ways code can be done by users... I think this is an aside, but I'm not really sure what this means. ~ Amory (u • t • c) 12:20, 30 January 2021 (UTC)
I’m not Izno, but I can think of 
function foobar() {
	if (false) {
		var wgPageName = 'foobar';
	} else {
		console.log(wgPageName);
	}
}
that should not be touched (wgPageName is a local variable here with the value of undefined), while for example 
var x = window,
    prefix = 'wg',
    name = 'pageName';
console.log(x[prefix + name[0].toUpperCase() + name.slice(1)]);
does use the deprecated global. —Tacsipacsi (talk) 23:24, 30 January 2021 (UTC)
Experience linting the wiki has taught me that users will find endless ways to do something you don't expect. It's just general pessimism on my part. ;) --Izno (talk) 05:21, 31 January 2021 (UTC)
Indeed! Thankfully(?) some of them are fairly repetitive, so when you've seen on VOA/morebits/advisor/etc., you've seen 'em all... As for your example Tacsipacsi, yeah, I do detect those. They stand out visually which, so I know clearly when I'm in one of those situations. ~ Amory (u • t • c) 15:27, 31 January 2021 (UTC)
Indeed, JavaScript deprecations like this get fixed by GIEs and staff all the time without advance notice. The users surely prefer their personal JS staying in a working state... so I'm not worried about any unwanted changes, provided we confirm each and every change is correct before saving, as you say. If you wanted to send a MassMessage that's fine but I don't think it's necessary. These seem like procedural fixes best executed without pestering users, most of whom presumably are not JS-savvy and probably copied the code from somewhere else. A heads up at VPT seems more than fine, and you could link to that in the edit summary. — MusikAnimal talk 21:20, 29 January 2021 (UTC)
Very much agreed with what Musik said. Enterprisey (talk!) 00:26, 30 January 2021 (UTC)
+1, just make sure the edit summary is informative. If a mass-message is sent out beforehand, make sure to say that no action is actually required by non-tech-savvy users since they will be fixed by (semi-)automated means. - Evad37 [talk] 00:45, 30 January 2021 (UTC)
So, from everybody above, basically: post at VPT, give it a few days or a week or so, then (barring objection at VPT) go ahead with, as always, a nice edit summary. Yeah? Breaking it up by skinname makes it pretty easy to do in bunches, and those end up being not too big. @Xaosflux: I know you're not wild about any of this, but does this sound reasonable to you? ~ Amory (u • t • c) 12:20, 30 January 2021 (UTC)

I've posted at VPT. ~ Amory (u • t • c) 22:09, 30 January 2021 (UTC)

Some notes as a GIE:

  • I composed a list of most used user scripts (based on traffic) and have been cleaning those but I was asked to stop in User talk:Ladsgroup#Removal of globals. It already shows big drops in number of global variable's loading. Should I continue?
  • The process is semi-automatic for me. I find them by the bot and it shows me a diff and I either approve/reject/ask for a bigger diff/edit and it's based on pywikibot and I think it should be semi-automatic (I know it's tedious as hell). For that reason, I actually do one variable at a time (I know it's annoying to have lots of edits instead of one but it would highly reduce the chance of me making mistakes and breaking users scripts).
  • If we are going to clean skin.js, we should reuse that list to clean importScriptURI as well. With a really precise regex (something like ^importScritpURI *?\( *?['"]https://(.+?)["'] *?\)$ we can fix most of those automatically. (I write one shortly).

HTH Ladsgroupoverleg 11:02, 30 January 2021 (UTC)

As noted above, I've now notified folks. I plan on giving folks a week or so then doing it myself; maybe revisit after that? I don't have access to your traffic results, so at that point it'd be good to compare/continue. As for importScriptURI... I don't disagree, but that's a slippery slope to we might as well do importScript, addOnloadHook, addPortletLink, etc. Gets complicated quick, and that discussion's semi-ongoing. Tourbot already handles some (all?) of those, so I planned for that to be my next crusade after this. ~ Amory (u • t • c) 12:20, 30 January 2021 (UTC)
To be clear, I've been vocal on this type of subject before - I'm not opposed to us going around and "fixing" some of these or even commenting our sections that are broken on User:xxx/x.js pages; agree that sending out notifications, and a hold period before proceeding is prudent. For long inactive users, disabling old scripts may be even better then trying to repair - these users may never return and it just adds more technical debt for whenever this comes up again in the future.
The importScript deprecation is a larger question for sure that deserves more continued discussion if we are going to make basically an "alias" for it.
What I'm most opposed to is trying to maintain personal scripts that are imported by others and would prefer that those "most used" scripts get moved to a more formal community maintained area (e.g. MediaWiki:xxxx.js) perhaps we make a naming convention and start doing this (e.g. MediaWiki:Userscript-Name.js) and more formally adopt the ongoing maintenance? (start each one with a disclaimer that though it is considered "safe" it isn't otherwise warranted)? Just spitballing here, thoughts? — xaosflux Talk 12:39, 30 January 2021 (UTC)
I'm not saying we should maintain user scripts but I want to mention that now errors and warnings get sent to logstash and grafana. So if a user script is getting lots of usage, any breakage on it will end up spamming our monitoring system. And for warnings, having lots of them show up in graphs prevents us from removing those deprecated code which would bring performance improvements to all of Wikipedia readers. So I'm highly in favor of small fixes that might look like maintaining those (but in reality it's not, it's just reducing warning spam in our system). Ladsgroupoverleg 13:01, 30 January 2021 (UTC)
Popular ones should be gadgets. We assume the same amount of work by moving it to MediaWiki space but gain none of the benefits of making a thing a gadget. --Izno (talk) 17:23, 30 January 2021 (UTC)
Agree, if gadgetizing - perhaps remove the old links and message the includers that they need to opt-back-in via preferences? — xaosflux Talk 17:36, 30 January 2021 (UTC)
We're off the original topic, but is it possible to get a good read on what scripts are actually being used on the reg? Ladsgroup, you say you've got that, right? That'd be useful for finding popular relied-upon scripts that aren't actively managed. Good targets. ~ Amory (u • t • c) 18:15, 30 January 2021 (UTC)
This is now largely moot as to importScriptURI as Ladsgroup this morning just went and replaced 600 or so pages that used importScriptURI. ~ Amory (u • t • c) 18:32, 30 January 2021 (UTC)

Missing nowiki tags in user scripts lead to strange template creations and protection requests

Could an interface administrator please add //<nowiki> to the top of the pages listed here?

https://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Template:(%3F:%22_%2B_projectData.inputTemplates.join(%27&hidelinks=1&hideredirs=1

Specifically, User:YuviPanda/AssessmentBar.js seems to be the source of this. The script includes templates like Template:(?:" + projectData.inputTemplates.join(', which have now been created by IN, and for which protection has been requested at WP:RFPP by IN as well. The actual solution is embedding the template code in nowiki tags, as advised at Wikipedia:User_scripts/Guide#<nowiki>_tags. I will decline the protection requests and intend to delete the templates as pages unambiguously created in error.

Please notify me when the transclusions have been removed. Thanks in advance, ~ ToBeFree (talk) 17:42, 20 February 2021 (UTC)

There is a lot of this. Ping Plastikspork and WOSlinker, who have been doing a lot of work to notify users. PS maintains User:Plastikspork/Script pages with missing templates/1, which is a way more conducive list. I went through a bunch of the folks who were inactive a little while ago, but I'm not sure how well the notifications have been responded to. ~ Amory (u • t • c) 19:03, 20 February 2021 (UTC)
As for the created templates, those should be deleted. ~ Amory (u • t • c) 19:03, 20 February 2021 (UTC)
Amory, I've been through Plastikspork's list and removed anyone who has edited in 2020 or 2021, and what is left is in User:WOSlinker/script_data, so you could update all of those without the need to notify anyone. -- WOSlinker (talk) 20:18, 20 February 2021 (UTC)

Bad clean up

@Ladsgroup: this is clearly not good :) Maybe when you folks are cleaning things up, you can add the the appropriate commented-out nowiki tags at the top and bottom of the pages? @Amorymeltzer and Izno: I have no idea how many of these there are! Thanks! Plastikspork ―Œ(talk) 23:00, 20 February 2021 (UTC)

Found some more here [2] [3] [4] [5] ... Just searching for username links in userspace found many of these, but that's just for inadvertent expansion of ~~~~ other inadvertent substitution would not be detected with such a search. Thanks! Plastikspork ―Œ(talk) 23:08, 20 February 2021 (UTC)
  • @Plastikspork: just to be clear, Ladsgroup is not an enwiki int-admin and is making these changes as a global interface editor. While we can forbid certain GIE's from using their access here - it needs to be for a good reason. Ladsgroup, can you explain why you are making those specific edits? These appear to be at best careless errors - please go through your contributions and revert any such errors as soon as possible. — xaosflux Talk 00:11, 21 February 2021 (UTC)

Hey, User:Xaosflux and User:Plastikspork. Thanks for reporting. First of all, these are technically not caused by my edits. It's because they haven't been touched fro really long time that mediawiki parser has changed and now any edits on those pages will cause a similar issue (my edits unearths the problem). Any edit on those will cause issues. Even purge would cause same issues. I'm already aware of the templates one and going through them one by one (User:Plastikspork/Script pages with missing templates/1) but wasn't aware of the signature ones. search says it's only eight pages and I'll fix them but if there's anything else I need to clean up, tell me and I find a way Ladsgroupoverleg 03:46, 21 February 2021 (UTC)

The signature ones are all cleaned up. Ladsgroupoverleg 04:51, 21 February 2021 (UTC)

@Ladsgroup: thank you for your response to this matter. — xaosflux Talk 05:47, 21 February 2021 (UTC)

wgArticlePath in afchelper gadget

The wgArticlePath variables in the afchelper gadget could do with updating to mw.config.get('wgArticlePath') if somebody fancied doing it. -- WOSlinker (talk) 18:25, 21 February 2021 (UTC)

Those are actually completely unused. They're the old version, the currently gadget is at MediaWiki:Gadget-afchelper.js (really a pass-through for User:Enterprisey/afch-master.js). I took care of everything in MW-space last year, but left that because I though they should be deleted or blanked rather than have a bunch of pointless edits made to them (cc ladsgroup). They're unused and unmaintained, and need not exist. ~ Amory (u • t • c) 18:50, 21 February 2021 (UTC)
That's on me; the script ought to be used from those pages, rather than userspace, and it would be faster besides. Tracking issue created. I'll blank those pages in the meantime. Enterprisey (talk!) 00:04, 22 February 2021 (UTC)
User:Amorymeltzer. I highly recommend keeping mediawiki namespace clean. The reason being is that if this gadget has XSS vulnerabilities (it happens), then it's vulnerability for ALL of enwiki (by using withJS= argument). So please either move them to user or wikipedia namespace if you see something like that. Ladsgroupoverleg 07:42, 22 February 2021 (UTC)
Sorry, what does that have to do with wgArticlePath? ~ Amory (u • t • c) 11:26, 22 February 2021 (UTC)
Nothing. It's just a general code hygiene request. Ladsgroupoverleg 19:10, 23 February 2021 (UTC)
Thanks Enterprisey; I've been meaning to bring it up again for half a year or something, keep forgetting. ~ Amory (u • t • c) 11:26, 22 February 2021 (UTC)

New script pages in Category:Pages using duplicate arguments in template calls

Three new script pages just popped up in Category:Pages using duplicate arguments in template calls.

Could someone put 

// <nowiki>

at the top and 

// </nowiki>

at the bottom of User:Hans2520/vector.js, User:Hans2520/WikiSocial.js, and User:Teraom/MyWikiSpace.js. These were all most recently touched by User:Ladsgroup. Thanks! Plastikspork ―Œ(talk) 18:58, 23 February 2021 (UTC)

 Done — xaosflux Talk 19:04, 23 February 2021 (UTC)

Bot request in relation to Int Admin rights

I have requested Int Admin rights for myself and my bot (request). Input is requested on both, though if I could get some eyes on the comment section of the actual request, that is my point in coming here. -- Amanda (aka DQ) 00:00, 25 February 2021 (UTC)

Nomination for merging of Template:Collapse bottom and Template:Hidden archive bottom

Template:Collapse bottom has been nominated for merging with Template:Hidden archive bottom. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. –MJL ‐Talk‐☖ 03:17, 28 February 2021 (UTC)

MJL, what does this have to to with interface admins? ~ Amory (u • t • c) 14:57, 28 February 2021 (UTC)
@Amorymeltzer: {{cob}} is used by MediaWiki:Protect-text, and while I know that all admins can modify that page, it is my understanding that such that interface messages are of more importance to interface admins than regular ones. –MJL ‐Talk‐☖ 18:55, 28 February 2021 (UTC)

Inactive interface administrators 2021-02-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:20, 28 February 2021 (UTC)

  •  Bureaucrat note:  Not done - WMF action, outside of community controls; will expire in a few months. — xaosflux Talk 00:26, 1 March 2021 (UTC)

Request for intadmin from Empire AS

Hello. I have recieved a request from Empire AS to add the wikibreak enforcer script to their common.js on enwiki. Their request is at meta:User_talk:Dreamy_Jazz#Last request. Please would an intadmin decide if this is appropriate to add to their common.js file, and if so please do add it. Dreamy Jazz talk to me | my contributions 19:55, 5 March 2021 (UTC)

 Not done @Dreamy Jazz: I'm not inclined to do this for a indef blocked sockpuppet here -- and they will likely end up getting unexpected results if they plan to use other projects. If they really want to, they could add that to: meta:User:Empire_AS/global.js. — xaosflux Talk 20:13, 5 March 2021 (UTC)
Xaosflux, sure. I'll let them know on meta. I did think that all the wikibreak enforcer script does is prevent them from sending emails on enwiki (as they have TPA revoked), so there was little need for it anyway. Dreamy Jazz talk to me | my contributions 20:16, 5 March 2021 (UTC)
@Dreamy Jazz: no concerns if you want to revoke enwiki email access on their block. — xaosflux Talk 20:19, 5 March 2021 (UTC)
I've asked if they would want their email revoked as a alternative to the enforcer script on meta. Dreamy Jazz talk to me | my contributions 20:34, 5 March 2021 (UTC)

Removal of wikibreak enforcer

I have taken many a months reflecting on how I can contribute better and would like to remove my wikibreak. Please do so at User:HeartGlow30797/common.js. — Preceding unsigned comment added by HeartatSchool (talk • contribs) 03:59, 19 March 2021 (UTC)

 Done — xaosflux Talk 21:59, 21 March 2021 (UTC)

Removal of wikibreak enforcer

I would like my wikibreak enforcer removed at User:IronManCap/common.js so I can have more flexibility with regards to wikibreaks. 2A00:23C7:5EA2:D000:742C:E510:684E:229A (talk) 20:38, 21 March 2021 (UTC)

 Done — xaosflux Talk 21:59, 21 March 2021 (UTC)

Request

Please remove the Wikibreak Enforcer script from User:JJPMastest/common.js; my test to see if I could bypass it using &safemode=1 didn't work. JJP...MASTER![talk to] JJP... master? 11:59, 25 March 2021 (UTC)

The editor was able to do this themselves. — xaosflux Talk 11:53, 20 April 2021 (UTC)


Inactive interface administrators 2021-03-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:20, 28 March 2021 (UTC)

Hi, MusikBot II is an active interface admin which under policy means I must possess the rights, too. I actually have global-interface-editor rights anyway (as well as being a steward), but I'm assuming the local flag is still desirable. That said I recognize I have not done much interface admin-y things as of late. If it means anything, I was just about to make some sitewide CSS changes, pending consensus for it. I can try to help with protected edit requests, too. But please let's allow my bot to keep running :) — MusikAnimal talk 23:53, 28 March 2021 (UTC)
@MusikAnimal: thanks for the note, as edits made by your bot are extensions of edits made "by you", I'd say you are not "inactive". An easy way to get yourself off this list is to make even a trivial or comment-only edit, for example to User:MusikBot II/GeonoticeSync/Test geonotice.js. — xaosflux Talk 00:13, 29 March 2021 (UTC)

Unmatched content model

Please change the content model of User:WikiMasterGhibif/editCounterNoAlert.js into JavaScript. Currently the script is imported by about a dozen people and anyone can edit it, which seemed like a security risk but the script isn't being loaded anyway because the MIME type doesn't match. Nardog (talk) 04:47, 10 April 2021 (UTC)

 Done @WikiMasterGhibif: this has been updated. — xaosflux Talk 08:45, 10 April 2021 (UTC)

Tabs Extension

Hi! Not sure if this is the right place to ask, but I was looking for a way to add in-page tabs to a page and was surprised when I couldn't really find anything, since this is a pretty basic and very useful tool for editing. I found the [Wikimedia Tabs] extension, but when I checked Special:Version to see if it's been installed I couldn't find it there. If it's not installed or if something similar (another method to create tabs that I'm not aware about) doesn't exist, then I wanted to know if it's actually possible to request installing this extension and if this is the right place to request it.

Thanks OUT 23:53, 21 March 2021 (UTC)

It is possible, but it needs community consensus. We've previously discussed it (sometime in the past year or two) and there was not consensus at that time. This is regardless the wrong place to discuss it; you will want WP:VPPRO or WP:VPT. Izno (talk) 00:05, 22 March 2021 (UTC)
Thanks, will submit a proposal there. OUT 01:34, 22 March 2021 (UTC)

Special:WantedTemplates

First batch

Hi, the list in Special:WantedTemplates will be regenerated in about 5 days, and I have compiled a list of all the .js and .css pages that are creating entries in that list (see User:Plastikspork/Script pages with missing templates/1). The simple nowiki fix is described in this thread above. Many of these popped up recently due to re-parsing of the page after other script maintenance [6] [7] [8] ... The more of the pages that can be fixed in Special:WantedTemplates the easier it will be to see the real problems when the page is regenerated. Thanks! Plastikspork ―Œ(talk) 21:18, 15 March 2021 (UTC)

Plastikspork - Are you asking for all pages in this list to be encapsulated with //<nowiki>...//</nowiki> at the very top and bottom of each script page? ~Oshwah~(talk) (contribs) 04:48, 17 March 2021 (UTC)
Oshwah, yes, just like this edit. Any reduction in the number of pages on that list will make it easier to find the real problems in Special:WantedTemplates. Thanks again! Plastikspork ―Œ(talk) 13:59, 17 March 2021 (UTC)
 Doing... — xaosflux Talk 11:00, 24 March 2021 (UTC)
 Done @Plastikspork: not on your original timeline, but this should be done now. — xaosflux Talk 11:31, 24 March 2021 (UTC)
@Xaosflux: Thanks! It looks like most of them worked! My bot updated the page and there are still 19 left in User:Plastikspork/Script pages with missing templates/1, which is much less than the 290 that were there before. It looks like the trick didn't work in some cases where there were already <nowiki>...</nowiki> there. In some cases, this is fixed by matching up the <nowiki> tags in the comments. In other cases, this can be fixed by using // <syntaxhighlight lang=js> ... // </syntaxhighlight> instead (assuming those tags aren't there already). In any case, Special:WantedTemplates is more manageable now, so fixing these is less critical (but still would be nice to have a clean list). Thanks again! Plastikspork ―Œ(talk) 13:35, 24 March 2021 (UTC)
@Plastikspork: feel free to ask those users to make the specific updates on their base talk pages. — xaosflux Talk 13:39, 24 March 2021 (UTC)
@Xaosflux: Sure, I will ask them to fix your edits. Thanks again. Plastikspork ―Œ(talk) 13:48, 24 March 2021 (UTC)
@Plastikspork: wait I missed somthing, did you want me to just REMOVE the nowiki wrappers I added on those pages? I'll do that. — xaosflux Talk 13:50, 24 March 2021 (UTC)
Do you have a list of the ones you want me to undo? — xaosflux Talk 13:51, 24 March 2021 (UTC)
That is, all of these, or just a subset? (User:Plastikspork/Script pages with missing templates/1). — xaosflux Talk 13:51, 24 March 2021 (UTC)
@Xaosflux: I just want you to change the // <nowiki> ... // </nowiki> that you added to // <syntaxhighlight lang=js> ... // </syntaxhighlight> for the 19 pages listed in User:Plastikspork/Script pages with missing templates/1. If that's not possible, I will ask the page authors individually. Thanks! Plastikspork ―Œ(talk) 13:56, 24 March 2021 (UTC)
@Plastikspork: OK, I've undone my edits on that short list, feel free to contact those users for the change you are suggesting. — xaosflux Talk 14:09, 24 March 2021 (UTC)

Another list

There's a list at User:WOSlinker/script_data of some that need doing. -- WOSlinker (talk) 18:29, 17 March 2021 (UTC)
@WOSlinker: does this still need to be done? If there was overlap with the first list, can you regenerate? — xaosflux Talk 11:31, 24 March 2021 (UTC)
I've checked and they've all been done. Thanks. -- WOSlinker (talk) 12:52, 24 March 2021 (UTC)

Requesting update of User:RedWarn/.js

The holder of the RedWarn account, Ed6767, is currently unavailable due to personal circumstances. Since the RedWarn team can't access the RedWarn account (per WP:ROLE), I'd like to request User:RedWarn/.js to be updated with the content from https://redwarn.gitlab.io/redwarn-web/redwarn.js, which is the output of the latest pipeline build on the RedWarn repository on GitLab. Thank you! Chlod (say hi!) 17:34, 26 March 2021 (UTC)

Confirming. ✨ Ed talk! ✨ 17:35, 26 March 2021 (UTC)
{{doing}} reviewing. — xaosflux Talk 20:10, 26 March 2021 (UTC)
this is a lot of difference to unpack, will have to get back to this when I have more time (or someone else could pick this up). — xaosflux Talk 20:12, 26 March 2021 (UTC)
Apologies for the giant chunk of changed text - it's mostly due to how the build script compresses the CSS in order to decrease file size. The changes made are documented on GitLab, which can be accessed here. The changes consist of the following commits:
Please ignore any changes to release/redwarn-web.js, as this is just a development artifact that no one has got around to removing yet. Thanks! Chlod (say hi!) 20:21, 26 March 2021 (UTC)
 Done — xaosflux Talk 00:36, 29 March 2021 (UTC)
@Xaosflux: Sorry to bother you more, but 13be6005 accidentally introduced a crashing bug in the code, I have pushed commit 69402f5a6f34ada28c6f73c69c3ba9a83cde2e7a that should fix it. The build artifact is here: https://redwarn.gitlab.io/redwarn-web/redwarn.js Thanks for your help! ―sportzpikachu my talkcontribs 02:46, 29 March 2021 (UTC)
eraser Undone @Sportzpikachu: this has been reverted. Please follow up at User talk:Ed6767 for more updates to this personal user script. — xaosflux Talk 10:04, 29 March 2021 (UTC)

Requested CSS page to hide search data

I request a MediaWiki CSS page, e.g. MediaWiki:Hidesearchdata.css, with this: 

/* styling for use with custom ?withCSS links */
.searchresult, .mw-search-result-data {
  display:none;
}

The request is similar to #CSS page creation request. The purpose is being able to make a withCSS link which only shows the page names on a search results page. For example, Category:Pages with disallowed DISPLAYTITLE modifications says: "This search only displays articles in the category". withCSS=MediaWiki:Hidesearchdata.css could be added to the url. searchresult is the excerpt from the page. mw-search-result-data is the size and date. PrimeHunter (talk) 11:49, 29 March 2021 (UTC)

 Done @PrimeHunter: MediaWiki:Hidesearchdata.css created. — xaosflux Talk 13:03, 29 March 2021 (UTC)
Thanks! I have used it in Category:Pages with disallowed DISPLAYTITLE modifications and it works. PrimeHunter (talk) 13:12, 29 March 2021 (UTC)
If we're going to add too many more of these ad hoc MediaWiki CSS pages (which I do not think is a good idea btw), consider a template to keep track of them and/or link to them and/or link between them. --Izno (talk) 15:08, 29 March 2021 (UTC)
@Izno: Category:Wikipedia ad-hoc CSS pages maybe? — xaosflux Talk 15:17, 29 March 2021 (UTC)
I was actually planning to make a list for both withCSS and withJS, explaining how they work and give links and descriptions to those which are known. Pppery mentioned three JS at Wikipedia:Village pump (technical)#Linking to template result: MediaWiki:ExcerptTree.js, MediaWiki:G13-restore-wizard.js,MediaWiki:FileUploadWizard.js. The feature is described at mw:Snippets/Load JS and CSS by URL. The code is in MediaWiki:Common.js. PrimeHunter (talk) 16:23, 29 March 2021 (UTC)
FYI Wikipedia:Dispute resolution noticeboard/request uses ?with= resources. — xaosflux Talk 18:07, 29 March 2021 (UTC)
@PrimeHunter the output is ugly. if there's going to be whole MW css page for this, we can aim for better presentation. Maybe remove all the extraneous spacing and add bullets before page names? Adding something like this prettifies things to an extent:
.mw-search-result-heading a::before {
    content: "\u2022 "; /* bullet */
}
.mw-search-results li {
    padding-bottom: 0;
}
– SD0001 (talk) 11:08, 30 March 2021 (UTC)
@SD0001: It wasn't ugly for me but that's apparently only because I have enabled "PrettyLog" at Special:Preferences#mw-prefsection-gadgets. Your CSS gives me the string "u2022" displayed before the page name. PrimeHunter (talk) 12:16, 30 March 2021 (UTC)
There should be no u in the code, i.e. content: "\2022 ";. However, it’s still hackish, it’s much easier and nicer to just enable the native bullet points: 
.mw-search-results li {
	padding-bottom: 0;
	list-style: unset;
}
—Tacsipacsi (talk) 17:36, 30 March 2021 (UTC)

CSS page creation request

Please create a CSS page consisting of: 

h2, #output, .mw-htmlform-ooui-wrapper, .firstHeading  {
  display:none;
}

This is to be used for showing just the results of Special:ExpandTemplates. See WP:Village pump (technical)#Linking to template result for the discussion. My specific application is a tool to help DYK nominators and reviewers, but I can envision that the ability to provide a link for displaying the results of a template call could prove to be very useful in many situations. The title of the page doesn't matter to me; whatever the standard convention would be. MANdARAX • XAЯAbИAM 18:48, 28 March 2021 (UTC)

I guess this is a request for a gadget, since it is not possible to add arbitrary CSS other than to Common.css or relevant pages. The use is sufficiently niche that doing so there does not make sense to me. Izno (talk) 18:55, 28 March 2021 (UTC)
This. @Mandarax: what would you do with such a page? Say we created it at User:Mandarax/Mandarax's_special_css_page.css for example (which you can do right now), then what? — xaosflux Talk 19:05, 28 March 2021 (UTC)
@Xaosflux: It's meant for use with withCSS= URLs, to remove the clutter from pages like https://en.wikipedia.org/wiki/Special:ExpandTemplates?wpInput=%7B%7BConvert%7C2%7Cmi%7D%7D. Suffusion of Yellow (talk) 19:32, 28 March 2021 (UTC)
 Done OK MediaWiki:HidefirstHeading.css is created: @Mandarax and Suffusion of Yellow: — xaosflux Talk 20:06, 28 March 2021 (UTC)
Thank you very much! (And I imagine there'll be many uses for this beyond my immediate intentions.) MANdARAX • XAЯAbИAM 21:34, 28 March 2021 (UTC)
Could you please add ", #mw-indicator-mw-helplink" to clean it up by removing a question mark and Help link? The code should be:
h2, #output, .mw-htmlform-ooui-wrapper, .firstHeading, #mw-indicator-mw-helplink {
  display:none;
}
Sorry I neglected this issue in my first request. My immediate application is a tool for DYK nominators and reviewers. Without this addition, the result will be displayed with an irrelevant Help link for ExpandTemplates, which may confuse users who could think it's for DYK help. MANdARAX • XAЯAbИAM 18:20, 30 March 2021 (UTC)
 Done @Mandarax: If anyone else wants this modified, or to discuss it further, please open a standard edit request or discussion on the associated talk page. — xaosflux Talk 20:13, 30 March 2021 (UTC)
Thanks again! MANdARAX • XAЯAbИAM 20:22, 30 March 2021 (UTC)
Could someone please put an example of how this is used at MediaWiki talk:HidefirstHeading.css which would serve as documentation and a reminder for the future. Johnuniq (talk) 20:56, 30 March 2021 (UTC)
 Done. MANdARAX • XAЯAbИAM 06:30, 31 March 2021 (UTC)

WikEd patch for non-breaking spaces (2)

Hi,

Four months ago, I made a request here to add an option to User:Cacycle/wikEd.js.

It was initially rejected because Cacycle replied that they would have a look. However, I got not reply for two months (see the full discussion User talk:Cacycle#Edit request). Could you please reconsider it?

Note that last week, I told Cacycle that I intended to re-open this request and I asked if they had any objection, and they did not respond.

Summary of the original request: I would like this change to be applied to User:Cacycle/wikEd.js. It does not affect the behavior of the script on enwiki, but would allow me to remove the fork on frwiki.

Orlodrim (talk) 17:04, 12 January 2021 (UTC)

@Orlodrim: Cacycle is not inactive and can certainly manage their own personal user script if they want to (Cacycle, if you are fine with others editing your personal script let us know maybe?) - and as you already said you are free to fork, especially if you are on another project - making frwiki editors dependent on a single editor on enwiki is fragile. — xaosflux Talk 17:37, 12 January 2021 (UTC)
Editor user_talk notification of this discussion left. — xaosflux Talk 17:39, 12 January 2021 (UTC)
Cacycle may simply have no time or no interest in maintaining that script despite being occasionally active. I am not in a hurry, but I hope you will accept to take this request into consideration if they keep not answering.
I have support on frwiki to remove the fork. I believe that critical bugs on the original version will continue to be detected and fixed faster than what we can do on frwiki, because this user script is also proposed as a gadget on this wiki where it has a much larger userbase (40000 users here vs. 3000 on frwiki), and there are too few people to take care of javascript bugs on frwiki.
Orlodrim (talk) 18:37, 12 January 2021 (UTC)
As the source of one of our gadgets, I wouldn't call it a personal user script. (As such it should really be in the MediaWiki namespace.) Interface admins should be acting on edit requests for gadgets. — JJMC89 (T·C) 05:28, 14 January 2021 (UTC)
In 2 10 weeks, Cacycle did not react to my request or to your notification. Would it be possible to apply the change?
I adjusted the diff link to take into account another fix done by someone else in the meanwhile.
Orlodrim (talk) 17:44, 26 January 2021 (UTC) 11:29, 27 March 2021 (UTC)
Is nobody willing to do this unless Cacycle says "yes", or is it just that my change seems useless for the English Wikipedia so nobody is interested in applying it, or is it something else?
Orlodrim (talk) 10:42, 27 March 2021 (UTC)
Okay, squeaky wheel, give me a minute to find the oil. Izno (talk) 15:09, 27 March 2021 (UTC)
 Done Izno (talk) 15:12, 27 March 2021 (UTC)
Thanks a lot! It works. Orlodrim (talk) 09:53, 11 April 2021 (UTC)

A pair of banner hiding gadgets

Do we still need:

  • Suppress display of fundraiser banners
  • Suppress display of CentralNotices

in gadgets? We have a spiffy new banners tab in preferences these days. Izno (talk) 23:48, 1 April 2021 (UTC)

@Izno: well, suppose the fundraiser one could be migrated - but people would need to go opt-out of the notice since it is on by default. As far as the other one, the preferences doesn't let you turn off "important" types of notices (or I'm assuming malformed notices that don't declare one of these types) so the second could still be useful. — xaosflux Talk 08:47, 10 April 2021 (UTC)
The fundraising gadget can definitely be deprecated. I don't think the fundraising team have run fundraising banners to logged in users in nearly a decade and the new preferences handle not just WMF fundraising but also tax campaigns by affiliates. The new preference needs two more categories added and once that is done I would encourage people to migrate to using preferences and we deprecate . There are clear advantages to the preferences option and one of the reasons it got built was to allow people to be more selective on what banners they could ignore, it also exists everywhere. Broadly speaking the only real exceptions that cant be opted out of are maintenance banners, and rare instances involving all logged-in users such as a significant terms of use change. Seddon talk 10:34, 20 April 2021 (UTC)
@Seddon: also, of all the banners the fundraising ones if used are most likely to properly declare their type. As far as deprecation goes though, the preference requires an "opt-out" action, so at the least we'll want to somehow let our users know, we have 28,314 users using it now - see next section for some ideas. — xaosflux Talk 11:46, 20 April 2021 (UTC)

About deploying StructuredCategories in English Wikipedia

Dear all,

I have recently developed a new tool that returns a structured description of a given Wikipedia Category based on the Wikidata Statements involving its direct members. This tool is called StructuredCategories and is described at d:Wikidata:Structured Categories. I ask this tool can be deployed in English Wikipedia and added to Preferences as a Gadget. The source code of this JavaScript tool is available at meta:MediaWiki:Gadget-StructuredCategories.js.

From a technical point of view, the deployment of StructedCategories includes:

  • Pasting this code mw.loader.load('//meta.wikimedia.org/w/index.php?title=MediaWiki:Gadget-StructuredCategories.js&action=raw&ctype=text/javascript'); in MediaWiki:Gadget-StructuredCategories.js.
  • Writing a translation of StructuredCategories: provide a structured description of a category based on Wikidata statements involving its direct members in MediaWiki:Gadget-StructuredCategories.
  • Adding the tool as a Gadget.

I ask if this is possible. — Csisc (talk) 21:49, 20 April 2021 (UTC)

@Csisc: hi again! This could certainly be possibly, however we are usually a bit picky about adding new gadgets. I suggest you first offer it as a tool that users can test in their userscripts, and you may advertise that at WP:VPM. For the page that needs to be translated first, you can ask for a volunteer on that page as well. Once ready and tested, you can propose we add it as an opt-in gadget by starting a discussion at Wikipedia:Village_pump_(technical), if it shows a consensus to add one of our interface-admins will activate it. — xaosflux Talk 22:52, 20 April 2021 (UTC)
xaosflux: Excellent idea. I already started a discussion at Wikipedia:Village pump (technical)#About deploying StructuredCategories in the English Wikipedia. However, advertising the tool at WP:VPM is an excellent idea. I will apply it. --Csisc (talk) 01:09, 21 April 2021 (UTC)

Preview warnings and hatnote TemplateStyles

Pages watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles. Izno (talk) 01:08, 23 April 2021 (UTC)

Deprecating a script/gadget

So I've been thinking about this for a little while, and wanted some ideas on a standard. We have multiple instances where we want to turn down a user script or gadget that is in use because a replacement is available (like the example above of a gadget->preferences migration; but also when we have a userscript->gadget migration). These require an opt-in preferences action from our users. Would like to have some repeatable, standard-ish way to notify them - perhaps a banner/popup/etc that can be put on their "old" script during a transition period. Open for ideas and samples here if anyone has already done some of this? — xaosflux Talk 11:46, 20 April 2021 (UTC)

Can’t gadgets turn on the new preference and then turn off themselves? Preferences (including enabled gadgets) can be modified through the API, to which gadgets have access. Of course this doesn’t work for user script→gadget migration and can happen only when the gadget actually loads, so inactive users will still have the gadget enabled, but it would provide a seamless gadget→preference (or gadget→other gadget) transition for somewhat active users. —Tacsipacsi (talk) 12:06, 20 April 2021 (UTC)
Gadgets do not run on Special:Prefs for security purposes. Gadgets with configuration store them in local JSON or similar. Izno (talk) 14:17, 20 April 2021 (UTC)
That’s true, but my proposal was to use the MediaWiki action API, which would mean (if it works) that the user wouldn’t even have to visit their preferences, the transition script would run on any other (non-restricted) page. —Tacsipacsi (talk) 17:39, 20 April 2021 (UTC)
@Tacsipacsi: do you have any proof of concept code for this? As you are an int-admin on huwiki I can add you as one on testwiki if you want to try there (ping me at testwiki:user talk:xaosflux). — xaosflux Talk 19:12, 20 April 2021 (UTC)
Take a look at User:AzaToth/twinkle.js; it takes the former (ancient!) home of a userscript and enables the gadget if not enabled. ~ Amory (u • t • c) 19:39, 20 April 2021 (UTC)
@Amorymeltzer: thanks so that is good for userscript-->gadget (and once that has time to bake in we can remove the known imports); got one for script/gadget --> preference? — xaosflux Talk 23:09, 20 April 2021 (UTC)
Same thing: gadgets are a "preference" with a specific naming structure. Any other preference can be done the same way, presuming the value is valid. So, for example, something like new mw.Api().saveOption('skin', 'modern'); would change your skin preference (for the better). ~ Amory (u • t • c) 23:53, 20 April 2021 (UTC)
Exciting. I can think of some scripts currently imported that really should move users to the gadget version. Izno (talk) 03:30, 21 April 2021 (UTC)
Indeed this trick is quite underused in practise. I suggested it for twinkle and also for Prosesize when it became a gadget. It's a good way to migrate users without annoying them with pop-ups or banners, but not good to keep around long-term (makes it difficult for users to disable the gadget when they want to – the script would enable it back!) Ideally I would say put it in place for 6 months then remove – anyone who logged in to their account in those 6 months would be migrated. – SD0001 (talk) 07:57, 21 April 2021 (UTC)
  • Hmmm, so looking at HideFundraisingNotice[ResourceLoader]|HideFundraisingNotice.css looks like to pull this off we would need to add an additional .js file to this gadget, but then that could set the preference ("centralnotice-display-campaign-type-fundraising": 0,), then potentially turn itself off ("gadget-HideFundraisingNotice": "0",) right? — xaosflux Talk 23:31, 22 April 2021 (UTC)
    @Xaosflux: Yes. Can be done with a single API call: new mw.Api().saveOptions({ "centralnotice-display-campaign-type-fundraising": 0, "gadget-HideFundraisingNotice": "0" }) (used saveOptions instead of saveOption). – SD0001 (talk) 13:18, 26 April 2021 (UTC)
OK, will test out on testwiki then I think the fundraising supress gadget-->preferences is a easy product case; any objections? — xaosflux Talk 13:43, 26 April 2021 (UTC)
I'm on board with this. Let me know if I can assist at all. Seddon talk 00:21, 27 April 2021 (UTC)

warning and success classes

Page watchers may be interested in WP:VPT#Tech News: 2021-18 regarding the warning/success classes, which are used some 20 times in Javascript pages. Izno (talk) 18:07, 3 May 2021 (UTC)

Inactive interface administrators 2021-04-28

The following interface administrator(s) are inactive:

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

For the record I removed Olga's rights since they were no longer needed anyway. Joe Sutherland (WMF) (talk) 21:15, 7 May 2021 (UTC)
Thank you, — xaosflux Talk 22:15, 7 May 2021 (UTC)

CSS at Unicode block article

An IP made a request at Unicode block which an interface admin might be able to resolve best. They're asking about changing the fonts used by the inline CSS and also suggesting the implementation of a class. It seems sane, but I still read Wikipedia in comic sans so best for someone else to take a look. — Wug·a·po·des​ 22:06, 14 May 2021 (UTC)

Suggested they use templatestyles there. — xaosflux Talk 22:26, 14 May 2021 (UTC)

T&S and interface admins

Tracked in Phabricator
Task T282624

Page watchers may be interested in WP:BN#T&S and interface admins. Izno (talk) 23:48, 11 May 2021 (UTC)

Local impacts

This should have little direct impact, initial thoughts:

  1. A community request and discussion that satisfies our policy to grant int-admin will still be required, it will still need to be closed locally, but then it will need to get posted over at meta to action. This will introduce a little delay in to the process.
  2. Resignations of only int-admin will need to be made by the int-admin at meta-wiki.
  3. Inactivity removals will need to be reported on meta-wiki for processing
  4. Other policy based removals would need to be requested over at meta-wiki as well

So we'll need to make a few procedural updates to our processes. — xaosflux Talk 01:05, 12 May 2021 (UTC)

May need to determine if other then self-resignations, we will require 'crats to "close" such discussions still and/or be the meta requester. — xaosflux Talk 01:14, 12 May 2021 (UTC)
The way it's handled with OS and CU rights, an arb has to make the request. I think having 'crats do this makes sense for basically the same reasons,and it would follow from that that they should also close the discussions. Beeblebrox (talk) 22:37, 14 May 2021 (UTC)

css request at MediaWiki talk:Filepage.css

Hi can another int-admin have a look at this, I'm getting "involved" now. — xaosflux Talk 00:30, 4 June 2021 (UTC)

Heads up for CSRF token change

I imagine most people this affects have seen it already, but just in case, I'm giving this more visibility. If you run code that uses CSRF tokens, you'll need to know about this change. -- RoySmith (talk) 16:34, 2 June 2021 (UTC)

Mediawiki JS pages using these tokens @Ragesoss. Apart from the guidedtours, MediaWiki:Gadget-commentr.js also uses intoken but that appears to be an unused test created by @The wub. – SD0001 (talk) 09:16, 3 June 2021 (UTC)
@SD0001 Oh wow, I had forgotten about that experiment. I think it can be safely deleted now, it was never actually used. the wub "?!" 09:34, 3 June 2021 (UTC)
And here are the userspace scripts sorted (roughly) by the usage counts. Popular ones include CSD-helper (@Ale jrb), Capricorn (@Wugapodes), DiscussionCloser (@DannyS712), several by @Writ Keeper, and many others ... – SD0001 (talk) 09:33, 3 June 2021 (UTC)
@SD0001: Thanks for the ping - I knew about the issue as a mediawiki developer, but didn't realize it would impact me as a script developer too - I should have time to fix it before the change gets deployed DannyS712 (talk) 09:40, 3 June 2021 (UTC)
Ah interesting, I'd completely missed this. Thanks! Ale_Jrbtalk 11:05, 3 June 2021 (UTC)
@SD0001 and RoySmith: Thanks much for letting me know! I've just updated the Wiki Education guided tours to CSRF tokens (and to use `rvslots`, to address another deprecation warning); all the adjustments looked basically like this. It looks like this probably affects The Wikipedia Adventure as well (@Ocaasi).--ragesoss (talk) 19:33, 28 June 2021 (UTC)

Dark mode/Green & black

A user wrote in (ticket:2021071910002231) that they tried enabling both gadgets, "Use a black background with green text" and "Dark mode: Use a light text on dark background color scheme", and after saving it, lost sight of their preferences link. Perhaps both options should be presented adjacently with an EITHER/OR message? Cabayi (talk) 17:51, 19 July 2021 (UTC)

@Cabayi: the ticket looks resolved, is it safe to assume that specific user was able to fix themselves? — xaosflux Talk 18:08, 19 July 2021 (UTC)
xaosflux, he hovered over where he thought preferences ought to be and got lucky. He seems happy with where he's at. Cabayi (talk) 18:16, 19 July 2021 (UTC)
@Volker E. (WMF): for "dark-mode". This is currently in the 'testing' section of gadgets, we could easily move it to the appearance section and put a description note on each to not use together? Any concerns? — xaosflux Talk 18:08, 19 July 2021 (UTC)

Inactive interface administrators 2021-07-28

The following interface administrator(s) are inactive:

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

 Done — xaosflux Talk 23:22, 28 July 2021 (UTC)

Edit filter false positive needing i-admin attention

See Wikipedia:Edit_filter/False_positives/Reports#NguoiDungKhongDinhDanh. Taking Out The Trash (talk) 18:43, 30 August 2021 (UTC)

 Done dealt with over there. — xaosflux Talk 18:56, 30 August 2021 (UTC)

Inactive interface administrators 2021-08-28

The following interface administrator(s) are inactive:

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

  •  Done removed. — xaosflux Talk 18:57, 30 August 2021 (UTC)

User .js pages needing edits

 Not done @UnitedStatesian: what exactly is wrong on those pages? What are they hurting, and why not fix it somewhere else? (e.g. don't populate that category from pages not in wikitext mode). — xaosflux Talk 20:28, 10 September 2021 (UTC)
@Xaosflux: Happy to do that; what code would I use in the category to prevent populating the category from pages not in wikitext mode? UnitedStatesian (talk) 21:21, 10 September 2021 (UTC)
Why? It looks like it was placed there on purpose. — xaosflux Talk 20:30, 10 September 2021 (UTC)
Also, all 3 of these editors appear to be active, have you discussed changes to their scripts with them already? — xaosflux Talk 20:31, 10 September 2021 (UTC)
I have not; I was advised it was best to handle it centrally here, as per prior practice, such as Wikipedia:Interface administrators' noticeboard/Archive 2#Edit to a user JS page to clear a category. UnitedStatesian (talk) 21:21, 10 September 2021 (UTC)
Generally speaking, the best practice is to contact the editor first before coming to intadmins. (The thread you link to refers to the fact that The user hasn't edited Wikipedia in six years so can someone with access sort out the changeover please?) Writ Keeper ⚇♔ 17:22, 11 September 2021 (UTC)
Indeed, I should have realized that when filing Wikipedia:Categories for discussion/Log/2021 September 10#Category:Categories populated by user script code, but it somehow slipped by mind (probably because most cases where there is a category being updated involve inactive users). That said, nothing I can see distinguishes the Category:Pages with templates in the wrong namespace part of this request from /Archive 2#Special:WantedTemplates, in which user scripts of active users were edited in order to remove them from maintenance lists of some sort. You do have a point about Category:Wikipedia Scripts having been intentionally added (which both UnitedStatesian and I appear to have missed), but again I see no reason that category maintenance should be forced to proceed differently because the page involved is a user script. But this last argument is applying similar reasoning to what got me criticized for abusing my template editor access at Wikipedia:Administrators' noticeboard/Archive320#Creation request, so maybe my vision for process uniformity does not enjoy consensus ... * Pppery * it has begun... 17:43, 11 September 2021 (UTC)

Inactive interface administrators 2021-09-28

The following interface administrator(s) are inactive:

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

  • Notified and removed. — xaosflux Talk 01:20, 29 September 2021 (UTC)

Remove category from some pages

Could someone remove some css & js pages from Category:FlightTime's custom user scripts as it's due to be deleted. (as listed at Wikipedia:Categories for discussion/Log/2021 October 17) Thanks. -- WOSlinker (talk) 11:42, 24 October 2021 (UTC)

@WOSlinker: FlightTime is active, have you tried asking them? Also, having redlink categories on personal userpages isn't really something we police too muhc. — xaosflux Talk 12:07, 24 October 2021 (UTC)
Fair enough, I'll delete the category and ask them to remove them from their pages. -- WOSlinker (talk) 12:12, 24 October 2021 (UTC)
@Xaosflux and WOSlinker: There were many pages asigned to that category and sub-categories. I have already created a list of those pages here: FlightTime/Pages, I will remove all the categories, but it might take a few days. I'll start with the .js & .css pages. - FlightTime (open channel) 13:58, 24 October 2021 (UTC)
Thank you. Don't think this requires administrator intervention now. — xaosflux Talk 20:02, 24 October 2021 (UTC)

importScript and script-installer again

I keep getting bugged about script-installer using importScript, so I would like to make a VPT discussion with a choice between having it use mw.loader.load or making a friendlier shim over mw.loader.load named importScriptBetter or something like that. (And then we'd track down all the remaining uses of {{iusc}} and switch them over.) Feedback requested. Directly pinging Izno and Xaosflux who I've discussed this with before. Convenience link to the most recent VPT discussion earlier this year. Enterprisey (talk!) 09:01, 22 October 2021 (UTC)

  • Not super worried one way or the other, but would prefer to not have shims without a good reason. — xaosflux Talk 13:11, 22 October 2021 (UTC)
  • Same. The difference in usability is pretty much trivial, but so is the cost. I would prefer no shim, but it's really not that big a deal. (We should definitely do something, though.) Writ Keeper ⚇♔ 13:39, 22 October 2021 (UTC)
  • Alright, no shim it is. (Maybe I'll add a preference if people complain.) My current plan is to do the migration by just having script-installer convert the whole page the next time it's used by a user to change their common.js page. Enterprisey (talk!) — Preceding undated comment added 22:41, 24 October 2021 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Interface_administrators%27_noticeboard/Archive_2&oldid=1086855496"