Wikipedia:Interface administrators' noticeboard

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Amorymeltzer (talk | contribs) at 12:52, 18 November 2019 (→‎Popular Personal Scripts: Replying to Amorymeltzer (using reply-link)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

    Welcome to the interface administrators' noticeboard
    Shortcuts

    This is the interface administrator noticeboard, for discussion of interface administrators and coordination of edits to the interface.

    Currently only interface administrators can undelete JS/CSS pages, if you have an uncontroversial undelete or deleted version retrieval request, please list it below.

    Any administrator can delete JS/CSS/JSON pages, for speedy deletions just use a CSD template on the page or its talk page.

    Individual requests for edits to interface or user JavaScript/CSS pages should continue to be made on their respective talk pages.

    Click here to start a new discussion

    3 interface-protected edit requests
    v·h
    Page Tagged since Protection level Last protection log entry
    MediaWiki:Gadget-WatchlistBase.css (request) 2024-03-02 23:26 Site CSS page (log)
    MediaWiki:Gadget-watchlist-notice-core.js (request) 2024-03-02 23:26 Site JS page (log)
    MediaWiki:Vector-2022.css (request) 2024-05-29 01:47 Site CSS page (log)
    Updated as needed. Last updated: 01:48, 29 May 2024 (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)[reply]

    Pinging Xaosflux and Amorymeltzer, who participated in the discussion on my talk page. — MusikAnimal talk 16:33, 11 October 2019 (UTC)[reply]
    @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)[reply]
    @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)[reply]
    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)[reply]

    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)[reply]

    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)[reply]
    mobile-sidebar does have a toggle (next to the watch button). SD0001 (talk) 20:40, 11 October 2019 (UTC)[reply]
    Word! Missed that, makes its potential usage much more reasonable. ~ Amory (u • t • c) 20:49, 11 October 2019 (UTC)[reply]
    Yeah, moving those WikEd translation js pages to mediawiki space is definitely a must. Galobtter (pingó mió) 05:13, 12 October 2019 (UTC)[reply]
    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)[reply]
    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)[reply]

    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)[reply]

    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)[reply]
    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)[reply]

    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)[reply]

    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)[reply]
    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)[reply]
    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)[reply]
    Should note that I did this lo those many weeks ago. ~ Amory (u • t • c) 01:10, 14 November 2019 (UTC)[reply]

    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)[reply]

    @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)[reply]

    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)[reply]

    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)[reply]
    @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)[reply]
    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)[reply]
    @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)[reply]
    @DannyS712: I'd think a talk page note would be sufficient. — xaosflux Talk 20:52, 27 October 2019 (UTC)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    Noted. I'll leave a note somewhere DannyS712 (talk) 23:46, 27 October 2019 (UTC)[reply]
    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)[reply]
    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)[reply]
    SD0001 has done this at Wikipedia:User scripts/Most imported scripts! (noted at VPT) ~ Amory (u • t • c) 12:52, 18 November 2019 (UTC)[reply]
    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)[reply]

    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)[reply]

    We really need you back as an intadmin. SD0001 (talk) 06:51, 29 October 2019 (UTC)[reply]
    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)[reply]
    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)[reply]
    Pinging Xaosflux, SD0001, and MusikAnimal for feedback. Enterprisey (talk!) 07:49, 31 October 2019 (UTC)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]

    .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)[reply]

    @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)[reply]
    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)[reply]
    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)[reply]

    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)[reply]

    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)[reply]
    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)[reply]
    Pinging some recently-active int-admins: @Amorymeltzer, Enterprisey, Galobtter, MSGJ, and Xaosflux: - Evad37 [talk] 14:26, 14 November 2019 (UTC)[reply]
    @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)[reply]
    @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)[reply]
    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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    Maybe something beginning with "lib"? - Evad37 [talk] 15:41, 14 November 2019 (UTC)[reply]
    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)[reply]
    I've renamed it to libExtraUtil - Evad37 [talk] 16:09, 14 November 2019 (UTC)[reply]
    @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)[reply]
    It's working now, the problem was just a missing pipe in MediaWiki:Gadgets-definition - Evad37 [talk] 16:37, 14 November 2019 (UTC)[reply]
    @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)[reply]
    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)[reply]
      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)[reply]
     Done - Evad37 [talk] 03:04, 18 November 2019 (UTC)[reply]

    Hidden gadgets

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

    @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)[reply]

    Sounds like we should be making Twinkle's Morebits a hidden gadget too, then. (There's about 1200 uses of Morebits in userscripts [1]) - Evad37 [talk] 01:15, 16 November 2019 (UTC)[reply]
    Agree that Morebits would be nice to have as a gadget. Enterprisey (talk!) 03:33, 16 November 2019 (UTC)[reply]
    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)[reply]
    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)[reply]
     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)[reply]
    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Interface_administrators%27_noticeboard&oldid=926745838"