Manual:Extension registration

Extension registration is the mechanism that MediaWiki uses to load extensions and skins. You put configuration data in a file named extension.json or skin.json in the root directory of your extension or skin, and MediaWiki uses this to register extensions and skins.

If you were looking for documentation on installing extensions instead, see this guide.

"Attributes" let you register something, such as a module, with another extension. For instance, the VisualEditor (VE) extension offers the $wgVisualEditorPluginModules hook, which other extensions can use to register a module with VE. If the Math extension were to register a module with VE, it would have something like the following in its extension.json:

{
	"attributes": {
		"VisualEditor": {
			"PluginModules": [
				"ext.math.visualEditor"
			]
		}
	},
	"manifest_version": 2
}

{
	"VisualEditorPluginModules": [
		"ext.math.visualEditor"
	]
}

If VisualEditor wants to access this attribute, it would use:

ExtensionRegistry::getInstance()->getAttribute( 'VisualEditorPluginModules' );

Extension registration has a requires section, which acts similar to Composer's require section. It allows an extension developer to specify several requirements for the extension, such as a specific MediaWiki version (or greater/less than) or another extension/skin. For example, to add a dependency on a MediaWiki version that is greater than 1.26.0, you can add the following code to extension.json: ^[1]

{
	"requires": {
		"MediaWiki": ">= 1.26.0"
	}
}

The key of the requires object is the name of the dependency (prior to MediaWiki 1.29.0 only MediaWiki was supported), the value is a valid version constraint (the format has to match the one used by composer).

In MediaWiki 1.29.0 and above you can also add dependencies on skins and other extensions like so:

{
	"requires": {
		"MediaWiki": ">= 1.29.0",
		"extensions": {
			"ExampleExtension": "*"
		},
		"skins": {
			"ExampleSkin": "*"
		}
	}
}

In MediaWiki 1.33.0(?!??) and above you can also add dependencies on PHP like so:

{
	"requires": {
		"MediaWiki": ">= 1.33.0",
		"platform": {
			"php": ">= 7.0.3"
		}
	}
}

Many extensions may provide features that work only if another extension is loaded too, without really needing this feature for the core extension function to work. As an example: If extension B is loaded, extension A can provide a real WYSIWYG editor, otherwise it will use a simple textarea. Extension A can profit from extension B (if it is loaded), but doesn't require it to be loaded to work properly. For this, you generally check, if the extension is loaded, rather than adding it as a hard dependency.

To implement a standardized way of checking, if an extension is loaded or not (without the need of extra work in an extension that is a soft-dependency in another one), extension registration can be used. It implements an isLoaded method, which returns a simple boolean, if the extension is loaded or not (the extension needs to be loaded with extension registration for this to work). Example:

if ( ExtensionRegistry::getInstance()->isLoaded( 'ExtensionB' ) ) {
	// do things only, if extension B is loaded
}

Since MediaWiki 1.32 it's also possible to check if an extension is loaded and satisfies a given composer version constraint:

if ( ExtensionRegistry::getInstance()->isLoaded( 'ExtensionB', '>=1.2' ) ) {
	// do things only, if extension B is loaded and has a version of 1.2 or greater.
}

If you would like to check if a specific version of an extension is loaded in earlier versions of MediaWiki, information like that can be extracted with the getAllThings method, which returns credit information for all loaded extensions. Example:

$bVersion = ExtensionRegistry::getInstance()->getAllThings()['ExtensionB']['version'] ?? null;
if ( $bVersion !== null && version_compare( $bVersion, '2.1.0', '>=' ) ) {
	// do things only, if extension B is loaded and has a version number greater than or equal to 2.1.0
}

Alternatively, if the extension B defines a special constant meant for this purpose during loading, it is possible to check, if it is defined:

if ( defined( 'ExtensionBVersion' ) ) { // You could also check for a version, if the constant holds the version
	// do things only, if extension B is loaded
}

A more brittle way, that should be avoided is to check if a specific class of extension B exists or not, e.g. using this code:

if ( class_exists( 'ExtensionBHooks' ) ) {
	// do things only, if extension B its classes exist
}

This might break if the extension exists in the file system but is not loaded, e.g. if composer was used for autoloading. If the class was renamed or ceases to exist (e.g. because it is not package public) this will also break.

In general it is preferred to share code via composer components instead of extensions. If the classes of an extension only need to exist, but the extension does not need to be configured nor loaded, for what you want to do, that is a strong indicator that that code should be split off into a composer component you should depend on instead.

By default, extension.json assumes that your config settings start with a "wg" prefix.

If that's not the case, you can override the prefix by using a special key:

{
	"config": {
		"_prefix": "eg",
		"MyExtSetting": true
	}
}

That would use a prefix of "eg", and set the global variable $egMyExtSetting to true.

Starting with manifest version 2, the configuration section of extension registration provides a lot more features and allows you to describe your configuration options with much more detail. Instead of having a single key -> value store for your configuration options, you can also add the following information.

The general structure of the config changes slightly to the following, more object-oriented version:

{
	"config_prefix": "eg",
	"config": {
		"MyExtSetting": {
			"value": true,
			"path": false,
			"description": "The description for the configuration",
			"descriptionmsg": "myextension-config-myextsetting",
			"public": true
		}
	},
	"manifest_version": 2
}

The value of the configuration moved to this place. This is the only required key for a configuration object.

The boolean value of the path key identifies, if the value of the configuration option should be interpreted as a filesystem path, relative to the extension directory root. E.g., if the value of the configuration is myFile.png and the path is true, the actual value will be /path/to/the/wiki/extensions/MyExtension/myFile.png.

The description key for a configuration option can hold a non-localized string, which can be used to explain the configuration option to other developers or the users (system administrators) of your extension. It may also be used as tooltip text on the parameters section of the extension infobox on the MediaWiki.org extension description page. The value of the description key is usually not exposed to the frontend of the wiki, however, take a look to the outlook for more information how this feature could be used in the future!

There's also the possibility to add a message key of MediaWiki's internal localisation system as a description (descriptionmsg), which, in the future, will be used to expose the description in the frontend of the MediaWiki installation.

This option is a boolean, which defaults to false, which means, that the configuration option and the value is marked as "private". This value is not used anywhere at the moment, take a look to the outlook to find out more about this option.

The mentioned changes above are also preparation steps for an improved configuration management in MediaWiki. The above changes allow us to, e.g., expose the configuration options of extensions in the MediaWiki UI. For this, the localised description message (descriptionmsg and description) and the indication, if the configuration option should be exposed or not (public) is needed.

MediaWiki allows any extension to register phpunit tests. Without extension registration, you would need to register a hook handler for the UnitTestsList hook, which would look something like:

public static function onUnitTestsList( array &$paths ) {
	$paths[] = __DIR__ . '/tests/phpunit/';
}

(as described on the manual page). However, this code looks the same for a lot of extensions, so you could call it unnecessary code duplication. If your extension uses extension registration and your phpunit tests are located in the tests/phpunit/ subdirectory of your extension, the phpunit wrapper of MediaWiki will autodiscover the unit tests with the help of extension registration. Therefore, you don't need to register the hook anymore and you don't need to specify, that your unit tests are saved in the default directory.

Since MediaWiki 1.25, any categories that an extension wants listed at Special:TrackingCategories must be registered in extension.json:

{
	"TrackingCategories": [
		"myextension-tracking-category"
	]
}

myextension-tracking-category is a system message which holds the category name. The extension adds it to pages by calling Parser::addTrackingCategory().

See Manual:Extension.json/Schema#callback.

If an extension or skin has library dependencies, it may have a composer.json file as well, see Manual:Composer.json best practices . Use the load_composer_autoloader field to make MediaWiki use Composer's autoloading when appropriate.

Some metadata fields overlap between extension.json and composer.json (discussed in task T89456), including :

• url and homepage
• license-name and license

• Maintained by Unknown or Unassigned^{[‍Maintainers page]}.
• Issue tracker: Phabricator MediaWiki-Configuration (Report an issue)

• Manual:Extension.json/Schema
  • docs/extension.schema.v2.json is the schema for extension.json (and skin.json).
• Known limitations
• Overview of architecture
• Migration guide - some recommendations on updating older extensions

• Report bugs against the MediaWiki-Configuration project.
• RfC about implementing extension registration