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.

You may need to uninstall your extension from LocalSettings.php if you receive errors that constants or functions cannot be redefined.

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 just very 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.

The downside of using these callbacks they are not backwards-compatible. If your extension used to do special setup in ExtensionName.php</tt>, an alternative is
 * define a setup function
 * add it to for backward compatibility in your old MyExtension.php file
 * add it in the  section of your extension.json</tt>

Also composer.json
If an extension or skin has library dependencies, it may have a composer.json</tt> file as well, see Manual:Composer.json best practices. Some metadata fields in these files overlap, including
 * and
 * and