Page MenuHomePhabricator

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

Description

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?withModule=ext.gadget.foo).
    • 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
Description:
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:
T204201: Extend MediaWiki:Gadgets-definition capabilities

Details

Reference
bz61007

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).
bzimport created this task.Feb 7 2014, 2:39 AM

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, https://en.wikipedia.org/wiki/MediaWiki:Gadget-switcher.js 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).

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 5 2016, 12:06 PM
Krinkle updated the task description. (Show Details)May 24 2017, 3:17 PM
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 https://sv.wikipedia.org/wiki/Wikipedia:Skrivstuga/WikiGap. 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?

He7d3r updated the task description. (Show Details)Apr 7 2018, 8:29 PM

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

Perhelion updated the task description. (Show Details)Feb 16 2019, 9:43 AM