Manual:Extension.json/Schema/zh

本页记录了extension.json使用的模式. 除非另有说明，否则所有字段均为可选字段. 目前尚未完成.

该方案的第一次迭代见 (MW 1.25+)，第二次迭代见  (MW 1.29+).

manifest_version
'''该字段必填. '''

指定正在使用的 extension.json 文件格式的版本. 今后，如果文件格式发生了重大变化，这个数字将递增，以继续支持使用旧格式的扩展.

目前支持以下值：
 * : 1.25+
 * : 1.29+

v2 提供了更强大的开发者验证功能，如果你的扩展已经需要 MediaWiki 1.29 以上版本，建议使用 v2. 不建议为了升级到较新的 manifest_version 而破坏 MediaWiki 与旧版本的兼容性.

目前，v1 和 v2 都添加了新功能，但有人建议在 MediaWiki 1.38 版本中冻结和软废止 v1 (在 Phabricator 上讨论).

示例：

name
'''该字段必填. '''

这是扩展的规范名称. It should not be changed once set, as it is used as an API for other extensions to detect what is installed. 字段 “不” 必须与扩展的目录名或其在MediaWiki.org的扩展名称空间中的页面名称相匹配.

namemsg
扩展的本地化版本. 信息密钥通常以 &lt;name>-extensionname 或 &lt;name>-skinname 格式命名.

type
扩展类型，按Special:Version排序. 支持以下类型：
 * &mdash; API扩展
 * &mdash; 反垃圾邮件扩展
 * &mdash; 用于编辑内容的扩展（自 1.31 版起，）
 * &mdash; 媒体处理程序
 * &mdash; 修改、添加或替换 MediaWiki 解析器 中功能的扩展.
 * &mdash; extensions that modify skins
 * &mdash; extensions that add special pages
 * &mdash; make a new variable
 * &mdash; does something else

Custom types can be added by using the hook. Known ones include: If not set, the extension will default to the "other" section, and if set to an invalid value the extension will not appear on Special:Version.
 * &mdash; Semantic MediaWiki extensions
 * &mdash; Wikibase extensions

author
The authors of the extension, may contain wikitext. This can either be a single string, or an array of strings. Additionally, the special string  may be used to add a generic "" 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. 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:
 * (must not point to other extension folders)
 * (must not point to other extension folders)

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.

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". See gender support.
 * &mdash; Boolean. Default is . See .
 * &mdash; Boolean. Default is . See .
 * &mdash; A string. See .
 * &mdash; Userright(s) required to edit in this namespace. An array or string.
 * &mdash; Set $wgCapitalLinks on a per-namespace basis. Boolean.
 * &mdash; Whether the namespace is conditional upon configuration and should not be registered (requires separate registration via a hook such as ). Boolean. Default is.
 * &mdash; Whether it is possible to move pages in this namespace. Boolean. Default is.

ExtensionFunctions
Note that extension functions cannot be used to programmatically update configuration variables 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
Deprecated hooks (see Stable interface policy). 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.

ForeignResourceDirs
Directory containing the extension's foreign resources (and the  file defining them). Should be given relative to the extension root.

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:

path
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 strategy
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.
 * &mdash; 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.
 * &mdash; 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).
 * &mdash; Uses  to handles nested arrays to a depth of 2 properly (e.g. ).
 * &mdash; 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.
 * &mdash; Uses, basically the recursive version of  . Unlike  , this will handle non-array fields the way one would expect.
 * (since MW 1.35.3) &mdash; no merging; the default will only be used when no global value is set.

config_prefix
Prefix to put in front of configuration settings when exporting them to.

The default is, so a configuration setting corresponds to a PHP global. Note that choosing a different config prefix can make it more difficult to find the extension setting corresponding to a given global.

ParsoidModules
A list of Parsoid extension module specifiers. A Parsoid extension module is a class implementing ; a specifier is a class name or specification or a Parsoid-specific module specification.

ForeignResourcesDir
The directory holding the  file, relative to the extension root. For more information, read ResourceLoader's guide on foreign resources.

attributes
Registration information for other extensions. This allows one extension to register things with other extensions. Attribute values must be JSON arrays or objects, and they will be merged together when retrieved in PHP.

In manifest_version 1 these were top level keys that could be arbitrarily named:

In manifest_version 2, these are now under the top level  key, and then nested under the extension name that the attribute belongs towards.

The full attribute name is the concatenation of the extension name and attribute name ( in the example below). Each key set directly under  must match the extension name (arbitrary top-level attribute keys are not supported). If an extension (EventLogging in this example) is not installed, the attributes won't be loaded into the registry.

To access the value of an attribute in PHP, you can use the ExtensionRegistry:

load_composer_autoloader
Load the composer autoloader for this extension, if one is present. This should be used if the extension has dependencies on libraries that are specified in. It is basically equivalent to the following code: