I moved the request for a skin.js/css redirect to bug 69555.

Alex: completely agree! I have noticed a lot of cargo cult programming. Japanese Wikipedia for example will copy and paste stuff from English Wikipedia but then it doesn't get updated when English Wikipedia will change. In the long run I think these sort of tweaks to the software will make every project happier.

What about setting $wgUseSiteJs = false on wikis where these scripts were migrated into default gadgets and recommending that as the way to customize the site?

There is probably more interesting code (and likely higher-quality, too) in default-enabled gadgets.

In T71550#721195, @He7d3r wrote:

Is this bug intended to be specific for enwiki?

I'd suggest that we make the scope global.

One advantage with the gadget approach is that people can turn the features off very easily. I'm not sure it's a good idea to ask users to edit user CSS files (which is not that intuitive and potentially error-prone for non-technical folks) if they didn't want a certain feature. People are already complaining about the new sandbox link extension.

Gadgets managed on each site are obviously a hack to some extent, but it might be worth exploring if we could come up with a uniform, simple mechanism that extensions can use to add a toggle switch to user preferences. This would also be helpful if we were to turn gadgets designed for power users (e.g. HotCat) into extensions.

In T71550#1196253, @wctaiwan wrote:

Gadgets managed on each site are obviously a hack to some extent, but it might be worth exploring if we could come up with a uniform, simple mechanism that extensions can use to add a toggle switch to user preferences.

Isn't the GetPreferences hook with 'type' => 'toggle' enough?

Probably. I was thinking of abstracting that away so that extensions can just append themselves to an array, without needing a hook function, but that would also work.

It might be more of an UX issue than a technical issue, evaluating the tradeoffs between configurability and streamlining user preferences, and deciding where to put such toggles, if we were to have them.

In T71550#1196637, @wctaiwan wrote:

It might be more of an UX issue than a technical issue, evaluating the tradeoffs between configurability and streamlining user preferences, and deciding where to put such toggles, if we were to have them.

Agreed. FWIW, I think that Beta Features - despite their supposed instability - are much more user-friendly than usual preferences from this perspective.

See T64559: Redesign Special:Preferences (tracking) and https://www.mediawiki.org/wiki/Requests_for_comment/Redesign_user_preferences

Honestly, if you require an off switch for the presence of a link in a menu, then I think you're the problem and not the UI. Extensions that need preferences generally already have them.

This task is UNCONFIRMED. Please provide local support for removal of those gadgets.

Nah, we can safely move features of gadgets into the software. We don't have an unconfirmed status in Phabricator anyway.

Nah, we can safely move features of gadgets into the software.

T95669 seems to disprove the claim. :) Gadgets are usually approved as gadgets, a property which includes the fact of having an associated preference in the gadgets section. A request to force a certain feature may not have achieved consensus in the first place, so consensus should be verified.

Of course the gadget code can be migrated to a repository, but enabling it on a wiki is another matter.

In T71550#1197568, @Krenair wrote:

Nah, we can safely move features of gadgets into the software. We don't have an unconfirmed status in Phabricator anyway.

Echoing Nemo, we do need to consider the possible regression of losing the ability to opt out of a feature. From a user's perspective, a JavaScript gadget is exposed only as a user preference in a different tab. Users don't care if the implementation changes from the Gadgets extension PHP inserting JavaScript to the dedicated extension PHP inserting JavaScript. To the user, that's invisible and they're more likely to care if a feature they were previously able to easily disable (checkbox in Special:Preferences) becomes slightly more difficult to remove (need silly code from a village pump).

For now, people are recommending using common.js and common.css work-arounds to hide various unwanted features. I would like to see us really think about whether we want to support JavaScript and CSS user subpages indefinitely. There are obvious benefits (extreme flexibility to users, on-site persistent interface customization, etc.) and detriments (security, obscurity, etc.). But whether we continue to support JavaScript and CSS user subpages or not, I think MediaWiki should do so with a full commitment for a long-term plan. We should avoid making promises or recommendations (such as "put this display:none; code in this page) that aren't long-lasting solutions.

MediaWiki needs to fully commit to either indefinitely supporting JavaScript and CSS user subpages or we need to figure out what a better long-term approach would be (if not JavaScript gadgets).

Vaguely related to the above comment: T60236: No longer allow gadgets to be turned on by default for all users on Wikimedia sites and T71445: Implement a proper code-review process for MediaWiki JS/CSS pages on Wikimedia sites.

And what of the projects other than Wikipedia (where maybe only 3 of the original 9 examples given might find some use as a formal, default extension)?

Are those "lesser" projects doomed to get stuck with even more insidiously unstoppable odds and ends - sold as some "new & improved" defaults; most of which will rarely be called upon if ever?

From the description:

• MediaWiki:Gadget-featured-articles-links.js, used by a few wikis to add icons to the sidebar links to featured/good articles in other languages

This functionality now comes from Wikibase and WikimediaBadges. Is it still enabled? Can be removed from the list?

"(This loads the base style for the watchlist. Please do not disable this option.)" in enwiki's gadgets is probably a good candidate for moving into the codebase too.

Seeing it pointed out, I'm a bit curious why that gadget was never changed to be hidden, since it's not supposed to be disabled.

A lot of wikis have gadgets for a simple purge link - can that be intergrated?

In T71550#6070008, @DannyS712 wrote:

A lot of wikis have gadgets for a simple purge link - can that be intergrated?

T56902: Deprecate and remove the purge action from MediaWiki

In T71550#6070011, @Reedy wrote:

In T71550#6070008, @DannyS712 wrote:

A lot of wikis have gadgets for a simple purge link - can that be intergrated?

T56902: Deprecate and remove the purge action from MediaWiki

It doesn't look like that is going anywhere - T56902#6311472
I propose that https://www.mediawiki.org/wiki/Snippets/Purge_action / https://en.wikipedia.org/wiki/MediaWiki:Gadget-purgetab.js become a part of core (or a really small extension)

MediaWiki:Gadget-DRN-wizard-loader.js was deprecated, moved to a ?withJS loader