ResourceLoader/Vocabulary

Web requests to load.php can specify values for these; ResourceLoader does so when it inserts load.php URLs in the HTML and JavaScript that it generates. PHP server code can retrieve their values through getDebug/Skin/Language() methods of ResourceLoaderContext. In the browser these usually map to debug, skin, and wgUserLanguage configuration values in 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: 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.