Extension talk:Gadgets

About this board

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

青子守歌 (talkcontribs)

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?

Krinkle (talkcontribs)

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

Reply to "@import won't work well?"

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

2
Dragoniez (talkcontribs)

Hi, I'm wondering if it's possible to hide a section of Gadgets-definition on Special:Preferences for users without a certain user right or those who aren't in a particular user group. I'm thinking about adding a section named 'management-gadgets' or something similar on my local wiki and put gadgets for sysops into it, but this will probably result in showing an empty section for non-sysops, am I right here? Any help would be appreciated.

Krinkle (talkcontribs)

You can restrict individual gadgets only. However, the user interface automatically takes care to hide empty sections.

This works both if the section is empty in the definition page, as well as if the section contains only gadgets that are hidden for the current user.

For example:

==foo==
*foo1[hidden|ResourceLoader]|foo1.js
*foo2[ResourceLoader]|foo2.js
==bar==
==baz==
*baz3[ResourceLoader|hidden]|baz3.js

This show only "foo" section in the preferences, and with one gadget (foo2).

Image captured at https://phabricator.wikimedia.org/F35327419

Gadget 2.0 design is horrible

1
Proactive programming (talkcontribs)

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

Reply to "Gadget 2.0 design is horrible"

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

3
SunAfterRain (talkcontribs)

I wanted to load a gadget from 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?

PerfektesChaos (talkcontribs)
SunAfterRain (talkcontribs)
Reply to "The way to get a gadget's dependencies from api or load.php"

Does this extension have ES6 support?

4
Lakejason0 (talkcontribs)

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.

Peter Bowman (talkcontribs)

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

Lakejason0 (talkcontribs)

As I said, this way there would be a lot of scripts loaded separately. Anyway, thanks for your explanation!

Lakejason0 (talkcontribs)
Reply to "Does this extension have ES6 support?"
Dermiddle (talkcontribs)

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.

Reply to "Gadget:ImageAnnotation"
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

8
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

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

peace

Reply to "Tracking adoption"

Best practice for gadget configuration

3
Inductiveload (talkcontribs)

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!

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"
Return to "Gadgets" page.