User Preferences don't offer Gadgets

I installed a local wiki via MoWeS including MW 1.18.0 at 2011-11-28. Then I added several extensions incl. Gadgets. All requirements for Extension:Gadgets should be fulfilled: LocalSettings has require_once. MediaWiki:Gadgets-definition is defined:

*Pfeil-hoch|Pfeil-hoch.js

[[MediaWiki:Gadget-Pfeil-hoch.js]] and [[MediaWiki:Gadget-Pfeil-hoch]] are imported. But this gadget is not yet accepted:

• Special:Gadgets doesn't contain any gadget.
• Special:Preferences doesn't show a tab Gadgets.

What do I miss? Are gadgets preserved for the WMF version of MW? If so, which files must be fixed? Do I need a configuration setting? What else? Thanks for help! Juergen Juetho 16:24, 5 January 2012 (UTC)

Can you provide a link to your wiki for us to look at ? In the mean time, confirm via Special:Version that your extension is actually being recognized properly. Krinkle 02:17, 6 January 2012 (UTC)

Unfortunately, it's a local wiki like I wrote. Special:Version shows Gadgets in the section Others.

I could search by myself if I could read the current installation and configuration of de-Wikibooks. But I don't know how to check LocalSettings.php and all the files in the includes folder like SpecialPage, SpecialPageFactory, and so on if there are relevant differences between WB and my own configuration. Juetho 08:03, 6 January 2012 (UTC)

Just adding that line to your MediaWiki:Gadgets-definition should already make it appear on Special:Gadgets and Special:Preferences, regardless of any configuration or importing of the actual JavaScript/CSS resources.

If that isn't working there are likely other, bigger, issues.

Are any other gadgets working ? Anything in your error log ? Krinkle 20:10, 7 January 2012 (UTC)

In the meantime, I checked some options. (The MW configuration script tells that options aren't necessary, but they are very useful.) Nevertheless, nothing helps.

MediaWiki:Gadgets-definition contains the line above, and this line only. I reduced the definition site to a simple gadget for testing.

The error log tells this:

(20024)The given path is misformatted or contained invalid characters: Cannot map GET /wiki/index.php/MediaWiki:Gadgets HTTP/1.1 to file, referer: http://localhost/wiki/index.php/MediaWiki:Gadgets-definition

Moreover, I found differences in Special:Preferences:

• Generally (like in my local wiki), there are 8 tabs: beginning with User profile and ending with Misc
• WMF projects add: Pending changes, Gadgets
• MediaWiki adds: Edit review, Gadgets, Threaded discussion, Contests

There must be a reason for the differences between WMF and MW. I suppose the same reason would lead to my problem's solution. Juetho 14:48, 26 January 2012 (UTC)

I don't understand anything anymore. After creating a new wiki including this gadget, there was no tab gadgets. After I switched on ShowExceptionDetails, the gadgets tab was shown. I wonder... Juetho 14:58, 26 January 2012 (UTC)

... and wonder on and on. It seems to work properly - also using other gadgets like wikEd.

The only exceptionDetail is "Zeitüberschreitung" (time overflow or so). But that's another problem because the local wiki works very slowly.

I would appreciate if you could give more hints. I want to write advices how to install a local wiki using MoWeS (see in my first post). Juetho 16:05, 26 January 2012 (UTC)

Maybe this is being caused by bugzilla:29794?

Try to open "MediaWiki:Gadgets-definition" for editing and paste the following line in your browser's address bar:

javascript:$('#wpTextbox1').val( $('#wpTextbox1').val().split(String.fromCharCode(8206)).join() ); void 0;

and then check if this makes any changes (like some of these). Helder 15:48, 8 February 2012 (UTC)

New feature

Is it possible to add option that we can set some of the gadgets only for IP and not confirmed and when they will registered it will dis-activated. Reza1615 (talk) 17:17, 20 February 2012 (UTC)

For anons: make them standard JS and check for javascript globals in the DOM (above body). Subfader (talk) 00:01, 21 February 2012 (UTC)

close, but this won't create the desired effect exactly - what the OP asked for would allow for registered users to "opt-in", while your solution does not. however, this is the closest i can think of with a single script.

alternatively, you could play a little variation on the above: call the gadget directly from common.js under the condition "mw.user.anonymous()", and make the gadget non-default. קיפודנחש (talk) 07:08, 21 February 2012 (UTC)

He wants it active for anons and inactive for loggedin users = no gadget. Subfader (talk) 10:11, 21 February 2012 (UTC)

I'd recommend do making it as a gadget to allow optimized loading of it as well as internalization. Simply make it a normal gadget that doesn't have [default] but does have [ResourceLoader]. And from MediaWiki:Common.js (as קיפודנחש suggested), call mw.loader.load('gadget.YOUR_GADGET_ID') under a conditional:

mw.loader.using('medawiki.user', function() {
    if (mw.user.anonymous()) {
        mw.loader.load('ext.gadget.YOUR_GADGET_ID');
    }
});

Krinkle (talk) 04:26, 23 February 2012 (UTC)

For the record: the mw.loader.load can also be in a default gadget hidden from preferences with the "|rights=hidden" hack (example) or with the native "hidden" option from the next version of the gadgets extension. Helder 19:24, 1 August 2012 (UTC)

Someone with proper insight should properly document the [hidden] parameter. — Edokter (talk) — 12:15, 20 May 2014 (UTC)

Be aware of typos, here's a working version of the code above:

mw.loader.using('mediawiki.user').done(function() {
    if (mw.user.isAnon()) {
        mw.loader.load('ext.gadget.allinterwiki');
    }
});

 « Saper // talk »  23:31, 28 January 2017 (UTC)

Cannot use gadgets

Hi, this is admin in Commerce Network Nightly Builds. I have a problem in setting gadgets. The problem is this: As I found that I the gadget extension is installed, then I went to Special: gadgets and edit "Uses:". After that, I ticked my check box in the preference page. There is no gadgets appeared, could someone please tell me how to fix it? -Shinghinyeung (talk) 12:17, 8 March 2012 (UTC)

You have to have the Javascript already prewritten and called in MediaWiki:Gadgets-definition. Jasper Deng (talk) 22:13, 8 March 2012 (UTC)

So what does this means?

I mean how to called in the page MediaWiki:Gadgets-definition. Shinghinyeung (talk) 09:20, 9 March 2012 (UTC)

Maybe one of the gadgets you enabled is broken?

Have you tried enabling only one at a time?

Try disabling all gadgets, and creating a small gadget containing only something like

alert('It works!');

to see if you can make it to display a message. Helder 16:57, 9 March 2012 (UTC)

I have tried it does not work. Shinghinyeung (talk) 03:39, 11 March 2012 (UTC)

In actual fact, I have no idea of how to build a gadget even I read the Extension: Gadget#usage section, could someone tell me how to enable a gadget. This is what I think I have missed out. -Shinghinyeung (talk) 03:24, 11 March 2012 (UTC)

I think I have declared the gadget, so I will try what Helder told me, please ignore the upper one. Shinghinyeung (talk) 03:36, 11 March 2012 (UTC)

I have tried both Helder and Jasper's method and it still does not work. The gadgets are all come from the Mediwiki.org and I have no idea what to do at the moment. Shinghinyeung (talk) 03:52, 11 March 2012 (UTC)

Have you looked at the instructions in Gadget kitchen? Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator (talk) 06:33, 11 March 2012 (UTC)

I looked at it, did some improvements, but still not working. Shinghinyeung (talk) 08:47, 11 March 2012 (UTC)

When you say "still not working", please be more specific. What have you tried? Do you see some kind of error message? You should probably also try coming into #mediawiki ^connect to get more immediate help. Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator (talk) 09:13, 11 March 2012 (UTC)

Sorry, I mean nothing happened. No gadgets function appeared.

But thanks for advising me, I am appreciated for your help. Shinghinyeung (talk) 11:37, 11 March 2012 (UTC)

mw.loader::execute> Exception thrown by ext.gadget.mySandbox: Bad constructor arguments

I am encountering the following error (which is visible in Chrome's console log):

mw.loader::execute> Exception thrown by ext.gadget.mySandbox: Bad constructor arguments

• I have MediaWiki 1.19.1 and have enabled the default Gadgets extension that came with the site.
• MediaWiki:Gadgets-definition contains only one entry

* mySandbox[ResourceLoader|dependencies=mediawiki.util,mediawiki.Title,mediawiki.Uri|default|rights=createpage]|mySandbox.js

• MediaWiki:Gadget-mySandbox contains the same info as Wikipedia's entry.

Add a "my sandbox" link to the personal toolbar area.

• The Gadgets tab is showing up in Preferences and the checkbox for Add a "my sandbox" link to the personal toolbar area is checked.
• MediaWiki:Gadget-mySandbox.js contains the same info as Wikipedia's entry.
• In trying to narrow down the issue, it appears to be blowing up on the following line:

url = new mw.Uri( title.getUrl() );

• I can put an alert right before that line and successfully get a value back for:

alert( title.getUrl() );

• So it appears to be choking on creating the new Uri object

Not that it would factor in to client-side script error, but here are the specifics on our WAMP environment:

• Windows Server 2008
• Apache 2.4.2
• MySQL 5.5.27
• PHP 5.4.5
• MediaWiki 1.19.1

Any assistance would be appreciated. Thanks!

-- Mattsmith321 (talk) 15:50, 27 September 2012 (UTC)

Forgot to include a couple of relevant facts:

• Problem is occurring in Chrome and IE8. I have not tested other browsers.
• I have hard-refreshed on both browsers (Ctrl+F5, Ctrl+Shift+R) with no change.
• I have shut everything down with no change (as expected).
• I have rebooted with no change (as expected). Mattsmith321 (talk) 15:54, 27 September 2012 (UTC)

I partially solved the issue. The value coming back from "title.getUrl()" was not coming back with the fully qualified path. It was just coming back with "/wiki/Special:MyPage/sandbox". However mw.Uri appears to need a fully qualified URL to work successfully. I'm not sure why I'm not getting the fully qualified URL. It could be because we mostly use the sub-domain (http://wiki vs http://wiki.example.com to access the wiki (since it is internal only). The quick and easy fix was to update MediaWiki:Gadget-mySandbox.js as follows:

url = new mw.Uri( 'http://wiki' + title.getUrl() );

Granted, this screws us for portability but it hasn't gone anywhere in seven years... Mattsmith321 (talk) 21:58, 27 September 2012 (UTC)

i believe it's the other way around: title.getUrl() actually is supposed to return the relative path (i.e., "/wiki/Special:MyPage/sandbox"). however, the mw.Uri is supposed to live peacefully with this value. so it seems that the problem lies with the mw.Uri object.

my guess is that some variable this library expects to have a value which should be set in LocalSettings.php, either does not have any value, or has bad value. קיפודנחש (talk) 02:25, 28 September 2012 (UTC)

Activating Gadgets on 1.17?

Hi. We're running MW 1.17 and I'm trying to activate the Gadgets extension. The version linked to on the download page says that the extension requires 1.17, yet when I try to activate it I get an error message saying 1.19 or later is required. When I follow the link for older versions here: https://www.mediawiki.org/wiki/Special:ExtensionDistributor/Gadgets I see only options to download for 1.19 and 1.20. Can anyone tell me how to enable Gadgets on 1.17, if that's at all possible? thanks Themicksa (talk) 14:50, 11 February 2013 (UTC)

MediaWiki 1.17 isn't in the download distributor because the 1.17 branches were maintained before we migrated from Subversion to Git, so they're not in the new system. Only branches from 1.19 onwards are in Git (and by extend in the distributor).

If you know how to use SVN, you can grab it here from the SVN repository (no longer maintained, but we've preserved old branches):

https://svn.wikimedia.org/viewvc/mediawiki/branches/REL1_17/extensions/Gadgets/

I'd really recommend upgrading to MediaWiki 1.19 or 1.20 soon though, as MediaWiki 1.17 is no longer supported (and MediaWiki 1.18 also just got its last maintenance release). Krinkle (talk) 02:31, 13 February 2013 (UTC)

Thanks for your reply. I didn't realise we were getting quite so far behind! I'll get our IT to upgrade asap. Themicksa (talk) 13:11, 21 February 2013 (UTC)

Bad luck for us who are running Debian stable (squeeze) then. We're stuck on version 1.15. Leif B. Kristensen (talk) 22:09, 21 February 2013 (UTC)

Indeed. Helder 19:20, 22 February 2013 (UTC)

Not working for 1.21.1?

See MediaWiki bug 49228 Rob Kam (talk) 22:55, 24 June 2013 (UTC)

Browsable gallery of known gadgets

Someone should make a gallery of gadgets, with a link to download it. Kinda like with extensions. RocketMaster (talk) 18:17, 30 September 2013 (UTC)

Gadgets 3.0? Helder 21:10, 30 September 2013 (UTC)

In addition to future plans for Gadgets 3.0. In the present there is:

• Special:Gadgets on mediawiki.org
• Special:Gadgets on en.wikipedia.org
• Special:Gadgets on meta.wikimedia.org

Each gadget has a description, links to source code pages, and an Export feature to download it as an XML bundle that can be imported using Special:Import on another wiki. Krinkle (talk) 04:29, 1 October 2013 (UTC)

[ResourceLoader] param

Does [ResourceLoader] parameter not work in MW 1.19.8? Because when I remove that my gadget starts working. UltimateSupreme (talk) 14:01, 11 November 2013 (UTC)

MobileFrontend

Hi! How to enable gadgets for MobileFrontend? UksusoFF (talk) 05:43, 30 April 2014 (UTC)

Gadget dependent on gadget

The page implies that it's possible to have one gadget dependent on another, but I can't seem to find a dependency syntax that works. Can someone give an example? – Robin Hood  ^(talk)</sp 22:54, 19 January 2015 (UTC)

* gadgetname[ResourceLoader|dependencies=ext.gadget.anothergadgetname]

Note that the ohter gadget must be loaded using ResourceLoader as well, otherwise it is not available as a module. -- [[User:Edokter]] {{talk}} 12:52, 20 January 2015 (UTC)

Thanks, that worked beautifully! I've added an example to the page to make it easier for future editors. – Robin Hood  ^(talk)</sp 19:49, 21 January 2015 (UTC)

== necessary in gadget-code == I [https://www.mediawiki.org/w/index.php?title=Extension:Gadgets&diff=2069537&oldid=1969775 deleted a section] about adding <nowik> in comments to the gadget code because this seems to be obsolete now. Please revert my edit, when this is still necessary. Thanks! [[User:Stephan Kulla|Stephan Kulla]] ([[User talk:Stephan Kulla|talk]]) 20:54, 4 March 2016 (UTC) == Renaming a gadget while keeping its activation state for users == Hi, just a feature request. It would be great to be able to rename a gadget (in ''MediaWiki:Gadgets-definition'' plus renaming the corresponding ''MediaWiki:Gadget-Foobar'' page), while keeping the users' preferences about its activation state. [[User:Od1n|Od1n]] ([[User talk:Od1n|talk]]) 05:44, 25 September 2016 (UTC) == Namespaces == What is use of these two gadget namespaces (gadget and gadget_definition)? I found some informations on [[Gadgets 2.0]] but it is not released yet. [[User:Wargo|wargo]] ([[User talk:Wargo|talk]]) 13:58, 17 October 2016 (UTC) :It is only for Gadgets 2.0. You can subscribe to [[phab:T31272]] and/or its subtasks to get notified of any progress on this. [[User:He7d3r|Helder]] 14:07, 17 October 2016 (UTC) == mw.loader.load(ext) == {{Archive top|result=Thanks.|status=resolved}} Hello, I want to use mw.loader.load('//en.wikipedia.org/w/load.php?modules=ext.gadget.popups&only=scripts'); instead of mw.loader.load('<nowiki>https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript');

But this code doesnt work. Iniquity (talk) 17:41, 29 April 2017 (UTC)

According to the code returned by https://en.wikipedia.org/w/load.php?modules=ext.gadget.popups&only=scripts, there is no module named "ext.gadget.popups" on English Wikipedia.

Indeed, on en:MediaWiki:Gadgets-definition this gadget was defined as "Navigation_popups", so this should work:

mw.loader.load('https://en.wikipedia.org/w/load.php?modules=ext.gadget.Navigation_popups&only=scripts'); Helder 02:04, 20 May 2017 (UTC)

Possibility to load from interwiki

Would it be possible to add the possibility to recognize an interwiki link in MediaWiki:Gadgets-definition and load file from there? Minilexikon (talk) 09:21, 8 June 2017 (UTC)

See ongoing (but stalled) work on Extension:Gadgets/Gadgets 2.0. (phab:T31272) Jeblad (talk) 04:50, 1 January 2018 (UTC)

Actually, global gadgets is not planed for gadgets 2.0 anymore. It is only going to happen on 3.0, if it ever does (see Extension:Gadgets/Roadmap#Gadgets_2.0, phab:T22153#2736770, phab:T31272#1469722). Helder 16:17, 29 April 2018 (UTC)

Gadget definition namespace?

What is the Gadget definition namespace for? I noticed there's nothing in the manual for it (and it's not even being used on Wikipedia). So what is it for? Pcj (talk) 13:45, 28 April 2018 (UTC)

It is for gadgets 2.0. See phab:T31272. Helder 16:10, 29 April 2018 (UTC)

Conditional loading in definitions, depending on action, namespace, etc.

Gadgets are often wrapped with conditional execution tests, like (made-up example):

if ( mw.config.get( 'wgNamespaceNumber' ) === 14
|| mw.config.get( 'wgAction' ) === 'history'
|| mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Contributions' ) {

    mw.loader.using( 'oojs-ui', function () {
        // gadget code
    } );

}

Note the above avoids loading the heavy OOUI when it's not used.

However, if you have the following definition line:

MyGadget [ResourceLoader|dependencies=oojs-ui] | MyGadget.js

… then OOUI will be loaded on each and every page.

Therefore, it could be helpful to implement additional definition options, that would load the gadget only on given namespaces/actions/specialpages/etc., like:

MyGadget [ResourceLoader|dependencies=oojs-ui|namespaces=14,>=0,Category,categorie|actions=diff,edit,history,view|specialpages=all/any,Contributions,whatlinkshere] | MyGadget.js

Od1n (talk) 09:29, 13 May 2018 (UTC)

I do support this request.

If I recall correctly, some other conditions like user group have been added in recent years, and similar wishes for namespace condition and action condition came up multiple times. PerfektesChaos (talk) 11:02, 13 May 2018 (UTC)

+1 Absolutely, there are many Gadgets which have wrapper or if not wasting needless resources on every page load.

Tracked in Phabricator
Task T204201

Tracked in Phabricator
Task T63007

OT PS: this Flow extension is horrible!! → User: Perhelion 09:45, 16 February 2019 (UTC)

What are "system messages"?

Extension:Gadgets#Pages Johnywhy (talk) 17:15, 18 June 2018 (UTC)

Help:System message Ciencia Al Poder (talk) 17:36, 18 June 2018 (UTC)

"shared" in metadata

I'm a coding guy from several wikis at FANDOM (formerly known as Wikia). FANDOM is running MediaWiki v1.19 (what a shame), so it's technically able to use the Gadgets extension. I was wondering when I did an api request to get all my activated gadgets, what query.gadgets.metadata.settings.shared means. Is it something like the current "dependencies" option?

Thanks in advance! Minilexikon (talk) 16:47, 25 July 2018 (UTC)

About gadgets using multiple css/js files with different conditions

Can I definite a gadgrt like this (if I were admin): a gadget using a.css, b.css and c.css. It displays for all users, but gadget-b.css only works for Vector users and c.css only works for Monobook users? SolidBlock (talk) 16:20, 27 January 2019 (UTC)

i do not know the answer to the question as phrased, but i think the same goal can be achieved rather simply:

each of the skins' bodies declares a class, e.g., for vector, it's "skin-vector" and so on and so forth.

you can define a single css for the gadget, and precede each of the rules (or rather, each of the rules which are "skin specific") with .skin_XXX, so each of those rules in your unified css, will apply to specific skin only.

i understand this is not what you asked, exactly, but if i understood correctly what you are trying to do, i think "my" solution is simple and straightforward.

peace קיפודנחש (talk) 18:08, 27 January 2019 (UTC)

There is a way to specify that the entire gadget is considered only if the current skin matches this or that particular one.

However, this was not your question. You want to run the gadget for every skin, but load particular resources depending on current skin.

Well, the current skin is known to the JS gadget, and depending on that you may load different CSS pages by mw.loader.load(). However, CSS definitions then arrive quite late and might change the first presentation in an undesirable way.

The suggestion made before is better: Load one common CSS resource from the first beginning, and distinguish by classes .skin-vector those rules which are not appropriate for all skins.

PerfektesChaos (talk) 18:24, 27 January 2019 (UTC)

Alternatively, you could split your gadget into a single common gadget and skin-specific gadgets (so for your example you would end up with three gadgets), which would avoid the load timing issues of PerfektesChaos' suggestion. However, it would then require your users to enable separate gadgets for the same functionality (or require you to set multiple gadgets to active by default and maybe hidden depending on what you're after).

So again, the suggestion to use skin-specific classes in a single CSS file is the best option here. 「ディノ奴千？！」^{☎ Dinoguy1000} 00:13, 28 January 2019 (UTC)

Using class selector ".skin-vector" is OK, but not convenient. But body class doesn't include usergroups. Maybe I can use JavaScript. SolidBlock (talk) 04:14, 28 January 2019 (UTC)

With JavaScript you can do nearly everything, but at the risk of en:FOUC.

It is almost impossible to wait until CSS has been loaded and is in effect, then beginning to insert your HTML elements.

There are classes depending on user groups, like sysop or not anonymous, but IIRC they need to be defined by project. German Wikipedia can limit CSS visible to sysop only, e.g. a block user button which is meaningless for everybody else, or do not offer user preferences to anonymous users.

Another approach would be to use the ostracised inline style="" and create HTML elements only under certain conditions and provide specific CSS. Such inline style is present together with the element and does not depend on style sheets arriving later. By smart programming they allow centralised maintenance like class rules. PerfektesChaos (talk) 15:53, 30 January 2019 (UTC)

Loading Remote Definition File For All Users

Over at Wikipedia, the Navigation popups instructions for "Installation on remote MediaWiki installations, or via your global.js" provide instructions only on loading for a single user. How can one load it for all users? Placing the recommended js in the remote wiki's "MediaWiki:Gadget-popups.js" has no effect. That recommended js is:

// [[Wikipedia:Tools/Navigation popups]]
mw.loader.load('https://en.wikipedia.org/w/load.php?modules=ext.gadget.Navigation_popups');

Jabowery (talk) 14:51, 21 April 2019 (UTC)

The path with MediaWiki:Gadget is one good starting point, but needs to be a bit more elaborated.

There are two approaches:

1. Activate (by default) for all users, but offer the capability to switch off (for registered users) or on.
2. Activate with almost no escape for all (desktop) users: MediaWiki:Common.js (not longer used here, for sake of first approach).

The first approach is much more flexible and user friendly; see MediaWiki:Gadgets-definition as an example and Extension:Gadgets.

For an external Wiki please be sure that this extension is installed. PerfektesChaos (talk) 15:40, 21 April 2019 (UTC)

How to have this code on a wiki page using Gadgets?

Hi,

How can I have this code script on a mediawiki page using Gadgets? Not on header or footer, I mean just within the content of a page, how can I have this?

Thanks,

<div id="15068716388"><script type="text/JavaScript" src="https://www.aparat.com/embed/aWf7R?data[rnddiv]=15068716388&data[responsive]=yes"></script></div> Farvardyn (talk) 21:02, 3 May 2020 (UTC)

You can't without whitelisting the script tag, and that will not happen on Wikimedia sites. Jeblad (talk) 16:39, 4 May 2020 (UTC)

Best practice for gadget configuration

Hi,

I have a gadget that I'd like to allow a user to be able to optionally configure. For example, say I'd like to pass in a boolean that disables the gadget based on some user logic (e.g. page name + phase of the moon). This config could be quite complex and contain arrays and objects and all sorts of things.

I have seen use of mw.hooks.fire/add, but this seems like it is vulnerable to ordering issues - it's not an issue when loading user scripts, as you can just load the script (which calls hooks.add) after setting up your config object and calling hooks.fire.

The problem is have is that the gadget performs an action pretty much immediately on page load, so it's more than possible the gadget could fire before the user has set the config (in this case, to disable it). For other actions (e.g. something like HotCat where the user will interact with it much later, you can be pretty sure the config got loaded by the time the user comes to interact with it.

However, it also needs to not block forever, as users without extra config should still be able to use the gadget (in the trivial "enable" example, the gadget is always enabled).

Is there a canonical "right way" to pass configuration to gadgets? Thanks! Inductiveload (talk) 20:10, 13 June 2020 (UTC)

Hi. Have you tried API:Options? It allows you to set persistent and per-user configuration values, just remember that keys must start with a userjs- prefix. Retrieval is achieved via mw.user.options.get, which means no asynchronous API calls are involved at all and you can use those values on page load.

Check w:pl:MediaWiki:Gadget-gConfig.js, w:pl:MediaWiki:Gadget-gConfig.css for an implementation of a custom preference manager which also enables a user interface for ease of access and modification of userjs-XXX variables. Of course, you can keep it far more simple than that. Peter Bowman (talk) 20:31, 13 June 2020 (UTC)

Thanks, that's an interesting approach.

However, it's not quite as flexible as I'd ideally like, since you can only set static values, whereas I'd quite like to be able to dynamically set some options. For example, you might want to disable a gadget based on a page title. Or, more practically, you might want to pass in a list of regexes for page processing. Inductiveload (talk) 21:15, 13 June 2020 (UTC)

Tracking adoption

Is there some way of tracking how widely used a particular Gadget is? I.e. how many users have enabled it (or disabled it if on by default)? André Costa (WMSE) (talk) 07:38, 2 July 2020 (UTC)

You can track usage of non-default enabled gadget in Special:GadgetUsage. Peter Bowman (talk) 08:57, 2 July 2020 (UTC)

Doh! How did I miss that one. Many thanks. André Costa (WMSE) (talk) 08:59, 2 July 2020 (UTC)

for completeness:

unfortunately, currently there's no way to view how many users disabled a default gadget.

there's an open ticket to add this stat to gadget usage: phab:T121516.

peace קיפודנחש (talk) 16:10, 2 July 2020 (UTC)

Associate Theme Gadgets - Select ONE

Is there a way to allow mutually exclusive selection of a Gadget? Just like one cannot use two skins at once, neither should they use to skin-theme Gadgets at once.

I have my theme Gadgets associated under a "Skin Theme" section on Special:Preferences#mw-prefsection-gadgets page, so there should be a way to give them radio-button like behavior I would think. ~z929669 Talk 02:46, 6 December 2020 (UTC)

I'd be happy to be proven wrong, but I don't think there's any built-in functionality to do something like that. I think you'd have to create a selector gadget whose responsibility is allowing your users to select a skin theme; the downside here is that now you've got to store their selection yourself. If it's a registered-accounts-only thing (as I'm guessing from the description you wrote), you can have the gadget create a page in the user's userspace with their setting (a .js or .json page would be best for this, since non-admin users cannot edit one of these pages outside their own userspace); if not, you'd have to set a cookie or use LocalStorage or something else browser-side. 「ディノ奴千？！」^{☎ Dinoguy1000} 08:20, 6 December 2020 (UTC)

Yes, my users are registered via a linked forum account, so it's a closed wiki. It doesn't hurt to have three skin theme gadgets. They override each other completely, with the lowest on the list having priority, but they can select all three at the same time, which seems clunky.

I thought there may be built-in functionality to allow mutually exclusive selection. ~z929669 Talk 14:48, 7 December 2020 (UTC)

Note that the "selector gadget" can't run on Special:Preferences (no site/user script/gadget code runs there at all, for security purposes), so users would still be able to select multiple such gadgets at once from that place, sadly. Jdforrester (WMF) (talk) 15:37, 7 December 2020 (UTC)

The point to suggesting a "selector gadget" was that it would take the place of the individual theme gadgets: instead of choosing a theme via Special:Preferences, editors would instead choose it via the selector gadget, and the themes themselves would no longer be listed on Special:Preferences. (I realize I forgot to actually say this before, though.)

Since the theme gadgets are designed such that they aren't conflicting if multiple are enabled, and alternatives to prevent this would involve extra balls to juggle for the gadget author/maintainer (and probably also flashes of unthemed content, before the theme has been able to load and be applied on the current pageview), it's probably better to just accept the current state of things - if Gadgets 2.0 is any indication, we're not likely to see improvements to the gadgets system for a long time. 「ディノ奴千？！」^{☎ Dinoguy1000} 21:32, 7 December 2020 (UTC)

Yeah, I was thinking the same thing. It works fine but is just not tidy. I can see users complaining that their theme selections aren't working without realizing that they left multiple selected

... on another note, this all could be complicated by the supposed planned move from Mediawiki to Gadgets namespace for loading resources. See: my post over there. Basically, a lot of wikis' css/js could be broken if not done with care. ~z929669 Talk 22:37, 7 December 2020 (UTC)

I can see users complaining that their theme selections aren't working without realizing that they left multiple selected

It sounds like each gadget can already detect when more than one is enabled; if that's right, then it should be pretty straightforward to have them display a warning if the user enables more than one of them. 「ディノ奴千？！」^{☎ Dinoguy1000} 23:29, 7 December 2020 (UTC)

Small comment: nowadays, you can store user selection without resorting to a page in their userspace.

The "options" api allows you to save user defined (or gadget defined) options, asking only that the option name starts with "user-". Retrival of option value does not require an api call, and mw.user.options.get() works like for any other option. Peace. קיפודנחש (talk) 15:09, 11 December 2020 (UTC)

targets=mobile

When defining a gadget, I suppose if I type targets=mobile, that gadget will be loaded only on mobile devices, just like MobileFrontend works. But that doesn't happen, so, what does targets=mobile do? Am I missing something? --Tinker Bell ★ ♥ 07:26, 28 April 2021 (UTC)

MobileFrontend doesn't load any gadgets, ever. Jdforrester (WMF) (talk) 15:11, 28 April 2021 (UTC)

Jdforrester, I just mentioned MobileFrontend as an analogy, MF serves a different interface based on the device type (desktop or mobile). I thought targets=mobile do the same with gadgets. --Tinker Bell ★ ♥ 19:51, 26 July 2021 (UTC)

@Jdforrester (WMF) Could you please elaborate on this? What is the purpose of targets=mobile then? Od1n (talk) 19:43, 26 July 2021 (UTC)

It's a hack to reduce the number of ResourceLoader manifests shipped to mobile readers, on the basis that it's a significant source of bloat. We're planning long-term to remove the targets system entirely. (Note that MF does now let you load mobile gadgets.) Jdforrester (WMF) (talk) 20:17, 26 July 2021 (UTC)

So, it works as expected actually? I couldn't confirm by looking at the code and commits, but I tried with some defined gadgets, and indeed they are loadable on mobile iif they have the targets=mobile. Od1n (talk) 21:33, 26 July 2021 (UTC)

Gadget:ImageAnnotation

Hello,

I need help. I have created a MediaWiki the extension Gadgets is installed and the steps for ImageAnnotator actually also all done, but unfortunately it does not work at all. I need a simple function from ImageAnnotator it only needs to annotate a single image. If someone would take a look at this or help me, I would be very grateful. Dermiddle (talk) 10:42, 24 November 2021 (UTC)

Does this extension have ES6 support?

In my memories ES6 was not supported due to the limit of ResourceLoader (it was quite a few versions ago), but now ResourceLoader does support ES6. I was told that you can use mw.loader.load but this way there would be a lot of scripts loaded separately, making the packaging meaningless. Seems like there is a "package" option available (unfortunately only in 1.38 and later) and I'm kinda interested. Lakejason0 (talk) 07:33, 9 January 2022 (UTC)

I believe ES6 support is still blocked by phab:T75714. Besides, per phab:T75714#7365697:

You can use mw.loader.load to load non-gadget non-es5 user scripts (from a URL). You just can't use >es5 in ResourceLoader JS (including user and MediaWiki common.js and skin.js files and gadgets).

Peter Bowman (talk) 10:00, 9 January 2022 (UTC)

As I said, this way there would be a lot of scripts loaded separately. Anyway, thanks for your explanation! Lakejason0 (talk) 16:36, 9 January 2022 (UTC)

Lakejason0 (talk) 16:35, 9 January 2022 (UTC)

The way to get a gadget's dependencies from api or load.php

I wanted to load a gadget from zh: on Meta Wiki.

However, when I using mw.loader.load( "https://zh.wikipedia.org/w/load.php?modules=ext.gadget.shortURL" ); to load, it throw a error:

ReferenceError: wgULS is not defined
    at load.php?modules=ext.gadget.shortURL:1:123
    at load.php?modules=ext.gadget.shortURL:1:741
    at runScript (load.php?debug=2&modules=startup&only=scripts&raw=1:1348:7)
    at execute (load.php?debug=2&modules=startup&only=scripts&raw=1:1474:4)
    at doPropagation (load.php?debug=2&modules=startup&only=scripts&raw=1:864:6)

wgULS is defined at ext.gadget.site-lib ( zh:MediaWiki:Gadget-site-lib.js ).

So, could I get a gadget's dependencies from api or load.php to automaticly load it before I try to load any gadget, like ext.gadget.shortURL on zhwiki? SunAfterRain 10:44, 22 April 2022 (UTC)

It is relying on a function wgULS() which is not specified within this script.

On Meta: they might have defined it on meta:MediaWiki:common.js but they did not now.

ULS does mean Universal Language Selector.

meta:Special:Preferences#mw-prefsection-gadgets does not mention a shortURL gadget. It seems to be unmaintained, if ever alive on meta:.

I do not see where you got the source from. PerfektesChaos (talk) 14:55, 22 April 2022 (UTC)

The source is zhwiki, aka Chinese Wikipedia (site-lib: zh:MediaWiki:Gadget-site-lib.js zh:Special:Gadgets/export/site-lib, shortURL: zh:MediaWiki:Gadget-shortURL.js zh:Special:Gadgets/export/shortURL), not in meta.

so if I tried to load "shortURL gadget" in "zhwiki", it throw error because wgULS isn't defined in meta wiki's common.js or some gadget defined in meta. SunAfterRain 15:30, 22 April 2022 (UTC)

Gadget 2.0 design is horrible

I just tried to use the Gadget 2.0 design and it is horrible. Description is stored in the Mediawiki namespace. The definition file is stored in the Gadget_definition namespace. The CSS and JS code is stored in the Gadget namespace. Did anybody ever try to actually use this system before implementing it? Why not just leave everything the way it is, but just store all the files in the Gadget namespace, so you have "Gadget:Mygadget Gadget:mygadget.css Gadget:mygadget.js if you need a second file Gadget-mygadget-morejs.js . Inside the Gadget:mygadget, just have a line that says "title" and "description". Then when a person is trying to either copy from an existing Mediawiki or creating their own, they can easily see if a file is missing or existing. Or just copy the templates system of just having mygadget/def or mygadget/json Proactive programming (talk) 06:28, 1 May 2022 (UTC)

Is there any way to hide a section for users who aren't in a particular user group?

@import won't work well?

I found that ja:MediaWiki:Gadget-dark-mode.css, which is @import en:MediaWiki:Gadget-dark-mode.css, does not work well. The reason seems that must come before all other types of rules but it's loaded on the bottom of load.php.

.mw-parser-output a[href$=".pdf"].external,
.mw-parser-output a[href*=".pdf?"].external,
.mw-parser-output a[href*=".pdf#"].external,
.mw-parser-output a[href$=".PDF"].external,
.mw-parser-output a[href*=".PDF?"].external,
.mw-parser-output a[href*=".PDF#"].external {
 background:url(//upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif) no-repeat right;
 padding-right:18px
}
span.PDFlink a {
 background:url(//upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif) center right no-repeat !important;
 padding-right:17px !important
}
.allpagesredirect a:link,
.allpagesredirect a:visited,
.redirect-in-category a:link,
.redirect-in-category a:visited,
.watchlistredir a:link,
.watchlistredir a:visited {
 color:#595959
}
.client-js > body.skin-vector #p-personal li {
 font-size:0.75em
}
.client-js > body.skin-monobook #p-personal li {
 font-size:1em
}
.client-js > body.skin-vector #p-personal ul {
 margin-right:5.0625em
}
.client-js > body.skin-monobook #p-personal ul {
 margin-right:7.6em
}
@import url(https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-dark-mode.css&action=raw&ctype=text/css);

How can I fix this? Do you have any tips to use @important on the Gadgets? aokomoriuta (talk) 23:02, 6 August 2022 (UTC)

Hi. Indeed, the CSS format does not permit use of @import anywhere other than at the start of a stylesheet. However, the guruantees we provide for batching and ordering stylesheet modules requires exactly that (in most cases) we place it somewhere later in the response.

In ResourceLoader we have a legacy exception for the "user" (personal user css) and "site" (site-wide Common.css) modules which historically are unable to register their subfiles as native. The exception is that when we encounter a later chunk, we split it out into a new request and/or flush the chunk as its own <style> element.

For all other modules (MW core, extensions, and gadgets) it is expected that code is loaded natively for optimium performance as we do not want the visual rendering of articles to be delayed by late-discovered additional requests, especially requests to other domains.

The type option for gadgets (docs) can switch between pure "styles" and "general". The main benefit of "styles" is that it loads immediately and before the page is visually rendered. However, this immediate-ness is contradicted when importing files from other wiki. The browser does not know about these files until after all the styles have arrived. Delaying rendering at this point is slow.

Your options are:

1. Make it a locally cached and optimised gadget, by copying the page content as well. This creates fast page views and no delays of dark mode.
2. Alternatively, you can set type=general. I tried this in jawiki rev 90881097 and confirmed that this "works" in so far that it makes the page render exactly as fast as if dark mode was not there, but then dark mode arrives at the same time as it would if we were to delay rendering for cross-domain styles import. Despite being faster, this way feels slower because we first see the fast page rendering and only then the dark mode.

There are ways to support @import with workarounds in our software that create complicated ways of loading stylesheets, that are difficult to debug and understand. I have choses in the past not to support this, and instead invest the cost in making everything else faster and simpler. The first option would be my recommendation in today's possibilities.

There is a third option, which is to develop the code as an extension and seek deployment (or in the future, "global gadgets", phab:T22153). Krinkle (talk) 09:36, 8 August 2022 (UTC)

Thank you for your advice. I understand current situation. I followed your suggestion#1 (copying) for dark-mode.css. aokomoriuta (talk) 00:32, 1 February 2023 (UTC)

Description text in Mediawiki:Gadget-section-X

Is it legal to add extra wikitext like categorization and description text after the title in Mediawiki:Gadget-section-X? Something like this

Title

<p style="font-weight: normal; font-size: initial;">
Section description
</p>

[[Category:Section headings]]

seems to work, but can it cause problems later? Hunsvotti (talk) 10:10, 9 October 2022 (UTC)

@Hunsvotti I would recommend against it. It is a common pattern within Wikipedia communities to use the talk page to categorize interface pages like these. That way the interface script, or interface text remains clean and pure from these organisational types of metadata.

As it stands today, it appears this indeed has no negative side-effects, but it seems like the kind of thing we might change to accomodate something we need in the future. Best to avoid it, I think! Krinkle (talk) 03:25, 10 October 2022 (UTC)

Thanks! Categorizing the talk page didn't even occur to me. Hunsvotti (talk) 18:40, 10 October 2022 (UTC)

Don't show tools in preferences

I installed this extension but it doesn't work, where could the problem be? Rick Sanchez (talk) 07:17, 29 November 2022 (UTC)

You're going to have to provide more detail: did you follow the usage instructions? What exact steps did you take? Are you seeing any error messages? 「ディノ奴千？！」^{☎ Dinoguy1000} 11:05, 29 November 2022 (UTC)

wfLoadExtension( 'Gadgets' ); in LocalSettings.php

I put the file in the extensions folder, but the tools are not displayed.

I don't get any error.

I also installed other plugins, I know how to install plugins.

My site https://wikidm.org/ Rick Sanchez (talk) 16:26, 29 November 2022 (UTC)

Okay, so this extension does not come with any gadgets actually preinstalled; you have to install them all yourself. Read through the usage instructions that I linked in my previous comment for a basic explanation of how to use the extension. 「ディノ奴千？！」^{☎ Dinoguy1000} 23:17, 29 November 2022 (UTC)

Thank you very much for the advice, I will read again. Rick Sanchez (talk) 12:32, 30 November 2022 (UTC)

Since I just found out about it myself, Gadget kitchen looks like a very good resource as well. 「ディノ奴千？！」^{☎ Dinoguy1000} 23:51, 30 November 2022 (UTC)

Thank you very much for your persistence and guidance Rick Sanchez (talk) 05:39, 1 December 2022 (UTC)

Bugged "requiresES6" option?

Hi, I recently converted a gadget on frwikt to ES6 syntax but despite specifying the 'requiresES6' option in the Gadgets-definition page, I get this error: "JavaScript parse error (scripts need to be valid ECMAScript 5): Parse error: Missing ; before statement in file 'MediaWiki:Gadget-CreerNouveauMot.js' on line 55". The thing is, it works on at least another one. What am I doing wrong? Thanks for your help. Danÿa (talk) 11:30, 29 November 2022 (UTC)

Here are some links:

• Gadgets definition: fr:wikt:MediaWiki:Gadgets-definition#Création
• Gadget that does not work: fr:wikt:MediaWiki:Gadget-CreerNouveauMot.js
• Gadget that does work: fr:wikt:MediaWiki:Gadget-Barre de luxe.js Danÿa (talk) 11:38, 29 November 2022 (UTC)

So, new development, it seems that I get this error only when the "default" option is active as well… Are there any compatibility issues between these two options that I am not aware of? I looked at the documentation but found nothing relating to this topic. Danÿa (talk) 12:05, 29 November 2022 (UTC)

Yes, you can't enable an ES6-only gadget by default as by default implies all users/skins/browsers, whereas by definition it would fail in ES5 browers where we do load other gadgets and stylesheets. This leads to compatibility issues, dependency problems, and code complexity that developers likely wouldn't test well given it doesn't affect their own browsers. Such blind spots create inverse incentives, where the "easy" and default behaviour is to create experiences that aren't accessible through no fault of your own.

The requiresES6 feature is a temporary option to allow experimental opt-in gadgets to start using this until we're ready to drop ES5 support for Grade A. See also Compatibility and T178356. Krinkle (talk) 13:18, 29 November 2022 (UTC)

Makes sense, thanks for your answer :) Unless I’ve missed it, I think it should be specified explicitely in the extension’s documentation so anyone can know before finding out too late. Danÿa (talk) 13:26, 29 November 2022 (UTC)

Special:Gadgets has no internal anchors

https://commons.wikimedia.org/wiki/Special:Gadgets

• doesn't have a way to link to sections (Special:Gadgets#blabla),
• doesn't have a table of contents.
• doesn't have a Talk: page. Jidanni (talk) 08:49, 15 February 2023 (UTC)

Last one first: No special page has a talk page in namespace (while it might be connected with flow discussion thread?).

First and second: Well, actually a good idea. Fragment identifiers might be derived from headline text at least, and perhaps the TOC algorithm may be applied to this particular special page, fed by the headline collection. PerfektesChaos (talk) 13:01, 15 February 2023 (UTC)

The definitions page (linked from the lead) is a regular page and does have a talk page.

The anchors should be generated from the raw section IDs (as seen on MediaWiki:Gadgets-definition, e.g. #Navigation instead of #Improved navigation), so that they remain the same across UI languages. Tacsipacsi (talk) 20:15, 16 February 2023 (UTC)

If users are looking at headline Improved navigation in particular language version, they will copy text of headline and use it for linking.

• No regular reader has access to the internal system message ID.

Therefore both id= need to be hidden in generated HTML:

• Visible headline text in particular language, available within that uselang= only.
• System message ID for programmers; rather sophisticated.

On regular pages there is currently

• <h2> without any id= now
• <span> with headline text in page language and id= generated from that localized text; also when generating TOC
• <span> with toolbox in user language

The first one might address the language independent fragment, the second one such visible text, and third one is not really expected on a special page.

• If both fragments are identical, one is to be omitted to ensure HTML document validity.

Someone should start a feature request at Phabricator. PerfektesChaos (talk) 13:22, 20 February 2023 (UTC)

Gadget source goes where?

It's unclear where the source files implementing gadgets go. The page only discusses defining which are available to users, but doesn't specify where the extension looks for the provided filenames for gadgets.

It should link to this: Gadget kitchen#Deploying or enabling a gadget Mcint (talk) 02:56, 2 June 2023 (UTC)

@Mcint

The definition syntax is * mygadget [options] | page names. The easiest and recommended way to create or edit the source code pages is through Special:Gadgets, where we automatically render each gadget's metadata in way that you can interact with, to create or edit the source codee page. You can learn more about the syntax and the special page, near the top of the page at Extension:Gadgets#Usage.

Alternatively, if you prefer navigate to a source page yourself, you could prepend "MediaWiki:Gadget-" in front of the specified page name. For examples of this logic, refer to the docs at Extension:Gadgets#Pages. Krinkle (talk) 13:00, 2 June 2023 (UTC)

What is the order CSS gadgets are loaded

I have several gadgets which contain only CSS and type is styles. However, no matter how I sort them in gadgets-definitions, the order they are loaded seems unchanged. Are they loaded in the alphabetical order, or the order they are defined in gadgets-definitions? SolidBlock (talk) 06:50, 5 September 2023 (UTC)

I'm not extremely familiar with gadgets, but likely alphabetical order if they're handled in a similar way as other ResourceLoader modules. Alex44019 (talk) 04:58, 22 September 2023 (UTC)

Docs is not clear

Minification for ES6

Categories and gadget definitions

Hi. Shouldn't gadget definitions be removed? Shouldn't categories be added? IKhitron (talk) 09:45, 4 March 2024 (UTC)

Comment syntax

Anybody happen to know (*cough*@Krinkle*cough*) whether / what comment syntax MediaWiki:Gadgets-definition supports? For things like site-wide styles or gadgets (default|hidden), things meant to be loaded by other gadgets, etc. it'd be very useful to drop a comment in the definition to help other admins out when trying to figure out what something does or why it is the way it is. Not that I've spent waaay too much time cleaning up inherited code here or anything… :) Xover (talk) 08:37, 11 May 2024 (UTC)

Hello. <!--HTML comments--> worked for me. Peter Bowman (talk) 16:39, 11 May 2024 (UTC)

HTML comments are removed before any processing. However, spaces around them aren’t, which has caused issues in the past (phab:T354385), so you should look out for spacing-related issues if you use comments. Tacsipacsi (talk) 10:05, 12 May 2024 (UTC)

Activation state when adding/removing "default" on hidden gadget

Suppose we have an hidden gadget that is – and always has been – hidden:

Foobar [ResourceLoader|hidden] | Foobar.js

If later we add the "default" keyword to it, will it become enabled for all users? Conversely, if later we remove the "default" keyword, will it become disabled for all users?

To put it otherwise, will the gadget be enabled/disabled for all users according to the presence or absence of the "default" keyword? Or is there any possibility that the activation state remains at what it was at a previous time (for instance, at the time the definition was created)?

I guess the activation state will match the presence or absence of the "default" keyword. But I would need to be 100% sure about this, as I considered tweaking a module that brings core functionality on frwiki, and it would rely on this behavior.

(for the sake of completeness, I know users can enable/disable gadgets – probably even the hidden ones – using the API instead of the Preferences page, but let's assume no one did this) (edit: apparently, according to phab:T299071, making such API request on an hidden gadget doesn't change its activation state) Od1n (talk) 00:28, 26 June 2024 (UTC)

Every time a page is requested from the server, it is checked for this particular account for this particular action which gadgets will be sent for loading.

That means that a change in gadget definitions has full effect rather immediately. PerfektesChaos (talk) 11:21, 26 June 2024 (UTC)

I had a quick look at the code, and phab:T299071 might be of great interest.

1. Hidden gadget are not added to the mw.user.options data: Hooks.php#149.
2. Later, the value is looked for, and because it doesn't exist, "onByDefault" is used as a fallback value: Gadget.php#249.

Therefore, we are sure hidden gadgets will be enabled/disabled depending on whether the "default" keyword is currently in the gadget definition.

Though, T299071 was only purposed as an optimization to reduce data size. I don't know if the loading behavior of hidden gadgets would have been the same without T299071. (edit: according to OP in T299071, hidden gadgets were already following this loading behavior before T299071) Od1n (talk) 17:01, 26 June 2024 (UTC)

In the mw.user.options a copy of Special:Preferences of registered accounts is transferred to the page JavaScript environment. Actually these are the items where by default or at least by user tic an activated value says that this gadget is to be run.

If you declare a non-hidden gadget to be hidden later, I guess a shadow of the old (last in effect) state might survive in the mw.user.options object of registered accounts.

On page loading, the mw.user.options (which are empty for anonymous users) will set to some kind of true value for all default gadgets, if not opt-out by registered accounts.

There can be arbitrary entries in mw.user.options created to some extent, which were never part of Special:Preferences.

Independent of JavaScript and mw.user.options packages of modules will be provided and sent based upon the current account for this particular action rendered in this particular skin for this particular namespace perhaps matching a certain category. PerfektesChaos (talk) 14:19, 29 June 2024 (UTC)

requiresES6 option not removed?

Hi,

I’ve just noticed that the requiresES6 option is marked as removed since version 1.42. However, it seems that it is not the case. I tried removing it from a gadget’s definition on frwikt (which is on version 1.44 according to its fr:Special:Version page) and it broke the gadget. Moreover, the fr:Special:Gadgets page shows a specific text when the option is specified, hinting that the option might still in fact be supported.

Is this an error on the extension’s page or am I missing something? Danÿa (talk) 00:35, 14 November 2024 (UTC)