@Krinkle, @Legoktm: Thanks. I've started creating some documentation at https://www.mediawiki.org/wiki/Gadgets_2.0. BTW, I've been trying to get the Gadget Manager interface running locally, but haven't had any luck. I've checked out 247869, switched wgGadgetsRepoClass to GadgetDefinitionNamespaceRepo and changed the SpecialGadgets registration to SpecialGadgets2.php. I currently get fatal errors about getDefinitionTitle() being undefined. Is there a particular patchset that I can checkout that will let me load the Gadget Manager and try it out? Do I also need to checkout any pending changesets in core?

Try the "RL2" branch in the Gadgets repository.

Thanks. That works.

Added some documentation on getting the dev code running in case anyone else wants to as well:
https://www.mediawiki.org/wiki/Gadgets_2.0#Temporary_method_until_Gadgets_2.0_code_is_merged

This is done, but waiting for feedback from @Legoktm.

@kaldari: did you get the feedback from @Legoktm ? Is this still only "normal" priority?

In T31398#1925023, @kaldari wrote:

This is done, but waiting for feedback from @Legoktm.

I'm interested in moving the four gadget namespaces to a shared read-only wiki. I want to refer to those namespaces via interwiki prefixes, mapped to the URL of a wiki that holds these content pages. To edit any page retrieved from a remote wiki, a user would need to login to that wiki to perform the editing.

Would the Gadget manager be impervious to this configuration -- that is, read-access to gadget namespaces would be via the interwiki table ??

thanks for any replies.

For those interested in implementing this, there is code for a Gadget Manager implementation already, and can be found in the RL2 branch of the mediawiki/extensions/Gadgets repo. This is from the 2011 prototype that @Catrope and myself worked on at the time.

It is however based on the deprecated jQuery UI. I suggest migrating it to HTMLForm instead.

In T125582#1993994, @TheDJ wrote:

Comments

• ...
• Gadgetmanager wise, I don't see many problems.
  • It's all jQuery UI, which we are trying to get rid off.. but it is fairly self contained, so I think that's ok for now, but is there a ticket for that ?

In T31398#9733653, @Krinkle wrote:

For those interested in implementing this, there is code for a Gadget Manager implementation already, and can be found in the RL2 branch of the mediawiki/extensions/Gadgets repo. This is from the 2011 prototype that @Catrope and myself worked on at the time.

It is however based on the deprecated jQuery UI. I suggest migrating it to HTMLForm instead.

In T125582#1993994, @TheDJ wrote:

Comments

• ...
• Gadgetmanager wise, I don't see many problems.
  • It's all jQuery UI, which we are trying to get rid off.. but it is fairly self contained, so I think that's ok for now, but is there a ticket for that ?

@Krinkle, hi! Would you like to rethink the manager and implement it on the community configuration?

@Urbanecm_WMF hi! Do you think it would be useful to use CC for gadget managment? And is this possible? :)

Change #1107096 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/extensions/Gadgets@master] Add special page UI for configuring gadgets in JSON repo

https://gerrit.wikimedia.org/r/1107096

I went ahead and created a user script. There are a few rough edges, but it is generally usable.

From https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1107096:

In T31398#12056236, @SD0001 wrote:

From https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1107096:

How hard would it be to make this use CommunityConfiguration? It's basically a tailored JSON editor just like all the other CC modules, so it's almost odd for it not to be in CC.

I do think Gadgets should not hard-depend on CommunityConfiguration, though. For tests, you can skip on the file level (outside the class structure) if the test class uses a trait that lives in CC.

In T31398#12056236, @SD0001 wrote:

From https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1107096:

Could you render that sections as details-summary and only keep the basic sections opened? Maybe also re-order a bit like so:

I think most gadgets are like hotcat:
HotCat (⚙️) [ResourceLoader | dependencies = mediawiki.api, mediawiki.user, mediawiki.language ] | HotCat.js
or even simpler:
colored-discussion (⚙️) [ResourceLoader] | colored-discussion.css
OldDiff (⚙️) [ResourceLoader] | OldDiff.css
searchFocus (⚙️) [ResourceLoader] | searchFocus.js

So you definitely need: a code name, description, pages, and in many cases dependencies. The rest is fairly rare. Even deps are sometimes loaded by gadgets internally.

And BTW. ResourceLoader should probably be selected by default.

In T31398#12056577, @MusikAnimal wrote:

How hard would it be to make this use CommunityConfiguration? It's basically a tailored JSON editor just like all the other CC modules, so it's almost odd for it not to be in CC.

I do think Gadgets should not hard-depend on CommunityConfiguration, though. For tests, you can skip on the file level (outside the class structure) if the test class uses a trait that lives in CC.

CommunityConfiguration makes sense for cases where there's a single JSON blob for the whole site. In case of gadgets, there's one for each gadget. I don't think CC supports that use case. Also, Codex doesn't support several of the widgets used here. (Even HTMLForm required several improvements to support this: 1108173, 1106741, 1107093).