Manual:Extension.json/Schema/fr

Cette page documente le schéma utilisé par extension.json. Tous les champs sont optionnels sauf contre-indication. Il est actuellement incomplet.

Pour la première itération de ce schéma voir (MW 1.25+), pour la seconde voir  (MW 1.29+).

manifest_version
Ce champ est obligatoire.

Ceci spécifie la version du format de fichier extension.json qui sera utilisé. A l'avenir, si des modifications viennent à changer le format du fichier, ce nombre sera incrémenté pour continuer à prendre en charge les extensions qui utilisent l'ancien format.

Actuellement les valeurs suivantes sont acceptées :
 * : 1.25+
 * : 1.29+

v2 fournit des fonctionnalités de validation plus fortes pour le développeur, et elle est recommandée si votre extension nécessite déjà MediaWiki 1.29+. Il est recommandé de supprimer la compatibilité avec les anciennes versions, simplement pour forcer la mise à jour vers un nouveau manifest_version.

Actuellement de nouvelles fonctionnalités sont ajoutées dans v1 et v2, mais il a été demandé de geler v1 et de le rendre obsolète dans la version MediaWiki 1.38 (discussion sur Phabricator).

Exemple :

name
Ce champ est obligatoire.

Il s'agit du nom canonique de l'extension. Il ne doit pas être modifié une fois qu'il a été défini parce qu'il est utilisé comme API pour que les autres extensions puissent détecter qu'elle a été installée. Le champ  ne doit pas forcément correspondre au nom du répertoire d'une extension ni au nom de sa page dans l'espace de noms Extension de MediaWiki.org.

namemsg
Version traduite du nom de l'extension. Typiquement la clé du message est nommée selon le format &lt;name>-nomDeLextension ou &lt;name>-nomDeLhabillage.

type
Type de l'extension, sert à trier sur Special:Version. Les types suivants sont acceptés :
 * &mdash; extensions de l'API
 * &mdash; extensions anti-pourriel
 * &mdash; extensions qui modifient le contenu (depuis la 1.31, )
 * &mdash; gestionnaires de médias
 * &mdash; extensions qui modifient, ajoutent ou remplacent des fonctionnalités de l'analyseur syntaxique de MediaWiki.
 * &mdash; extensions qui modifient les habillages
 * &mdash; extensions qui ajoutent des pages spéciales
 * &mdash; créer une nouvelle variable
 * &mdash; fait autre chose

Vous pouvez ajouter des types personnalisés en utilisant l'accroche. Les valeurs connues comprennent : Si non initialisé, l'extension est affectée à la section other, et si la valeur assignée est non valide l'extension n'apparaîtra pas dans Special:Version.
 * &mdash; extensions Semantic MediaWiki
 * &mdash; extensions Wikibase

author
Auteurs de l'extension, peut contenir du texte wiki. Ceci peut être soit une chaîne unique, soit un tableau de chaînes. En plus, la chaîne spéciale  peut être utilisée pour ajouter un suffixe générique «  » en utilisant le message.

version
The current version of the extension. Should be in a format supported by Composer.

url
URL to the extension's "homepage" or documentation. Typically points to.

description
Description of the extension, may contain wikitext. It is recommended to use descriptionmsg instead.

descriptionmsg
Localization message key for the extension's description, typically in the format &lt;extensionname>-desc. This will override description.

license-name
The SPDX license identifier for the license the source code is licensed as. If you create a file named  or   (with an optional   extension) in the extension root directory with the contents of the license, it will also be linked and visible from Special:Version.

requires
The requires section allows you to document dependencies on versions of MediaWiki core (1.26+) and other extensions (1.29+).

You can use any version specifier that composer supports. For MediaWiki, it is best practice to specify a >= for the minimum supported version, unless you know a future version is explicitly broken. For extensions, if they don't have a version specifier set, or don't use a versioning system, use a plain * to indicate any version is acceptable.

If your extension uses Wikimedia Continuous integration, you also need to add extension dependencies to in the   project.

platform
You can also express a dependency on platform settings, currently limited to PHP version and PHP extensions. Note that most extensions are expected to follow the PHP version requirements for the versions of MediaWiki core they support, and specifying a more restrictive PHP version contraint should only be done in exceptional cases. Checking for PHP extension versions isn't supported right now.

In this example, the extension requires 1.32 (which has a minimum requirement of PHP 7.0), and additionally expresses that it needs a higher dependency of at least PHP 7.1 since it requires usage of some newer PHP feature. Furthermore, it required the curl PHP extension to be installed.

suggests
Allows listing suggested but not required dependencies. The format is identical to.

ResourceFileModulePaths
Specifies the default paths to use for all ResourceLoader file modules.

The allowed properties are:

These correspond to the same options in each module definition in. If a value is not specified in the module definition, the default value specified here will be used.

SkinLessImportPaths
Path to the skin-specific LESS import directory, keyed by skin name. Can be used to define skin-specific LESS variables.

QUnitTestModule
A ResourceLoader file module, to loaded when running JavaScript unit tests. This follows the same syntax as ResourceModules.

Internally, when is , this module is automatically registered under the name " ".

MessagePosterModule
Allows extensions to add additional files or dependencies to the  module bundle. This follows the same syntax as ResourceModules.

AuthManagerAutoConfig
The following properties are available:
 * &mdash; Pre-authentication providers.
 * &mdash; Primary authentication providers.
 * &mdash; Secondary authentication providers.

namespaces
Method to add extra namespaces.

The following properties are available:


 * &mdash; An integer. The numeric identifier of the namespace, as used in the database. Since MW 1.30, the namespace ID can be overwritten locally, by defining the respective constant in LocalSettings.php before loading the extension. Extension code must therefore always use the constant for the namespace ID, and never use the ID as a literal in PHP code. Consider listing your id number used at Extension default namespaces to avoid conflicts with other extensions.
 * &mdash; A string. The name of the constant that the extension code uses to refer to the namespace ID.
 * &mdash; A string. The name of the namespace, as used in titles.
 * &mdash; Gender object. Properties are either "male" or "female". Voir la prise en charge du gendre.
 * &mdash; Booléen. La valeur par défaut est . Voir .
 * &mdash; Booléen. La valeur par défaut est . Voir .
 * &mdash; A string. Voir .
 * &mdash; Userright(s) required to edit in this namespace. An array or string.
 * &mdash; Set $wgCapitalLinks on a per-namespace basis. Booléen.
 * &mdash; Whether the namespace is conditional upon configuration and should not be registered (requires separate registration via a hook such as ). Booléen. Default is.
 * &mdash; Whether it is possible to move pages in this namespace. Booléen. Default is.

ExtensionFunctions
Note that extension functions cannot be used to programmatically update configuration variabels or register hooks. For that purpose, a registration callback should be used instead.

MessagesDirs
If you use the default directory layout with localized messages in the  directory, you can specify:

AutoloadClasses
Example:

AutoloadNamespaces
Array containing mapping of namespaces to directories in a PSR-4 compatible manner. Here's an example:

In this case all of the PHP classes are under the  namespace, and the naming of the classes directly maps to the files located in the   directory (relative to the extension.json file). Note that the namespace portion must end with.

Extensions using this feature should require at least MediaWiki 1.31 in  file:

For example, see Gerrit change 468385.

TestAutoloadClasses and TestAutoloadNamespaces
Both are the same as AutoloadClasses and AutoloadNamespaces, except that they are only used when running tests.

For example, see Gerrit change 556240.

Hooks
It's possible to register multiple callbacks for the same hook event:

HookHandlers
ObjectFactory specifications for new-style hook handlers.

DeprecatedHooks
Accroches obsolètes (voir les Règles des interfaces stables). Maps hook name to an array with  (MediaWiki version) and   (optional, usually omitted).

RestRoutes
List of route specifications to be added to the REST API. See API:REST API/Extensions.

SkinOOUIThemes
Map of skin names to OOUI themes to use.

OOUIThemePaths
Map of custom OOUI theme names to paths to load them from.


 * scripts
 * Path to script file.


 * styles
 * Path to style files.  will be replaced with the module's name.


 * images
 * Path to image definition files.  will be replaced with the module's name. If the files don't exist, default theme's images will be used instead.

callback
Sometimes extensions need to do non-standard things during registration, or are just very complex. You can specify a  key in your extension.json if you need to execute some PHP code. The value should be set to a valid PHP callable, for example:. ExtensionRegistry will execute this callback after it processes the extension.json file and sets all the other globals and configuration settings. This happens after LocalSettings, so all user-specified configuration is available, but some defaults set by MediaWiki might not have been initialized yet.

The callback is provided with two parameters, an array containing information about the extension (a subset of extension.json) and an instance of SettingsBuilder.

The callback isn't a normal hook function, it runs in early initialization. See Manual:Extension registration/Limitations for what sort of things may require custom registration.

Manual:$wgExtensionFunctions and the SetupAfterCache, BeforeInitialize and ApiBeforeMain hooks provide other ways of programmatically interacting with configuration.

config
The config section is where you can define configuration settings that sysadmins can change to configure the extension. This section should only be used for things that are configured in LocalSettings.php - if it is supposed to be modified by other extensions, you should use attributes, or if it is just class metadata, use a private static variable or something like that. The format of config changed in manifest_version 2.

Manifest version 1
A simple example:

This is equivalent to writing  in PHP. Note that the typical "wg" prefix is not included, as that will be added by default. If your settings start with a different prefix like, you can use the magic   key:

This is now equivalent to writing  in PHP.

A more complex example:

The first setting,, has keys that are numbers, so PHP will turn them into integers, even though they are strings in JSON. Because of how PHP treats integer keys when merging arrays, we need to use a different type of merge here, so we set a different "merge strategy" using the magic key. In the second example, we have a nested array, which requires a different type of merging, since we want to allow people to continue writing  in their LocalSettings.php.

Changes in manifest version 2
With MediaWiki 1.29, a new manifest_version (2) was introduced. In this version, the config section is improved in several ways. To support these changes, the signature of a set of configuration option and configuration value changed a bit. The key of the config object is still the configuration name; however, the value of that key is an object, which describes this configuration option, where one of the values is the value. You can find information about what the specific keys and values for a configuration option are on the extension registration documentation page. An easy example of the new schema, which simply is one configuration option and its value, would look like:

A more complex one would look like:

Paths
As demonstrated in the example above, a configuration option can have the  key defined. When present and set to, the value of the setting will be interpreted as a path local to the extension. For example, an extension might define its configuration as The value for the configuration option "Setting" will be resolved to.

Merge strategies
The merge strategy defines how to merge the default value of the configuration setting with the global value (the value of the  global variable). This only makes sense for array-valued configuration settings. The following merge strategies are available: When not explicitly set, the merge strategy defaults to. When at least one of the global value and the default is not an array, the merge strategy is ignored and the global value will simply override the default.
 * : Uses the   PHP command: array elements with numeric keys will be interpreted as non-associative list items and concatenated to the array (with the keys renumbered if needed), array elements with non-numeric keys will be interpreted as hashmap items and overwrite items with the same key.
 * : Uses the  PHP operator, so fields of the default value will only be used when the corresponding field is not set in the global value. This is useful for associative arrays with integer keys (such as namespace IDs).
 * : Uses  to handles nested arrays to a depth of 2 properly (e.g. ).
 * : Handles arrays even deeper than 2 with . Given the unintuitive behavior of this method (example), this strategy is not recommended. A configuration setting that is more than 2 levels deep suggests too many things are being configured in one setting, and splitting it into multiple settings might be a good idea.
 * : Uses , basically the recursive version of  . Unlike  , this will handle non-array fields the way one would expect.
 * (since MW 1.35.3): no merging; the default will only be used when no global value is set.

config_prefix
Prefixe à insérer devant les paramètres de configuration lors de l'export vers.

La valeur par défaut est, et une valeur de paramètre correspond à une variable globale PHP. Notez que si vous choisissez un préfixe de paramètre différent il pourra être plus difficile de retrouver le paramètre de l'extension correspondant à la variable globale concernée.

ParsoidModules
Liste de spécifieurs de modules de l'extension Parsoid. Un module d'extension Parsoid est une classe qui implémente ; un spécifieur est un nom de classe ou une spécification de ou encore une spécification de module dédié Parsoid.

attributes
Informations d'enregistrement pour les autres extensions. Cela permet à une extension d'enregistrer des éléments en rapport avec d'autres extensions. Les valeurs des attributs doivent être des tableaux JSON ou des objets, et ils seront fusionnés quand ils seront récupérés dans PHP.

Dans manifest_version 1 il s'agissait des clés de premier niveau que vous pouviez nommer arbitrairement :

Dans manifest_version 2, elles figurent sous la clé  de premier niveau, et sont imbriquées sous le nom de l'extension à laquelle l'attribut appartient. Le nom complet de l'attribut est la concaténation du nom de l'extension et du nom de l'attribut ( dans l'exemple ci-dessous). Si cette extension (EventLogging dans notre cas) n'est pas installée, les attributs ne seront pas chargés dans le registre.

Pour accéder à la valeur d'un attribut en PHP, vous pouvez utiliser ExtensionRegistry :

load_composer_autoloader
Charger le chargeur automatique de composer pour cette extension, s'il en existe un. Ceci doit être utilisé si l'extension a des dépendances sur les bibliothèques spécifiées dans. Ce qui équivaut en gros au code suivant :