Manual:Extension registration/ja

拡張機能の登録 (Extension registration) は、コメント依頼に基づいて MediaWiki 1.25 で導入された、拡張機能や外装の読み込みについての新しいシステムを指します.

Rather than include metadata about extensions inside PHP files that depends upon filescope, global state and load order, these are now stored in a file named extension.json or skin.json in each extension and skin. 新しい  クラスがこれらのファイルを処理します.

使用法
以前は LocalSettings.php で以下のようにインクルードしていたでしょう:

これは以下のように変換できます:

If you keep your extensions in a location different from $IP/extensions, you need to override $wgExtensionDirectory. If your skins are not in $IP/skins you need to override the poorly named $wgStyleDirectory. This must be done before you load any extensions or skins.

or if you want to do it within one line:

移行 (拡張機能の開発者向け)
The script maintenance/convertExtensionToRegistration.php helps you migrating from PHP entry points to a JSON metadata file. If your extension supports older versions of MediaWiki, you should keep your PHP entry point FooBar/FooBar.php</tt> until you drop support for those older versions.

Sample command lines:

You may need to uninstall your extension from LocalSettings.php if you receive errors that constants or functions cannot be redefined. You should replace your PHP entry point file (FooBar.php) with something like the following to not break wikis during the upgrade process. If you need to keep pre-1.25 compatability, remove the die line and instead keep the old PHP setup.

Or skins

Features
If you are loading a large number of extensions, extension registration will provide a performance boost as long as you have APC (or APCu) installed. Extensions that are loaded together with  will be cached together.

Attributes
A recurring problem is how to "register" something with another extension. Usually this meant that you had to load one extension before another. For example, VisualEditor has a  which allows extensions to add their modules. However, in VisualEditor's entry point it has:

This means that if any extension appends to the array before VisualEditor is loaded, VE will wipe out its entry in this array. Some extensions depended upon a specific load order, others hacked around this with. Extension registration solves this problem with "attributes". In the Math extension, its extension.json</tt> would have something like:

When VisualEditor wants to access this attribute it uses:

登録のカスタマイズ
Sometimes extensions need to do non-standard things during registration, or are just very complex. There are two features that can be used to support these cases:


 * コールバック

You can specify a 'callback' key in your extension.json</tt> if you need to execute some PHP code. The value should be set to a valid PHP callable, like. will execute this callback after it processes the extension.json</tt> file.


 * Custom processors

By default, all extensions use the  implementation of the   interface. This can be overridden by specifying a  key set to a class name. It is recommended that custom processors extend the ExtensionProcessor, and required that they implement the Processor interface.

Also composer.json
If an extension or skin has library dependencies, it may have a composer.json</tt> file as well, see Manual:Composer.json best practices. Some metadata fields in these files overlap (discussed in T89456, including
 * and
 * and

関連項目

 * Report bugs against the MediaWiki-Configuration project.
 * Manual:Developing extensions#Setup and describe the old approach of declaring extension information in PHP code and variables