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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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?
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.
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.
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.
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.
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?