Manual:Extension registration

Extension registration refers to the new system of loading extensions that was introduced in MediaWiki 1.25 following a 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  or   in each extension.

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 it will optimize the loading of extensions.

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

Migrating
A script has been written to help with migrating from PHP entry points to JSON:. If your extension supports older versions of MediaWiki, you should keep your PHP entry point until you drop support for those older versions.

Note: 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 to. However, in VisualEditor's entry point it has:

This means that if any extension appends to the array before VisualEditor is loaded will have it's module wiped out. 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 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

A 'callback' key can be specified in your extension.json if you need to execute some PHP code. The value should be set to a valid PHP callable, like. This callback will be executed after the extension.json file is processed.


 * 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.