Page MenuHomePhabricator

Allow specifying when a gadget should load (conditional category, 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:

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
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.

@Krinkle How would I work on this if there's no active owner? I would love to work on this as it could solve the same issues that the UseResource extension can, but if there's no one to review my commits what's the point?

@BrandonXLF Yeah, I would not recommend writing a lot of code now (as much as I'd like to see that). But your word here that you'd be interested in helping with this, which you have now given, I think is enough for me to try to start some conversations. I can't promise anything, but I hope to tell you something within a few weeks!

Sounds good, hoping for the best!

Krinkle renamed this task from Allow specifying when a gadget should load (conditional, page title, action or namespace) to Allow specifying when a gadget should load (conditional category, action, or namespace).Apr 18 2021, 8:43 PM
Krinkle updated the task description. (Show Details)

Change 747112 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/extensions/Gadgets@master] Allow specifying action pages in definitions

Change 747112 merged by jenkins-bot:

[mediawiki/extensions/Gadgets@master] Allow specifying page actions in definitions

@Johan, what do you say, do we need to publish this?

@IKhitron: In case you're thinking about Tech News (not sure), please see - thanks!

Don't understand what are you trying to say.

Is there a list of all accepted action values somewhere? E.g. is there a way to load a gadget only when viewing diffs?

Is there a list of all accepted action values somewhere? E.g. is there a way to load a gadget only when viewing diffs?

Diffs generally qualify as action=view with, depending on URL parameters and preferences, a diff and below it either the current content or a previous revision content or no content ("diffonly").

Keep in mind that these conditions exist solely for the purpose of optimising payload performance. The actual activation or intialisation of functionaly must be based on checks or hooks inside the gadget code (e.g. mw.hook('wikipage.diff') and other hooks). As such, we do not need a perfect match for every scenario.

Also keep in mind that once loaded at least once, the code remains cached in the browser until the gadget is edited. So the main thing we're optimising isn't per-se what loads on a page, but what is loaded for a person in a given browsing session on a given day. E.g. if someone is likely never to need the code that day, don't load it.

With this in mind, the main category we are optimising for is simple article namespace page views vs everything else. For diffs we could go in a number of directions:

  1. We could load gadgets for action=history on diffs (in addition to action=view gadgets). This has the benefit of avoiding overlap between action values, but the downside of exposing the true (but otherwise mostlyh hidden) detail that the conditions are only for optimising, not for hard enforcement. That is, you cannot assume that a gadget will only ever load in the specified action. It can also be loaded via mw.loader.using() or dependencies= anywhere else. And if we go with loading action=history on diffs, then it will be true in that case as well.
  1. We could introduce a fake action value of action=diff. This would mean on diffs we load action=view and action=diff. This has the downside of making the action parameter no longer something you can know and understand based on general MediaWiki knowledge and instead now requires discovering and learning the special meaning in the Gadgets extension. Also may cause conflicts in the future, and will forever cause a small level of confusion. But it has the benefit of allowing to load something only for diffs and not on history page. I don't know if that is significant however, as it can be a rather effective means of preloading. People generally spend a few seconds on the history page deciding what to do. Loading it in the background there into the cache before clicking on a diff seems useful.

Change 922062 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/extensions/Gadgets@master] Add support for content models in definitions