Manual:Extension registration/de

Extension registration ist der Mechanismus, den MediaWiki nutzt um Erweiterungen und Skins zu laden. Konfigurationsdaten werden in eine Datei mit dem Namen  oder   im Stammverzeichnis Ihrer Erweiterung oder Skins eingetragen und MediaWiki verwendet diese Daten um Erweiterungen und Skins zu registrieren.

Vor MediaWiki 1.25 wurde die Konfiguration für Erweiterungen und Skins in einer PHP-Datei mit gleichem Namen wie die Erweiterung oder der Skin geschrieben, zum Beispiel  oder. Dieses Vorgehen ist veraltet und Entwickler von vorhandenen Erweiterungen und Skins sollten beginnen ihre Erweiterungen in das neue Format zu Migrieren.

Migration für Systemadministratoren
Früher hätten Sie in Ihre LocalSettings.php etwa folgendes eingetragen:

Dies schreibt man jetzt so:

Wenn Sie Ihre Erweiterungen in einem anderen Verzeichnis als $IP/extensions gespeichert haben, müssen Sie  ändern. Wenn Ihr Skin nicht im Verzeichnis $IP/skins gespeichert ist, müssen sie ändern. Dies muss geschehen, bevor Sie irgendeine Erweiterung oder einen Skin laden.

alternativ kann das auch in einer Zeile konfiguriert werden:

Migration für Entwickler von Erweiterungen
Das Skript maintenance/convertExtensionToRegistration.php hilft Ihnen PHP Einsprungspunkte in eine JSON-Metadatendatei zu migrieren. Wenn ihre Erweiterung ältere Versionen von MediaWiki unterstützt, sollten Sie Ihren PHP-Einsprungspunkt FooBar/FooBar.php beibehalten solange die Unterstützung für die älteren Versionen bestehen bleibt.

Beispiel für Befehlszeilen :

Wenn der Fehler angezeigt wird, dass Konstanten oder Funktionen nicht neu definiert werden konnten, müssen Sie Ihre Erweiterung in LocalSettings.php deinstallieren (d.h. auskommentieren). Sie sollten Ihre PHP Einsprungpunkt-Datei (FooBar.php) mit einem Code wie folgendem ersetzen, damit Wikis während des Aktualisierungsprozesses nicht abbrechen. Wenn Sie Vor-1.25 Kompatibilität beibehalten wollen, entfernen Sie die die Zeile und belassen stattdessen die alte PHP-Konfiguration.

Oder Skins

Entwicklerdokumentation
PHP entry points usually have some documentation of configuration settings that is useful and shouldn't be lost. Unfortunately JSON doesn't support comments. It is recommended that you transfer configuration documentation to a README file in the extension's repository. You should also document configuration on-wiki in your Extension:MyExtension page. It is possible to include some documentation directly in the extension.json file as well. Extension registration ignores any key in extension.json starting with ' ' in the top-level structure or under, so you can put comments in those parts of the JSON file. For example:

Dies sollte nur für kurze Notizen und Kommentare verwendet werden.

Funktionen
Wenn Sie eine große Anzahl von Erweiterungen laden, bietet "extension registration" eine Leistungssteigerung, sofern Sie APC (or APCu) installiert haben. Erweiterungen, die zusammen mit  (mit Mehrzahl -s) geladen werden, werden zusammen zwischengespeichert.

Eigenschaften
Ein immer wieder auftretendes Problem ist, wie man etwas bei einer anderen Erweiterung "registriert". Normalerweise bedeutet dies, dass Sie eine Erweiterung vor einer anderen laden müssen. Zum Beispiel hat VisualEditor ein, das es Erweiterungen ermöglicht ihre Module hinzuzufügen. However, in VisualEditor's entry point it has:

Wenn eine Erweiterung das Array erweitert bevor VisualEditor geladen ist, wird VE beim Laden alle Einträge aus dem Array löschen. Einige Erweiterungen hingen von einer bestimmten Ladereihenfolge ab, andere hackten um diese mit herum. "Extension registration" löst dieses Problem mit "Eigenschaften". In der Erweiterung Math ist in ihrer extension.json</tt> etwa folgendes eingetragen:

Wenn VisualEditor auf dieses Attribut zugreifen möchte, ruft er folgende Funktion auf:

Anforderungen (Abhängigkeiten)
"Extension registration" hat einen  Abschnitt, der ähnlich wirkt wie der   Abschnitt beim Verfasser. Er erlaubt einem Erweiterungs-Entwickler mehrere Anforderungen für die Erweiterung, wie beispielsweise eine spezifische MediaWiki Version (oder größer / kleiner als) oder einer andere Erweiterung (noch nicht implementiert, siehe ) zu spezifizieren. Um zum Beispiel eine Abhängigkeit von einer Erweiterung auf eine MediaWiki-Version größer als 1.26.0 zu ergänzen, können Sie den folgenden Code in  einfügen:

Der Schlüssel des  Objekts ist der Name der Abhängigkeit ist (derzeit wird nur MediaWiki unterstützt), der Wert ist eine gültige Versions-Einschränkung (das Format muss einem aus von Verfasser verwendet) entsprechen.

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.

Configs (Your extension/skins settings)
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.

Anpassen der Registrierung
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.

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

Siehe auch

 * 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
 * Bekannte Einschränkungen
 * Überblick über die Architektur
 * docs/extension.schema.json</tt> ist das Schema für  (und skin.json). Es gibt ein Werkzeug, das diese Dokumentation erzeugt.
 * RfC zur Umsetzung der Registrierung von Erweiterungen