Manual:Extension registration/fr


 * extension.json redirects here. For a list of specifications, go to Manual:Extension.json/Schema directly.

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

If you were looking for documentation on installing extensions instead, see this guide.

Fonctionnalités
Si vous chargez un grand nombre d’extensions, l’enregistrement d’extensions permettra un gain de performance tant que APC (ou APCu) est installé. 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 autre extension. For instance, the VisualEditor (VE) extension offers the hook, which other extensions can use to register a module with VE. If the Math extension were to register a module with VE, it would have something like the following in its : Quand l’Editeur Visuel veut accéder à cet attribut, il utilise :



Prérequis (dépendances)
L'enregistrement d'extension possède une section, qui agit de manière similaire à la section   de Composer. Elle permet à un développeur d'extensions de spécifier plusieurs prérequis pour l'extension, comme une version spécifique de MediaWiki (ou plus récent que, plus ancien que) ou une autre extensions ou habillage. Par exemple, pour ajouter une dépendance sur une version de MediaWiki plus récente que 1.26.0, vous pouvez ajouter le code suivant dans  :

La clé de l'objet  est le nom de la dépendance (avant MediaWiki 1.29.0 seulement   était pris en charge), la valeur est une contrainte de version valide (le format doit être compatible avec celui utilisé par Composer).

Dans MediaWiki 1.29.0 et plus récent vous pouvez aussi ajouter des dépendances vers des habillages ou d'autres extensions comme par exemple :

Dans MediaWiki 1.33.0 (?) et ultérieur, vous pouvez aussi ajouter des dépendances sur PHP ainsi :



Vérifier qu'une extension est chargée alors qu'elle n'est pas nécessaire
Beaucoup d'extensions peuvent apporter des fonctionalités qui ne travaillent que si une autre extension est également chargée, sans que cette fonctionalité ne soit réellement demandée pour que la fonction d'extension du noyau soit opérationnelle. Comme exemple : si l'extension B est chargée, l'extension A peut fournir un éditeur réellement WYSIWYG, sinon on utilisera une simple zone textuelle. L'extension A peut profiter de l'extension B (si elle est chargée), mais n'en n'a pas besoin pour être chargée et fonctionner correctement. Pour cela on regarde habituellement si l'extension est chargée plutôt que de l'ajouter comme dépendance codée en dur.

Pour implémenter une manière standardisée pour vérifier qu'une extension est chargée ou pas (sans avoir besoin de développement supplémentaire dans une extension qui dépend logiciellement d'une autre), l'enregistrement d'extension peut être utilisé. Il implémente une méthode , qui retourne un booléen indiquant si l'extension est chargée ou pas (l'extension doit être chargée avec l'enregistrement d'extension pour que cela fonctionne). Exemple:

Depuis MediaWiki 1.32 il est également possible de vérifier si une extension est chargée et si elle satisfait une contrainte de version de Composer :

Si vous vouliez vérifier qu'une version spécifique d'une extension était chargée dans les précédentes versions de MediaWiki, ce type d'information peut être extrait avec la méthode , qui retourne l'information de crédit pour toutes les extensions chargées. Exemple:

De la même manière, si l'extension B définit une constante spéciale dans ce but durant le chargement, il est possible de vérifier si elle est définie :

Une autre manière parallèle qui doit être évitée est de vérifier si une classe spécifique de l'extension B existe ou pas, par exemple en utilisant le code :

Ceci peut ne pas fonctionner si l'extension existe dans le système de fichiers mais n'est pas chargée, par exemple si Composer a été utilisé pour l'auto-chargement. Si une classe a été renommée ou cesse d'exister (par exemple parce qu'elle ne fait plus partie des paquets publiques) cela va provoquer également la rupture.

En général, il est préférable de partager le code par des composants Composer plutôt que des extensions. Si les classes d'une extension n'ont besoin que d'exister, mais que l'extension n'a pas besoin d'être configurée ni chargée pour ce que vous voulez en faire, c'est une très bonne indication que le code doit être découpé dans un composant Composer duquel vous devez dépendre à la place.



Configurations (vos paramètres d'extensions et d'habillages)
Par défaut,  suppose que vos paramètres de configuration commencent avec le préfixe « wg ».

Si ce n'est pas le cas, vous pouvez réécraser le préfixe en utilisant une clé spéciale :

Cela va utiliser le préfixe « eg » et mettre la variable globale à true.

À partir de manifest version 2, la section de configuration de l'enregistrement des extensions fournit beaucoup plus de fonctionnalités et vous permet de décrire vos options de configuration de manière beaucoup plus détaillée. Au lieu d'avoir enregistré une seule clé &rarr; valeur pour vos options de configuration, vous pouvez également ajouter les informations suivantes.

La structure générale de la  change légèrement par la suite, en devenant une version plus orientée objet :

value
La valeur de la configuration a été déplacée à cet endroit. C'est la seule clé obligatoire pour un objet configuration.

path
La valeur booléenne de la clé  indique si la valeur de l'option de configuration doit être interprétée comme un chemin dans le système de fichiers, relativement au répertoire racine de l'extension. Par exemple, si la valeur de la configuration est  et que   vaut true, la  valeur actuelle sera.

description
La clé  pour une option de configuration peut contenir une chaîne non traduite, qui peut être utilisée pour expliquer l'option de configuration de votre extension, aux autres développeurs ou aux utilisateurs (administrateurs système). Peut être aussi utilisé comme texte d'infobulle pour la section des paramètres dans la boîte d'information de l'extension, sur la page de description de l'extension de MediaWiki.org. La valeur de la clé de decription n'est habituellement pas affichée pour l'IHM du wiki, néanmoins, cherchez sur le sujet pour avoir plus d'informations sur la manière dont cette fonctionalité pourrait être utilisée dans le futur !

descriptionmsg
Il existe aussi la possbilité d'ajouter en tant que description, une clé du message dans le sytème de localisation interne de MediaWiki, ce qui dans le futur, sera utilisé pour présenter la description au niveau de l'interface utilisateur de l'installation MediaWiki.

public / private
Cette option est un booléen, qui vaut  par défaut, ce qui signifie que l'option de configuration et la valeur sont marquées "private". Cette valeur est utilisée nulle part en ce moment, cherchez un peu sur le sujet pour en découvrir plus à propos de cette option.

Perspectives
Les modifications mentionnées ci-dessus sont également des étapes préparatoires pour une gestion améliorée de la configuration dans MediaWiki. Ces changements nous permettent par exemple d'afficher les options de configuration des extensions dans l'IHM MediaWiki. Pour cela, le message de description traduit ( et  ) ainsi que l'indication si l'option de configuration peut être affichée ou pas  sont nécessaires.



Auto-découverte des tests unitaires
MediaWiki permet à toute extension d'enregistrer des tests unitaires php. Sans l'enregistrement d'extension, vous devriez enregistrer un gestionnaire pour l'accroche, qui ressemblerait à ceci :

(comme décrit sur la page du manuel). Cependant, ce code a la même apparence pour beaucoup d'extensions, vous pouvez donc appeler cela une duplication inutile du code. Si votre extension utilise l'enregistrement des extensions et que vos tests phpunit se trouvent dans le sous-répertoire  de votre extension, le conteneur phpunit de MediaWiki va découvrir automatiquement les tests unitaires avec l'aide de l'enregistrement des extensions. C'est pourquoi il n'est plus utile d'enregistrer l'accroche, ni de spécifier que les tests unitaires sont stockés dans le répertoire par défaut.



Personnaliser l’enregistrement

 * Voir Repli du schéma dans Extension.json.



Et composer.json
Si une extension ou un habillage dépendent de bibliothèques, il peut exister également un fichier, voir. Utilisez le champ  pour que MediaWiki se serve de l'auto-chargement de Composer quand c'est nécessaire.

Quelques champs de métadonnées sont les mêmes entre  et   (discussion dans ), dont :
 * et
 * et



Gestion du code


Documentation

 * est le schéma pour  (et skin.json).
 * Migration guide - some recommendations on updating older extensions
 * Migration guide - some recommendations on updating older extensions
 * Migration guide - some recommendations on updating older extensions
 * Migration guide - some recommendations on updating older extensions

Feedback

 * Rapportez les bogues dans le projet MediaWiki-Configuration.
 * RfC à propos de l’implémentation d’un système d’enregistrement d'extensions