Manual:Extension registration/ru

Регистрация расширения - механизм, который MediaWiki использует для загрузки расширений и стилей оформления(skin). Вы помещаете конфигурационные данные в файл  или   в корневой директории вашего расширения или темы оформления, и MediaWiki использует его, что бы зарегистрировать расширение или тему оформления.

До MediaWiki 1.25, конфигурация для расширений и тем оформления находилась в PHP файле с именем расширения или темы оформления, например  или. Это устарело, и разработчики существующих расширений и тем оформления должны начать миграцию для разработчиков расширений

Миграция для системных администраторов
До этого ваш LocalSettings.php, подключался так:

Сейчас можно преобразовать в:

Если вы храните расширение не в $IP/extensions, вам нужно переопределить. Если вы храните стиль оформления не в $IP/skins, вам нужно переопределить плохо названную. Это должно быть сделано до того, как вы загрузите расширение или стиль оформления.

если вы хотите сделать это в одну строчку:

Миграция для разработчиков расширений
Скрипт maintenance/convertExtensionToRegistration.php поможет вам мигрировать с PHP точек входа(?) на файл метеданных JSON. Если ваше расширение поддерживает старые версии MediaWiki, вы должны оставить вашу точку входа FooBar/FooBar.php пока не перестанете поддерживать старые версии.

Пример запуска команды:

You may need to uninstall your extension from LocalSettings.php if you receive errors that constants or functions cannot be redefined. Вы должны заменить вашу PHP точку входа (файл FooBar.php) на что-то наподобие следующего, что бы не сломать wiki в процессе апгрейда. Если вам надо сохранить совместимость с pre-1.25, удалите строку die и оставьте старую загрузку через PHP.

Или стили:

Вспомогательная документация
PHP точки входа обычно имеют документацию настроек конфигурации, которая полезна и не должна потеряться. К сожалению JSON не поддерживает комментариев. Рекомендуется переместить документацию конфигурации в файл README репозитория расширения. Вы также должны задокументировать конфигурацию в вики на странице вашего расширения Extension:MyExtension. Возможно также добавить некоторую документацию напрямую в extension.json. Регистрация расширения игнорирует любые ключи в extension.json</tt>, начинающиеся с ' ' в корне структуры или под, так что вы можете поместить комментарии в этих местах. Например:

Это должно использоваться только для кратких пометок и комментариев.

Возможности
Если вы загружаете большое количество расширений, регистрация расширений может быть ускорена, если у вас установлен APC (или APCu). Расширения, которые загружаются вместе с  (с множественными -s) будут кэшироваться вместе.

Атрибуты
Повторяющаяся проблема - как "зарегистрировать" что-то с другим расширением. Обычно это означает, что вы хотите загрузить одно расширение перед другим. Например VisualEditor имеет, который позволяет расширениям загружать их модули. Тем не менее в точке входа VisualEditor'а имеется:

Это означает, что если расширение добавляется в массив до VisualEditor'а, VE сотрет эту запись в массиве. Некоторые расширения зависели от определенного порядка загрузки, другие взламывали это при помощи. Регистрация расширений решает эту проблему при помощи "атрибутов". В расширении Math его extension.json</tt> имеет что-то следующее

Когда VisualEditor хочет получить доступ к атрибуту, он использует:

Требования (зависимости)
Extension registration has a  section, which acts similar to composer's   section. It allows an extension developer to specify several requirements for the extension, such as a specific MediaWiki version (or greater/less than) or another extension (not implemented yet, see ). To, e.g., add a dependency of an extension to a MediaWiki version, that is greater than 1.26.0, you can add the following code to :

The key of the  object is the name of the dependency (currently only MediaWiki supported), the value is a valid version constraint (the format has to match the one used by composer).

Check, if an extension is loaded without actually require it
Many extensions may provide features that work only if another extension is loaded too, without really needing this feature for the core extension function to work. As an example: If extension B is loaded, extension A can provide a real WYSIWYG editor, otherwise it will use a simple textarea. Extension A can profit from extension B (if it is loaded), but doesn't require it to be loaded to work properly. For this, you generally check, if the extension is loaded, rather than adding it as a hard dependency.

To implement a standardized way of checking, if an extension is loaded or not (without the need of extra work in an extension that is a soft-dependency in another one), extension registration can be used. It implements an  method, which returns a simple boolean, if the extension is loaded or not (the extension needs to be loaded with extension registration for this to work). Example:

Alternatively, if the extension B defines a special constant meant for this purpose during loading, it is possible to check, if it is defined:

A more brittle way, that should be avoided is to check if a specific class of extension B exists or not, e.g. using this code:

This might break if the extension exists in the file system but is not loaded, e.g. if composer was used for autoloading. If the class was renamed or ceases to exist (e.g. because it is not package public) this will also break.

In general it is preferred to share code via composer components instead of extensions. If the classes of an extension only need to exist, but the extension does not need to be configured nor loaded, for what you want to do, that is a strong indicator that that code should be split off into a composer component you should depend on instead.

=== Конфиги (настройки вашего расширения/стиля)

By default, extension.json assumes that your config settings start with a "wg" prefix. If that's not the case, you can override the prefix by using a special key:

That would use a prefix of "eg", and set the global variable  to true.

Unit tests auto-discovery
MediaWiki allows any extension to register phpunit tests. Without extension registration, you would need to register a hook handler for the UnitTestsList hook, which would look something like: (as described on the manual page). However, this code looks the same for a lot of extensions, so you could call it unnecessary code duplication. If your extension uses extension registration and your phpunit tests are located in the  subdirectory of your extension, the phpunit wrapper of MediaWiki wil autodiscover the unit tests with the help of extension registration. Therefore, you don't need to register the hook anymore and you don't need to specify, that your unit tests are saved in the default directory.

Кастомизация регистрации
Sometimes extensions need to do non-standard things during registration, or are just very complex. 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, for example:. will execute this callback after it processes the extension.json</tt> file.

The callback isn't a normal hook function, it runs in early initialization.

See for what sort of things may require custom registration.

Также 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.
 * Old versions of Manual:Developing extensions#Setup (prior to May 2015) and describe the old approach of declaring extension information in PHP code and variables
 * Known limitations
 * Overview of architecture
 * docs/extension.schema.json</tt> is the schema for  (and skin.json). there is a tool that generates documentation from this.
 * RfC about implementing extension registration