Page MenuHomePhabricator

Allow specifying when a gadget should load (conditional, page title, action or namespace)
Open, MediumPublic


Gadgets, when enabled by a user, load on all pages in all namespaces. This doesn't cause any immediate functional problems, but is inefficient. In some cases, very unacceptably inefficient, to the point that a gadget may be removed from a wiki or disabled due to performance problems. This is usually worked around in one of two ways:

  1. The gadget is split into two parts. A part that contains the actual gadget itself (hidden, disabled by default). And a (tiny) second part that is loaded always and checks whether the current page is the "right" one, and then loads the other.
    • Downside: Two definitions instead of one.
    • Downside: The page will first load without the gadget, and then later the gadget gets loaded (typically between 1-10s seconds later, depending on the connection and bandwidth).
  2. The gadget is made hidden and is instead loaded by url parameter (e.g. /wiki/Example?
    • Downside: Cannot be enabled on a per-user base (url parameter applies to all users). It also means the gadget only loads when the user follows a specific link, e.g. not when visiting the page through other means.
    • Downside: The page will first load without the gadget, and then later the gadget

We should instead add an option directly in the Gadgets extension to specify when a gadget should load (by default still everywhere).
Eg. based on the namespace, or page title, or page action, or canonical special page name.

Original request:

Author: gryllida

We should add an option to specify what pages a gadget is active on. Many probably just do this manually, but it looks reasonable as some gadgets would only be useful for contributors' talk pages for example. This could be a namespace name, or sometimes even a glob mask (Wikipedia talk:Articles for Creation/*).

See Also:
T17075: Per book, category and/or template CSS and JavaScript

See Also:

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:05 AM
bzimport set Reference to bz61007.
bzimport added a subscriber: Unknown Object (MLST).

Wouldn't it make more sense to have pages list the gadgets they want to run on them, rather than gadgets listing the pages they want to run on? For example, currently loads and runs on every page, but only does stuff if the page contains an element with class "switcher-container". If pages chose their gadgets, then pages that needed that could put something like {{LOADGADGET:switcher}} somewhere on them. It's not possible for that gadget to choose its pages, since any page could have a switcher-container element added to it, and it wouldn't be practical to update the gadget each time.

There's value to both.

When thinking about a single page, I agree being able to specify it on the page is a lot more useful, practical and maintainable (such gadget definition should not be concerned with which pages want that module).

However there is also a use for loading modules declaratively based on wider semantics. Not a plain page name, but for example based on namespace, title pattern, or details about the current user or page. As well as potentially for pages that don't exist (though MediaWiki:Noarticletext could be ab/used for that).

Krinkle renamed this task from Allow specifying what pages a gadget should run on in the definition to Allow specifying when a gadget should load (conditional, page title, action or namespace).Jun 5 2017, 5:16 PM
Krinkle updated the task description. (Show Details)
Krinkle removed a subscriber: wikibugs-l-list.

Please find the solution. I think we really need an option to avoid gadgets load on mobiles, as we have in personal scripts.

At WMSE, we could have used this recently. For WikiGap, we wanted to add a signup button to There was a gadget for this, but it had been disabled since it was loaded on all pages, but only actually used on a few. With @Nirmos's help, we managed to get it up and running for the event, but as this could be useful in the future, it would be good to be able to enabled the gadget only for certain pages.

So, this task is kind of two-pronged in that there's partly an extension of MediaWiki:Gadgets-definition (see T145997 for an example) that's being discussed, and partly per-page loading with for example
<load module="ext.gadget.MyAmazingGadget"/> that would be added to a page's wikitext. While an extension to MediaWiki:Gadgets-definition would be a lot more powerful and be of use for more gadgets, I assume that this would also be more difficult.

Now, I'm not a MediaWiki developer, so I may be completely wrong here, but it seems to me that the per-page loading would be really easy to do, as all the pieces needed are already available, for example a function to add modules to a page (OutputPage::addModules?). @Krinkle, are there any actual difficulties with allowing per-page loading, or is it just that someone needs to write the code for this?

@Imarlier, is there any chance that the Performance team could schedule this for an upcoming quarter?

@Nirmos There are no specific difficulties that I am aware of at this time. However, there is still the aspects of maintenance overhead, system complexity, and user/developer friendliness. These aspects may inform other solutions to be found instead.

For now, un-tagging Performance-Team since we don't maintain Gadget extension. The Gadgets extension uses a system called ResourceLoader internally which we do maintain, but from what I can tell, the feature talked about in this task would not involve changes to ResourceLoader.

Change 624517 had a related patch set uploaded (by BrandonXLF; owner: BrandonXLF):
[mediawiki/extensions/Gadgets@master] Add support for namespaces in definintions

@BrandonXLF Based on your interest in the UseResource extension, perhaps you'd like to work on or help with this task instead?

Note that the Gadgets extension is currently lacking an active owner, someone to make sure it works week-afte-week, that new bugs are fixed, and that all the features we've put into it in the past will keep working even when the world around us is changing (browsers, operating systems, other MW features, etc.) Taking on additional features might be difficult until an active owner is found. But when there is someone active and willing to work on it, like yourself, that might make it easier for us all to get the ball rolling again.