Already supported.

Change #1088874 merged by jenkins-bot:

[mediawiki/extensions/Gadgets@master] Show if gadget is hidden

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

Change #1088874 had a related patch set uploaded (by Pppery; author: Pppery):

[mediawiki/extensions/Gadgets@master] Show if gadget is hidden

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

This issue has been already discussed thorougly in the task linked by Bugreporter.

Change #1085310 merged by jenkins-bot:

[mediawiki/extensions/Gadgets@master] Fix safe mode warning message

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

Change #1085311 merged by jenkins-bot:

[mediawiki/core@master] preferences: Fix safe mode warning message

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

Change #1085311 had a related patch set uploaded (by Ammarpad; author: Ammarpad):

[mediawiki/core@master] preferences: Fix safe mode warning message

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

Change #1085310 had a related patch set uploaded (by Ammarpad; author: Ammarpad):

[mediawiki/extensions/Gadgets@master] Fix safe mode warning message

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

Gadgets also shows similar message under Gadgets preference tab and it has the same problem

Hi, my suggestion for naming conventions is:

the category existence check has already happened on the first server loading of the edit page which is the only load for live preview

The parse API should return ext.gadget.Calculator as one of the modules.

I believe the problem is the module presence (to be eligible for return) is dependent on category existence, but the category existence check has already happened on the first server loading of the edit page which is the only load for live preview. You can request the parsing API to return the categories of the page blindly, but then you really have to parse that info (maybe in MediaWiki-extensions-Gadgets) and dynamically load the module if it qualifies.

The only benefit with supporting templates is that using them in interface messages won't weirdly cause a category to show up at the bottom in unexpected contexts like special pages. It also doesn't need a row in categorylinks, sure, but I suspect communities would toss in a category anyway for tracking.

In T63007#10203165, @Tacsipacsi wrote:

I still think T241524: Parser function for loading gadgets is the way to go, not this. If a template with a template gadget has a sandbox, there are two options:

• The sandbox is also added to |templates=. This is impossible if you’re not an interface admin.
• Instead of the main template, a subtemplate has been added to |templates=, which does nothing except for triggering the gadget load (so that the same version can be safely used in the live template and the sandbox). This is no better than those useless categories, except that it appears two lines higher up at the bottom of the edit window than a hidden category.

@Tacsipacsi Regarding the sandboxes of templates with template gadgets, when I work in such sandboxes, I generally don't want to load the same gadget as the main template, but a modified version of the gadget, which I usually store in a subpage of my userpage and load from my common.js

Sure, other approaches may be (marginally) better, but realistically speaking, will take years to happen. This approach can be implemented now and wouldn't block or hinder the development of better alternatives. If anything, it would give it some extra push by helping the development of actual tools to be loaded by said alternatives.

Yup, <templatescripts> (akin to <templatestyles>) seems much cleaner.

I still think T241524: Parser function for loading gadgets is the way to go, not this. If a template with a template gadget has a sandbox, there are two options:

Hi! I just submitted 1077955 to add support for templates in the gadget definitions. After the merge of 1005092, me and a few others developed several JavaScript-enhanced templates (see template gadgets and global gadgets). However, although loading gadgets via categories is technically enough, it leads to the creation of many obscure and otherwise useless categories (see every subcategory here and here). This is unnecessary and cumbersome, it would be better if we could load gadgets based on the presence of specific templates, which is generally the intended functionality anyway.

Change #1077955 had a related patch set uploaded (by Sophivorus; author: Sophivorus):

[mediawiki/extensions/Gadgets@master] Add support for templates in definitions

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

Change #1077955 had a related patch set uploaded (by Sophivorus; author: Sophivorus):

[mediawiki/extensions/Gadgets@master] Add support for templates in definitions

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

In T357197#10110025, @Ladsgroup wrote:

Just mentioning that soon TLSv1.2 will be phased out and given https://caniuse.com/?search=tls%201.3 vs https://caniuse.com/?search=await users who can't use async/await won't be able to connect at all so the whole discussion here about compatibility and impact is moot.

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 ?

Just mentioning that soon TLSv1.2 will be phased out and given https://caniuse.com/?search=tls%201.3 vs https://caniuse.com/?search=await users who can't use async/await won't be able to connect at all so the whole discussion here about compatibility and impact is moot.

In T357197#10110025, @Ladsgroup wrote:

Just mentioning that soon TLSv1.2 will be phased out and given https://caniuse.com/?search=tls%201.3 vs https://caniuse.com/?search=await users who can't use async/await won't be able to connect at all so the whole discussion here about compatibility and impact is moot.

I wanted to note T373711: Add support for Scribunto, JavaScript, CSS, JSON and Vue to CodeMirror 6 which I hope to have tackled by MW 1.44, if not sooner. This is not a proposal to replace CodeEditor/Ace (yet), but CodeMirror does already has support for Vue. So I guess keep that in mind in your decision making.

See rEGAD5d3a547c8bd63a6b77f9705c096ebfd11d1fdb75 and T29766#7611796