Page MenuHomePhabricator

Allow files from other wikis in gadget definitions
Open, Needs TriagePublicFeature

Description

Currently, all JS/CSS/JSON files in a gadget definition must be from the local wiki. It should be possible to specify files from another wiki on the WMF cluster.

And/or equivalently, it should be possible to define a gadget which is entirely loaded from another wiki – essentially a "pointer" gadget. This could be marked as hidden and used as a dependency for a user-facing gadget.

Usecases

  1. i18n/l10n: Generally, gadgets would want to load the core part from another wiki, and specify a local file with i18n strings and per-wiki configurations.
  2. Use of foreign libraries: A gadget on frwiki or dewiki should be able to use enwiki's Morebits.js library without having to maintain a local copy.

Example:

*HotCat [ ResourceLoader ] | HotCat.js@commonswiki | HotCat.css@commonswiki | HotCat-enwiki-config.json (MediaWikiGadgetsDefiniton is too limiting w.r.t. syntax, but the GadgetDefinitionNamespace syntax can be made more systematic)

Or equivalently,

Core hidden gadget which is a pointer to a gadget on foreign wiki.
*HotCat-core [ ResourceLoader | source = HotCat@commonswiki | hidden ]
The user-facing gadget, which just add a site config file to the core hidden gadget
*HotCat [ ResourceLoader | dependencies = ext.gadget.HotCat-core ] | HotCat-enwiki-config.json

Event Timeline

The usecases are same as that of global gadgets (T22153), but this is more moderate proposal, and could be more easily realisable. Apart from the technical complexity, truly global gadgets raise difficult questions – such as which community would maintain or edit the gadgets. In the absence of a sane code review workflow (T71445) and the very high access level (int-admin) required for editing, it will be difficult for users to maintain a gadget on a central foreign wiki.

If I understand correctly, this is proposing a very specific solution to a problem that is more general than that. The problem (or use case) is for gadgets to be maintained on a central wiki and used from there on another wiki.

The direction I set out for this is to faccilitate registration and loading of a module directly from another wiki. This is currently used in production by the GlobalCssJs extension in Wikimedia production. This is based on the ResourceLoader "source" capability, which allows a module implementation to come from a different domain. I choose this design as it seemed easier to use and maintain, compared to more flexible but complex solutions that involve individual entities to be loaded from different wikis. Including for example complexity of cross-wiki interactions within a single web request, caching, permissions, and duplication of registrations.

I think opening up this ability would be a mistake and make the system significantly less stable and more difficult to reason about in the long-term. I appreciate that the edge case of including a local file into another module at the same time, but do not think it is worth the complexity to handle in this way. There are other ways of addressing that particular edge case, which if there are issues with could be discussed in a seprate task that focusses on that. In general I would recommend making tasks for issues other than bugs focussed on the problem rather than a specfiic solution, as this makes it easier to keep the conversation going, to find/merge it duplicate tasks, and include past conversations and research from other people. Of course you can propose a solution at the same time in the task description as well, if you have something in mind already.

Yes I realised allowing files from multiple wikis in the same gadget could be complex. This is where the alternative/equivalent suggestion ("it should be possible to define a gadget which is entirely loaded from another wiki – essentially a "pointer" gadget") comes in – precisely based on what GlobalCssJs does. In terms of meeting the usecases, this is equivalent to the original suggestion as we can always create another gadget that uses it as dependency and adds the extra local files.

Basically, I would expect another syntax for gadget identifiers similar to page names:

  • commonswiki:HotCat

A mw.loader.load("commonswiki:HotCat") will request the identical module bundle as has been specified within host wiki.

  • It is not really the business of other wikis to configure how to access particular resource pages at .js .json .css or whatever level.
  • The other wiki will be responsible to maintain the package specification.
  • It is obvious for RL how to resolve the request into a resource module from that wiki. All requests from that wiki might be collected and merged into one cacheable multi-module URL for that wiki. This is the same as for resources from current site. It might be even shared in browser, since the URL is identical for a request from own site and when visiting another wiki and asking for the same bundle.
  • Somebody might offer a (hidden) library gadget which could consist of just one .js resource page only if that is a universally useful script. It will be installed and executed as everything else.

Please see T36958 on user-level gadgets. I am thinking in three levels, and I could imagine that all three will be available one day:

  • global
  • site
  • user myself

I would expect in Special:Preferences that all three chapters are offered in future. However, I am not sure which century.

This leads to a unique syntax as

  • mw.loader.load("commonswiki:HotCat") as specified and maintained there,
  • mw.loader.load("user:SD0001:BestStuff") from local site,
  • mw.loader.load("global:SuperLib") from some central wiki,
  • mw.loader.load("OurHelpers") from local site which is available today,
  • mw.loader.load("metawiki:user:SD0001:BestStuff") even that for globally active users.