Extension talk:Gadgets

Jump to navigation Jump to search

About this board

Previous discussion was archived at Extension talk:Gadgets/Archive on 2012-01-06.

Tinker Bell (talkcontribs)

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?

Jdforrester (WMF) (talkcontribs)

MobileFrontend doesn't load any gadgets, ever.

Tinker Bell (talkcontribs)

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.

Od1n (talkcontribs)

@Jdforrester (WMF) Could you please elaborate on this? What is the purpose of targets=mobile then?

Jdforrester (WMF) (talkcontribs)

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

Od1n (talkcontribs)

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.

Reply to "targets=mobile"

Associate Theme Gadgets - Select ONE

Z929669 (talkcontribs)

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.

Dinoguy1000 (talkcontribs)

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.

Z929669 (talkcontribs)

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.

Jdforrester (WMF) (talkcontribs)

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.

Dinoguy1000 (talkcontribs)

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.

Z929669 (talkcontribs)

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.

Dinoguy1000 (talkcontribs)

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.

קיפודנחש (talkcontribs)

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.

Reply to "Associate Theme Gadgets - Select ONE"

Tracking adoption

Summary by André Costa (WMSE)

Track usage of non-default enabled gadget in Special:GadgetUsage.

André Costa (WMSE) (talkcontribs)

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

Peter Bowman (talkcontribs)
André Costa (WMSE) (talkcontribs)

Doh! How did I miss that one. Many thanks.

קיפודנחש (talkcontribs)

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.


Reply to "Tracking adoption"

Best practice for gadget configuration

Inductiveload (talkcontribs)


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!

Peter Bowman (talkcontribs)

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.

Inductiveload (talkcontribs)

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.

Reply to "Best practice for gadget configuration"

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

Farvardyn (talkcontribs)


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?


<div id="15068716388"><script type="text/JavaScript" src="https://www.aparat.com/embed/aWf7R?data[rnddiv]=15068716388&data[responsive]=yes"></script></div>
Jeblad (talkcontribs)

You can't without whitelisting the script tag, and that will not happen on Wikimedia sites.

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

Loading Remote Definition File For All Users

Jabowery (talkcontribs)

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]]
PerfektesChaos (talkcontribs)

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.

Reply to "Loading Remote Definition File For All Users"

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

Od1n (talkcontribs)

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
PerfektesChaos (talkcontribs)

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.

Perhelion (talkcontribs)
Reply to "Conditional loading in definitions, depending on action, namespace, etc."

About gadgets using multiple css/js files with different conditions

SolidBlock (talkcontribs)

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?

קיפודנחש (talkcontribs)

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.


PerfektesChaos (talkcontribs)

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.

Dinoguy1000 (talkcontribs)

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.

SolidBlock (talkcontribs)

Using class selector ".skin-vector" is OK, but not convenient. But body class doesn't include usergroups. Maybe I can use JavaScript.

PerfektesChaos (talkcontribs)

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.

Reply to "About gadgets using multiple css/js files with different conditions"
Minilexikon (talkcontribs)

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!

Reply to ""shared" in metadata"

What are "system messages"?

Johnywhy (talkcontribs)
Ciencia Al Poder (talkcontribs)
Reply to "What are "system messages"?"