Manual:Extension registration/fr

L’enregistrement d’extensions est le mécanisme utilisé par MediaWiki pour charger les extensions et les habillages. Vous placez les données de configuration dans un fichier nommé  (respectivement  ) placé dans le dossier racine de votre extension (resp. habillage) et MediaWiki utilise ces données pour enregistrer les extensions et les habillages.

Avant la version 1.25 de MediaWiki, la configuration des extensions et des habillages était réalisée en PHP dans un fichier portant le nom de l’extension ou de l’habillage, par exemple  ou. Cette méthode est obsolète et les développeurs d’extensions ou d’habillages devrait commencer une transition vers le nouveau format.

Migrer, pour les administrateurs système
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 devez modifier. Si vos habillages ne sont pas situés dans le dossier $IP/skins, vous devez modifier la variable (mal nommée). Cela doit être fait avant tout chargement d’extension ou d’habillage.

ou, en une seule ligne :

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. Si vous avez besoin de garder la compatibilité pre-1.25, retirez la ligne die et conservez l’ancienne configuration en PHP.

Ou, pour les habillages :

Conserver la documentation
Les points d’entrée PHP contiennent généralement de la documentation pour les options de configuration, qui est utile et ne devrait pas être perdue. Malheureusement, le JSON ne permet pas d’inclure des commentaires. Il est recommandé de déplacer la documentation de la configuration dans un fichier  placé dans le dépôt. Vous devriez aussi documenter votre extension sur ce wiki dans la page Extension:MonExtension. Il est de plus possible d’inclure un peu de documentation dans le fichier  : le système d’enregistrement des extensions ignore les propriétés de   dont les noms commencent par le caractère   pour l’objet principal et l’objet   ; vous pouvez ainsi y insérer les commentaires. Par exemple :

Cette méthode devrait être réservée à de brefs commentaires.

Fonctionnalités
Si vous chargez un grand nombre d’extensions, l’enregistrement d’extensions permettra un gain de performance si vous avez installé APC (ou APCu). Les extensions qui sont chargées ensemble avec  (avec un suffixe -s marquant le pluriel) seront mises en cache ensemble.

Attributs
Un problème récurrent est la façon « d’enregistrer » quelque chose avec une extension. En général, cela signifie que vous avez à charger une extension avant une autre. Par exemple, l’éditeur visuel a  qui permet aux extensions d’ajouter leurs modules. Ainsi, dans le point d’entrée de l’éditeur visuel, il y a :

Cela signifie que si une extension ajoute quelque chose au tableau avant que l’éditeur visuel soit chargé, celui-ci effacera l’entrée dans ce tableau. Quelques extensions dépendent d’un ordre de chargement spécifique, d’autres bricolent quelque chose avec. L’enregistrement d’extensions résoud ce problème avec les « attributs ». Dans l’extension Math, son extension.json aurait quelque chose comme :

Quand l’éditeur visuel veut accéder à cet attribut, il utilise :

Requirements (Dependencies)
Extension regsitartion has a  section, which acts similar to composer's   section. It allows an extension developer to specify several requirements for the extension, such as a specific MediaWiki version (or greater/less than) or another extension (not implemented yet, see ). To, e.g., add a dependency of an extension to a MediaWiki version, that is greater than 1.26.0, you can add the following code to :

The key of the  object is the name of the dependency (currently only MediaWiki supported), the value is a valid version constraint (the format has to match the one used by composer).

Check, if an extension is loaded without actually require it
Many extension may provide features, which only works, if another extension is installed, too, without really needing this feature for the core extension function to work. As an example: If extension B is installed, extension A can provide a real WYSIWYG editor, otherwise it will use a simple textarea. Extension A can profit from extension B (if it is installed), but doesn't require it to be installed to work properly. For this, you generally check, if the extension is installed, rather than adding it as a hard dependency. In the PHP entry point structure you can do this by checking, if a specific class of extension B exists or not, e.g. using this code: or by checking, if a constant (which needs to be set in extension B's PHP entry point) is defined: Both ways are error prone, class and constant namens, that aren't used for dependency checks only, are subject to change, which would break your "Extension-Installed-detection". To implement a standardized way of checking, if an extension is installed or not (without the need of extra work in an extension that is a soft-dependency in another one), extension registration can be used. It implements an  method, which returns a simple boolean, if the extension is installed or not (the extension needs to be loaded with extension registration for this to work). Instead of doing one of the above ways, you can do the following:

Configs (Your extension/skins settings)
To customise your configs since you may not use a wg prefix you can implant this like this:

__prefix has to go on top of all the configs in the config section.

an example with a custom prefix extension and skin is

note sf instead of wg for prefix. to use wg in config you just change sf to wg.

Personnaliser l’enregistrement
Quelques fois, les extensions ont besoin de faire des choses non-standard au cours de l’enregistrement ou font des choses très complexes. Vous pouvez spécifier une clé 'callback' dans votre extension.json si vous avez besoin d’exécuter du code PHP. La valeur devrait pouvoir être appelé en PHP, comme. exécutera ce callback après qu’il ait traité le fichier extension.json.

Ce callback n’est pas un hook classique, il est exécuté pendant les premières étapes de l’initialisation.

Consultez pour voir quels cas peuvent nécessiter un tel enregistrement spécialisé.

Et composer.json
Si une extension ou un habillage dépend de bibliothèques, il peut y avoir également un fichier composer.json</tt>, voir les bonnes pratiques pour composer.json. Quelques champs de métadonnées sont les mêmes (discussion dans T89456), dont :
 * et
 * et

Voir aussi

 * Rapportez les bugs dans le projet MediaWiki-Configuration.
 * Les anciennes version de Manual:Developing extensions (avant mai 2015) et décrivent l’ancienne approche de déclaration des informations des extensions dans les variables et le code PHP
 * Limitations connues
 * Aperçu de l’architecture
 * Schéma pour  et skin.json : docs/extension.schema.json</tt>. Un outil permet de générer de la documentation à partir de celui-ci.
 * RfC proposant l’implémentation d’un système d’enrgistrement des extensions.