ResourceLoader/Vocabulary

Context

Web requests to load.php may set values for context keys. ResourceLoader does this when it creates load.php URLs in HTML (via RL\ClientHtml and OutputPage), and in JavaScript (via mw.loader).

In PHP code, the context values can be retrieved through getter methods of ResourceLoaderContext, such as getLanguage. In the browser these can be retrieved as the debug, skin, and wgUserLanguage configuration keys from mw.config.

• debug: Also known as Development mode. See Debug mode for more information.
• skin: The ID of the skin that the requesting page uses.
• lang: The language code of the interface that the requesting page is displayed in.

Module

• module: A bundle of one or more resources, identified by a module name.
• resource: Any part of a module's content (script file, stylesheet, interface message).
• message blob: One or more interface messages in a given language, encoded using JSON.
• dependencies: One or more other modules that must load before the current module.
• group: A mechanism for altering the way requests are batched. This has downsides, but can in certain cases improve performance. Learn more at ResourceLoader/Architecture#Balance.
• target: (Deprecated) A mechanism for instructing the server to omit some of the defined modules from the client-side registry. See also: Target system.
• registry (server-side): Modules defined by MediaWiki core and extensions, that can be queued via OutputPage.php. See also: RL/DEV#Loading modules.
• registry (client-side): Modules available to the current browser context. This is a subset of modules defined server-side. Several mechanisms and optimisations reduce which module's metadata end up transmitted to the client-side, such as the skipFunction, and the active skin (T236603).
• skip function: If a module's skip function returns true in the current browser, the module is considered "loaded" and satisfies any dependency requirement without actually downloading or executing any JavaScript code. This encourage adoption of web standards in newer browsers. This avoids investing extra development on a way to build this on the lowest-common denominator, or other costly workarounds. It also removes the need to compromise or seggregate our audience by which product features they can use. This aligns with MediaWiki Engineering/Frontend practices#Principles. See Developing with ResourceLoader and MainConfigSchema::ResourceModules in the MediaWiki PHP docs for how to use this.
• origin: The authority that created the resources in a given module. This represents the module's trust level, and determins whether it may be loaded in contexts with heightened security requirements. For example, personal scripts and site scripts (user-generated JavaScript customizations edited through the wiki) are not allowed on Special:UserLogin and Special:Preferences. We recognize these four origin values:
  • Core-Sitewide: Source code developed as part of trusted software (MediaWiki core, skin or extension).
  • Core-Individual: Auto-generated by trusted software for an individual webrequest (e.g. key-value JSON holding account metadata or their notification count).
  • User-Sitewide: Raw source code provided by end-users of the wiki who have site-wide permissions (e.g. Common.js or a gadget, editable by elected interface admins).
  • User-Individual: Raw source code provided directly by any other individual user.