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 [<tvar|url>http://php.net/manual/en/language.types.callable.php</> 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.