Manual:Extension registration

Extension registration refers to the new system of loading extensions and skins that was introduced in MediaWiki 1.25 following an 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:

If you keep your extensions in a location different from $IP/extensions, you need to override $wgExtensionDirectory.

If your skins are not in $IP/skins you need to override the poorly named $wgStyleDirectory.

This must be done before you load any extensions or skins.

Migrating for extension developers
The script maintenance/convertExtensionToRegistration.php</tt> 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</tt> until you drop support for those older versions.

Sample command lines:

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

You should replace your PHP entry point file (FooBar.php) with something like the following to not break wikis during the upgrade process.

If you need to keep pre-1.25 compatability, remove the die line and instead keep the old PHP setup.

Or skins

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.

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 (discussed in T89456, including
 * and
 * and