This task tracks tasks for the Gadgets 2.0 initiative, including any new requirements for ResourceLoader in MediaWiki core.
See also:
| rEGAD extension-Gadgets | |||
| rEGADfce6fdfb20f5 Goodbye Gadget/Gadget_definition namespaces! | |||
What's the current situation here? Is this task stalled? I can neither see any major contributions done to this (nearly done?) project in more then a year nor any major blockers.
Had been hoping to put "Work on Gadgets 2.0" on the wishlist this year, but they are excluding "Global" work, following up on @MGChecker's note from last year - has this been abandoned?
In a conversation last year on wmtech IRC I got an answer, that WMF pulled devs out of this task to do more important stuff. This task therefore have got no devs and money attached from a Foundation and it is not going to be fixed in a near future.
Just for the sake of not loosing the information: I noted that there seems to be something like a standard pattern of how other web-tech-based projects deal with this, namely the pattern of:
These patterns can be found in
– https://www.figma.com/plugin-docs/intro/
– https://wiki.mozilla.org/WebExtensions
– https://dev.jamovi.org/index.html
It might be helpful to look into these things. Particularly the way figma approached the security problems of sharing client-side run code is interesting; they published some blogposts about it.
There might also be a good connect to recent ideas to use react/MVVM that make hook into DOM hard (not that it is a sustainable idea in the first place…)
Is this task (which has 3 or 4 open subtasks) superseded by Gadgets-2.0 nowadays (which currently has 11 open tasks), or what is its exact difference (as it says "implement" and not "deploy")?
Change 981674 had a related patch set uploaded (by Krinkle; author: SD0001):
[mediawiki/extensions/Gadgets@master] Remove redundant data updates for NamespaceRepo
Change 981674 merged by jenkins-bot:
[mediawiki/extensions/Gadgets@master] Remove redundant data updates for GadgetDefinitionNamespaceRepo
Hello! I see that work on gadgets is being done a little more actively than before. And I see that almost all the tasks in this epic are closed. Should we expect gadgets 2.0 soon? And if not, is there any active roadmap? :)
Note: T323811: [EPIC] Community configuration 2.0: Factor Community configuration out of GrowthExperiments proposed to migrate gadget definitions to another complete different schema.
Proposed text for Tech-News:
Gadgets allow interface admins to create custom features with CSS and JavaScript. In 2015, the Gadget and Gadget_definition namespaces and gadgets-definition-edit user right were reserved for an experiment, but never used. These were visible on Special:Search and Special:ListGroupRights. The unused namespaces and user rights are now removed. No pages are moved, and no changes need to be made. (T31272)
Longer explanation:
The Gadgets extension allows admins to define gadgets via a configuration page in the "MediaWiki" namespace, as well as store CSS and JavaScript for these gadgets as wiki pages in that same namespace. For security reasons, the "MediaWiki" namespace is restricted such that only elected admins can create and edit pages there. This is how the Gadgets extension has worked since its inception, originally created in 2006 by Daniel Kinzler.
In 2011, @Krinkle and @Catrope proposed the "Gadgets 2.0" initiative to improve the UX and editing experience for managing gadget definitions (details at mw:Extension:Gadgets/Gadgets_2.0). We implemented a GUI for gadget mgmt, a rewritten backend for gadgets that would use JSON instead of the novel syntax we have today, and redefined access control.
The project was green-lit in 2012, and we began to experiment with different ideas, I suggested we move gadget definitons to a dedicated namespace, protected with separate user rights. I proposed this because, at the time, the user right that protected the "MediaWiki" namespace (editinterface) and the Administrator user group (sysop) were predominantly granted to volunteers for the purpose of content moderation (i.e. protecting/deleting pages, and blocking users). Understanding sofware security isn't part of the assessment communities make. Placing this behind a separate user right would improve security and separate the concerns (in both directions; both to not require giving content moderation to gadget devs, and to not require giving security access to moderators). At the time, it seemed most robust to implement this by having the pages in a separate namespace.
By the end of 2012, resourcing was cut. The code remains in the experimental "RL2" branch in Git, separate from the main Gadgets codebase.
Meanwhile, MediaWiki core gained native support for content models in 2013, including a built-in model for JSON pages.
In 2015, Kunal (@Legoktm) dusted off the Gadgets 2.0 experiment as volunteer, and added some of it to the master branch. Kunal simplified the code a lot by embracing the native JSON support in MediaWiki core. However, it did keep the new namespaces and user right. The feature remained disabled by default, via a configuration flag, however, it did unconditionally reserve the new namespaces and user right, thus exposing them all Wikimedia wikis (e.g. on Special:Search) as empty and non-editable namespaces.
Meanwhile, following a MediaWiki core decision in 2018 (T190015), access controls were refined in MediaWiki core to split off new editsitecss, editsitejs, and editsiteconfig from the old editinterface, along with a new "Interface admin" user group (https://meta.wikimedia.org/wiki/Creation_of_separate_user_group_for_editing_sitewide_CSS/JS).
As of 2024, the Gadgets 2.0 implementation is internally known as MediaWikiGadgetsJsonRepo, and remains incomplete and disabled by default via a configuration variable. Last week, I updated this code and simplified it further to embrace the above developments. In particular:
The MediaWikiGadgetsJsonRepo feature, if completed, would now store its JSON pages under MediaWiki:Gadgets/<id>.json instead of Gadget_definition:<id>. This is in line with present-day expectations and matches how extensions like AbuseFilter, SpamBlacklist, VisualEditor and Citoid store their editable configuration pages.
Note: If there are pages in Gadget namespace, they will become inaccessable and should be moved to a valid title starting with Gadget: once the namespace is gone.
There are, at least on enwiki (and probably only enwiki). The most correct outcome for them is to fall out of the gadget namespace into the main namespace with "Gadget: Foo" titles, since they were never meant to be in gadget namespace in the first place, but I am willing to clean up locally as long as they don't fall into the void.
In particular, https://en.wikipedia.org/wiki/Gadget_talk:Invention,_Travel,_%26_Adventure contains significant content which as much as I'd like to have it vanish into the void and forget about this whole episode <mostly sarcastic>, really should be moved to another namespace rather than deleted. I guess I could manually empty the namespace before the new version is deployed, though.
Pages that need migration:
krinkle@mwmaint1002 $ foreachwiki sql.php --json --query 'SELECT page_namespace,page_title FROM page WHERE page_namespace IN (2300,2301,2302,2303) ORDER BY page_title ASC;' | tee gadget_ns.txt … $ cat gadget_ns.txt | grep -vE '\[\]|---|^[a-z0-9_]+wik[a-z]+$' > gadget_ns.grep.txt …
Results from public wikis:
Reminder to myself to never underestimate the creativity of vandals. All of the non-enwiki pages were vandalism/nonsense of some sort which I've tagged for deletion.
One question arrived now: Is editing of any MediaWiki:Gadgets/ page requiring successor of previous editinterface or gadgets-definition-edit right?
If gadgets-definition is given to all sysops by MediaWiki:Gadgets/<id>.json this will change access to gadget management, may be wanted or unwanted:
What is the future extent of editsiteconfig?
BTW, there is a typo sofware in the press release, and mgmt should not get broadcasted.
Small wikis without IF-admin could manage offered gadgets and circumstances themselve.
Such issue should be solved by global gadgets.
However, gadgets-definition does need an advanced understanding of effects. By bad default too many resources may be loading, or the list of required .js and .css pages is too long or short, and together with hidden a desaster could be covered.
Once T323811 is a thing, we would have a interface to configure gadgets (so we no longer need to edit the definition manually), and we may include good practice there.
A global gadget solving issues specific to issues with Brobdingnag language for Brobdingnag Wikipedia is not a valid case for a global gadget.
No, global gadgets are not a solution for everything, and even if some global gadgets are offered the configuration as desired by local community is on decision of the local community, not the decision of a global WMF government deciding for 950 wikis what is good and useful for everybody.
Today, MediaWiki:Gadgets-definition is declared as a "Raw HTML message", which is how we restrict non-JS pages to require the editsitejs right, which is generally given to the "Interface admin" user group and not "Administrators" (sysop).
The MediaWikiGadgetsJsonRepo experiment, in its current draft, requires the same editsitejs right for editing MediaWiki:Gadgets/<id>.json pages.
Please note that at the moment these page titles are not anything. Not today, this week, nor next week. I was describing a change within an experimental feature that is currently incomplete, disabled by default, and plays no role in this weeks train deployment.
Thanks. I've forked paste P58013 and update it. Diff at https://phabricator.wikimedia.org/transactions/detail/PHID-XACT-PSTE-r2k7e22q3mrfvvk/
Affected pages on Wikipedias where the change is not yet deplyoyed. These could be moved (without redirect please) to e.g. under a Broken/ prefix in the main namespace. After tomorrow, admins can then easily delete them, or rename them "back" without that prefix to keep.
Affected pages on wikis where the change is already deployed. of links and their currently localised name names:
The latter ones are inaccessible except via index.php?curid=PAGEID. Regular links to them no longer work, for example, the last one in the list is nominated for deletion and thus member of https://ru.wiktionary.org/wiki/Category:Викисловарь:К_быстрому_и_безусловному_удалению, but there the entry links to Special:Badtitle/NS2301:зачем as fallback, because the namespace is no longer recognised for linking.
I've looked for a maintenance script to rename pages automatically (either shortly before, or after) deleting a namespace. maintenance/namespaceDupes.php comes to mind, and actually describes itself as "articles to fix after adding/deleting namespaces". But, it appears only the first part of that sentence was ever implemented. The script only sources pages from NS_MAIN, so that by definition will not match pages in a deleted namespace. Anyway, I guess the list is small enough I can fix these by hand.
Mentioned in SAL (#wikimedia-operations) [2024-02-29T01:49:51Z] <Krinkle> ruwiktionary UPDATE page SET page_namespace=1,page_title=CONCAT('Broken/NS2301:',page_title) WHERE page_id=2469240 AND page_namespace=2301 T31272
Mentioned in SAL (#wikimedia-operations) [2024-02-29T01:50:43Z] <Krinkle> ruwiktionary UPDATE page SET page_namespace=1,page_title=CONCAT('Broken/NS2303:',page_title) WHERE page_id=2469241 AND page_namespace=2303; T31272
I have cleaned up on enwiki, deleting one page and its talk outright (since I was the only author, and yes I know it will be unrecoverable even by admins once the namespace vanishes) and moving the other two to other namespaces.
I don't have rights to move without leaving a redirect anywhere else.
Sorry, I wanted to point out that no changes need to be made is problematic. Lua api mw.title:inNamespace would detect the existence of the incoming namespace and throw an error. Abruptly removing the namespace obviously destroys some modules. e.g. Module:PJBSClass#rev80701284@zhwiki
FYI: We noticed a small bug in the pt.wiki MediaWiki:Deletereason-dropdown as {{ns:2300}}/{{ns:2301}}/{{ns:2302}}/{{ns:2303}} was no longer valid. It may be worth doing a scan to identify whether those is still used in other wikis.
Change #1014636 had a related patch set uploaded (by Krinkle; author: Krinkle):
[mediawiki/extensions/Gadgets@master] Replace EditFilterMergedContent hook with ContentHandler override
Hello! Question/Idea: Can we use the #growthexperiments-communityconfiguration "framework" for gadgets?
We need to first productionize it. Community configuration has multiple potential usages (described in T323811), but there are little we can do before that task is resolved.
Change #1014636 merged by jenkins-bot:
[mediawiki/extensions/Gadgets@master] Replace EditFilterMergedContent hook with ContentHandler override
Hi, my suggestion for naming conventions is:
In the module, pages parameter, you would list [ "main.css", "main.js", "main.json"] and it should know to make these subpages of the same rootpage as the definition.json.
Any page that's Gadgets/*/definition.json is automatically a gadget content model
Similar deal for messages where you expect subpages of Gadgets/mygadget
A couple benefits:
The only downside I see is that it requires moving existing gadget pages, but that shouldn't be too hard, a default migration system could make Gadgets/name/definition.json and have the content pages share the same name as it did before, with e.g. Gadgets/name/name.js until a later date when people fix individual gadgets to conform to the new convention nicely.
One other consideration is that if there is a reason to create the page Gadgets/mygadget then *moving* gadgets is really easy, just move all subpages. So maybe that page could contain the i18n string for the gadget that displays in preferences? Then you are encouraged to always create it & it'll be useful if you ever need to move. Extra incentive to make your i18n strings!