Manual:Extension registration/fr

L’enregistrement d’extensions se réfère au nouveau système de chargement des extensions et habillages introduit dans MediaWiki 1.24 à la suite d’une RFC.

Plutôt que d’inclure les métadonnées à propos des extensions dans des fichiers PHP qui dépendent de la porté, de l’état global et de l’ordre de chargement, celles-ci sont enregistrées dans un fichier nommé extension.json ou skin.json dans chaque extension et skin. La nouvelle classe  traite ces fichiers.

Utilisation
Auparavant, votre fichier LocalSettings.php aurait inclus quelque chose comme :

Cela peut être converti en :

Si vous conservez vos extensions dans un endroit autre que $IP/extensions, vous pouvez interagir directement avec ExtensionRegistry :

Migrer, pour les développeurs d’extensions
Le script maintenance/convertExtensionToRegistration.php vous aide à migrer vos points d’entrée PHP en un fichier de métadonnées JSON. Si votre extension supporte d’anciennes versions de MediaWiki, vous pouvez garder votre point d’entrée PHP FooBar/FooBar.php jusqu’à ce que vous retiriez le support pour ces anciennes versions.

Exemples de ligne de commande :

Vous pourriez avoir besoin de désinstaller votre extension dans LocalSettings.php si vous avez des erreurs disant que des fonctions ou des constantes ne peuvent pas être redéfinies. Vous devriez remplacer votre fichier de point d’entrée PHP (FooBar.php) en quelque chose qui ne casse pas les wikis durant le processus de mise à jour. If you need to keep pre-1.25 compatability, remove the die line and instead keep the old PHP setup.

Fonctionnalités
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.

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

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

Voir aussi

 * Report bugs against the MediaWiki-Configuration project.
 * Manual:Developing extensions#Setup and describe the old approach of declaring extension information in PHP code and variables