Page MenuHomePhabricator

Move code in enwiki MediaWiki:Common.js and Gadgets to MediaWiki software
Open, LowPublic

Description

There are various bits of JavaScript in Common.js and default gadgets to customise the enwiki experience. It is a shame they are not customisable in LocalSettings.php or bits of code in the JS experience.

Let's aim to start removing the need for this code in enwiki (and then long term in other projects) and help update our software to meet the use cases/address the gaps that editors of that page have clearly identified.

Currently, the default gadgets (which registered users can opt-out) are these:

Some of them were previously in Common.js, and some are just loaders for the main scripts which are used in specific pages. These would benefit from T17075: Per book, category and/or template CSS and JavaScript.

See also

Details

Reference
bz69550

Related Objects

StatusAssignedTask
OpenNone
OpenNone
OpenNone
OpenNone
DeclinedNone
ResolvedTheDJ
ResolvedNone
ResolvedParent5446
Resolvedcsteipp
Resolvedmatmarex
Resolvedmatmarex
Resolvedmatmarex
DeclinedGlaisher
ResolvedNone
ResolvedNone
OpenNone
OpenCenarium
DeclinedBawolff
ResolvedJdlrobson
ResolvedNone
OpenNone
OpenNone
OpenNone
OpenNone
ResolvedWargo

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:30 AM
bzimport set Reference to bz69550.
bzimport added a subscriber: Unknown Object (MLST).

Common.js ships blank in MediaWiki.

I imagine this is meant to be about Wikimedia. :-)

Is this bug intended to be specific for enwiki?

In the last months/days we have migrated a few of the scripts which were loaded from common.js[1] to gadgets enabled by default:

  • Geonotices:

https://en.wikipedia.org/wiki/WP:Village_pump_%28technical%29/Archive_129#Migrating_Geonotice_to_a_gadget

  • Interwiki links to good/featured articles/lists:

https://en.wikipedia.org/wiki/MediaWiki_talk:Common.js#Global_gadget_for_LinkFA
(this will be superseded by Wikidata badges - bug 40810)

  • RefTools:

https://en.wikipedia.org/wiki/MediaWiki_talk:Common.js#Move_initializeRefTools_to_a_default_gadget

But it is likely that similar improvements are still pending on other N wikis.

Moreover, we still have to migrate other parts, such as

  • Extra edit buttons:

https://en.wikipedia.org/wiki/MediaWiki:Common.js/edit.js

  • Addition of links to rendered PNG images in different resolutions:

https://en.wikipedia.org/wiki/MediaWiki:Common.js/file.js

  • Dismiss-able buttons to watchlist messages:

https://en.wikipedia.org/wiki/MediaWiki:Common.js/watchlist.js

  • Loader for [[Meta:WikiMiniAtlas]]: [1]
  • Old collapsible tables/navframes in[1], to be synced with (and then loaded from)

https://www.mediawiki.org/wiki/MediaWiki:Gadget-collapsibleTables.js
(jquery.makeCollapsible from core still lacks functionality to be used instead of the local versions, and there are bug reports for them)

  • Rewriting of links to stay on secure server:

https://en.wikipedia.org/wiki/MediaWiki:Common.js/secure_new.js

And there are also thinks like:

  • A workaround for bug 8912 in the bottom of MediaWiki:Common.js/edit.js
  • Implementation[1] of redirects from /skin.js to the JS page associated to the skin the user is using. This could be added to MediaWiki.

[1] https://en.wikipedia.org/wiki/MediaWiki:Common.js

Yes to be clear, I think we should be going through English Wikipedias Common.js and moving code here into the software. I then envision similar bugs for other language projects.

To me the need to use Common.js is highlighting issues in the core software that need to be fixed. We should be making the software more efficient. The redirect of User:Jdlrobson/skin.js to User:Jdlrobson/vector.js if I have Vector enabled is a great example. This should be /in/ the software! :)

Have updated bug title to be clearer. Sorry.

enwiki sounds like a good starting point (given that a ton of things just get copied directly from there), but that's not to say we shouldn't be improving JS used on other wikis.

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.

He7d3r updated the task description. (Show Details)Dec 2 2014, 7:24 PM
He7d3r set Security to None.

Is this bug intended to be specific for enwiki?

I'd suggest that we make the scope global.

GOIII added a subscriber: GOIII.Mar 14 2015, 12:14 PM
wctaiwan added a subscriber: wctaiwan.EditedApr 9 2015, 10:19 PM

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.

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.

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.

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.

Nemo_bis added a subscriber: Nemo_bis.

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.

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).

GOIII added a comment.Apr 14 2015, 3:10 AM

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?

Nemo_bis removed a subscriber: Nemo_bis.May 6 2015, 12:09 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 4 2015, 7:06 PM
He7d3r updated the task description. (Show Details)Sep 26 2015, 4:39 PM
Prtksxna updated the task description. (Show Details)Mar 25 2017, 6:19 AM
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?

wctaiwan removed a subscriber: wctaiwan.Mar 25 2017, 6:32 PM
TheDJ updated the task description. (Show Details)May 11 2018, 2:34 PM
TheDJ removed a subscriber: wikibugs-l-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.

Elitre removed a subscriber: Elitre.Nov 28 2018, 2:42 PM