Jump to content

Wikipedia:Interface administrators' noticeboard/Archive 1

Add links
From Wikipedia, the free encyclopedia
< Wikipedia:Interface administrators' noticeboard
This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 05:35, 10 February 2019 (Archiving 1 discussion(s) from Wikipedia:Interface administrators' noticeboard) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 1Archive 2Archive 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 href="xxx">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)

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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Interface_administrators%27_noticeboard/Archive_1&oldid=882598800"