Manual:Extension registration

Extension registration refers to the new system of loading extensions and skins that was introduced in MediaWiki 1.25 following a rfc>Requests for comment/Extension registration|RfC.

Rather than include metadata about extensions inside PHP files that depends upon filescope, global state and load order, these are now stored in a file named extension.json or skin.json in each extension and skin. The new  class processes these files.

Usage
Previously your LocalSettings.php would include something like:

This can be converted to:

For ideal performance, if you are loading multiple extensions/skins, you should use the plural function, as they optimize the loading of extensions.

If you keep your extensions in a location different from $IP/extensions, you can interact with the ExtensionRegistry directly:

Migrating
The script maintenance/convertExtensionToRegistration.php helps you migrating from PHP entry points to a JSON metadata file. If your extension supports older versions of MediaWiki, you should keep your PHP entry point FooBar/FooBar.php until you drop support for those older versions.

For WMF-deployed extensions, the following snippet should not be added until Wikimedia production is converted entirely (T87875) as it will have a negative performance impact.

Features
If you are loading a large number of extensions, extension registration will provide a performance boost as long as you have APC (or APCu) installed. Extensions that are loaded together with  will be cached together.

Attributes
A recurring problem is how to "register" something with another extension. Usually this meant that you had to load one extension before another. For example, VisualEditor has a  which allows extensions to add their modules. However, in VisualEditor's entry point it has:

This means that if any extension appends to the array before VisualEditor is loaded, VE will wipe out its entry in this array. Some extensions depended upon a specific load order, others hacked around this with. Extension registration solves this problem with "attributes". In the Math extension, its extension.json</tt> would have something like:

When VisualEditor wants to access this attribute it uses:

Customizing registration
Sometimes extensions need to do non-standard things during registration, or are simply extremely complex. There are two features that can be used to support these cases:


 * callbacks

You can specify a 'callback' key in your extension.json</tt> if you need to execute some PHP code. The value should be set to a valid PHP callable, like. will execute this callback after it processes the extension.json</tt> file.


 * Custom processors

By default, all extensions use the  implementation of the   interface. This can be overridden by specifying a  key set to a class name. It is recommended that custom processors extend the ExtensionProcessor, and required that they implement the Processor interface.