Manual:Extension.json/Schema

This page documents the schema used by extension.json. All fields are optional unless otherwise specified. It is currently incomplete.

name
This field is required.

This is the extension's canonical name. It should not be changed once set, as it is used as an API for other extensions to detect what is installed.

manifest_version
This field is required.

This specifies the version of the extension.json file format that is being used. In the future if breaking changes are made to the file format, this number will be incremented to continue supporting extensions using the older format.


 * : 1.25+
 * : 1.29+ Note: This field is typically placed at the bottom of extension.json files.

namemsg
A localized version of the extension's name. Typically the message key is named in the format -extensionname or -skinname.

type
The type of extension it is, for sorting on Special:Version. The following types are supported: Note: custom types can be added by using the hook. If not set, the extension will default to the "other" section.
 * — API extensions
 * — antispam extensions
 * — media handlers
 * — extensions that modify, add or replace functionality in the MediaWiki parser
 * — extensions that modify skins
 * — extensions that add special pages
 * — make a new variable
 * — does something else

author
The authors of the extension, may contain wikitext. This can either be a single string, or a list of strings. Additionally, the special string  may be used to add a generic "and others" suffix using the   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. Note: it is recommended to use descriptionmsg instead.

descriptionmsg
Localization message key for the extension's description, typically in the format -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 "COPYING" 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 and other extensions. 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.

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.

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.

Merge strategies
The following merge strategies are available:
 * : Default, does not need to be explicitly set. Any keys that are integers will be re-numbered when merging.
 * : Handles keys with integers properly.
 * : Handles nested arrays to a depth of 2 properly (e.g. ).
 * : Handles arrays even deeper than 2, though realistically, a configuration setting that is nested more than 2 arrays suggests too many things are being configured in one setting, and splitting it into multiple might be a good idea.
 * : TODO why should this be used?