Wikipedia:Interface administrators' noticeboard/Archive 1

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

de:MediaWiki:common.css

I have transferred format definitions for de:Template:Taxobox and de:Template:Infobox Virus to local de:Vorlage:Taxobox/styles.css. This format definitions can now be deleted in de:MediaWiki:common.css.--Cactus26 (talk) 06:58, 31 August 2018 (UTC)

Cactus26, interface administrator's on the english wikipedia have no extra abilities to edit css on the german wikipedia. You'll have to ask a dewiki interface administrator. Galobtter (pingó mió) 07:07, 31 August 2018 (UTC)
Thanks for your quick answer. Do you know where there is a noticeboard for dewiki?--Cactus26 (talk) 07:09, 31 August 2018 (UTC)
Cactus26, I don't know what's happening on dewiki. You could ask one of the people who are already interface administrator's I suppose individually Galobtter (pingó mió) 07:18, 31 August 2018 (UTC)
@Cactus26: You should try de:Wikipedia Diskussion:Benutzeroberflächenadministratoren first. --Izno (talk) 12:18, 31 August 2018 (UTC)
Moreover, most of these sort of requests should be made on the talkpage of the relevant page. ~ Amory (u • t • c) 10:35, 31 August 2018 (UTC)

Set to JSON

Hopefully I am in the right place! Would it be possible to change Template:Calendar_date/Configuration.js to type JSON? It's still an alpha template so editing permissions are still open. (the file will be JSON-only) -- GreenC 14:39, 30 August 2018 (UTC)

@GreenC: it will look like this: Template:Calendar date/Configuration.json. Is it OK to also rename the page to that title (.js-->.json)? — xaosflux Talk 15:51, 30 August 2018 (UTC)
Yes that's fine, thanks! -- GreenC 16:46, 30 August 2018 (UTC)
Seems to me like that page should be a Module page, stored in a Lua table, since it's not hooking into a Javascript system but instead the Module. --Izno (talk) 15:59, 30 August 2018 (UTC)
That's probably what will happen but I used JSON for proof of concept, I like doing things 3 times over again :) Although honestly there is no major performance issue with mw.text.jsonDecode() vs. mw.loadData(), the JSON file will be more accessible to more users than Lua code would be, and JSON is now a universal format. If all your doing is storing configuration data that will be accessible to the largest number of users. -- GreenC 17:23, 30 August 2018 (UTC)
Moved offtopic discussion to Template talk:Calendar date. --Izno (talk) 17:11, 31 August 2018 (UTC)
 Done @GreenC: it is now at Template:Calendar date/Configuration.json. — xaosflux Talk 17:06, 30 August 2018 (UTC)

Relevant rights

Does interface-admin include all of the normal admin rights, particularly block and unblock? In the Wikipedia talk:Interface administrators discussion about having an IA-bot updating geonotices, I proposed that such a bot not be made a normal admin, since if someone untowardly gained access to the bot account and then got blocked, the bot account shouldn't be able to unblock itself. Nyttend (talk) 03:37, 23 September 2018 (UTC)

Nyttend, no, interface administrators do not have the normal admin permissions. Enterprisey (talk!) 03:42, 23 September 2018 (UTC)
Good, thanks. Nyttend (talk) 04:00, 23 September 2018 (UTC)

Edit request to editProtectedHelper

As there are only eleven people who could respond, I figured I might as well post about my recent edit request here. Revert if this is spam. Enterprisey (talk!) 03:43, 23 September 2018 (UTC)

@Enterprisey:, the edit-request process is good - but this does bring back to light a recurring problem: user scripts owned by inactive editors or otherwise abandoned. My first though on seeing your request was to say go ask at user_talk: of the owner - but as they have been inactive for a year that's not going to work. So that leaves "fork to new owner" or "move to community page" as the best options I can think of. Depending on the number of uses, communication for other users that are dynamically loading the page would be needed. This seems like a good venue to discuss improvements to this situation - anyone? — xaosflux Talk 14:57, 23 September 2018 (UTC)
It's a problem of finding a maintainer, regardless of where it ultimately lives. We don't have many editors experienced with Javascript; those that are can make the modifications already for the most part, they're just busy doing Other Things Too. --Izno (talk) 16:51, 23 September 2018 (UTC)
As Izno implies, there are two issues, right? Lack of upkeep, and the potential security issue of being in an inactive user's space. It's certainly reasonable to move some items to MW — easyblock jumps to mind first and foremost — but keeping pages as "redirects" like User:Ais523/adminrights.js doesn't make things any more secure or easily maintainable and technically any intadmin can still edit in the original user's space. Also, I vaguely recall a discussion (phabricator, maybe) about plans to restrict executable javascript to the MediaWiki and User namespaces, not that that particularly matters in this case. ~ Amory (u • t • c) 01:44, 24 September 2018 (UTC)
@Amorymeltzer: I believe so, and in these cases placing in the mediawiki namespace would be the way to go. Agree, redirects are a bad idea - which means either forcibly updating the existing transcluders, leaving them a message to self-update if they want the current version, editing it for them (generally a bad idea!), or the like. — xaosflux Talk 02:21, 24 September 2018 (UTC)
I mean, if someone does the work of maintaining a gadget, I don't think it's unreasonable for the user of that gadget to expect that the gadget might change. I suppose I would be concerned about leaving in place 'redirects' like we're doing with the adminrights script above--suppose that user were compromised? Is that the issue you were trying to get at originally? I think I'd be okay with an Iadmin bot, run by an Iadmin (yo, MusikAnimal ;), tasked with changing editors's Javascript to use the maintained script directly (or unmaintained script directly). (We could admin-lock those pages as well, but what's to guarantee that someone is who they say they are? Gosh, rabbit hole of security problems to some degree--I hadn't thought about how unsecure it is to use anyone else's scripts.) I suppose we could indeed have a community place if an adopter doesn't stand up to at least take away that vector (or the adopter can take it into his user space). Mediawiki:Unmainted-scripts/script-name.js or similar? --Izno (talk) 03:06, 24 September 2018 (UTC)
@Izno: not sure about the forced edits/redirects. If I included User:Izno/superscript.js - it means I'm making a decision to trust you - others should not presume that I trust some future maintainer that wants to take over. — xaosflux Talk 04:27, 24 September 2018 (UTC)
Sure, which makes it a little thorny both ways... I would rather trust an active account than an inactive account (an Iadmin most of the three, which will be required if we can't find an active maintainer, but if we can find an active maintainer...). The problem right now, e.g. with the Ais523 Javascript above where we've replaced the middleman's script with the maintainer's script, which means you have to trust both people now, which is categorically worse. --Izno (talk) 13:14, 24 September 2018 (UTC)
I think User:Ais523/adminrights.js should be blanked. — xaosflux Talk 14:09, 24 September 2018 (UTC)
That's another solution. It is a bit disruptive without some bot which can go through the list of users (regardless of recent activity) and warn them that they will need to take action if they want to use the maintained script. I.e., have a general API deprecation policy. It also only takes care of the problem when the script (abandoned or by abandoned account) has a matching maintained script. Scripts without a match by inactive users--being able to tell them that the script is not maintained by an active account and then also blank/turn those off might also be a reasonable approach. I suspect we'd get a lot of grief with either path but at least it would help Wikipedia move forward with oft-legacy scripts. I'll shut up now though and see if there is an IAdmin who wants to chime in. --Izno (talk) 14:19, 24 September 2018 (UTC)
Notification is certainly a plus, and by blanking as opposed to deleting the notification directions could certainly include how to make a personal fork (e.g. copy/paste to your own page). — xaosflux Talk 14:55, 24 September 2018 (UTC)

There's an argument to be made that interface admin bit implies that they are trusted to edit other users' js, but I can't say the community has explicitly authorized it broadly. Truth be told, TheDJ did a fair amount of related work a year ago in a very valiant attempt to clean up and fix a ton of scripts, which I imagine was well received. I think blanking the Ais script without warning would cause some disruption, and IAs should be prepared to use the edituserjs right. On the other hand, some scripts were blanked (User:Smith609/toolbox.js is probably the most popular example), and I don't think I've seen any complaints. I don't think moving to MW will ever solve maintenance issues, but it would at least reduce an ongoing cycle of risk as folks become inactive. Perhaps the thing to do is wait until an IA policy is established (ha!) and the corps is a bit healthier, then propose an ongoing cycle of moving the main offenders (lookin' at you, Lupin!). Without thinking too hard, I can imagine something like:

  1. Notify inactive owners of popular scripts.
  2. If they remain unresponsive for 2-4 weeks or approve, interface-admins move the page to MW space and leave a deprecation warning and importScript/mw.loader "redirect."
  3. Each month, we pick a script, and notify users (VPT, bot notification, etc.) of the change with instructions on who to do it.
  4. One or two weeks later, perhaps after a second VPT warning, we remove the "redirect" but leave the warning (especially for global users).
  5. Clean up and help users for the next week or two.

Regardless, I think we can make a fairly ordered proposal for the community that should hopefully reduce the amount of work and notifications. Even doing the first two steps and advertising the list and instructions for a few months should greatly reduce the amount of effort required. ~ Amory (u • t • c) 16:13, 24 September 2018 (UTC)

  1. Cataloging the "inactive popular scripts" may be the 'hardest' part here? — xaosflux Talk 18:04, 24 September 2018 (UTC)
Pull content of every common/vector/modern/monobook/etc. user subpage, count every importScript/mw.loader? User:Facenapalm has a list at User:Facenapalm/Most imported scripts; AFAICT it's not exactly accurate, but the top-most candidates seem correct and would be enough to occupy my quick draft proposal for a while. ~ Amory (u • t • c) 18:16, 24 September 2018 (UTC)
User:Facenapalm/Most imported scripts is collected via wikisearch query (that's first step — the next is to analyze query answer with bot), and the size of query answer is limited by 10k results. So effectively that's not most imported scripts — that's most used scripts in first found 10k userpages (considering the fact that not every found userpage is common/vector/modern/monobook/etc subpage). I have no plans to fix that because the bot that collects statistics was written for usage in Russian Wikipedia and we have only 1,6k userpages with importScript. I'm also not counting mw.loader. Facenapalm (talk) 18:32, 24 September 2018 (UTC)
So actually I have script that "pulls content of common/vector/modern/monobook/etc user subpage" and "counts every importScript", its python source code can be obtained here, but do not forget to change 19th, 29th and 59th-69th lines (they're in Russian) and find a better way to get full list of common.js/etc pages to replace 48th line with it. The license is MIT so everyone allowed to use it. Facenapalm (talk) 18:41, 24 September 2018 (UTC)

editProtectedHelper Script question

Howdy! On October 2 a WMF employee, Pchelolo made a post about some suggested updates that should be made to User:Jackmcbarn/editProtectedHelper. Since October 5 it seems this script isn't working for some editors and I'm thinking its due to these suggested updates not being implemented and so does another editor who left a comment on the talk page. However I'm not entirely sure because this is not my area of expertise lol. I was curious if anyone would be able to take a look at the suggested updates and the script to see if that is the reason. ♪♫Alucard 16♫♪ 13:12, 6 October 2018 (UTC)

Yes, the first issue (changing to API version 2.0.0) seems to fix it. I left an edit request over there. Enterprisey (talk!) 03:06, 7 October 2018 (UTC)

Fix User:Joeytje50/JWB.js/load.js

Could someone please fix this script?

Specifically this part: 

mw.config.get('wgAction') == 'view')

The double equal sign needs to be changed to non-equal like this: 

mw.config.get('wgAction') !== 'view')

It's been broken for 5 days and I already left a message on the talk page of the author but he's not responding, and considering that his last edit before the day he made that revision was on August, I don't expect him to reply at any time soon.--Manuel de la Fuente (talk) 14:37, 8 October 2018 (UTC)

Ping to @Joeytje50:. — xaosflux Talk 14:50, 8 October 2018 (UTC)
Emailed maintainer. — xaosflux Talk 14:51, 8 October 2018 (UTC)
Joeytje50 - Looks like this was fixed by removing the condition from the if statement entirely. Let us know if you still have issues. ~Oshwah~(talk) (contribs) 19:25, 12 October 2018 (UTC)
@Manuel de la Fuente: I still do insist that this change is not necessarily wrong. It should still load just fine with the change in place. I did however fix something else (this) which did not break anything on Wikipedia, but did break on other wikis I've tried. I've made that change at the same time as the change to remove the if-condition.
So, I am planning on re-adding the if-condition back considering I don't see any reason this should break anything; the default action on a page is view, and this allows you to make edits to the page (action=edit) while not having to uninstall the script. If you think this would break the script again, please let me know which wiki you are experiencing this, so that I may be able to determine what is causing this. Otherwise, my next edits to the script will be re-adding this condition with == 'view'.Joeytje50 (talk) 19:50, 12 October 2018 (UTC)

URL should be fixed for Hong Kong edit a thon sitenotice

Hi! At MediaWiki:Gadget-geonotice-list.js the URL for the Hong Kong edit-a-thon notice isn't properly displaying. It should be https://outreachdashboard.wmflabs.org/courses/Wikimedia_Community_User_Group_Hong_Kong/Asian_Month_Editathon_in_Hong_Kong_2018/home

Also, if Macau can be included in the Hong Kong edit-a-thon geonotice that would be great! WhisperToMe (talk) 19:29, 16 October 2018 (UTC)

@WhisperToMe: the link appears to already go there, except with your request above this would bypass the sign up page, how is it displaying for you now? @Deryck Chan: can you take a look at this? — xaosflux Talk 20:19, 16 October 2018 (UTC)
It is displayed as [https://outreachdashboard.wmflabs.org/courses/Wikimedia_Community_User_Group_Hong_Kong/Asian_Month_Editathon_in_Hong_Kong_2018 an Edit-a-thon for the Asian Month] right now. I've captured a screenshot on my phone to illustrate that.--Spring Roll Conan ( Talk · Contributions ) 20:26, 16 October 2018 (UTC)
To the interface admins: It might be nice to add Guangdong province too, as the English Wikipedia largely isn't blocked in Mainland China and there are foreigners living in Guangdong province who may be interested in attending. WhisperToMe (talk) 20:37, 16 October 2018 (UTC)
@春卷柯南, WhisperToMe, and Xaosflux: Oh yes, I remember there being something about single-bracket links not working inside geonotices but <a>text</a> does... I've made that change and also added an extra geonotice covering all of Canton Province. Conan: Can you check whether the link displays correctly now? Deryck C. 17:43, 17 October 2018 (UTC)
@Deryck Chan: Thanks for your help! I went to check the display by turning the VPN off but I don't see a sitenotice at the top. I'm wondering if the "country" and geography fields interfere with each other? WhisperToMe (talk) 00:40, 18 October 2018 (UTC)
@Deryck Chan: Now it works, thanks. @WhisperToMe: I've sort out what happened, and I'm puzzled to hear the problem. --Spring Roll Conan ( Talk · Contributions ) 10:24, 18 October 2018 (UTC)
I checked the source code and notice that "HongKongNov18" and "HongKongNov18GD" are separate. The country codes of the first can't possibly interfere with the corners of the second. I am also at a loss on how the second isn't showing up in GD... WhisperToMe (talk) 22:10, 18 October 2018 (UTC)
Resolved
I restarted my phone and found the HK geonotice does display on my watchlist. Deryck, thank you very much for your help! :) 06:35, 19 October 2018 (UTC)
If these will be common we could look at adding 'outreachdashboard' to the meta:Interwiki_map. — xaosflux Talk 17:50, 17 October 2018 (UTC)

Requested

an interface edit at MediaWiki talk:PageTriageExternalTagsOptions.js :-)∯WBGconverse 11:08, 29 October 2018 (UTC)

Winged Blades of Godric, we have Category:Wikipedia interface-protected edit requests, so no need to post edit request if you request there Hhkohh (talk) 12:11, 29 October 2018 (UTC)
Hhkohh, this is to draw quick attention to the request, since the very-previous edit request has botched a part. feature of Pagetriage-interface, (for no fault of anyone, though:-)).Best, ∯WBGconverse 12:25, 29 October 2018 (UTC)
@Cyberpower678: want to take a look at this as you were last updating it? — xaosflux Talk 14:05, 29 October 2018 (UTC)
I'm aware of it. I usually allow some time for comments before committing the changes.—CYBERPOWER (Trick or Treat) 14:06, 29 October 2018 (UTC)
FWIW, posting a message here can be useful to expedite a request - it's easy to watch a noticeboard (through Special:Watchlist) but difficult to watch changes in category membership. Deryck C. 14:33, 29 October 2018 (UTC)
Deryck Chan, you can watch User:AnomieBOT/IPERTable Galobtter (pingó mió) 14:34, 29 October 2018 (UTC)
(edit conflict) @Deryck Chan: good point - and a great fix for that is to watch list User:AnomieBOT/IPERTable. — xaosflux Talk 14:35, 29 October 2018 (UTC)
Now that this is live, I'm going to MMS all the IAdmins to consider that. — xaosflux Talk 14:36, 29 October 2018 (UTC)
Ah, very nice. Thank you bot-op! Deryck C. 14:42, 29 October 2018 (UTC)

Compromised Example

FYI: There was a compromised IAdmin on enwikiquote - some of the vandalism can be seen in the history still, one page was deleted. The account has been identified and globally locked. You should know where to look if you want to see more information. — xaosflux Talk 21:54, 22 October 2018 (UTC)

Uh, that's meant to be suppressed. If it is not, please email me. — regards, Revi 12:30, 26 October 2018 (UTC)
@-revi: see email. — xaosflux Talk 13:22, 26 October 2018 (UTC)
<3 — regards, Revi 14:24, 26 October 2018 (UTC)

CSP coming to town

From today's tech news:

  • Advanced item The wikis now have a content security policy report. This means that you might get a warning in your javascript console when you load external resources in your user scripts. For security reasons it is recommended that you don't do this. It might not be possible to load external resources in your scripts in the future. [1]
— xaosflux Talk 21:15, 29 October 2018 (UTC)

JS/CSS-protected edit request

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.

Should we create a variant of {{edit fully-protected}} that's for JS/CSS pages, say {{edit interface-protected}}? It could put the request in the dedicated category Category:Wikipedia interface-protected edit requests, that way int-admins can monitor it. The relevant message is MediaWiki:Protectedpagetext, though I'm not certain how you'd check if the page is JS/CSS. There is also MediaWiki:Sitejsprotected & MediaWiki:Sitecssprotected (MediaWiki), and MediaWiki:Customjsprotected & MediaWiki:Customcssprotected (User). — MusikAnimal talk 21:38, 26 September 2018 (UTC)

@MusikAnimal: lets not use it yet, but you can make the framework. Mostly I don't want to break User:AnomieBOT/PERTable yet - once the policy goes live and we get past the "stop gaps" then it would be a good time. — xaosflux Talk 21:50, 26 September 2018 (UTC)
Second. Would be nice to transclude on this page. ~ Amory (u • t • c) 01:31, 27 September 2018 (UTC)
@MusikAnimal and Xaosflux: Rules are in place, RfCs done, is it time to create this one? ~ Amory (u • t • c) 17:05, 19 October 2018 (UTC)
@Amorymeltzer: seems like a good idea, lets coordinate with @Anomie: to get User:AnomieBOT/IPERTable going to report on them. — xaosflux Talk 17:40, 19 October 2018 (UTC)
@Xaosflux: I updated the bot, on User:AnomieBOT/PERTable user and site CSS/JS rows should now be red. To start populating User:AnomieBOT/IPERTable, I think you'll need to update Module:Protected edit request/active to have the "box:exportRequestCategories" function put pages into Category:Wikipedia interface-protected edit requests and have the "title.getProtectionLevelText" function return "editinterfaceprotected". Anomie⚔ 18:29, 21 October 2018 (UTC)
​​​ I made some changes to Module:Protected_edit_request/active and Module:Protected_edit_request, but AFAICT it doesn't work (Template:Edit interface-protected treats the page as fully protected). I'm not really sure what the issue is — I've no experience in Lua — any ideas? ~ Amory (u • t • c) 20:55, 25 October 2018 (UTC)
Probably Module:Effective protection level needs to be updated. Anomie⚔ 12:25, 26 October 2018 (UTC)
 Done That did it, thanks. ~ Amory (u • t • c) 19:11, 26 October 2018 (UTC)
{{Edit interface-protected}} works, WP:EPH works and uses {{EIp}}, and IPERTable updates nice and quick! I think that's everything, aside from a few doc pages? ~ Amory (u • t • c) 20:43, 26 October 2018 (UTC)
Tied off a few more loose ends; only remaining thread is that MediaWiki:Protectedinterface shows for all interface pages, so while the module will take care of using the correct category the default section header will be "Protected edit request" instead of "Interface-protected". Do we have a good way of determining content model via template? ~ Amory (u • t • c) 16:34, 27 October 2018 (UTC)
Hmm have to look, hacky workaround is if pagetitle ends with .js/.css in that namespace. — xaosflux Talk 16:46, 27 October 2018 (UTC)
@Amorymeltzer and Xaosflux: see mw:Extension:Scribunto/Lua reference manual#Title objects - can access content model through Lua. Galobtter (pingó mió) 16:53, 27 October 2018 (UTC)
I just didn't think it worth it to create a new module just for this, although I suppose it could be useful elsewhere down the line. ~ Amory (u • t • c) 17:11, 27 October 2018 (UTC)
 Done with Module:Page, no need to reinvent the wheel! It's cosmetic, perhaps, but the correct edit template should now be showing up. ~ Amory (u • t • c) 01:22, 1 November 2018 (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.

New IAdmin request

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

Hi, all, I've requested IAdmin over at WP:BN. Thanks! Writ Keeper ⚇♔ 20:42, 7 November 2018 (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.

New/modified gadget

Hi, all, I was just wondering what the process is for editing old gadgets and modifying new ones (if there even is one).

As I mentioned at VPT, I've kind of taken over the 2006 toolbar that some users prefer, currently located at User:Writ Keeper/Scripts/legacyToolbar.js. I've also retrofitted the MediaWiki:RefToolbarLegacy.js script to work with it; the changes for that are at User:Writ Keeper/Scripts/legacyRefToolbar.js. A diff of my changes is here; they basically consist of removing some external lookup functionality that was making my console light up like a Christmas tree with CSP violations, adding the hook to make it load with the modified toolbar, and probably some other minor modifications. I don't believe the MW version of the script actually does anything in its current state, after the 2006 toolbar was removed.

So, what I'm asking is: what should I do to make these gadgets? I don't know if there's any official or unofficial code review process; I know several people have been using it without complaint so far, but I know that that only goes so far. I do now have IAdmin, so I can technically make all the changes myself, but I didn't want to go crazy with power right away without seeing what the norms are. Any thoughts? Writ Keeper ⚇♔ 16:57, 15 November 2018 (UTC)

@Writ Keeper: per Wikipedia:Gadget it is basically, propose it at VPT, do it. For something as long-standing as this one I think it would be fine to add it to 'Testing and development' section while proposing, so long as you won't be sad if the proposal says to sod off! :D — xaosflux Talk 17:50, 15 November 2018 (UTC)

Refund request

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.

No reason was given as to why this has to be requested here. Can I have this page User:Mlpearc/ClerkingTBLinks.js un-deleted. Thank you. - FlightTime (open channel) 00:54, 22 November 2018 (UTC)
 Doing... — xaosflux Talk 01:31, 22 November 2018 (UTC)
Thank you :) - FlightTime (open channel) 01:34, 22 November 2018 (UTC)
 Done @FlightTime: the page has been restored and moved to User:FlightTime/ClerkingTBLinks.js so that you will be able to access it, the current version is blank but you can restore from history as needed. If you actually want it placed back in User:Mlpearc's subpage please log in as that user and confirm here. Best regards, — xaosflux Talk 01:36, 22 November 2018 (UTC)
No, your action was perfect, thanks again. - FlightTime (open channel) 01:38, 22 November 2018 (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.

Move request

I was asked by the user to move User:PerfektesChaos/js/WikiSyntaxTextMod/dX.7.js to User:PerfektesChaos/js/WikiSyntaxTextMod/dX.js without leaving a redirect. However, I don't have the required rights. Could an interface admin do it instead? Thanks. --Leyo 23:19, 24 November 2018 (UTC)

 Doing... reviewing request. — xaosflux Talk 23:41, 24 November 2018 (UTC)
 Done also notified PerfektesChaos at their talk page. — xaosflux Talk 23:47, 24 November 2018 (UTC)

Thank you. (@Leyo: U2)

  • This is caused by Bug phab:T210195.
  • I was not aware of this particular page here.
  • I have connected this page now with the equivalent in German Wikipedia.
  • When I went through the Regular User Guide To Sysop Actions some days ago I could not find this place mentioned anywhere.

Greetings --PerfektesChaos (talk) 11:58, 25 November 2018 (UTC)

2FA requirement

Hello IAdmins, please note WMF Office now requires 2FA to be activated for accounts with interface administrator access. Accounts out of compliance will have access revoked by the office. See your wiki-mail for more information. — xaosflux Talk 01:51, 17 November 2018 (UTC)

Xaosflux, I support this. —CYBERPOWER (Around) 01:55, 17 November 2018 (UTC)
Looks like only enwiki iadmins got it or I got manually excluded ;-( meh. — regards, Revi 02:01, 17 November 2018 (UTC)
@-revi: I suspect they are making the rounds, half of the email was about meta:CNadmins as well, but I got it to my enwiki mail not my metamail. — xaosflux Talk 02:04, 17 November 2018 (UTC)
I've asked T&S to post this somewhere (anywhere) that communities can reference - they will look in to that early next week per the email reply I received. — xaosflux Talk 02:05, 17 November 2018 (UTC)
Don't worry -revi: I got it twice, you can have one of mine if you like. ~ Amory (u • t • c) 12:11, 17 November 2018 (UTC)
Oh well... I think I heard someone saying the person who was sending emails hit... rate limit. — regards, Revi 13:50, 17 November 2018 (UTC)
I just gave User:WMFOffice account creator for (noratelimit) access here. — xaosflux Talk 14:52, 17 November 2018 (UTC)
Hmm, undone - is already in staff@global - I'm sure they can figure it out :D — xaosflux Talk 14:54, 17 November 2018 (UTC)
He was not using WMFOffice account, IIRC. I think he figured out anyway. — regards, Revi 15:31, 17 November 2018 (UTC)
I absolutely support having 2FA enabled as a required condition for holding the interface administrator user rights. We absolutely cannot allow the risk of accounts with this user right being compromised and having the safety and security of every editor and this site in the hands of someone who intends to act and implement content maliciously... We shouldn't stand for it, and this is a step in the right direction. ~Oshwah~(talk) (contribs) 23:36, 27 November 2018 (UTC)

Int-Admin Main Page Proposal

I know some of the IAs have already commented but just wanted to post a link to Wikipedia:Administrators' noticeboard#Proposing a temporary measure to assist in protecting the Main Page to temporarily limit Main Page edits to int-admins due to the compromising of admin accounts issues. Posted here INTADMIN page from correct suggestion by Xaosflux.

Note: I have !voted, but hopefully this is a suitably neutral link - as a significant expansion of the IA remit it seemed suitable to post a specific link. Nosebagbear (talk) 16:06, 27 November 2018 (UTC)

FWIW IAdmins, see 943 already active, I don't expect we will get many edit requests on this alone. — xaosflux Talk 16:23, 27 November 2018 (UTC)
Interesting proposal. It would have to be able to be enabled and disabled quickly and easily. Obviously, limiting the Main Page to only interface administrators during times where this isn't an emergency and dire need isn't present will likely cause unnecessary red tape and may impose hardship upon our admins when legitimate edits need to me made (though this need is not frequent). As Xaosflux stated above, edit filter 943 does exactly this already and we pretty much have this proposal implemented as-is... ~Oshwah~(talk) (contribs) 23:31, 27 November 2018 (UTC)
Okay, so I looked through some of the discussion at AN, and I see and understand some of the opposition. Implementing anything different than the edit filter and the status quo is going to be difficult in many aspects. In order to protect the main page and all of its transfusions and other assets fully, cascading protection would have to be applied. This means that only interface administrators could update it, add ITN, TFA, OTD, etc., which is done daily. This would put the responsibility on us to carry out. Naturally from there, people will apply to be interface administrators in order to be able to participate and edit the main page. This is not what the interface administrator user rights are meant to be used for, so we'll essentially start having more admins applying and becoming interface admins... then we're pretty much back to where we started before this user right was created and implemented. That's a stupid bad spiral downwards, and a pathway we should not support opening the gate for, and I agree that either we stick to using the edit filter for emergencies and times of dire need, or we come up and develop a different solution that resolves this but doesn't put the interface administrator user rights into the equation... I support some method to secure the main page in times like this, but other than the edit filter, we don't have the right functions to implement a good solution at this time. ~Oshwah~(talk) (contribs) 23:52, 27 November 2018 (UTC)
Worth noting (since it doesn't seem to be present on the AN discussion) that IntAdmins were chosen to reduce the attack surface, and also because their accounts are much less likely to be compromised with mandatory 2FA. Agreed the current abusefilter should be a temporary measure. -- Ajraddatz (talk) 23:39, 27 November 2018 (UTC)

To put direct Main page edits in to perspective for 2018 the 26 direct edits have been (numbered from oldest to newest) 

(1)  A erroneous use of AWB by an admin
  (2)  Partial revert of (1)
  (3)  Rest of revert of (1)

(4)  A styling edit following an edit request
  (5)  Reversion of (4)
  (11) Re-implementation of (4) following full discussion

(6)  Some new divs, following an edit request
  (7)  A correction of a technical error introduced by (6)
  (10) A correction of a technical error introduced by (6)  
  (13) A correction of a technical error introduced by (6)
  (14) A correction of a technical error introduced by (6)

(8)  Reword one label
  (9)  Cleanup of text formatting from (8)

(12) Technical em padding adjustments

(15) Conversion to TemplateStyles
  (16) Reversion of (15)
  (17) Re-conversion to TemplateStyles
  (18) Reversion of (17)

(19) - (26) actions by and cleaning up from compromised admins
I think this is rather illustrative of some important points: (a) MP edits are rare, (b) MP edits have not been urgent, (c) MP edits have mostly been problematic. Leaving the filter on and dealing with these via edit-requests, with the added caution that even int-admins need to be extra careful seems sensible to me. — xaosflux Talk 14:25, 28 November 2018 (UTC)

Administrators unable to view deleted history for .js and .css pages

This might not be the correct place to post this, but I noticed that when following the discussions at this noticeboard I (as an administrator) am unable to view the deleted revisions of .css or .js pages. This applies to interface pages like Mediawiki:Common.js as well as other user's .js or .css. While I understand the technical reason to remove access for all admins to edit .css and .js pages as risk management, I find removal of administrators' ability to even see deleted revisions perplexing and cannot locate a discussion where this was talked about. If I try to view a deleted revision, I receive the standard:

"You do not have permission to view a page's deleted history, for the following reason:
The action you have requested is limited to users in one of the groups: Administrators, Oversighters, Researchers, Checkusers. "

Looking at Special:ListGroupRights, it does not appear there is a special userright involved here. Is there something I am missing or is this a bug? Mifter (talk) 06:56, 25 November 2018 (UTC)

It was part of the WMF change to introduce interface administrators. I have wanted to undelete these kind of pages a couple of times, but that is not really enough of a justification to have the right. I would expect the interface administrator to check if the script is safe before restoring. Apart from requests at WP:REFUND I have not needed to view deleted .js and .css pages myself. However perhaps that view only right could be granted to administrators reasonably safely. Graeme Bartlett (talk) 09:12, 25 November 2018 (UTC)
Tracked in Phabricator
Task T202989
Just to add to Graeme's answer, phab:T200176 discussed the ability for sysops to delete or undelete such pages, while phab:T202989 is where work on this particular issue was being done. In short, the ability to view these should return. The issue of the busted error message is here. ~ Amory (u • t • c) 11:30, 25 November 2018 (UTC)
I am the author of phab:T201052 which attempts to draw a full picture wrt rights and operations and security.
In brief on the issue of this section, there are two more aspects:
  • A deleted page or revision may contain bad code (malware) and offer ways to exploit leaks.
  • A regular sysop account may be hacked and misused.
These are reasons to give regular sysops the right to delete interface resources in order to stop execution of bad code as soon as possible.
Once bad code has been deleted (which may have been reason for deletion) the number of eyes who shall be able to read that malicious ideas shall be quite small.
If someone wants to read such hidden code a copy might be sent via e-mail by an interface admin.
However, I wonder why a popular page like Common.js should be deleted. Anyway, if deletion of JS (and as by-product CSS) pages or revisions takes place and it vanished from visible regions that has certain good reasons, and bad content shall not be in effect again.
Greetings --PerfektesChaos (talk) 12:16, 25 November 2018 (UTC)
Thank you for the information and followup everyone, I'll look forward to those phabricator tasks being resolved and patches rolled out down the road. Best, Mifter (talk) 03:36, 27 November 2018 (UTC)
Oh wow. I'm obviously late to the party here, but great find... thank you for reporting this. :-) ~Oshwah~(talk) (contribs) 23:32, 27 November 2018 (UTC)
Reading the phab tasks and thinking a bit more, it seems that there are certain rights that need to be Interface Admin only (for the whole idea behind Interface Admin to work) and and others that can remain with all sysops (as my understanding is Interface Admin is a pure security move for .js and .css regarding the attack surface due to their unique ability to cause harm, not a desire to create separate "levels" of sysop.) For example:
  • Edit: Self-explanatory - only Interface Admin (except for own user .js and .css.)
  • Delete: As deleting a .js or .css page just reverts to the Mediawiki default and could be useful for CSD-U1 or in case of a compromise, could stay with all sysops.
  • Move: As above, moving away (e.g. from User:Foo/monobook.js to User:Foo/sandbox) could be fine as it restores the default, but moving in would need to be Interface Admin. On the whole, might be more trouble than its worth to split out.
  • Revdel: No real reason to restrict as it does not touch content.
  • Undelete: Almost certainly needs to stay with Interface Admin as the ability to selectively undelete is the ability to edit.
  • Protect: Through cascading protection, Sysops can already protect any page even if it is a .js or .css (same reason cascading semi-protection was removed) and I recall seeing some cases where user .js and .css has been protected by admins previously so could probably stay with all sysops.
  • Viewdeleted: As this whole topic came up, doesn't appear to be an issue for all sysops as view only cannot edit.
I believe that's most of the relevant rights/advanced permissions (if I missed any important ones, I'm happy to add and talk about). Also, in doing this I also noticed a (small) glitch in that Special:ListGroupRights is not fully alphabetical as even though most rights are listed alphabetically, some are listed off old group names, e.g. it lists administrators after stewards and before template editor (based off sysop), edit filter manager at the top of the list (as it used to called the abusefilter) which we might want to have standardized. Best, Mifter Public (talk) 20:45, 28 November 2018 (UTC)
FYI, that list is alphabetical by the canonical names. — xaosflux Talk 20:51, 28 November 2018 (UTC)
Thanks! I figured as much and had forgotten about using the qqx language code to view the corresponding interface message. Best, Mifter (talk) 03:17, 29 November 2018 (UTC)

Requested move

Support moving from test account --DannyS712 test (talk) 23:08, 2 December 2018 (UTC)
User creation log (DannyS712 test created by DannyS712) to save a click. Enterprisey (talk!) 04:08, 3 December 2018 (UTC)
 Done ~ Amory (u • t • c) 11:36, 3 December 2018 (UTC)

Requested move

Please move User:DannyS712 test/orphan.js to User:DannyS712/deOrphan.js.

DannyS712 created this test account here

--DannyS712 test (talk) 20:23, 13 December 2018 (UTC)

Support --DannyS712 (talk) 20:24, 13 December 2018 (UTC)

Requested move

Please move User:DannyS712 test/logs.js to User:DannyS712/logs.js. Sorry to keep asking, but I want to develop new scripts in a different account to avoid any unpleasant surprises. --DannyS712 test (talk) 08:03, 15 December 2018 (UTC) --DannyS712 (talk) 08:04, 15 December 2018 (UTC)

 Done Do you want the redirect DannyS712 or no? ~ Amory (u • t • c) 10:56, 15 December 2018 (UTC)
@Amorymeltzer: I'd like to keep the redirect. Also, is there a better way to be requesting these moves? Completely uncontroversial, but require IAdmin rights... --DannyS712 (talk) 10:59, 15 December 2018 (UTC)
If you're going to test using your alt, then this is probably the best venue. You could technically use {{edit interface-protected}} on the talkpage, but between moving and deleting the talk page(s), that'd be more (slightly) work/actions. What unpleasant surprises were you worried about? I understand it for the wikibreak script, but for these others there doesn't seem to be a need to use the test account at all. ~ Amory (u • t • c) 11:10, 15 December 2018 (UTC)
I'm using that account for testing lots of random javascript, and my coding experience is very limited. Just to avoid the possibility of messing something up. For example, when I use a script from someone who is no longer active (like User:Technical 13), sometimes I'll fork it to make my own, but since I don't know why they left, this may have some unintended side effects. Better safe than sorry, right? --DannyS712 (talk) 11:13, 15 December 2018 (UTC)
@DannyS712: you can also just create the new page on your main account and copy-paste it in, if you don't want the old page anymore you can tag it for speedy deletion (the standard administrators can delete these pages, just not edit/move them). — xaosflux Talk 15:31, 15 December 2018 (UTC)

Requested move (again, sorry)

Please move User:DannyS712 test/new pages.js to User:DannyS712/New pages feed.js (without deleting the redirect). Thanks, --DannyS712 test (talk) 23:50, 17 December 2018 (UTC) --DannyS712 (talk) 23:51, 17 December 2018 (UTC)

 Done @DannyS712: moved, as noted above - especially if you don't want the redirect removed: as you are the only author you can simply create the new page and paste in your code, that way you can self-service these in the future. — xaosflux Talk 00:08, 18 December 2018 (UTC)
@Xaosflux: Next time I'll try to remember that. Thanks --DannyS712 (talk) 00:47, 18 December 2018 (UTC)

Protected edit request - deletion of redirect in user space

Tracked in Phabricator
Task T210922
Tracked in Phabricator
Task T210195

Could someone please delete the redirect at User:UninvitedCompany/Monobook.js? I'm trying to clean up old junk in my userspace, and apparently I can't do it myself. The Uninvited Co., Inc. 19:07, 29 November 2018 (UTC)

Oh wow... that's very interesting. I was able to recreate this issue on test-wiki. I literally just created a .js page using my test account and at User:Oshwah-TEST/MoveMeTest.js, and then renamed it by moving it to User:Oshwah-TEST/MoveMeTest2.js. I'd be interested to know if a normal administrator could even delete the redirect as it is..... ~Oshwah~(talk) (contribs) 13:18, 1 December 2018 (UTC)
@Oshwah: I was able to delete testwiki:User:Oshwah-TEST/MoveMeTest.js as an an admin that was not also an int-admin. — xaosflux Talk 13:35, 1 December 2018 (UTC)
Xaosflux - Okay, that's good to know; thank you for testing it and for letting me know the result. :-) ~Oshwah~(talk) (contribs) 13:42, 1 December 2018 (UTC)
@Oshwah: is the bug that admins can't delete if the page is their OWN page but can others? I can make your alt account a temp admin over there if you want to test more? — xaosflux Talk 13:44, 1 December 2018 (UTC)
Xaosflux - The bug in the ticket is that users cannot edit the redirect that's generated after they create a .js or .css page and then move it somewhere else within their own user space. I was just interested to see if admins could delete the redirect given the fact that even the user who created the page couldn't even edit it... :-) ~Oshwah~(talk) (contribs) 13:56, 1 December 2018 (UTC)
@Oshwah: note: this thread itself was reported by an admin, who was also the page owner. I may do more testing later. — xaosflux Talk 14:01, 1 December 2018 (UTC)
Xaosflux - Same here; I'll also continue testing. I know he's an admin; my apologies if my previous response caused any confusion with what I was trying to say. :-) ~Oshwah~(talk) (contribs) 14:04, 1 December 2018 (UTC)
@Oshwah: OK certainly a bug here is what happens:
1)A user create a userjs page
2)A user moves their userjs page to a new title
3)The user can not delete (1) even if they are an admin
3.1) All other admins CAN delete (1)
— xaosflux Talk 15:34, 1 December 2018 (UTC)
Technically a different bug than the one reported, but probably the same thing. Opening another ticket. — xaosflux Talk 15:34, 1 December 2018 (UTC)
phab:T210922 opened. — xaosflux Talk 15:40, 1 December 2018 (UTC)
@UninvitedCompany: thanks for letting us know. This appears to be a permission checking bug. If any other admin has this issue right now just put a {{speedy}} tag on the talk page, since every admin "except yourself" can process these. — xaosflux Talk 15:41, 1 December 2018 (UTC)
Xaosflux, admins cannot add {{speedy}} on the page unless the root problem is resolved which checks for edit permission.. –Ammarpad (talk) 16:00, 1 December 2018 (UTC)
@Ammarpad: oops - I left off to put it on the "talk page" :D — xaosflux Talk 16:09, 1 December 2018 (UTC)

Xaosflux, I was just able to delete [2] but am unable to restore it - clicking view/restore generates a permission error that I'm not a sysop - even though I am (on testwiki). Home Lander (talk) 19:06, 1 December 2018 (UTC)

@Home Lander: that is expected, only interface admins can undelete those type of script pages. Ideally admins should be able to VIEW them, but that is pending phab:T202989. — xaosflux Talk 19:13, 1 December 2018 (UTC)

Thanks for the deletion and for the ticket. Happy to have found a new hole in the envelope. The Uninvited Co., Inc. 02:14, 2 December 2018 (UTC)

Bots that use the modification of .css pages for task emergency shutoff

A general note, for those who might not already be aware, that there are some bots that are setup to use the creation/modification of a .css page in the bot's userspace as an emergency shutoff in lieu of blocking. As these were setup prior to the stripping of those permissions from all sysops, those shutoffs largely would no longer work as intended. I just left a note on a bot owner's talk page about this, but thought it would be prudent to post here (and potentiality at BAG) in case anyone has a list of bots that use such a mechanism, any thoughts if we want to encourage migration away from that method of emergency shutoff, or other input. For what its worth, I sketched out what permissions all sysops either already retain, or possibly could retain here which could be useful to consider when thinking about what might workable for these shutoffs. Best, Mifter (talk) 07:04, 8 December 2018 (UTC)

I think the idea for use css was that the page would be limited to sysops and the (bot)user in question? Using a regular page — even just changing the content model — and protecting would still allow sysops (or TE, ExC, etc.) to edit the page without changing the code, which seems reasonable to me. Sysops can still delete these pages, so depending on how the bot is coded nothing (except updating the shutoff instructions) may need to be done. A related issue of bot operators not being able to edit js/css subpages of their own bots was raised a few times, such as here. I haven't seen any issues yet? ~ Amory (u • t • c) 12:14, 8 December 2018 (UTC)
They should just change to .json if they want to use the same concept - users can edit their "own" .json's and so can all admins. — xaosflux Talk 13:38, 8 December 2018 (UTC)
I think these are usually used where for some reason they want the bot to be able to edit it (probably for non-admin bot ops), else wikitext and protection should certainly be fine. — xaosflux Talk 13:40, 8 December 2018 (UTC)
Thanks, Xaosflux, given that, .json seems to be the easiest for a drop in replacement as it appears to act similarly as a .css page used to. Best, Mifter (talk) 19:57, 11 December 2018 (UTC)

Inactive interface administrators 2018-11-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:47, 28 November 2018 (UTC)

  • Looks like this was an WMF action by JSutherland (WMF) for phab:T210029 (adding "Reader Trust Quicksurvey") and expires on 20181212, should be removed before the next monthly activity audit. No local action required. — xaosflux Talk 23:56, 28 November 2018 (UTC)
    How often does this update? I literally only gave him the right this morning. Unless it's talking just "active" in general? In any case, yeah, this expires very soon. Joe Sutherland (WMF) (talk) 23:58, 28 November 2018 (UTC)
    @JSutherland (WMF): I think it is only monthly and the timing just got really (un)lucky. It is "inactive" according to our local policy (Wikipedia:Interface administrators) as there have been no actions that require this access during the review period. We do not allow community appointed int-admins that are not admins, so "edits to mediawiki namespace" aren't counted here. If this was going to be a permanent thing we could update the bot code for username exemptions. — xaosflux Talk 00:10, 29 November 2018 (UTC)
    Ah, interesting! I didn't know this report existed. :) Sounds good, probably not likely to be a permanent thing given how powerful the rights are. (We have an approval process within the Foundation for things like this.) Joe Sutherland (WMF) (talk) 00:25, 29 November 2018 (UTC)
    Just to add, the bot has a nice check for users that recently got the group, but since this wasn't done locally there was no record of it. ~ Amory (u • t • c) 01:57, 29 November 2018 (UTC)
    I've updated the check to consider the logs on meta. — JJMC89 (T·C) 04:07, 29 November 2018 (UTC)
    Thanks, though these should be very very rare! Like Amory said, good test of the bot! — xaosflux Talk 04:38, 29 November 2018 (UTC)
  • Well, good test of the bot! ~ Amory (u • t • c) 00:36, 29 November 2018 (UTC)
  • Just FYI this has now expired; per the phab, all necessary pages were made two weeks ago. ~ Amory (u • t • c) 20:11, 12 December 2018 (UTC)

New Wikimedia password policy and requirements

The Wikimedia Foundation security team is implementing a new password policy and requirements. You can learn more about the project on MediaWiki.org.

These new requirements will apply to new accounts and privileged accounts. New accounts will be required to create a password with a minimum length of 8 characters. Privileged accounts will be prompted to update their password to one that is at least 10 characters in length.

These changes are planned to be in effect on December 13th. If you think your work or tools will be affected by this change, please let us know on the talk page.

Thank you!

CKoerner (WMF) (talk) 21:14, 12 December 2018 (UTC)

Copied from WP:BN. — xaosflux Talk 21:54, 12 December 2018 (UTC)

Deletion of User subpage

Could an int-admin please delete User:FR30799386/undo/v2.js? — fr + 16:34, 18 December 2018 (UTC)

 Done @FR30799386: in the future you may just tag these for speedy delete, standard admins may deleted these pages, just not edit them. — xaosflux Talk 17:26, 18 December 2018 (UTC)

User:Alex 21/script-colourcompliance.js (on AN)

An interface administrator's attention is requested at WP:AN#User:Alex 21/script-colourcompliance.js. Enterprisey (talk!) 07:07, 1 January 2019 (UTC)

Pinging Oshwah Hhkohh (talk) 07:11, 1 January 2019 (UTC)
I believe that I can be of assistance here. ;-) ~Oshwah~(talk) (contribs) 07:35, 1 January 2019 (UTC)
The requested modification has been  Done. ~Oshwah~(talk) (contribs) 07:40, 1 January 2019 (UTC)

Two MFDs for MediaWiki pages

Could one or more interface admins please review Wikipedia:Miscellany for deletion/MediaWiki:Amethyst.css and Wikipedia:Miscellany for deletion/MediaWiki:Fast.css. --RL0919 (talk) 19:06, 31 December 2018 (UTC)

I closed both as delete - could an Interface admin delete the two pages pursuant to that? Galobtter (pingó mió) 10:14, 2 January 2019 (UTC)
Looks reasonable-- Done. Writ Keeper ⚇♔ 16:08, 2 January 2019 (UTC)
@Galobtter: FYI any admin should be able to delete these pages for future reference. — xaosflux Talk 16:33, 2 January 2019 (UTC)
I thought so actually, but didn't work for me. Galobtter (pingó mió) 17:06, 2 January 2019 (UTC)
Didn't work for me either, that's why I came here for assistance. --RL0919 (talk) 17:31, 2 January 2019 (UTC)
@Galobtter and RL0919: thanks for the replies, looks like we only 'fixed' that for USERjs/USERcss pages (in phab:T200176). These should be fairly rare - feel free to post here if there are more. If it starts becoming a regular thing we could expand the delete on it with another dev request. — xaosflux Talk 18:13, 2 January 2019 (UTC)

ReferenceTooltips

Heads up for interested editors: see WP:VPT#Suggestion to update Reference Tooltips gadget. --Izno (talk) 14:41, 4 January 2019 (UTC)

script edit needed

Moved from WT:INTADMIN

Can someone come by the discussion at Wikipedia:Village_pump_(technical)#created_timestamp.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:48, 25 December 2018 (UTC)

It looks like the change requested on the relevant .js page (User:Eizzen/PageCreator.js) has been made and the issue resolved. Let us know if the issue continues and we can certainly fix it. :-) ~Oshwah~(talk) (contribs) 06:33, 29 December 2018 (UTC)
Oshwah I am not sure if you are following along, but I have posted an update.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 05:25, 3 January 2019 (UTC)
TonyTheTiger - Thanks for the ping! Is everything working okay? What's up? :-) ~Oshwah~(talk) (contribs) 05:36, 3 January 2019 (UTC)
As I stated there, I am now seeing GMT, which is an improvement over Central Time, but is not UTC. Still need some help, I think.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 05:10, 7 January 2019 (UTC)
@TonyTheTiger: so for that - your browser is making that value, not the script. It has apparently been a long time fight of why this is a 'wont fix' in javascript implementations. We could possibly hack @Eizzen: to hardcode "UTC" in there, but I think it would break it for users actually in GMT. The same issue may occur with other timezones that have the same offset. — xaosflux Talk 05:29, 7 January 2019 (UTC)
Xaosflux, I am hearing "This is as good as it is going to get. No further changes are possible."-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 20:08, 7 January 2019 (UTC)
@TonyTheTiger: you could fork the script, and have it leave off the TZ or manually enter 'UTC' as text, instead of having your browser determine and insert that TZ, since this is someone's personal script that you are using I don't want to go to far in to re-writing it as-is. Perhaps we could make a 'gadgets light' area like User:UserScripts/scripts/xxxx to place scripts that people like but don't really have specific maintainers... — xaosflux Talk 20:31, 7 January 2019 (UTC)
Xaosflux, you are talking about an expertise I don't have. I am asking if people know how to fix this. I am nto trying to make decisions on how to make the fix.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 01:35, 9 January 2019 (UTC)
@TonyTheTiger: I was mostly referring to people in general. The "problem" here is that you are trying to rely on something that was maintained by one user who has left, I'm discussing some options for further encouraging "community" support for these type of things. — xaosflux Talk 01:57, 9 January 2019 (UTC)
I think that's an interesting idea, although perhaps addressed by putting gadgets in their own sort of repository, so that editors can be manually whitelisted for each gadget. But honestly I'd prefer a new protection level for intadmins, plus approved people who can edit user scripts. Enterprisey (talk!) 07:02, 9 January 2019 (UTC)
@Enterprisey: perhaps the Gadgets: namespace......phab:T31272. — xaosflux Talk 18:41, 9 January 2019 (UTC)

Int-admin assistance requested for reviewsourcecheck script

Hi, could an interface admin please help out at User talk:Lingzhi/reviewsourcecheck § Toggle. Thanks, Evad37 [talk] 10:59, 10 January 2019 (UTC)

Seemingly dealt with by MSGJ ~ Amory (u • t • c) 21:52, 10 January 2019 (UTC)

Undeletion of FWTH's user scripts

After FWTH just retired, Primefac deleted his user pages per request. I'm requesting that his script-related pages be undeleted and moved to my (test account's) user space. Specifically, "User:Flooded with them hundreds/XYZ" be refunded at "User:DannyS712 test/FWTH/XYZ". I'm asking here because most are javascript/css pages.

I'd like to request a copy of each .js and .css, as well as:

These were chosen based on title alone, so if there are any not script-related, or others that are, I'd be grateful if you could undelete/not undelete those. I'm asking here since all IAdmins are also Admins, and I thought it would be better to centralize my request. I will message those who imported FWTH's scripts when I have them up and running in my user-space, and will maintain them as needed. thanks, --DannyS712 (talk) 22:25, 20 January 2019 (UTC)

@DannyS712: AFAICT only sectionremover and pagemoverclosure are scripts. I'll check those two and restore/move them to your space. ~ Amory (u • t • c) 22:43, 20 January 2019 (UTC)
 Done User:DannyS712 test/FWTH/sectionremover.js and User:DannyS712 test/FWTH/PageMoverClosure.js ~ Amory (u • t • c) 22:48, 20 January 2019 (UTC)
@Amorymeltzer: If FWTH was messing around with any other javascript for future ideas, I'd like to take a look. Would that be okay? --DannyS712 (talk) 22:50, 20 January 2019 (UTC)
I took a look, there's nothing particularly interesting. A few things tweaked around for personal preference, but nothing major and most were explicitly for personal use. ~ Amory (u • t • c) 22:59, 20 January 2019 (UTC)
And if you want the non .js/.css pages undelted, you can follow up at WP:REFUND. — xaosflux Talk 23:14, 20 January 2019 (UTC)

Some more scripts

Thanks, --DannyS712 (talk) 06:48, 23 January 2019 (UTC)

 Done @DannyS712: the page has been restored to: User:DannyS712/sectionmover.js — xaosflux Talk 12:24, 23 January 2019 (UTC)

Draft proposal: Script modules

I have a draft proposal for script modules – bits of Javascript code intended to be easily reused by userscripts, and stored in the MediaWiki namespace. Could you (interface admins) please review it, and leave feedback on the talk page? Cheers, Evad37 [talk] 03:01, 26 January 2019 (UTC)

@Evad37: I'm also going to advertise the discussion in the next issue of my newsletter, since this seems like the kind of thing it would be useful for, given the target audience --DannyS712 (talk) 03:05, 26 January 2019 (UTC)
Thanks DannyS712 - Evad37 [talk] 03:07, 26 January 2019 (UTC)

Help needed deleting .css and .js pages

Please see User talk:Siddiqsazzad001. Per their request I have deleted the pages in their userspace. They would also like their .css and .js pages deleted. ~ ONUnicorn(Talk|Contribs)problem solving 18:11, 31 January 2019 (UTC)

 Done — xaosflux Talk 18:18, 31 January 2019 (UTC)

Move js files for rename

Per User talk:Stanglavine, looks like they hit a page move filter when renaming a user, so the js subpages of Special:PrefixIndex/User:Md.altaf.rahman need to be moved to a subpage of User:Dead.rabbit. Galobtter (pingó mió) 12:06, 1 February 2019 (UTC)

If anyone is curious, this is due to phab:T212082. Galobtter (pingó mió) 12:15, 1 February 2019 (UTC)
 Done @Dead.rabbit, Stanglavine, and Galobtter: the move has completed. — xaosflux Talk 13:04, 1 February 2019 (UTC)

Template:Calendar date/Configuration.json

Requesting a content model change from JSON to Wikitext. Or could just be deleted, it's been replaced by a Lua Module and was never used in production, either way works. -- GreenC 00:38, 19 February 2019 (UTC)

@GreenC: I don't think this is the right place to request that - all admins can edit JSON pages as well as editcontentmodel; its not specific to IAdmins. --DannyS712 (talk) 01:46, 19 February 2019 (UTC)
 Already done — JJMC89 (T·C) 02:33, 19 February 2019 (UTC)

Voluntary code review

Anyone interested in participating in a voluntary "request for code review" process? Please discuss at Wikipedia talk:User scripts#Voluntary code review (not here) - Evad37 [talk] 03:42, 20 February 2019 (UTC)

IAdmin eyes (perhaps) requested

No idea if this is the right place, and I don't see a notice telling me I must inform the editor, etc., that I have started this discussion. So I haven't. In any case, they've only been here a week (although on the other hand, that means their first three edits were to their .css page, which you can probably be the judge of yourselves). Anyway, can someone have [User:Roxspirit/vector.css|a look at it]]? It's appearing tagged as "Possible self promotion in userspace", so the system says. Many thanks, ——SerialNumber54129 13:41, 28 January 2019 (UTC)

@Serial Number 54129: I went over most of it, that code is a bit messy and may have some performance issues - but it will only impact them when logged in. In general, it is changing the display to a "night mode" type of display. They may only be interested in reading, and like the look of it. I'm not worried about anything related to spam there. The large base64 images are just our logos, tinted gray and blank. — xaosflux Talk 14:50, 28 January 2019 (UTC)
OK @Xaosflux:, thanks very much, just checking—just a false positive then. I did think it was odd that it was their first edit, but, perhaps to people who live code, it's second nature to hunt those pages out first  :) incidentally, is there a requirement to notify from here? ——SerialNumber54129 14:58, 28 January 2019 (UTC)
@Serial Number 54129: no, but in most cases it would be courteous - don't think it would have been useful in this situation though. In general, this page wouldn't really be the best place to deal with user behavior type issues where someone would need to defend themselves - which is where the notification requirements on other pages mostly stemmed from. — xaosflux Talk 16:16, 28 January 2019 (UTC)
I'll also add that one of the great benefits of having and using an account is as a reader. I spent my first few years without editing simply because logging in meant I could have a different better skin and use popups when reading. Editing user css seems like a great use of an account. ~ Amory (u • t • c) 03:04, 31 January 2019 (UTC)
Ditto. This was precisely why I created account. My first 24 edits were restoring the monobook background, among other tweaks. Though, I am now appreciative that I didn't know I could simply go back to Monobook... I much prefer my hybrid skin with Vector features! :) — MusikAnimal talk 03:55, 20 February 2019 (UTC)

Interface admin mailing list

I doubt we'd use it much, but say if someone wanted to report a security vulnerability with a user script, they can't (or shouldn't) report it here. Emailing int-admins one by one would be a pain, and Phabricator may not be appropriate either if it's not a widely used script. A mailing list would offer a venue to privately contact us about these matters. Thoughts? — MusikAnimal talk 00:47, 19 February 2019 (UTC)

Sure, sounds like a good idea. Enterprisey (talk!) 04:27, 20 February 2019 (UTC)
Yeah, seems sensible - Evad37 [talk] 07:05, 20 February 2019 (UTC)
I'm not opposed to this, but I think we'd need to be careful not to attempt to claim authority we don't have. If there's a major issue with a local, semi-popular script that shouldn't be mentioned on-wiki, this could indeed be handy, but that is exceedingly rare. Any sysop can delete the offending page and if it's a true emergency stewards can act, so IRC would be reasonable. You'd obviously know better than I would if security@ would get annoyed with something small/local, still I'd sooner sysops take a "delete first, ask later" stance with reported vulnerabilities. Perhaps something like the current crat table, which has email buttons as well as (voluntary) timezones? Also, it'd likely need to be done through OTRS to reduce spam, as heavy moderation by list admins might defeat the purpose. ~ Amory (u • t • c) 11:21, 20 February 2019 (UTC)
Amorymeltzer, sysops can delete JS? I thought it was completely off limits to admins. —CYBERPOWER (Chat) 16:32, 20 February 2019 (UTC)
@Cyberpower678: they can delete, but not view-delete or restore user[js|css] pages (phab:T200176). — xaosflux Talk 16:36, 20 February 2019 (UTC)
Xaosflux, so if, hypothetically, a rogue/compromised admin just went on a JS deletion spree, the community has to wait on one of use to clean up the mess? That sounds like fun. —CYBERPOWER (Chat) 16:38, 20 February 2019 (UTC)
Yup - luckily as far as annoying things admins can do it's not as disruptive (as it is 100% not reader impacting to have some user scripts deleted). — xaosflux Talk 16:42, 20 February 2019 (UTC)
Good idea. ~Oshwah~(talk) (contribs) 20:10, 22 February 2019 (UTC)

Inactive interface administrators 2019-02-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:49, 28 February 2019 (UTC)

 Done
Notified: Special:Diff/885587411
Removed: Log
— xaosflux Talk 00:04, 1 March 2019 (UTC)

Edit request I can't find a better place to put

The content model of MediaWiki:Gadget-formWizard/WikiProject Women's Health/Join and all the other subpages of MediaWiki:Gadget-formWizard should be changed to JavaScript. {{3x|p}}ery (talk) 16:29, 24 February 2019 (UTC)

Eight days later with no comments from Harej ... {{3x|p}}ery (talk) 19:52, 4 March 2019 (UTC)

From what I've been looking at, this would be a cosmetic-only change correct? — xaosflux Talk 19:55, 4 March 2019 (UTC)
It is correct that I had a cosmetic motivation when I filed this request, however the effects won't be purely cosmetic as it will make the pages, which are loaded as JavaScript by MediaWiki:Gadget-formWizard-core.js only editable by interface administrators. {{3x|p}}ery (talk) 20:03, 4 March 2019 (UTC)
@Pppery: why not change it to JSON? --DannyS712 (talk) 05:53, 21 March 2019 (UTC)
Well, for starters, it's not JSON. Anyway, Galobtter took care of all these I believe. ~ Amory (u • t • c) 11:05, 21 March 2019 (UTC)
Looks like it should be... It's only "not JSON" because of the variable declaration?... --Izno (talk) 13:58, 21 March 2019 (UTC)
Also the mw.user.getName().replace(' ', '_') (and all the extra commas break validity, but that is easily fixable of course). Galobtter (pingó mió) 14:14, 21 March 2019 (UTC)

MediaWiki:Group-checkuser.css

Hi. I figured that since there are very few interface administrators, it might be useful to add a note here. I have requested that MediaWiki:Group-checkuser.css be created. See the full explanation and rational at MediaWiki talk:Group-checkuser.css. Thanks, --DannyS712 (talk) 05:10, 22 March 2019 (UTC)

Done by TheDJ ~ Amory (u • t • c) 10:22, 22 March 2019 (UTC)

Dark Mode

Is it possible that a dark mode could be implemented? — Preceding unsigned comment added by 2A02:C7D:468E:A000:F471:C019:6F48:38FE (talk) 14:09, 22 March 2019 (UTC)

2A02, it will probably be worked on as part of the 2019 wishlist. --Izno (talk) 14:12, 22 March 2019 (UTC)

Refund

After long wiki break:

-- Siddiqsazzad001 (talk) 18:23, 25 March 2019 (UTC)

 Doing... — xaosflux Talk 18:33, 25 March 2019 (UTC)
 Done @Siddiqsazzad001: your pages have been restored. — xaosflux Talk 18:35, 25 March 2019 (UTC)
Siddiqsazzad001 - See the message I left on your user talk page. :-) ~Oshwah~(talk) (contribs) 05:59, 10 April 2019 (UTC)

Undeletion of my common subpages

Can you please undelete these two? Thanks, Dreamy Jazz 🎷 talk to me | my contributions 14:13, 10 April 2019 (UTC)

 Done , left note at user talk. — xaosflux Talk 15:33, 10 April 2019 (UTC)

Move request

Hi. Can User:DannyS712 test/meta.js please be moved to User:DannyS712/Meta.js, making sure to leave a redirect behind? I didn't want to just copy paste it because another user is already importing it. Thanks, --DannyS712 (talk) 22:21, 13 April 2019 (UTC)

 Done I would have thought you should have been able to self-service this @DannyS712:. Were you getting a sloppy Fatal exception of type "InvalidArgumentException" type error? — xaosflux Talk 23:05, 13 April 2019 (UTC)
Never mind, just saw it was different usernames. — xaosflux Talk 23:06, 13 April 2019 (UTC)
@Xaosflux: thanks for helping! --DannyS712 (talk) 23:07, 13 April 2019 (UTC)
@DannyS712: I am fairly certain redirects are not followed for loading of Javascript. --Izno (talk) 22:02, 14 April 2019 (UTC)
@Izno: The "redirect" that was left behind was:
/* #REDIRECT */mw.loader.load("//en.wikipedia.org/w/index.php?title=User:DannyS712/Meta.js\u0026action=raw\u0026ctype=text/javascript");
which means that anyone that imports the redirect also loads the new page. While the normal syntax of redirects isn't followed for loading javascript, moving javascript pages creates redirects with a different syntax. --DannyS712 (talk) 22:06, 14 April 2019 (UTC)
Yep, and they are just a mess. But if you import someone else's personal js pages you shouldn't expect any stability anyway. — xaosflux Talk 22:09, 14 April 2019 (UTC)
@DannyS712: The problem with these kind of "redirects" is that everything from &action=raw comes back with cache-control: private, s-maxage=0, max-age=0, must-revalidate which means that on a high-latency connection you're making the user wait for a chain of HTTP 304s until the browser reaches the actual script. Ideally &action=raw should respect &maxage= like API does, but as it stands there's no (non-hacky) way to override the default cache-control header when loading scripts that are unlikely to change. See phab:T71460. Suffusion of Yellow (talk) 22:43, 14 April 2019 (UTC)
@Suffusion of Yellow: as I noted above, I agree this is messy, but it's not really DannyS712's fault, this goes back to the 'use at your own risk' status of importing someone else's personal scripts v.s. using a community maintained gadget. — xaosflux Talk 23:40, 14 April 2019 (UTC)

Copy of a deleted script

Hi. Are any IAdmins willing to provide me with a copy of User:Flooded with them hundreds/VisualEditist.js? I'd like to take it over (see User talk:DannyS712#Adopting another user script for more). If yes, please restore it to User:DannyS712 test/VE.js. Thanks, --DannyS712 (talk) 04:26, 25 April 2019 (UTC)

It's just this:
$.when( mw.loader.using('mediawiki.util'), $.ready ).then( function() {
    mw.util.addPortletLink( 'p-views', mw.util.getUrl(mw.config.get('wgPageName')) + '?veaction=edit', 'VE', '', 'Edit this page in VisualEditor', 'e');
} );
:
If it's just one person using this I think it'd be easier to just tell them, assuming they care. ~ Amory (u • t • c) 10:09, 25 April 2019 (UTC)
@Amorymeltzer: Thanks for the copy. I'll tell them, but I'd also like to try the script for myself. Thanks, --DannyS712 (talk) 02:25, 26 April 2019 (UTC)

Inactive interface administrators 2019-04-28

The following interface administrator(s) are inactive:

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

 Done — xaosflux Talk 00:45, 29 April 2019 (UTC)

Not being able to access my common.js due to other account being redirected

Resolved
 – There were likely easier ways to do this, but this was the quickest way to close this out. — xaosflux Talk 23:49, 19 May 2019 (UTC)

User:HawkAussie/common.js
So I had requested that my username on both of my accounts so that it would be HawkAussie (main) and AussieHawk (secondary) instead of Matt294069 (main) and HawkAussie (secondary) that it was. This went well until I tried to access my common.js for this account and it's stating that it's not available due to the redirect from HawkAussie to AussieHawk. So can you please give me to access to this for me. HawkAussie (talk) 23:24, 19 May 2019 (UTC)

@HawkAussie: for redirected pages you will need to log in with the actual account that is associated with the page to make .js edits. If you just want it deleted you can make a speedy deletion request on its talk page as any admin can delete the page. — xaosflux Talk 23:31, 19 May 2019 (UTC)
@Xaosflux: I have tried using the other account but that is not working as it's only accessible for this account and the interface team. And I attempted to use a speedy deletion request but because it's a redirect for my other account, that won't be able to apply either. HawkAussie (talk) 23:37, 19 May 2019 (UTC)
@HawkAussie: ok - we don't really have a way to "give you access" - do you want User:HawkAussie/common.js deleted? — xaosflux Talk 23:39, 19 May 2019 (UTC)
Or just blanked out? — xaosflux Talk 23:40, 19 May 2019 (UTC)
@Xaosflux: Properly blanked out so that it will be able to work on it. HawkAussie (talk) 23:41, 19 May 2019 (UTC)
 Done @HawkAussie: it has been blanked, let me know if you need anything else on this. — xaosflux Talk 23:43, 19 May 2019 (UTC)
Thanks for that, I am able to edit it now. HawkAussie (talk) 23:44, 19 May 2019 (UTC)

Inactive interface administrators 2019-05-28

The following interface administrator(s) are inactive:

— JJMC89 bot 23:19, 28 May 2019 (UTC)

 Done — xaosflux Talk 23:28, 28 May 2019 (UTC)
eraser Undone as there was 1 deleted edit on 2019-05-09. — xaosflux Talk 23:33, 28 May 2019 (UTC)
The re-load should make the bot be quiet for a month at least! — xaosflux Talk 23:37, 28 May 2019 (UTC)
I think it checks when the bit was granted, and won't report based on using the tools until they've been an int-admin for six months. Good thing RS edited their talk, so there's no issue of having it removed in one month after only technically having the perm for two months! ~ Amory (u • t • c) 16:15, 2 June 2019 (UTC)
I mean, realistically, this person HAS been inactive - but the policy is very forgiving, and only admins can audit this. I've got no concerns for this access for this person, but do think these things should all require "publicly accessible" logs/edits for transparency. — xaosflux Talk 01:20, 3 June 2019 (UTC)
For CSS/JS edits, yes it waits until they've been an iadmin for 6 months. For the 2 months with no edits or logged actions, it doesn't. So we could be back here on 28 August at the earliest. — JJMC89 (T·C) 02:02, 4 June 2019 (UTC)

Request for moving a script page

Tracked in Phabricator
Task T225366

Can an iadmin please move User:SD0001/UNBIO-article-links.js to User:SD0001/UnassessedArticleLinks.js (because it has upgraded to take care of more stuff than just CAT:UNBIO)? Unable to do so myself because I keep getting a fatal error of type "InvalidArgumentException". SD0001 (talk) 14:48, 19 June 2019 (UTC)

 Doing... checking on this. — xaosflux Talk 14:58, 19 June 2019 (UTC)
 Done @SD0001: not sure why you were getting that error, but the move is done. Would you like the redirect deleted? — xaosflux Talk 15:01, 19 June 2019 (UTC)
No need to delete the redirect. Thanks. SD0001 (talk) 15:03, 19 June 2019 (UTC)
The error is phab:T225366. (I seem to be advertising that one of late.) --Izno (talk) 16:24, 19 June 2019 (UTC)

U1 deletion of javascript subpage

Would someone please delete User:Wugapodes/FAC Image Check.js under WP:CSD#U1. It doesn't have much functionality, and I'm pretty sure it duplicates an existing alt-text script that is much better. I tried adding the U1 tag but I don't think templates work on .js pages? Thanks in advance. Wug·a·po·des​ 23:10, 19 July 2019 (UTC)

 Already done - any admin can delete (but not restore) those pages. — xaosflux Talk 23:26, 19 July 2019 (UTC)
Thanks, good to know! Wug·a·po·des​ 23:45, 19 July 2019 (UTC)

Inactive interface administrators 2019-07-28

The following interface administrator(s) are inactive:

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

 Done — xaosflux Talk 23:26, 28 July 2019 (UTC)

Global contribs link?

I hope this is the right place to ask. I just noticed (from the link on commons) that the global contribs tool seems to be working again. Would it be possible to have the link added back to the contribs page here? Thanks, –Deacon Vorbis (carbon • videos) 02:10, 9 August 2019 (UTC)

Comment. I sent this user here via WP:Discord. If it's the wrong place, blame me. –MJL ‐Talk‐☖ 02:31, 9 August 2019 (UTC)
@Deacon Vorbis: If you're talking about https://tools.wmflabs.org/guc/, it should already be there. --DannyS712 (talk) 02:32, 9 August 2019 (UTC)
That's because I just put it there :) — xaosflux Talk 02:34, 9 August 2019 (UTC)
@Xaosflux: oh, thanks --DannyS712 (talk) 02:37, 9 August 2019 (UTC)
(edit conflict) Done @Deacon Vorbis and MJL: I made the change, but it didn't require an IAdmin. For reference any admin can maintain that footer via Template:Sp-contributions-footer (and anyone can put edit requests on its talk page). Best regards, — xaosflux Talk 02:32, 9 August 2019 (UTC)
Cool, thanks all! –Deacon Vorbis (carbon • videos) 02:37, 9 August 2019 (UTC)

User:Mr. Juicyfun/common.js

I'm trying to clean up the Category:Shortcut templates with missing parameters maintenance category, and the only page that's left is User:Mr. Juicyfun/common.js. Mr. Juicyfun was blocked for disruptive editing. What he's done here is copied the Module:Shortcut Lua code into his common.js file, and somehow, the Shortcut module is being called and adding the js to the maintenance category. Can the page be cleaned up so that it's no longer put in the maintenance category, either by commenting the code out or by deleting the page? Harryboyles 02:44, 17 August 2019 (UTC)

 Done @Harryboyles: this page was deleted. — xaosflux Talk 14:10, 18 August 2019 (UTC)
Thanks a lot.Harryboyles 09:23, 19 August 2019 (UTC)

Wikipedia:Geonotice requests for August 2019

Hi, there are a couple of Wikipedia:Geonotice requests, one from 8 August 2019, & mine from 16 August 2019. However, neither of these have been added to Wikipedia:Geonotice/list.json. Is this the right place to ask an interface administrator to take a look? Peaceray (talk) 05:00, 19 August 2019 (UTC)

@Peaceray: both were handled by Galobtter - since any admin can edit the json page, in the future you may want to post at WP:AN instead. --DannyS712 (talk) 05:49, 19 August 2019 (UTC)
It's okay, he didn't know. Peaceray, you're welcome to post here, even if you think that it might belong elsewhere. :-) ~Oshwah~(talk) (contribs) 09:33, 22 August 2019 (UTC)
Sorry, I didn't mean to imply otherwise - of course you can post here, but if its urgent AN may be more help. Glad it was resolved --DannyS712 (talk) 09:34, 22 August 2019 (UTC)
I've fixed up the directions for getting help on that. — xaosflux <spanstyle="color:#009933;">Talk 11:52, 22 August 2019 (UTC)
Thanks everybody. Yes, there were a couple of places in Wikipedia:Geonotice that pointed to here. I took care of one & xaosflux took care of the other. Peaceray (talk) 04:19, 23 August 2019 (UTC)

Inactive interface administrators 2019-08-28

The following interface administrator(s) are inactive:

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

 Done notified user and removed. — xaosflux Talk 01:49, 29 August 2019 (UTC)

Chess viewer

Would an interested interface admin please close and implement the consensus at Wikipedia:Village pump (technical)#Enable chess PGN viewer for chess articles? Wug·a·po·des​ 23:59, 22 August 2019 (UTC)

I'm seeing support that some people want this, but it looks like there is still some discussion on "HOW" to make it happen. Pings to @Galobtter and Izno: who were involved in that discussion. @Wugapodes: can you spell out exactly the technical changes you are asking for below (or are you asking for someone to create the technical solution)? For any of these changes, has this been tested here yet? — xaosflux Talk 00:39, 23 August 2019 (UTC)
As far as using this for changing the display of an article to our readers, what is the expected fall-back article state for readers without javascript, those using screen readers, etc? — xaosflux Talk 00:42, 23 August 2019 (UTC)
@Xaosflux: These are good questions to which I don't have great answers off the top of my head. @קיפודנחש: might know how they answered this question on the Hebrew Wikipedia; when I turn off javascript and navigate to a chess article page, it alerts me that I need to enable javascript to see the game. That may or may not be a fall-back state we want, I also see the merit in simply not displaying anything, but ideally the fallback state would not display the raw PGN to readers without javascript as it is unlikely to be useful to them. I'm not familiar with how screen readers work and what they pay attention to in the HTML, so if anyone has knowledge or input on that point, it would be appreciated. As you've probably already realized, the specifics of MediaWiki gadgets is not exactly my strong suit, and while I propose(d) a particular implementation I also recognize a lot of people have way more knowledge on this than I do. I would welcome anyone giving what they believe is a better solution than this one.
The idea is that there would be a template which takes as its input the raw PGN text and wraps it in an HTML tag with a ".pgn-source-wrapper" class. I suggested a <div>, but there are likely better solutions which would play nicely with screen readers and disabled javascript. It would be this element which the javascript looks for and processes. While Galobtter has a solution which is likely more elegant, I don't understand it fully and will leave to them to explain so that I do not mess it up. The implementation which I understand and have in the proposal is that the javascript and css currently in use on the Hebrew Wikipedia is copied to EnWikipedia. These files would be placed in MediaWiki:Gadget-pgnviewer.js and MediaWiki:Gadget-pgnviewer.css respectively, though there may be a more standard naming convention. MediaWiki:common.js would then be modified to load the gadget if it encounters a page with an HTML element having the ".pgn-source-wrapper", otherwise it would not be loaded to avoid unnecessary resource usage on the many pages that do not need it. Wug·a·po·des​ 01:33, 23 August 2019 (UTC)
  • I'm certainly a bit wary about running any script on every single page for every single reader just to see if there is a class that will be on <0.1% of articles. As far as fall-backs go, this isn't going to run for our huge number of readers on mobile, or on the wikipedia app this way. Is this only expected for desktop readers? — xaosflux Talk 02:21, 23 August 2019 (UTC)
    • That's understandable and a number of people, I think Izno was one, were concerned about that point as well. Galobtter I believe had a more typical solution? From what I understand, they suggested setting it as a default gadget, but in a way specific to the English Wikipedia. I think Galobtter explains it best here. From that comment it seems that the core gadget, in this case probably MediaWiki:Gadget-pgnviwer-core.j, would be loaded on demand by another gadget, MediaWiki:Gadget-pgnviewer.js. MediaWiki:Gadget-pgnviewer.js would be loaded as a default gadget, and that would be set up like MediaWiki:Gadget-geonotice.js which only loads the script when we need it to. Whether that is any different in terms of performance than the solution I suggested I am not really sure. Is your concern that searching the page in either case would still be a problem? I notice that MediaWiki:Gadget-geonotice.js only needs to perform a string comparison to check whether it should run. Wug·a·po·des​ 04:32, 23 August 2019 (UTC)
      • My initial concern is creep, having to load a different "is x here" on every single page read, for every single thing that someone may want to do something similar for will grow bloated. These cases are often better served by extensions (think of the media players, or even something small like the music score (probably a good example % of articles size). I'd like to hear more from Galobtter. If we really want to do this perhaps a check for some sort of "locally enhanced elements" that would only require 1 check that would then call the additional related helpers? — xaosflux Talk 11:22, 23 August 2019 (UTC)

Sorry for not having a great understanding of the technical implementation, but thank you for being so helpful by explaining what shortcomings you see. I've been reading up on extensions in the hopes that I can get this implemented at some point, and I get the sense that the most viable path is through an extension. Sorry if this is a bother, but would anyone be able to answer some questions I still have about extensions and perhaps give feedback on two possible implementations I'm thinking over?

  • Are extensions exclusively written in PHP?
  • Since extensions seem to run server side rather than client side, is it able to effectively handle interactive content such as the back and forward buttons on the chess game viewer?

If this were to be turned into an extension, my current idea is for the extension to output a chess board and the navigation interface in HTML so that the client-side javascript does not need to. It would use unicode glyphs for the chess pieces rather than images. I've got a working example in my sandbox at User:Wugapodes/sandbox4 (though it requires some css in User:Wugapodes/common.css to render properly), and I tested it with the GoogleVox screen reader which handles it well. Since it is in HTML and CSS if javascript is disabled the fallback would be displaying the starting position output by the extension.

I get a little stuck at this point with how to allow for the interactive content, hence the second question. For this to be server-side my understanding is that every click would require a get request from the server which does not seem ideal. An alternative would be to have a gadget which defines functions that are called when the interface buttons are selected, and these functions would change the board state. So while it would be on by default, other than the function definitions the javascript which makes it work would only be run when a user clicks a button on the interface which was constructed by the extension server-side. Many people are rightfully wary of site-wide javascript, but since I don't have the same depth of knowledge I'm not sure I can accurately evaluate which course would be better. Do these seem like they would work and move us in the right direction? Wug·a·po·des​ 21:12, 23 August 2019 (UTC)

The extension would have a PHP part that defines a tag (like extensions give us <ref> or <syntaxhighlight>), and a JS part that's basically the gadget which is loaded on the page by the use of the tag. Anomie⚔ 23:06, 23 August 2019 (UTC)
some answers to questions and reservations above
so i was mentioned above, with some questions. i will try to describe what we do on hewiki, and the rationale.
  1. javascript disabled: we display a message saying something like "this space is for the interactive game. in order to see it, enable javascript on your browser". IMO, this is reasonable: in a similar fashion, people reading wikipedia with text readers do not see images and videos, but this is not good reason not to show images and videos to the vast majority of readers who _can_ see images and videos. we do not display the raw PGN on hewiki, even though a reasonable reader of a chess article is likely to find it useful (more precisely, they'll find the "algebraic notation" part of the PGN useful). one reason not to display it, is,the fact that we tend to use the viewer to display multiple games (e.g., all the games of a championship, or the games of one round of a tournament, in a single viewer with game selector), and displaying all of them is not reasonable, and displaying just one is too arbitrary.
  2. mobile: this one is easy. if you activate the viewer on mobile (via Mediawiki:mobile.js), it works fine for mobiles too. it specifically sense for "minerva" skin, and displays without the tabs, as the tab library is not mobile-friendly. the question of "how does it look" on mobile is delicate: the script and css are somewhat "responsive", but on small enough devices it's less useful, e.g: on iphone 4, you can see the full board and notation, but you have to scroll to see the buttons and click "play". presumably, once you hit "play", scroll back a bit to see the full board). on "regular" iphone 6/7/8 (not "plus"), galaxy 5 and 6, and most other devices on the chrome simulation, it displays impeccably. what i'd suggest is to open, e.g., he:משחק האלמוות, and switch to mobile view. if you happen to use chrome, you can simulate different devices by clicking F12 and then hit the "mobile" icon at the left of the top toolbar. chrome will let you select the device, and the orientation. ruwiki, i believe, chose not to activate it on mobile. enwiki should choose. naturally, i believe what we did in hewiki (activating on mobile) is the better option. (note: if you use BRION's "mobile simulation, remember it's pretty old - it simulates a device significantly smaller than today's norm).
  3. cost of scanning the page to test for "some class", and worry about "creep": personally, i don't worry. practically, this is something our software already does dozens of times on each page load, and i think the cost (jquery) is negligible. i do not think "creep" is something to worry about at this point. if this becomes a real worry, i outlined in wp:vpt what ruwiki does, and what hewiki does in this regard: basically, safe and simple "on-demand" loading of scripts, which requires a single test for specific class in common.js, and loads all the content-dependent scripts when needed. adding a new script that can be loaded "on-demand", does not add the code run on page load for pages which do not need it, so once you implement this mechanism, the "creep" stops. i am not advocating for enwiki to adopt this mechanism ATM, i mentioned it here just to say that we can use such scripts with no "creep", and indeed, this viewer on hewiki and ruwiki adds zero code to each page load. there are ~ 10 lines in common.js (and on hewiki, another 7 on mobile.js), which run once, and handle all the "on demand" scripts. hewiki has about half a dozen such scripts, and ruwiki may have a bit more.
some more comments
now, the viewer is somewhat "configurable", by the template that activates it. the actual implementation of the template that generates it sets all those params. so the viewer behaves differently on ruwiki and hewiki. this is because the ruwiki and hewiki templates used for the viewer, provide it with different configurations, even though ruwiki did not copy the script locally, and loads it from hewiki when needed, so both literally run exactly the same script. if enwiki is to install the viewer, it should decide on parameters. local CSS modifications are also an option. so if enwiki is to activate the viewer, there are some decisions to make, regarding how enwiki wants it to behave. i would suggest consulting the chess community about the choices enwiki wants to make.
DISCLOSURE: i really really want to see this activated on enwiki, and it will give me some small ego boost, so please, do not hesitate to ask questions, and ask for my help. i will assist in any way i can, including actually doing some of the work (someone granted me "template editor" perms on enwiki, so there are some things i could do), and including making reasonable modifications to the viewer code.
peace - קיפודנחש (aka kipod) (talk) 04:37, 24 August 2019 (UTC)
קיפודנחש have you tried publishing this as an extension? Seems like that would make it a lot more adoptable, not to mention maintainable across projects (including non-WMF projects). — xaosflux Talk 22:40, 24 August 2019 (UTC)
@Xaosflux: no, and i am not going to. i briefly peeked into it, and as far as i can tell, it's a lot of bureaucracy, with little or no perceived value in this case. extensions make sense for extending the functionality on server side, and less so as a vehicle to send JS code to the client. getting it "sanctioned" as safe would be nice, but that's it, and it's not enough, considering the cost of making it an extension.
afaik, there already _is_ pgn viewer extension: mw:Extension:PgnJS. i briefly looked into it (TBH, i looked into it before writing my viewer, and though i think the code have improved since, i still don't like it). dozens of files, many thousands of lines, multiple CSS. IMO, it's not a well engineered piece (and i could not find any demo site). please look at both viewers code - "mine" is a single source file, with less than 1000 lines, and single CSS, with some 120 lines. read the code of both, and compare. i don't think the extension is "more adoptable".
i mentioned "making reasonable modifications to the viewer code" - unfortunately, making it an extension is outside this scope. peace - קיפודנחש (aka kipod) (talk) 23:43, 24 August 2019 (UTC)
For what it's worth, I'm looking into how viable it would be to turn this into an extension and would be willing to go through the bureaucracy if it means we get an interactive chess game viewer. I tried the test wiki linked to from mw:Extension:PgnJS, but it crashed in my browser so while a good place to start looking, I think more work will be needed. There's still a ton of things I don't know, but Kipod's JS could probably still be used and may actually be an improvement. PgnJS is rather big and has a number of dependencies that Kipod's script doesn't have. If the PGN parsing was moved out of his script and into PHP, the extension would probably be pretty light and efficient. Wug·a·po·des​ 05:15, 25 August 2019 (UTC)
  • My code creep concern is that while doing this for "chess viewer" isn't expensive, then we get another scan for "chemical viewer", "spaceflight path viewer", "dice roller", etc, etc. I still think that extension in general are better for these, but if we want to do this client-side we should plan for the future at the same time. Do you see any drawbacks to a multi-step process of: (1) single client check for "enhanced local content class" (2) Load the "enhanced local content manager" (3) load the script? In that method (1) can be very small and light and resuable for future enhanced content. This is meant to be high-level and some of these may be better "load the gadget). — xaosflux Talk 14:57, 25 August 2019 (UTC)
    IMO good should not be the enemy of perfect here - it would be nice if this was an extension, and if someone wants to put the effort into that (or vote for doing that in the community wishlist?), that would be good, but a gadget is still good to have. One - or even many - JQuery selector checks should not be particularly expensive either: their speed would be measured probably in the tens of thousands of operations per second. Nothing against a generic loader of enhanced local content, but if there is only gadget that can make use of it, I would personally wait until or if there are more gadgets doing such checks, to do that. Galobtter (pingó mió) 23:07, 25 August 2019 (UTC)
(edit conflict) before everything, disclaimer: i tend to be long-winded, and some would say tedious. sorry about that, but i'm going to be long-winded (at least) one more time - i interpret some of the above as questions addressed to me, and i'll try to answer the best i can.
@Xaosflux: - i don't want to sneeze at your concern, but (1) i don't see all those "on demand content-modification scripts" you mentioned. i did not see any "chemical viewer" or "spaceflight path viewer" or any of the other you mentioned proposed (TBH, i didn't see any of them at all) if there were such proposals which i missed - my bad. IMO, refusing something good because of some hypothetical "slippery slope" concern, which have no evidence of being real, is not good policy. (whether or not this viewer is "something good" is a different question. the consensus on wp:vpt seems to indicate it might be).
as to your question: this can be done simpler than what you alluded to "multi-step process of: (1) single client check for "enhanced local content class" (2) Load the "enhanced local content manager" (3) load the script?". i outlined in wp:vpt what ruwiki is doing (10 lines in ru:mediawiki:common.js, from #321) and what hewiki are doing (12 lines in common.js, plus 7 in mobile.js). see line #261 and forward in he:Mediawiki:common.js. i will outline it here again:
  1. in common.js, look for one specific class (we use "executeJS").
  2. for each element found with this class, look for "data-script" and "data-gadget" attribute (in mobile.js, look, e.g., for "data-mobile-gadget")
  3. the content of the data attribute, indicates which script or gadget should be loaded. these scripts and gadgets must reside in a very specific place in mediawiki namespace: for scripts, their name _must_ look like "Mediawiki:Script/<script name>.js", and for gadgets, they _must_ be hidden gadgets whose name look like "Mediawiki:Gadget-ondemand-<gadget name>" (gadgets in hewiki only- ruwiki does not use this mechanism for gadgets). naturally, it means interface editors should vet the scripts and gadget that match these patterns as if they are vetting common.js itself.
  4. from usability POV, this is exactly the same as "template styles": in a similar manner to the way a template can demand some extra CSS, by loading a "templatestyle", a template can demand some extra JS, by transcluding a template called "Script load", and passing the desired script as parameter. the mechanism is simple, contains almost no "moving parts" (10 lines in common.js and one template), safe, cheap, and adds a useful functionality. we (hewiki) use it for several such scripts: not those you mentioned, but, e.g., a script that enhances the usability of "image map", a script that allows use of "Tabs" (mainly in "portal" namespace), without having to always load the tabs library, the pgn viewer, and some more.
so bottom line: i'm not sure i fully understood your description, but inasmuch as i did, it sounds more complex than it should be. there is no need for "enhanced local content manager". those unenhanced dozen lines in common.js do it as well as it can be done.
if you ask i i'd recommend enwiki to copy this mechanism - i think the fact this is what hewiki does is all the recommendation i can give. i did take part in the discussions and in the implementation, and i think it's good and useful.
if think about doing something similar, i suggest you read 2 sources linked above, note the differences, and either use one or the other, or do something similar yourself (for hewiki, we use this mechanism for mobile too, so there's some code in mobile.js too).
@Wugapodes: feel free to do with this script anything you like - please read the "license" at its top. it is much more liberal than CCbySA. it basically says "do whatever you want with this". FWIW, i do not think wrapping it in an extension will add any value. you write "If the PGN parsing was moved out of his script and into PHP, the extension would probably be pretty light and efficient". if i may say so myself, the currnent implementation is already light and efficient. (FWIW, i did write another PGN parser in LUA (which is also used on enwiki), and is used to display multiple {{Chess diagram}}s from a single game, by passing to the template the PGN, and list of positions you want to show from the game)
iiuc, what you propose is for the extension to parse the game, and then pass this parsed game, using some notation you'll have to invent, to the script. forgive my french, but this is back-assward. we already have a perfectly good (and standard) notation to describe the game - it's called algebraic notation or pgn. the script does not break a sweat parsing the PGN, and your proposal describes a bad solution to a problem that does not exist.
bottom line: i see zero value in wrapping this in an extension (getting the "this is safe" seal from mediawiki team will be sweet, but this is a "political", not a technical consideration). you are welcome to do it, of course, but i do not think it will be good investment of your time.
@Galobtter: i totally agree (i know you did not really ask me, but anywhoo).
peace - קיפודנחש (aka kipod) (talk) 00:12, 26 August 2019 (UTC)
As far as using something reusable, what is the scope of the deployment for chess viewer expected to be? Even if this was used on every single page in Category:Chess recursively (which is a stretch) this would be used on <~0.01% of pages for an extra script that is needed on every page view. That is why I'm suggesting that if we want to do support for minority use scripts that we give them a single wrapper/loader so that when the next project comes along we don't have to have this discussion again. — xaosflux Talk 01:57, 26 August 2019 (UTC)
I would like to get the opinion of a WMF engineer. Jdl seems like a good resource here, but I'll take as many opinions as not. (I'm not sure who all has experience with JavaScript.)
As for the current fallback content on the external wikis, absolutely not ok. Advanced gadgets should fail or degrade gracefully; this case should naturally leave the Pgn visible.
This should still be an extension, regardless. It will be extra JavaScript (however small) delivered to every user of the platform, for benefits on some tiny proportion of articles; an extension would take care of that price. The other clear and obvious benefit is multi-wiki/multi-tool support in a way adding this script piecemeal will not provide. --Izno (talk) 02:15, 26 August 2019 (UTC)

I've managed to get mw:Extension:PgnJS set up on a test installation of mediawiki 1.33.0 and it seems to work fine. When javascript is disabled, it does not display any output. As a place to start, that seems the best option. I'm not sure if it passes the security standards to be deployed on the English Wikipedia, so that would need to be figured out and potentially fixed before anything else. Eventually the back end should probably be replaced with Kipod's code; the extension has not been updated in two years and it is worth having code that someone knows and actively maintains over potentially stale code. What does everyone think of that? Wug·a·po·des​ 03:14, 27 August 2019 (UTC)

  • For whatever my opinion is worth, I've been following that discussion off and on, and I pretty much agree with Galobtter: I think it's a good enough solution to convert the code and loader into a gadget and include it in the gadgets section. I definitely would *not* support modifying common.js directly, but that shouldn't be necessary if we make things a gadget. I don't know that anything more heavyweight, like extensions, needs to be done. Writ Keeper ⚇♔ 14:52, 27 August 2019 (UTC)
    @Writ Keeper: I'm not opposed to the gadget route - as far as implementation what do you think of my idea of a generic "loader gadget" that then spins up any needed other gadgets (vs an always-on gadget, or a feature specific loader gadget that loads the feature gadget)? — xaosflux Talk 15:00, 27 August 2019 (UTC)
    Mmm, I feel that what prevents the proliferation of loader scripts for minority applications from being a problem is simply that, being gadgets, they can be turned off in Special:Preferences if you don't like the performance hit. I do like your common loader idea, though. Something like: create the code for gadget <X> in Mediawiki:gadget-<X>.js, per usual, but make the common loader class the only defined dependency of <X> in Mediawiki:Gadgets-definition, so that the only resource that's loaded on pageview is the common loader (i.e. <X>[ResourceLoader]|commonLoader.js). Then, it can go through and do something like:
    if(mw.user.options.get("gadget-<X>") == 1) && $(".<enhanced HTML class name>").length > 0)
{
	mw.loader.load("/w/index.php?title=Mediawiki:gadget-<X>.js&action=raw&ctype=text/javascript");
}
    ...as a check to load the gadget itself, for each gadget that is supported by the common loader. Is that like what you're thinking of? Writ Keeper ⚇♔ 15:26, 27 August 2019 (UTC)
regardless of the actual mechanism to trigger the load, i think it's best to place the actual code in a hidden gadget, so the parameter you pass to the loader is not "/w/index.php?title=bla", but rather "ext.gadget.bla". some advantages are minimization, dependencies, and loading both js and css in one operation.
as to the triggering mechanism: personally, i do not see 3 lines added to common.js as a deadly sin - look at the content of this file now. it's filled with "special cases" stuff that do more work than sensing for a class and calling the loader, also for a small number of cases (BTW: this "extraJS" and "ExtraCSS" from address line seems fishy. what are they for?).
ALSO: some change to mobile.js can't be avoided if this is to work for the > 50% mobile readers (as mentioned, the viewer is happy to show on mobile - i suggest you try it on hewiki [ruwiki chose not to activate for mobile] ). peace - קיפודנחש (aka kipod) (talk) 17:07, 27 August 2019 (UTC)

Moving forward

Wanted to bump this again for those who are still interested. @Xaosflux and Writ Keeper: you both seemed to have been having a productive discussion on implementation; what are your thoughts on how to move forward with this? Wug·a·po·des​ 23:16, 1 September 2019 (UTC)

In case there are some who have not examined the relevant lines from the Hebrew Wikipedia common.js file, here it is:

Extended content

Attribution: he:Mediawiki:common.js 

// On demand loading of scripts and gadgets, initial version from ruwiki.
// Detects uses of templace "טען סקריפט"
// and loads specifically-named scripts or gadgets.
// for a script to be loadable this way, its name must begin with "Mediawiki:Scripts/"
// for a gadget, its name as defined in gadgets-definition must begin with "ondemand-"
if ( mw.config.get('wgCanonicalNamespace') !== 'Special' ) 
mw.hook( 'wikipage.content' ).add( function( content ) {
		var beenthere = {};
		$( '.executeJS', content ).each( function () {
			var script = $( this ).data( 'scriptname' );
			if ( script && $.trim( script ) ) {
				script = $.trim( script );
				if ( ! beenthere[script] )
					mw.loader.load( "/w/index.php?title=Mediawiki:Scripts/" + script + ".js&action=raw&ctype=text/javascript", "text/javascript" );
				beenthere[script] = true;
			}
			var gadget = $( this ).data( 'gadgetname' );
			if ( gadget && $.trim( gadget ) ) mw.loader.load( 'ext.gadget.ondemand-' + $.trim( gadget ) ); // np repetitions - resourceloader takes care
		} );
} );

As Kipod said, for each element with an "executeJS" class, the data attributes for scriptname and gadgetname are examined and the corresponding code loaded. This implementation is generic and will be able to accommodate future on-demand scripts, if desired and approved to be available to the on-demand mechanism. As suggested earlier, if the English Wikipedia implementation were to be limited to on-demand gadgets, the loading code could be put into a special on-demand loader gadget that is a dependency of the gadget. isaacl (talk) 17:43, 3 September 2019 (UTC)

Undeletion of User:James-the-Charizard/common.css

Back in April of this year, I tagged my common css as CSD U1 since I didn't want it at that moment. I would like the page back, but have it blanked. (So I can keep the history of the page.) James-the-Charizard (talk) 18:13, 7 September 2019 (UTC)

 Done @James-the-Charizard: restored. — xaosflux Talk 19:40, 7 September 2019 (UTC)

Reply link

I have left a message on User_talk:Enterprisey/reply-link#Reply_link_and_the_Teahouse. If Enterprisey doesn't respond within 48 hours, could you try to fix the script? Interstellarity (talk) 14:28, 12 September 2019 (UTC)

@Interstellarity: User:Enterprisey/reply-link.js is a personal user script and the user is not inactive. We generally do not alter anyone's personal scripts without very good reason. You are free to fork that script to your own space. — xaosflux Talk 15:22, 12 September 2019 (UTC)
Also note, the disclaimer at the top of User:Enterprisey/reply-link Warning! This script is still being tested and debugged. Bugs are still present.. — xaosflux Talk 15:23, 12 September 2019 (UTC)
 Request withdrawn by requester per Special:Diff/915326812. Discussion is always welcome below if anyone else has anything to add. — xaosflux Talk 15:52, 12 September 2019 (UTC)

#p-pagetriage-enqueue on Main page

Tracked in Phabricator
Task T207485

Hmm, WP:ITSTHURSDAY? Think this is new, and really it doesn't belong on this page - any suggestions for the 'best' way to remove this. Appears as pagetriage-enqueue in the "tools" section of the sidebar. — xaosflux Talk 16:16, 27 September 2019 (UTC)

And yes, I'm already thinking about Main_Page/styles.css or the like........ — xaosflux Talk 16:17, 27 September 2019 (UTC)
This is to allow loading of curation toolbar on "any" page. It really shouldn't show on mainpage, but no one thought of that on the phab task and when the code was merged. – Ammarpad (talk) 16:36, 27 September 2019 (UTC)
Do you have a link to the task where it's being discussed? ~ Amory (u • t • c) 16:52, 27 September 2019 (UTC)
Hmm, phab:T207485 maybe. — xaosflux Talk 16:55, 27 September 2019 (UTC)
Yes, thanks Xaosflux. – Ammarpad (talk) 16:57, 27 September 2019 (UTC)
(edit conflict)Is adding the main page to the queue something we can prevent from taking place via edit filter? I'm not sure about it, but might that be cheaper? At least until it's dealt with in the software. It's only a brief amount of CSS, admittedly, but it does get an awful lot of views... It's not super urgent, so I might be inclined to let it lie for a bit since that phab seems pretty well watched. ~ Amory (u • t • c) 16:56, 27 September 2019 (UTC)
Well, it's not like everybody is seeing the link. It's only visible to people with the right permission. – Ammarpad (talk) 16:59, 27 September 2019 (UTC)
Indeed my point — css would be loaded for everyone, it's not urgent, and folks who can and would use it are likely not going to do so for the main page. Should be removed/fixed/etc. but preferably (IMO) by the software itself. ~ Amory (u • t • c) 17:02, 27 September 2019 (UTC)
@Amorymeltzer: patch filed DannyS712 (talk) 17:26, 27 September 2019 (UTC)
... +2 by MusikAnimal - should be deployed on wiki by Monday DannyS712 (talk) 18:01, 27 September 2019 (UTC)
Could use MediaWiki:Group-patroller.css and MediaWiki:Group-sysop.css to not load css for everyone. Galobtter (pingó mió) 23:05, 27 September 2019 (UTC)
Note, this seems to create a new dead-end workflow for an editor, if you unreview a page you authored, you can't undo your action. See phab:T234067. — xaosflux Talk 17:08, 27 September 2019 (UTC)
  • Hmm, If my analysis is correct, overall this change is probably problematic (or maybe I should say not well thought out). Theoretically, clicking the link will "unreview" the mainpage, and therefore noindexed until re-reviewed. I just tested it at Test (I use the page since it only loads on mainspace pages). I don't know how this feature will interact with what was described here. If it's true that after 90 days mainspace articles cannot be de-indexed, then a useless link is now being shown on >5 million pages, this is not ideal. If this new feature works as it says on the tin, then it's really problematic; because now (some) people have the power to de-index a 10-year old page, heck even the mainpage and it's 2001 contemporaries. I don't think the community approve of this. – Ammarpad (talk) 17:21, 27 September 2019 (UTC)

Hello, everyone. My name is Ilana, and I'm the product manager for the Community Tech. We're currently looking into the issue, and we plan to dig into it on Monday. In the meantime, here is some background information, as provided by the engineers: "We implemented the 'add to queue' functionality per request of the NPP community. But you are right; weighing things out, it seems like we need broader consensus, to say the least. The original request, by the way, was to simply be able to use Page Curation's tagging features on any page. This unfortunately isn't how it works; the page must be in the 'queue' for the Page Curation toolbar to be functional (it also has to do with scope, e.g. Page Curation is supposed to be only for 'new' pages). So the compromise was to introduce the workflow (a) add page to queue, (b) tag as desired, (c) re-review, or leave unreviewed at the reviewer's discretion. We can revert this change if you all feel it is necessary, but I don't think we can do any deploys until Monday." IFried (WMF) (talk) 20:59, 27 September 2019 (UTC)

Hey IFried (WMF), thanks for the update. If you want a further conversation on the (un)deployment of the tool itself, you'd probably be better off at WT:NPP or WT:NPP/R; this board won't garner the interested parties to opine or provide feedback on that. And as for I don't think we can do any deploys until Monday, it is Friday of course! ~ Amory (u • t • c) 21:13, 27 September 2019 (UTC)
@IFried (WMF): this doesn't seem to be any "rush" situation (also why we are using this somewhat backwater technical coordination page to talk about it right now) - and I don't think anyone here sees a specific problem with what was trying to be accomplished, just with the unintended consequences - as well as making sure it is well documented and understood. Keep in mind the difference between "patrolled" and "reviewed" here, as well as what (or not what) impact is made against NOINDEX. — xaosflux Talk 21:27, 27 September 2019 (UTC)
Regarding "add to queue" is this also "un-mark as reviewed" / mark as "unreviewed"? — xaosflux Talk 02:13, 28 September 2019 (UTC)
If you click the link and confirm (which I believe is what you mean by "add to queue"), two log entries will be generated:
  1. 17:05, 27 September 2019 Ammarpad talk contribs marked Test as unreviewed (Tag: PageTriage)
  2. 17:05, 27 September 2019 Ammarpad talk contribs added Test to the New Pages Feed (Tag: PageTriage).
They inverted here, so the second log entry is what happens first, then followed by the first. – Ammarpad (talk) 05:23, 28 September 2019 (UTC)
Thanks @Ammarpad:, the NOINDEX notes refer to 'patrol' status not 'review' status, so that shouldn't change here. — xaosflux Talk 12:07, 28 September 2019 (UTC)
I admit these really confuse me. What does "review" do to a page then? – Ammarpad (talk) 03:55, 29 September 2019 (UTC)
@Ammarpad: see this log as an example. "Review" puts a page in to or out of the review queue, there is overlap though - since using the review tools will also cause a page to be "patrolled". It is possible to patrol a page alone as well - we have two systems that ride on top of each other, and the implementation at enwiki is different from most other projects. Currently you can mark a page "unreviewed" as well, but there is no way to "unpatrol" a page (and I don't think this is trying to create one). — xaosflux Talk 04:06, 29 September 2019 (UTC)

Update for everyone, including @Xaosflux, Ammarpad, and Amorymeltzer: We've investigated the issue and confirmed that adding old pages (>90 days) to the queue will not remove them from search results. However, we identified that our changes did introduce the ability to unreview the Main Page, which should never occur. For this reason, a fix (thanks to DannyS712) has been developed, and it should be on production tomorrow. Thanks for your assistance and flexibility as we looked into the issue! --IFried (WMF) (talk) 20:01, 2 October 2019 (UTC)

Thanks for the info. IFried (WMF). – Ammarpad (talk) 05:26, 4 October 2019 (UTC)

editToken --> csrfToken migration

There exist no lesser than 212 user scripts that have been rendered dysfunctional by the recent removal of editToken from the mw.user.tokens object in the JavaScript interface. (See phab:T234576.) It would be great if someone can fix all these in one go by using some automation to replace editToken with csrfToken, or to be precise, doing the regex replace mw\.user\.tokens\.get\( ?['"]editToken['"] ?\) → mw.user.tokens.get('csrfToken') . This would be helpful since many of these scripts are probably written by inactive users. SD0001 (talk) 19:09, 14 October 2019 (UTC)

Probably better to reference phab:T235300 because it includes the more-correct way to deal with edit tokens. That said, Krinkle has a bot for the replacements; not sure how/why these didn't get taken care of. --Izno (talk) 21:44, 14 October 2019 (UTC)
I think he only looks at MWspace gadgets, not user scripts, and also only saves if it passes some other checks. I'm in favor of this sort of thing for this type of change, as it's quite amenable to a quick search and replace without touching much else, and the deprecation was felt sudden. I'm happy to try to take care of it later this week (wed, thurs, fri) if other folks think it'd be welcome. That being said, to the best of my knowledge we've had no good conversation about intadmins doing this sort of bulk work, and while I would consider it a net positive I imagine some folks might take issue. At least some of these are certainly actively used, though there's no perfect way to assess what's abandoned or what's worth doing, so we'd have to cover them all. ~ Amory (u • t • c) 01:26, 15 October 2019 (UTC)
I'm not a big fan of trying to maintain broken personal user scripts without being asked by the owners. No issue with dropping a bulk TALK notice on them about this discussion in case the owners want to look after their scripts. — xaosflux Talk 02:35, 15 October 2019 (UTC)
^This, generally speaking. Writ Keeper ⚇♔ 13:47, 15 October 2019 (UTC)
👍 ~ Amory (u • t • c) 17:08, 17 October 2019 (UTC)
I can't understand what's the reluctance against making an unambiguously positive change to hundreds of scripts that will unbreak many of them. It is far-fetched to call this "trying to maintain broken personal user scripts" - when it's clearly a single maintenance edit that can be done en masse. The 150 or so scripts that remain (Krinkle has fixed the remaining ~60 since the time of the original post) can be fixed in <1 minute by writing some javascript that any iadmin could have written in <10 minutes:
mw.loader.getScript('/w/index.php?title=MediaWiki:Gadget-morebits.js&action=raw&ctype=text/javascript').then(function() {
   // morebits library loaded to use its Morebits.batchOperation class used for bulk api processing 
	var searchResultsPage = 'https://en.wikipedia.org/w/index.php?title=Special:Search&limit=250&offset=0&ns2=1&search=insource%3A%2Fmw%5C.user%5C.tokens%5C.get%5C%28+%3F%5B%27%22%5DeditToken%5B%27%22%5D+%3F%5C%29%2F+intitle%3A%22.js%22&advancedSearch-current=%7B%7D';

	var api = new mw.Api();

	$.ajax(searchResultsPage).then(function(html) {
		var listOfPages = $(html).find(".mw-search-result-heading a").get().map(e => e.textContent);
		var bo = new Morebits.batchOperation('');
		bo.setPageList(listOfPages);	
		bo.run(function doForEachPage(page) {
			api.edit(page, function(rev) {
				return {
					text: rev.content.replace(/mw\.user\.tokens\.get\( ?['"]editToken['"] ?\)/g, "mw.user.tokens.get('csrfToken')"),
					summary: 'Update deprecated user.tokens key',
					watchlist: 'nochange'
				};
			}).always(console.log);
		});
	});

});
But instead, it looks like people want to play bureaucracy and/or show high-handedness given the exclusivity of iadmin powers. SD0001 (talk) 19:52, 17 October 2019 (UTC)
I support a bulk change. I can't think of any compelling reasons not to make it. xaosflux, why do you think any owners might object to this change? Enterprisey (talk!) 00:49, 18 October 2019 (UTC)
Enterprisey Mostly just because it is busy work, like cleaning up a lint error in someone's personal sandbox for someone that has left the project - only for these pages it should be even less useful as the page will be even less read by others. Administrators shouldn't have to dedicate resources to maintaining dead single-use personal pages. As the change doesn't seem in any way "dangerous" I'm not really opposed to someone working on it - just that of all the backlogs on the project the priority of this is very very low. — xaosflux Talk 00:59, 18 October 2019 (UTC)
Okay, cool, so you'd be fine with someone doing this. Writ Keeper and Amorymeltzer, since you commented below xaosflux's earlier comment, would you oppose someone actually making this change? Or were you just agreeing with the point that we shouldn't be continuously maintaining old, broken scripts? Enterprisey (talk!) 01:03, 18 October 2019 (UTC)
With my intadmin hat on, it's more the latter, but my strongest feelings are honestly with my userscript-writer hat on. I would much rather be asked to fix something and take responsibility to fix it myself than have someone else do it for me, for reasons similar to Wugapodes below, among others. Writ Keeper ⚇♔ 01:52, 18 October 2019 (UTC)
Fine enough, for this specific change this time - but I don't think it's the "best" thing to do and would rather people self service their own pages. Things that could help that may include some wishlist items like: Have a notification if any of your current scripts have an error in them, have the script editor call out "broken" things in the editor. — xaosflux Talk 02:01, 18 October 2019 (UTC)
As I said above, I think this particular case is amenable given the straightforward find-and-replace nature of it, and I'm happy to do it, but in general I'm mixed on it. Intadmins were created for security purposes first and foremost, and I'm not certain there's consensus on-wiki for us to mass-edit userpages; we should be careful not to try to WP:OWN everything with a .js or .css suffix. There's a lot of junk that's quite outdated — I myself have an old script that I don't like and I'm not sure worked even before this change — and aside from pointless edits, I do think we'd be suggesting that broken things might be "fixed" even when they have other issues. When there are more complicated fixes, we don't want to be on the hook.
What might be worth doing is to create a list of "most imported" scripts and try to target those, although what we'd really want is "most imported by recently-active users" which is rather more involved. ~ Amory (u • t • c) 10:17, 18 October 2019 (UTC)
we'd be suggesting that broken things might be "fixed" - I definitely understand your line of argument. I'm finding it hard to think of how we would be giving that impression, though - if a script was already broken, this change won't fix it, so all we're doing here is restoring functionality of scripts that broke recently.
I think most imported by recently-active users is certainly one solution, but given that there are fewer than 100 scripts with this issue (statistics from SD001's post above - I haven't checked) a more straightforward batch change would probably work as well. Enterprisey (talk!) 01:03, 19 October 2019 (UTC)
  • I think a bulk talk message would be the better option. I didn't know what the problem with WP:Capricorn was until I asked Amory if they were also having problems with the script. For editors who maintain scripts but aren't up to speed on the nitty gritty of mediawiki update, knowing that the process of getting tokens has been updated would probably be slightly more useful than just having it changed. Teach a man to fish and all that. Wug·a·po·des​ 01:42, 18 October 2019 (UTC)
    What about inactive script authors who probably won't fix their scripts? Enterprisey (talk!) 07:47, 18 October 2019 (UTC)
    If they are inactive they won't be using said broken scripts then will they? — xaosflux Talk 11:07, 18 October 2019 (UTC)
    What about active users importing those scripts? Scripts are hardly ever written for the author's sole use. SD0001 (talk) 12:14, 18 October 2019 (UTC)
    Really this is a caveat emptor problem. We really should be encouraging "popular" scripts to move in to gadget land so they can be more properly community-maintained. — xaosflux Talk 13:52, 18 October 2019 (UTC)
    Sure, I agree with that, but it might take a while. What about making the fix now? In my opinion this is a one-time issue that should be dealt with relatively soon, and only if this sort of thing becomes a pattern should we consider more long-term changes like that. Enterprisey (talk!) 01:00, 19 October 2019 (UTC)

.refbegin and .reflist

Does anyone know if there's a reason why {{refbegin}} has its own class that is identical to the .reflist class in MediaWiki:Common.css? There's a comment in common.css that says "Keep in sync with Template:Refbegin/styles.css" so it seems that the two are supposed to be identical. Is there something I'm missing or can I edit {{refbegin}} to use .reflist? Wug·a·po·des​ 00:10, 4 November 2019 (UTC)

@TheDJ: if you are around this is about your update. May have only been for a migration period? — xaosflux Talk 00:25, 4 November 2019 (UTC)
N.B.: Their userpage says they have notification and mentions turned off on enWiki. I left a message on their talk page. Wug·a·po·des​ 00:53, 4 November 2019 (UTC)
Wugapodes, you can edit refbegin to make use of both reflist and refbegin classes. Just note that for template styles it is good to prefix the CSS rules with a template specific class to avoid any conflicts. Them being separate is mostly an artefact of history, but also note that the underlying HTML for both is different and at times core html changes way before our html output (or way later). Keeping that distinction has use at times. —TheDJ (talk • contribs) 09:06, 4 November 2019 (UTC)

XFDcloser gadgetification

The VPT proposal was archived with several supports and no opposition after two and a half weeks. Can one of you int-admins help make this happen? From what I understand:

- Evad37 [talk] 04:15, 12 November 2019 (UTC)

This is the proper course. I didn't see this until now, but had I, I still would have suggested it! ~ Amory (u • t • c) 01:07, 14 November 2019 (UTC)
Okay, I made what I thought were the neccessary edits (see my contribs for today), per the above/following the guide at mw:Extension:Gadgets. It shows up in preferences as expected, but with it enabled (and my common/skin js disabled), it fails to load with console warnings:
Skipped unresolvable module ext.gadget.XFDcloser
Exception in resolve:
Error: Unknown module: ext.gadget.extra
    at sortDependencies (load.php?lang=en&modules=startup&only=scripts&raw=1&skin=timeless:8)
    at sortDependencies (load.php?lang=en&modules=startup&only=scripts&raw=1&skin=timeless:9)
    at resolveStubbornly (load.php?lang=en&modules=startup&only=scripts&raw=1&skin=timeless:9)
    at Object.load (load.php?lang=en&modules=startup&only=scripts&raw=1&skin=timeless:20)
    at load.php?lang=en&modules=startup&only=scripts&raw=1&skin=timeless:82
    at load.php?lang=en&modules=startup&only=scripts&raw=1&skin=timeless:82
The ext.gadget.name is what mw:Extension:Gadgets advise to make one gadget depend on another. Is this a temporary(caching?) problem, is the mediawiki.org advice wrong, or did I screw something up? - Evad37 [talk] 14:14, 14 November 2019 (UTC)
Pinging some recently-active int-admins: @Amorymeltzer, Enterprisey, Galobtter, MSGJ, and Xaosflux: - Evad37 [talk] 14:26, 14 November 2019 (UTC)
@Evad37: looks like we were both in MediaWiki:Gadgets-definition at once, feel free to revert me. — xaosflux Talk 14:47, 14 November 2019 (UTC)
@Evad37: after both of our changes, it appears to be loading now, not sure if it is working "properly". As far as the "extra" gadget, I think it might be better to have a longer, more descriptive "name"? — xaosflux Talk 14:51, 14 November 2019 (UTC)
It is now loading, but is throwing an error "extraJs is not defined". Will try undoing your edit and see if that works, because I think peers is meant to be for CSS only. As for the name, any suggestions? XFDC-extra? - Evad37 [talk] 14:54, 14 November 2019 (UTC)
@Evad37: extra.js does not need to be a hidden or peer gadget. It just needs to be in the mediawiki namespace for it to be loaded by XFDcloser as a dependency (the same way as morebits). SD0001 (talk) 14:57, 14 November 2019 (UTC)
@SD0001: Will that ensure that extra.js is loaded before XFDcloser.js is executed? If so, it should be mentioned in the mediawiki.org documentation - Evad37 [talk] 15:07, 14 November 2019 (UTC)
@Evad37: I would assume so (provided extra.js is written before XFDcloser.js). That is how Twinkle loads Morebits, and Morebits is being used in the very third line of MediaWiki:Gadget-Twinkle.js. SD0001 (talk) 15:16, 14 November 2019 (UTC)
Interesting. But is there much downside to having an additional hidden gadget? Because 
mw.loader.using(["mediawiki.util" /* , ...other modules... */ , "ext.gadget.extra"]).then(function(){ // ... depenedencies now loaded
is somewhat nicer than 
$.when(
    mw.loader.using(["mediawiki.util" /* , ...other modules... */]),
    window.extraJs || mw.loader.getScript("https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-extra.js&action=raw&ctype=text/javascript")
).then(function(){ // ... depenedencies now loaded
- Evad37 [talk] 15:41, 14 November 2019 (UTC)
None that I know of. I only said it doesn't need to be made a hidden gadget. Even morebits.js should be made a hidden gadget per above, as it's being by a quite a few other scripts. SD0001 (talk) 16:15, 14 November 2019 (UTC)
If MediaWiki:Gadget-extra.js will be "useful for other scripts" something more generic maybe? Else XFDC-extra sounds just fine. — xaosflux Talk 15:00, 14 November 2019 (UTC)
I've already got other userscripts using the code (the copy in my userspace at the moment), so yeah, probably something more generic - Evad37 [talk] 15:07, 14 November 2019 (UTC)
Maybe something beginning with "lib"? - Evad37 [talk] 15:41, 14 November 2019 (UTC)
I'm not too picky on the name, just that "extra" for a site-wide gadget is a little too nondescript. — xaosflux Talk 15:43, 14 November 2019 (UTC)
I've renamed it to libExtraUtil - Evad37 [talk] 16:09, 14 November 2019 (UTC)
@Evad: Hi, does libExtraUtil have to be a separate gadget? It looks like it might work more easily if you add libExtraUtil.js directly to XFDcloser's list of script pages. --Krinkle (talk) 16:31, 14 November 2019 (UTC)
It's working now, the problem was just a missing pipe in MediaWiki:Gadgets-definition - Evad37 [talk] 16:37, 14 November 2019 (UTC)
@Evad37: Is there an advantage to doing something like what you have currently at User:Evad37/XFDcloser.js? It's a bit more complicated, but wouldn't going back to something like your v3 subpage — like what gadgets def does for watchlist-notice and watchlist-notice-core (and a few others) — lighten the load a bit? ~ Amory (u • t • c) 23:14, 17 November 2019 (UTC)
  1. The current approach at User:Evad37/XFDcloser.js is to prompt users to enable the gadget, but only on XFD pages. If they ignore the bubble notification, they can still use XFDcloser, but loaded from the gadget version instead of my userspace so that I'm not maintaining two nearly identical scripts.
  2. Yeah, that does makes sense ( that isn't quite how the v3 subpage worked, that was there so that I could have beta testers load a different subpage instead of v3 when I was trying new features. The checks on whether to run or not were still in v3. But I get what you mean) - Evad37 [talk] 23:57, 17 November 2019 (UTC)
    Yeah sorry — I was trying to illustrate by example, but should've just said "pull a whatever-core.js." ~ Amory (u • t • c) 01:19, 18 November 2019 (UTC)
 Done - Evad37 [talk] 03:04, 18 November 2019 (UTC)

Hidden gadgets

Heading inserted at 03:54, 16 November 2019 (UTC), previously part of #XFDcloser gadgetification - Evad37 [talk] 03:54, 16 November 2019 (UTC)

@Evad37 and SD0001: Actually there’s another upside of using a hidden gadget and mw.loader.using() instead of mw.loader.getScript()—the latter loads the script as-is, while the former makes use of ResourceLoader, which means that the script is minified and may be appended to other RL modules (both lessen bandwidth need), and it also has some cache control as a hash is appended to the URL, which changes upon edits, so users quickly get the new version. —Tacsipacsi (talk) 22:50, 15 November 2019 (UTC)

Sounds like we should be making Twinkle's Morebits a hidden gadget too, then. (There's about 1200 uses of Morebits in userscripts [3]) - Evad37 [talk] 01:15, 16 November 2019 (UTC)
Agree that Morebits would be nice to have as a gadget. Enterprisey (talk!) 03:33, 16 November 2019 (UTC)
I've opened https://github.com/azatoth/twinkle/issues/748 to notify Twinkle devs, and because they would need to update some of their documentation - Evad37 [talk] 04:06, 16 November 2019 (UTC)
FWIW I generally agree with this. I can take care of it Sunday if another IA hasn't yet. ~ Amory (u • t • c) 04:34, 16 November 2019 (UTC)
 Done ​​I'm heading out so feel to make any changes if I've borked anything. Adjusted XFDCloser's loading as well. ~ Amory (u • t • c) 12:25, 18 November 2019 (UTC)

Popular Personal Scripts

I'd really like to see popular personal scripts advance to Gadgets when possible, but for a stop gap any thoughts on getting script owners to explicitly opt-in to allowing edit requests on their scripts from others to be routinely processed by admins? — xaosflux Talk 23:38, 21 October 2019 (UTC)

I was just going through the gadget list and wondering if any could/should be removed, either because they have very little usage or now have native MediaWiki solutions (e.g. syntax highlighting, IP range contributions). I worry about the list becoming too long, so we might want to be a little strict about what user scripts get moved in. In general however, I agree that if it's really that popular of a script, it probably deserves to be a gadget. The other thing is they need to be stable (reply-link for instance is hugely popular but, as advertised, is still in alpha).
To answer your question, I'm in the school of thought that gadgets belong to the community. The original author should be contacted about any major changes, but they would need to be OK with the possibility that such changes are made without their explicit permission (following consensus, as necessary). On the flip side, it'd be nice if any sizable gadget was under version control somewhere (GitHub, Bitbucket, etc.), to make it easier for code review, but this would require someone has push access which is probably limited to the original author. — MusikAnimal talk 18:46, 27 October 2019 (UTC)
@MusikAnimal: regarding the 'opt-in' I was mentioning above, I mean for User:Username/*.js pages. I'm always hesitant to touch these even for bug fixes - since it is someone's personal bug - but perhaps the page owners could put an opt-in on their talk pages welcomining GEI's and IAdmins to fix technical bugs as they arise. — xaosflux Talk 19:06, 27 October 2019 (UTC)
Bah, that makes more sense. In my opinion, if the user script is very popular and has a glaring, easily-fixable bug, and the author is not responsive, we should not hesitate to implement the fix. This is done quite a bit already (many thanks to TheDJ). You're doing the author a favour, along with all the users of the script, so I think it's pretty uncontroversial. When the author retires, we commonly fork the script and have the original one source the new one. So essentially they have the same net effect. If we're talking about feature development and other major changes (user-facing or just with the code), an opt-in template permitting such changes makes sense to me. Though in such case it's probably better to go the route of forking the script or promoting it to a gadget, as you say. — MusikAnimal talk 19:51, 27 October 2019 (UTC)
@Xaosflux: how can I note such an opt in? I'm okay with edits, as long as they include a note on my talk page as well, so that I can update the source / notes / etc. DannyS712 (talk) 20:06, 27 October 2019 (UTC)
@DannyS712: I'd think a talk page note would be sufficient. — xaosflux Talk 20:52, 27 October 2019 (UTC)
@Xaosflux: like a note at the top of my talkpage, or on the talk page of the script? DannyS712 (talk) 21:56, 27 October 2019 (UTC)
@DannyS712: the talk page of the script itself, unless you have that redirected to your main talk - then maybe a script comment? — xaosflux Talk 23:05, 27 October 2019 (UTC)
@Xaosflux: that is really tedious to do for all of them - I'm okay with it for all of my .css and .js subpages. Would an editnotice work? Or, could we make a list somewhere of users who opt in? DannyS712 (talk) 23:07, 27 October 2019 (UTC)
@DannyS712: the point would be that if someone were to come try to work on your script, they should know that you are giving the permission. Our normal method of letting people know about the status of a page is it's talk page, we also use comments on scripts. Some potential future helper shouldn't have to try to track down that you are opting in - it should be very obvious to them and anyone who is auditing them. — xaosflux Talk 23:17, 27 October 2019 (UTC)
@Xaosflux: Would the script documentation page work? I use a standard template on mine. If not, its fine, I'll do an AWB run... DannyS712 (talk) 23:19, 27 October 2019 (UTC)
@DannyS712: I'd think the same problem - if someone found a deprecated method in say User:DannyS712/Red files.js something directly related to that page should be giving up your permission I'd think. — xaosflux Talk 23:45, 27 October 2019 (UTC)
Noted. I'll leave a note somewhere DannyS712 (talk) 23:46, 27 October 2019 (UTC)
FWIW this is why I was suggesting a "most imported" list or something. It'd be far easier for all parties. Another option is a single template or category to generate a list. ~ Amory (u • t • c) 00:13, 28 October 2019 (UTC)
Something reusable is a good idea, something where you would have to think: hmm, first I have to know about this other list - then look it up, then validate that the entry is legitimate gets a bit far from some sort of comment at the top of your script page or on the script talk for example. Perhaps a user caetgory on the talk page would work, easy enough to check if it was legitimately added. — xaosflux Talk 03:53, 28 October 2019 (UTC)
SD0001 has done this at Wikipedia:User scripts/Most imported scripts! (noted at VPT) ~ Amory (u • t • c) 12:52, 18 November 2019 (UTC)
While I appreciate the courtesy being shown here, this seems like a place where WP:UOWN is best to considered. Userspace is still community owned, and if a bug in a script is causing problems for a lot of editors it should be fixed no matter what namespace it is hosted under. Encouraging the use and creation of gadgets is ideal, but in the meantime, I don't think it's worth bending over backwards. You all are amazingly good at coding, and I don't think you should worry about making obvious improvements in userspace. WP:BOLD applies to IAdmins too. Wug·a·po·des​ 05:30, 28 October 2019 (UTC)

My personal and unofficial policy was:

  1. anything where the user was gone, i would simply edit to my best judgement (and add to my watchlist)
  2. anything where the user was not a script dev, and where there were syntax errors, or other errors that would interfere with the ability of the user to USE the website, i would just edit (consumer doesn't understand what's happening and just wants things to 'work')
  3. anything where the user was apparently a script developer, I would leave a message on the talk page, asking to take action
  4. anywhere such talk page messages were not being picked up, yet issues like in point 2 started to affect end users, i would make a fix and leave a message on the dev's talk page.
  5. anything where the user was gone and an better maintained version existed I would replace the script and load the maintained version (no message)

That was my policy. Mostly in the spirit of most stuff is unmaintained and sitting around will only prolongate the period where nothing happens. And when scripts can break the experience of the website of end users, that is just not a good thing. —TheDJ (talk • contribs) 11:13, 28 October 2019 (UTC)

We really need you back as an intadmin. SD0001 (talk) 06:51, 29 October 2019 (UTC)
I'm somewhat liking TheDJ's line of thinking, perhaps we could codify and get ratified something for when it is generally considered acceptable to edit other's scripts? (v.s. the 'opt in' method). — xaosflux Talk 12:50, 29 October 2019 (UTC)
Good idea. Thoughts on adding the following to WP:IADMIN under "User scripts" or something? (If everyone here likes it, I'll make a new subsection and notify VPPR/VPT.)

Interface administrators may edit a user script if it can be improved and its author is inactive, or if it is broken and its author doesn't respond to talk page messages about it. In both cases, interface administrators may edit the script directly, but should also consider converting the user script to a gadget, forking it, or redirecting it to a better-maintained version.

Enterprisey (talk!) 03:24, 30 October 2019 (UTC)
Pinging Xaosflux, SD0001, and MusikAnimal for feedback. Enterprisey (talk!) 07:49, 31 October 2019 (UTC)
@Enterprisey: simply "having a broken script" and ignoring a talk message is a very low bar - when "ignore it" seems like a fine option, this is lacking a compelling reason why this should be happening. — xaosflux Talk 12:41, 31 October 2019 (UTC)
I worry this being a policy page if it will be taken too literally. TheDJ's guideline is quite good, but taking it a step further -- if it is a really popular script, and there's an easily fixable bug that's causing a lot of problems, don't wait for the OK from the author. Just fix it and let them know after the fact. I don't want to have to file this scenario under IAR. You are not breaking a rule by doing a lot of good and no harm. Fixes or feature development that require code refactoring, etc. are of course different and that's when you'd likely want to consult them, and consider forking/gadgetizing if you get no reply. I would put "at the interface admin's discretion" somewhere in this wording, and clarify gadgetizing still needs to go through WP:VPT to establish its usefulness. — MusikAnimal talk 18:55, 31 October 2019 (UTC)
Although I don't imagine that interface admins would bother fixing a personal script with no users other than the author, I think it would be helpful to have something to make it clear that the intended scope is scripts that others use and rely on. There's not much benefit in fixing a script no one else uses. isaacl (talk) 19:09, 31 October 2019 (UTC)

Gadgets sourcing user scripts

Following up from Special:Permalink/920644229#Gadgets with imports. There are numerous gadgets that source user scripts. This usually is done so that non-int-admin gadget maintainers can easily deploy updates. While there is a convenience factor, it is a security risk, and it undermines the whole point of having interface admins. Essentially non-admins are able to act as interface admins. This is not good. https://w.wiki/9ue and https://w.wiki/9uf identify some such gadgets, but there may be more. Some gadgets ultimately source user scripts on other wikis, too. Ideally everything will live in the MediaWiki namespace (either here or on the foreign wiki), and all updates will go through interface admins.

Should we proceed with migrating these to MW namespace? Should we prohibit this practice moving forward? Are there any exceptions?

My opinion is yes, migrate them all, prohibit this practice, with no exceptions. Even if the maintainer is an interface admin, that might not remain true. Keeping all site-wide JS in the MediaWiki namespace seems like the safest system. Thoughts? — MusikAnimal talk 16:31, 11 October 2019 (UTC)

Pinging Xaosflux and Amorymeltzer, who participated in the discussion on my talk page. — MusikAnimal talk 16:33, 11 October 2019 (UTC)
@MusikAnimal: in general I think we should avoid any userpage imports there. Any thoughts on cross-project imports? — xaosflux Talk 16:44, 11 October 2019 (UTC)
@Xaosflux: I think they are fine so long as they live in the MW namespace on whatever wiki they originate from. If it is a very simple gadget you might just copy it here, but otherwise it's nice to let the maintainers give us free updates. All wikis have the same interface admin restrictions so we should be safe in that regard. Of course, if the cross-wiki script originates in the userspace, then we should consult them to move it to the MW namespace, or host our own fork here. — MusikAnimal talk 16:57, 11 October 2019 (UTC)
Agree with all of the above, that ideally MWspace should only load MWspace (and select items from wmflabs, perhaps, but that another issue). I'm not certain that everything should by default being in the MediaWiki-Gadget- pseudonamespace, but going back and forth there doesn't matter much. I do think it'd be good to migrate everything if we can, but I imagine there are going to be some major issues with long-term things like WikiEd or JWB. It might make sense to get a list of everything so we can audit potential issues and let that inform the next steps. I also think we should do a similar aduit for fully-protected WPspace scripts (I think I mentioned this on your talk a while ago, xf, while discussing cascading protection or something). ~ Amory (u • t • c) 17:20, 11 October 2019 (UTC)

Here's the list I came up with based on https://w.wiki/9ue and https://w.wiki/9uf:

The first several instances are very popular gadgets, and most of them are actively maintained. Perhaps we should see if the maintainers are content making edit requests moving forward? In my opinion this should be obligatory. — MusikAnimal talk 17:54, 11 October 2019 (UTC)

Some quick thoughts:
  • Comments in local time is popular and has an active maintainer (as of April). At the time I went through the diffs to try to verify all the changes, but it thankfully hasn't needed too much active work. Probably worth asking Gary how he'd feel moving it to MWspace.
  • The google trans script is a prime candidate for moving IMO, especially since the maintainer isn't a sysop.
  • RTRC links to meta:User:Krinkle/RTRC.js which actually just imports mw:MediaWiki:Gadget-rtrc.js, so that's a super easy fix.
  • MediaWiki:Gadget-RegexMenuFramework.js has been hidden and is deprecated in favor of meta:TemplateScript. Per Special:GadgetUsage there are ~15,000 installations, although I'm not sure it even works. We should offer TemplateScript as a gadget, but at the very least we could import the script from tools (incidentally, this is my personal biggest concern for the coming CSP lockdown).
  • I think we can just have Enterprisey overwrite the subpages, there shouldn't be any issues right?
  • I'm going to delete the compare link script as it's hasn't been working since for 4.5 years, especially in light of the 2008 conversation leading to its move.
  • I can see the utility of mobile-sidebar for users, and it does still appear to be working fine enough vector, but it's a weird fit. I have a hard time imagining someone wanting it on 100% of the time, so I must think that the 4700 users are inactive, with some maybe enabling it temporarily now and then. If we're set on keeping something like it, we can just fork Brion's code and place it here, but I'd be in favor of deleting it. It really needs a portlet serving as a toggle to be useful IMO. See note below, there's a toggle, so we should just copy BV's code.
More urgently, I've only just now realized how huge of a risk WikiEd is. It imports a few dozen userspace js pages for translation stuff (search for wikEd.InitTranslations) and near the top in terms of users. ~ Amory (u • t • c) 19:39, 11 October 2019 (UTC)
mobile-sidebar does have a toggle (next to the watch button). SD0001 (talk) 20:40, 11 October 2019 (UTC)
Word! Missed that, makes its potential usage much more reasonable. ~ Amory (u • t • c) 20:49, 11 October 2019 (UTC)
Yeah, moving those WikEd translation js pages to mediawiki space is definitely a must. Galobtter (pingó mió) 05:13, 12 October 2019 (UTC)
Pursuant to my above comments, I've dealt with the easy/obvious/low-hanging fruit of RTRC, mobile-sidebar, and compare link. For RegexMenu I still think we should just replace it with TS as a potential stopgap at least (no less safe, at least); we can then unhide the gadget. ~ Amory (u • t • c) 12:11, 12 October 2019 (UTC)
LinkFixr and (to a lesser degree) HighlightEditSection have some imports by some active folks. It's a finite number and shouldn't be too hard to change them since it's a simple fix. The great Magnus Manske is occasionally active, although those haven't been updated in ages. ~ Amory (u • t • c) 14:54, 12 October 2019 (UTC)

This topic has been on my mind, following a similar, much-earlier, discussion. I agree firstly with a strict, "no tolerance" policy for user scripts being imported into gadgets, however useful they may be. I am also honestly concerned that we import cross-wiki gadgets, from users who will not have gone through our local process (RFA, for better or worse) for getting the interface admin role. I might even suggest that we should have a strict no-crosswiki scripts policy here as well, but I'm willing to put that one to an RFC. There is probably some middle-ground there to consider. (There's another can of worms that a compromised interface administrator could unilaterally push changes without review, but I know that's a bigger one and has a few phabricator epics attached to it.) --Izno (talk) 19:48, 11 October 2019 (UTC)

Disallowing cross-wiki gadget imports would be a very bad idea. Gadgets like HotCat are maintained at one place (commons in this case) and all wikis import from there. If every wiki were to keep a separate copy, do you expect the maintainers to update it (or make an edit request for update) on every single wiki, every time? SD0001 (talk) 20:14, 11 October 2019 (UTC)
I agree. I'm actually working on a new version of m:MoreMenu that is wiki-agnostic, and having the script in one place is the primary motivation. Interested wikis import one JS page and everything just "works", no configuration or translations necessary. I think x-wiki is fine, so long as the script in its entirety exists in the MW namespace. If we are importing a x-wiki gadget here, we essentially are entrusting the int-admins who control it. — MusikAnimal talk 20:55, 11 October 2019 (UTC)

I disagree with your stand on user controlled gadget files on Wikipedia. I maintain GoogleTrans gadget quite well by having it sourced from a file in my user space. I think the current system works quite well, and your suggestion is a sign of the security at all costs mania of the US today. This is also a backdoor way to reduce the number of gadgets out there since any maintenance to the gadget is prevented by your suggestion. Endo999 (talk) 21:15, 11 October 2019 (UTC)

I'm not sure about a 100% prohibition - but perhaps we should add an extra warning to the descriptions page at least. — xaosflux Talk 22:51, 11 October 2019 (UTC)
Regarding RTRC, User:Krinkle is a GIE, so not having a trustiness type issue, but that one looks like it is bouncing back and forth across 3 projects to run? — xaosflux Talk 22:57, 11 October 2019 (UTC)
Just replace its contents with mw.loader.load('https://www.mediawiki.org/w/load.php?debug=false&modules=ext.gadget.rtrc&lang=en'). This is the ResourceLoader-minimised version that would load faster than the raw version at https://www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-rtrc.js&action=raw&ctype=text/javascript . SD0001 (talk) 04:01, 12 October 2019 (UTC)
Should note that I did this lo those many weeks ago. ~ Amory (u • t • c) 01:10, 14 November 2019 (UTC)
Building on what I said above about MediaWiki:Gadget-RegexMenuFramework.js, perhaps what we should do is add its replacement, meta:TemplateScript, then have that old hidden gadget source the new replacement. I'm not sure the old one even works, so a simpler option could be to just replace it with a message to users to change to the new one; after a while, anyone who hasn't switched won't, so we could reasonably remove it. We could get fancy and try to have the old gadget disable itself and enable the new version, but that might be a bit invasive. ~ Amory (u • t • c) 04:26, 3 December 2019 (UTC)

Userspace, crosswiki, and toolforge imports

Scripts in userspace may not require special permissions or going through any community vetting process, but they expand the avenues of attack by exactly one user; and their script may have been picked precisely because they have demonstrated trustworthyness. I think these are actually the least risky.

Toolforge has no special requirements for access, does not require 2FA, access is approved by a single person after a superficial check for red flags, and there are no audit mechanisms once access has been granted. Changes there will not show up in any log or watchlist here, so any bad actor won't be caught until after we've all mined bitcoin for a while. I'm not actually convinced Gadgets here should ever import anything from Toolforge (asking it for data, sure, but not actually importing and executing code from there).

Other wikis—especially smaller ones—have vastly different policies and cultures. Admin and interface admin is assigned as a bit more or less for the asking, without checking for 2FA (which I don't mind because it's a dumb requirement, but…), and nobody is likely to notice any changes because smaller projects don't have the manpower for that kind of thing. Due to lack of manpower they tend to be averse to formal policy or rigid processes and anything smacking of bureauocracy: the very mechanisms that enable trust in security terms. Most smaller projects are badly pinched for people willing to swing the mop, not to mention technical work.

Foreign language projects may also have a majority of users subject to repressive regimes in the associated countries, regimes willing to exert various forms of pressure on its citizens for their goals. Or put another way, even Germany and the US have pre-emptive hacking in the toolbox that police are allowed to use for various purposes, and in large parts of the world use of such tools are not even subject to any checks and balances to speak of. Can you think of any regimes that might be interested in what its citizens are doing on Wikipedia? Or who might have a special interest in particular Wikipedia users?

On the other end of that scale is Commons: in the grand scheme both policy and culture there is pretty similar to here. Importing HotCat from there poses very little real risk.

I don't think flat out forbidding any particular kind of import is proportionate to the risk, but there's a rather large continuum of risks and attack vectors that needs to be recognized and handled. Maybe userspace imports to MW:-space should only be permitted from particular users subject to some kind of vetting (something "BAG Light"-esque maybe?)? And crosswiki from Commons subject to a one-time approval complemented by some kind of active cross-project coordination and agreement on policies? Maybe other cross-wiki imports should be forbidden unless some minimum standards for compatible policy and process are documented? --Xover (talk) 11:34, 12 October 2019 (UTC)

@Xover: it used to be that any admin could update/make a gadget; now it is only a very small group so I think any quality control concerns can just be agreed to (on this board for example). — xaosflux Talk 01:32, 14 November 2019 (UTC)

Gadget and userscript unit testing

Tracked in Phabricator
Task T240647

Hi all. I've created User:Evad37/WikiUnit.js to make on-wiki unit testing a bit easier to implement. I've been thinking about this for a little while, since I have these testcases for User:Evad37/extra.js that I haven't yet migrated to mediawiki namespace for the gadget version MediaWiki:Gadget-libExtraUtil.js. Before preceding any further (i.e. looking at gadgetising and/or moving to Meta), I thought it would be good to get some feedback. In particular, in regards for i18n strategy (I'm thinking having a dedicated JSON subpage for message translations, rather than the current wikidata thing – which works for a short phrase or word, but not for longer messages) and the adequacy of the confirmation box (disallowing loading javascript outside of mediawiki namespace and your own user space would be somewhat safer, but somewhat less useful). - Evad37 [talk] 09:04, 9 December 2019 (UTC)

Personally I created tests for m:User:DannyS712/Global watchlist.js at User:DannyS712/Global watchlist.js - how have others been testing scripts? DannyS712 (talk) 01:18, 10 December 2019 (UTC)
@DannyS712: I don't see any tests at User:DannyS712/Global watchlist.js ... did you mean to link a different page? - Evad37 [talk] 01:52, 10 December 2019 (UTC)
Not sure how that happened - User:DannyS712 test/Global watchlist tests.js is the right link --DannyS712 (talk) 01:56, 10 December 2019 (UTC)
That's pretty cool what you've got there. But setting up a unit testing framework shouldn't be something that has to be done on a per-script basis. The sort of scritp/gadget I'm working on would help with that. But thinking about it, ideally it would be a mediawiki extension, so that it is available on all wikis (that it is deployed to), and so it could use translatewiki for translations. - Evad37 [talk] 02:37, 10 December 2019 (UTC)
This topic was broached at the recent Wikimedia Tech Conference 2019 related to the Developer Productivity & onwiki tooling topic. It was one piece of the pie. I suspect a comment over there might see some feedback here. --Izno (talk) 03:20, 10 December 2019 (UTC)
I've left a note there, and also at T39230 Provide standard way to create/run QUnit tests for Gadgets and user scripts - Evad37 [talk] 23:44, 10 December 2019 (UTC)
This is great. As far as i18n goes, since this tool is just for developers rather than for end-users, I don't see much point in supporting different languages? I have to say, querying wikidata to get the translation of a single phrase is funny, especially as the long confirm texts are only in English. SD0001 (talk) 03:12, 10 December 2019 (UTC)
Yeah, at the time I thought it might be the only phrase needing translation, if the confirmation was removed and only mediawiki namespaced or own-userspace testcases were loaded. But now that there are multiple, non-generic messages, using wikidata isn't a good fit. While i18n may for the most part be cosmetic, the confirmation dialog should be as understandable as possible in case non-technical users enable it, or unwittingly load it from a link (on wikis which have mw:Snippets/Load JS and CSS by URL) - Evad37 [talk] 06:32, 10 December 2019 (UTC)

I've created phab:T39230 for having this functionality in a MediaWiki extension - Evad37 [talk] 00:40, 13 December 2019 (UTC)

block reasons

Before I get to my specific request, am I right that we need one of you guys in order to make an edit to the standard drop-down list of block rationales? Beeblebrox (talk) 21:31, 15 December 2019 (UTC)

You don't need one for MediaWiki:Ipbreason-dropdown. -- zzuuzz (talk) 21:50, 15 December 2019 (UTC)
Ah, thanks. I seemed to recall there used to be a link when you opened the menu that allowed it right from there, so I thought maybe we couldn't access that anymore. Change made, it was pretty minor. Thanks, again! Beeblebrox (talk) 23:31, 15 December 2019 (UTC)
I still see the link Edit block reasons at the bottom right on another wiki where I’m admin (but not interface admin). Are you sure it’s not there? It must be some kind of bug then. —Tacsipacsi (talk) 16:50, 16 December 2019 (UTC)
It remains where it's been for a very long time, at the bottom of Special:Block. I suspect remembering where you saw it is often an issue. -- zzuuzz (talk) 16:57, 16 December 2019 (UTC)
Yup, that is where it's located, and any administrator can modify it. ;-) ~Oshwah~(talk) (contribs) 21:50, 17 December 2019 (UTC)

permissions message for rawhtml

Hi all, there is a discussion open that could use an outside view about interface-admin restricted rawhtml pages at MediaWiki talk:Siterawhtmlprotected. Please take a look if you have a moment. Thank you, — xaosflux Talk 17:43, 24 December 2019 (UTC)

Undeletion request for Familytree.js

The familytree.js script was deleted without a proper debate. It is a valuable and an easier tool to make the family trees in comparison with the present template. Could we re-evaluate the decision, I consider that there is no reason to delete it. If there is a need for the script to be moved to my namespace/user pages, to avoid it being deleted in the future, I'm all for it. --Daduxing (talk) 12:01, 9 January 2020 (UTC)

If you wish to appeal and XfD, I'd first contact the closing sysop, which is Premeditated Chaos. We can do the dirty work if PMC or a subsequent Wikipedia:Deletion review favor restoring, but the decision to do so wouldn't be made here. ~ Amory (u • t • c) 12:18, 9 January 2020 (UTC)
I'll note that there are ~170 user imports of the script, of varying degrees of activity. ~ Amory (u • t • c) 12:21, 9 January 2020 (UTC)
Sure fine by me, if Daduxing wants to take ownership of it I don't see why it can't be restored/moved to their userspace. I've restored User:GregU/familytree, but I don't seem to be able to restore User:GregU/familytree.js since I'm not an interface admin. ♠PMC♠ (talk) 12:32, 9 January 2020 (UTC)
@PMC: these shouldn't (and will be mostly useless to maintain under someone else at the current name (User:GregU/familytree) - do you intend to move that to somewhere like User:Daduxing/familytree? (w/o redirect) ? — xaosflux Talk 12:37, 9 January 2020 (UTC)
Sorry, maybe I'm just editing too late into my shift, but I have no idea what you mean when you say "these shouldn't". They shouldn't be restored? Moved? ♠PMC♠ (talk) 12:58, 9 January 2020 (UTC)
@Premeditated Chaos: if Daduxing wants to maintain this, I don't have an issue having it restored, but it should be put in their userspace not the old one, especially the .js file. (1) Daduxing won't be able to actually edit it at User:GregU/familytree.js, (2) some users may have trusted GregU enough to subsequently import their script, but they would need to opt-in to importing scripts under Daduxing's control. Would you like User:GregU/familytree.js restored and moved without redirect to User:Daduxing/familytree.js under WP:REFUND? — xaosflux Talk 14:12, 9 January 2020 (UTC)
Yeah, sorry, I thought that's what I said? I only didn't do it myself because I don't have the powers. (And I didn't do the initial move in case there was some issue with the .js restoration). ♠PMC♠ (talk) 14:37, 9 January 2020 (UTC)
Just to say I completely agree with Daduxing – this should be undeleted (or at least a copy of its text given so that they can make their own user script from it). The restoration looks uncontroversial to me (per this page's header), as the deletion process only had one comment in addition to the nominator, and it doesn't look like the users of the script, or the template it's used for's talk page (Template talk:Tree chart) or any wiki projects were notified, or there would have been an objection or two at least! ‑‑YodinT 14:38, 9 January 2020 (UTC)
 Done @Daduxing, Premeditated Chaos, and Yodin: the page has been restored and placed at User:Daduxing/familytree.js. Apologies if I was confusing above! — xaosflux Talk 14:58, 9 January 2020 (UTC)

Can an interface admin help with this?

Today, I noticed the script User:Cumbril/RefConsolidate.js has stopped working because the user was renamed Kaniivel. Unfortunately, the redirect process caused some of the dependent scripts to break. Namely, the & was instead replaced with \u0026.

Can an interface admin fix the following lines:

  • User:Cumbril/XmlToJSON.min.js
    • Current version: 
      /* #REDIRECT */mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Kaniivel/XmlToJSON.min.js\u0026action=raw\u0026ctype=text/javascript");
    • Revise to: 
      /* #REDIRECT */mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Kaniivel/XmlToJSON.min.js&action=raw&ctype=text/javascript");
  • User:Cumbril/RefConsolidate.js
    • Current: 
      /* #REDIRECT */mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Kaniivel/RefConsolidate.js\u0026action=raw\u0026ctype=text/javascript");
    • Revise to: 
      /* #REDIRECT */mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Kaniivel/RefConsolidate.js&action=raw&ctype=text/javascript");
  • User:Cumbril/RefConsolidate start.js
    • Current: 
      /* #REDIRECT */mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Kaniivel/RefConsolidate start.js\u0026action=raw\u0026ctype=text/javascript");
    • Revise to: 
      /* #REDIRECT */mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Kaniivel/RefConsolidate start.js&action=raw&ctype=text/javascript");

On another note, this appears to be a common problem among scripts made by users who have since been renamed. I think that \u0026 in JavaScript pages should probably be replaced sitewide with &. epicgenius (talk) 23:44, 20 January 2020 (UTC)

 Doing... — xaosflux Talk 00:00, 21 January 2020 (UTC)
 Done @Epicgenius: I've done this - however it is not really a good practice, as it introduces a beansy future condition as-is. The people using this should update their scripts to point to the new source. — xaosflux Talk 00:04, 21 January 2020 (UTC)
Xaosflux, in this case, the third script I listed was dependent on the first two scripts. People were only installing the third script. epicgenius (talk) 00:20, 21 January 2020 (UTC)
@Epicgenius: so they shouldn't have much to update :) and really Kaniivel should fix their own script to not call back to redirects. — xaosflux Talk 00:26, 21 January 2020 (UTC)
Xaosflux, I understand now. Thanks for the explanation, and thanks for fixing this. epicgenius (talk) 00:27, 21 January 2020 (UTC)
@Epicgenius and Xaosflux: Fixed the scripts. Thanks for the notification! Also, happy to hear that someone is actually using my script :). Gives me the motivation to continue with improvements. Kaniivel (talk) 00:53, 21 January 2020 (UTC)
@Epicgenius: For the record, \u0026 is the same as & --DannyS712 (talk) 01:09, 21 January 2020 (UTC)
DannyS712, thanks. I knew that, but didn't initially say it because I didn't feel it was relevant. epicgenius (talk) 01:17, 21 January 2020 (UTC)
@Epicgenius: it is relevant - the imports weren't broken; there is no difference between using the two forms from a technical point of view DannyS712 (talk) 01:26, 21 January 2020 (UTC)
DannyS712, I see now. Thanks. So that meant I didn't have to make the above edit request at all? epicgenius (talk) 01:27, 21 January 2020 (UTC)
@Epicgenius: Exactly DannyS712 (talk) 01:28, 21 January 2020 (UTC)
However, for beansy reasons, it was still good that this was done. — xaosflux Talk 02:00, 21 January 2020 (UTC)
Also phab:T107289 seeks to use & instead of the 0026 code one day. — xaosflux Talk 02:03, 21 January 2020 (UTC)

A temporary site logo has been placed in MediaWiki:Common.css per discussion at Wikipedia:Village_pump_(miscellaneous)#6,000,000th_article - if this breaks anything please revert without delay. — xaosflux Talk 19:33, 23 January 2020 (UTC)

Inactive interface administrators 2020-01-28

The following interface administrator(s) are inactive:

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

 Done - removed per policy. — xaosflux Talk 23:21, 28 January 2020 (UTC)

spam at User:Games.indo/common.css

Could an intadmin please delete User:Games.indo/common.css? It needs a G11 deletion, but since it's a user interface page I can't tag it. creffett (talk) 00:48, 16 February 2020 (UTC)

 Done @Creffett: tagging the talk page of something like that would suffice in the future. — xaosflux Talk 01:11, 16 February 2020 (UTC)
Xaosflux, will remember that for next time. Thanks! creffett (talk) 01:25, 16 February 2020 (UTC)

Interface language is wrong

Tracked in Phabricator
Task T246071
Resolved
Screenshot of the Interface administrators' noticeboard of the English Wikipedia with a German language interface

It's supposed to be English for the entirety of English language Wikipedia, but now I for some reason get UI elements in my native language instead. Please fix this, it's confusing and annoying. --84.213.45.97 (talk) 04:18, 25 February 2020 (UTC)

What the IP is talking about is that non-logged in readers see English Wikipedia with a non-English interface - see the screenshot I took. I dunno how long this is been around but it can be a problem since it seems like the non-English interface does not use the customized interface messages as I noticed when testing a titleblacklist issue for Phabricator. It's an issue for WP:VPT rather than this noticeboard, IMO, however. Jo-Jo Eumerus (talk) 10:51, 25 February 2020 (UTC)
I believe this is phab:T246071, which indeed is where it will be handled. ~ Amory (u • t • c) 11:32, 25 February 2020 (UTC)
This has been fixed now! https://wikitech.wikimedia.org/wiki/Incident_documentation/20200225-mediawiki_interface_language --84.213.45.97 (talk) 05:39, 27 February 2020 (UTC)
Excellent! ~Oshwah~(talk) (contribs) 06:36, 12 March 2020 (UTC)

MediaWiki:Group-user.js

Hello, since {{REVISIONID}} does not work now (see phab:T137900), it is causing issues with prefilled reason in Template:Renameuser2 and Template:Usurp2. So please create MediaWiki:Group-user.js (see m:MediaWiki:Group-user.js) so that the solution provided at phab task can be implemented. Thanks! ‐‐1997kB (talk) 05:54, 21 February 2020 (UTC)

I get it, but it seems rather excessive to add some javascript, even if it's tiny, to every user's page load, just so global renamers have an easier time with requests. I haven't checked, are there are other templates using this trick that would further justify making this change? ~ Amory (u • t • c) 11:00, 21 February 2020 (UTC)
I am only aware of usage in these two templates. If you have any better idea without creating that page, we can implement that. ‐‐1997kB (talk) 11:26, 21 February 2020 (UTC)
I was about to say the same thing as Amorymeltzer. I think the benefit here is not worth loading this for every user. Alternative ways should be considered such getting dedicated bot to add the permalink or script like the one used at WP:PERM. – Ammarpad (talk) 11:55, 21 February 2020 (UTC)
Found out that Template:Unblock-un is also using it. ‐‐1997kB (talk) 12:33, 21 February 2020 (UTC)
Which is fine, but it is the same thing, this was just a shortcut for a very small group of people - if the templates are broken then fix them (turn off the bad links). — xaosflux Talk 12:52, 21 February 2020 (UTC)
Well I have updated the templates to link with just main page (not the specific revision), which seems kinda fine to me. If anybody comes up with better solution update it please. ‐‐1997kB (talk) 13:04, 21 February 2020 (UTC)
Seems like this would be ripe for a global-renamer user script, a la the meta example. ~ Amory (u • t • c) 13:08, 21 February 2020 (UTC)
Meta is pushing this on "all users" as well, which is also overkill but there are much less meta users and usage. — xaosflux Talk 13:47, 21 February 2020 (UTC)
Exactly right. ~ Amory (u • t • c) 17:01, 21 February 2020 (UTC)

WP:Requested moves#Technical requests is another application broken by the removal of support for {{REVISIONID}}. See Wikipedia talk:Requested moves#Permalinks no longer linked in move reasons. We're all here to ask for help with MediaWiki:Group-user.js because that's the only solution presented by the developers who broke our apps, in their "migration guide". I'd be happy if the solution only worked for administrators and users with page mover rights. An installable "gadget" would do the trick. – wbm1058 (talk) 16:53, 29 February 2020 (UTC)

@Wbm1058: your explanation above suggests that this is only needed by a very small minority of editors, so adding code for every editor on every page load is certainly overkill if it could be done in MediaWiki:Group-sysop.js or MediaWiki:Group-extendedmover.js. That being said, it also seems to be only needed for a minority of those users as well - so an opt-in gadget (Page moving helper gadget or the like) sounds like a good answer. — xaosflux Talk 17:19, 29 February 2020 (UTC)
Thanks, I didn't even know that MediaWiki:Group-sysop.js and MediaWiki:Group-extendedmover.js existed. A gadget would be ideal if we could count on drive-by users to install the gadget before using, but getting everyone to follow instructions isn't easy. If the load caused by a few extra lines of code is significantly less than the previous load caused by {{REVISIONID}} generation, then maybe it's worth installing it in the two MediaWiki script files, for user convenience and to ensure more consistent use. wbm1058 (talk) 18:58, 29 February 2020 (UTC)
@Wbm1058: anything in the group.js gets loaded on every single page load; the prior was only when making an edit and using that template (if I'm reading this right) so it is a much bigger difference. — xaosflux Talk 19:08, 29 February 2020 (UTC)
(edit conflict) The "previous load caused by {{REVISIONID}} generation" was, in effect, that pages that contained the magic word were several times slower to save. That seems much less of a big deal than the new way of extra JavaScript being loaded on every logged-in or autoconfirmed page view. (Just putting it in MediaWiki:Group-extendedmover.js isn't good enough, because some RM/TR requests are made my IPs, and don't have any pages in the way, meaning an autoconfirmed user could in theory do it. Another possible reason for such a request would be the title blacklist, creating a request that could be processed by a template editor who is not a page mover). * Pppery * it has begun... 19:10, 29 February 2020 (UTC)
So, as I said at Wikipedia talk:Requested moves#Permalinks no longer linked in move reasons, the revisionID permalinks aren't placed in the edit summaries of ordinary edits, but only the edit summaries of page moves, which are clearly more resource-intensive operations, e.g. HERE. Thus, it's the page movers who leave the permalinks – to the version of the technical requests page that was live at the time the page was moved.
Maybe we can talk the developers into re-enabling {{REVISIONID}} during page-move operations only? If this is indeed more efficient than loading JavaScript, then it strikes me as disingenuous to suggest JavaScript as the "migration" solution. wbm1058 (talk) 20:03, 29 February 2020 (UTC)
You're misunderstanding me. re-enabling {{REVISIONID}} during page-move operations only isn't a thing because the {{REVISIONID}} magic word is evaluated when the page Wikipedia:Requested moves/Technical requests is rendered, not when the page move happens. The long parenthetical in my previous post was explaining that one doesn't need to be a page mover to execute a request at RM/TR. * Pppery * it has begun... 20:34, 29 February 2020 (UTC)
What is the big deal from one script not working the way it used to? Can't see this preventing anyone from actually making a request, nor from anyone actually fulfilling it correct? — xaosflux Talk 22:40, 29 February 2020 (UTC)

So if I understand correctly, most of the time this functionality is used ONLY to prefill the editsummary (or the edit itself) with the revisionid, for purposes of a select group making the action ? In that case, create a gadget, with the replace functionality as described, enable by default but place a relevant rights filter in the gadget definition, so that only those with that right (and thus the only ones to be able to actually perform the action) receive the gadget. formwizard gadget does this for instance. And of course try to do it with as few gadgets possible of course. You might as well hide the action with 'sysop-show' to only make it visible to sysops for instance (ps, might be that not all groups have relevant show/hide classes, it's been a while since that was checked I think). —TheDJ (talk • contribs) 15:48, 4 March 2020 (UTC)

Btw. putting it in a relevant group-groupname.js might be 'cheaper', as that is automatically added to the the 'user' module of the relevant user, whereas a gadget, actually adds a RL module definition, which is then included on every page for every user. Of course that is only a couple of bytes on each pageview, but still. It sort of depends on the level of control needed and the size of the group you are targeting, what the right choice is. —TheDJ (talk • contribs) 15:53, 4 March 2020 (UTC)
  • For some reason revisionid is working while using Template:Unblock-un, see User talk:LSBRUK (hover over rename user link). If anyone can figure out how it is working, maybe that can be implemented. ‐‐1997kB (talk) 14:01, 18 March 2020 (UTC)
    @1997kB: [[Special:Permalink/{{REVISIONID}}]] works: Special:Permalink/- on talk pages, and will continually update if the page is edited again. — xaosflux Talk 15:52, 18 March 2020 (UTC)
    1997kB, I wrote User:Enterprisey/rename-reason-fixer.js; should work for {{Renameuser2}}, {{Usurp2}}, and {{Unblock-un}}. Any way I can let people know about this? Enterprisey (talk!) 16:20, 16 April 2020 (UTC)
    @Enterprisey: I can post it on renamer's mailing list if you want. Also few other wikis uses renameuser2 setup so if it can recognise wiki and reflect that in reason that would be great. ‐‐1997kB (talk) 01:14, 17 April 2020 (UTC)
    Sounds great, and done! Enterprisey (talk!) 02:35, 17 April 2020 (UTC)
    @Enterprisey: Done. Can you please create a doc page for script with installation instructions on other wikis. ‐‐1997kB (talk) 06:13, 17 April 2020 (UTC)
    Ok, done. Sadly this script requires a special CSS class to be put in the local template (example of me doing it) before it can be used on a wiki - I've mentioned that in the docs, but it might still trip people up. Enterprisey (talk!) 06:45, 17 April 2020 (UTC)
    Update: the CSS class is no longer necessary. Enterprisey (talk!) 23:14, 17 April 2020 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Interface_administrators%27_noticeboard/Archive_1&oldid=1142596090"