Manual:Extension registration/de


 * extension.json redirects here. For a list of specifications, go to Manual:Extension.json/Schema directly.

Extension registration ist das Verfahren, das MediaWiki zum Laden von Erweiterungen und Skins nutzt. Die Konfigurationsdaten werden in eine Datei namens  oder   geschrieben, welche im Stammverzeichnis der Erweiterung oder des Skins abgelegt wird. MediaWiki verwendet diese Dateien, um Erweiterungen und Skins zu registrieren.

If you were looking for documentation on installing extensions instead, see this guide.

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

Eigenschaften
Ein immer wieder auftretendes Problem ist, wie man etwas bei einer anderen Erweiterung "registriert". For instance, extensions can register a module with the VisualEditor (VE) extension through the hook. If the Math extension were to register a module with VE, it would have something like this in its :

The  node needs to be an object with the extension name as key and an object of attribute/value pairs as the value. Be aware that the key in the subobject must not contain the extension name!
 * manifest version 2

Manifest version 1 does not have a separate section for :
 * manifest version 1

Wenn VisualEditor auf dieses Attribut zugreifen möchte, würde es folgendes verwenden:



Anforderungen (Abhängigkeiten)
Extension registration verfügt über einen -Abschnitt, der sich ähnlich zu  Composers  -Abschnitt verhält. Er erlaubt einem Erweiterungs-Entwickler mehrere Anforderungen für die Erweiterung, wie beispielsweise eine spezifische MediaWiki Version (oder größer / kleiner als) oder eine andere Erweiterung oder einen anderen Skin anzugeben. Um zum Beispiel die Abhängigkeit von einer MediaWiki-Version größer als 1.26.0 zu ergänzen, kann folgender Code in  eingefügt werden:

Der Schlüssel des  Objekts ist der Name der Abhängigkeit ist (vor MediaWiki 1.29.0 war nur   unterstützt), der Wert ist eine gültige Versions-Einschränkung (das Format muss dem von Composer verwendeten entsprechen).

In MediaWiki 1.29.0 und darüber können auch Abhängigkeiten von Skins und anderen Erweiterungen wie folgt hinzugefügt werden:

In MediaWiki 1.33.0(?!??) and above you can also add dependencies on PHP like so:



Überprüfe, ob eine Erweiterung geladen ist, ohne sie tatsächlich zu benötigen
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.

Um eine standardisierte Möglichkeit der Überprüfung zu implementieren, ob eine Erweiterung geladen ist oder nicht (ohne die Notwendigkeit von Mehrarbeit in einer Erweiterung, die eine weiche Abhängigkeit von einer anderen hat), kann Extension registration verwendet werden. Sie implementiert eine -Methode, die über ein einfaches boolean zurückgibt, ob die Erweiterung geladen ist oder nicht (die Erweiterung muss mithilfe von "Extension registration" geladen werden, damit dies funktioniert). Beispiel:

Seit MediaWiki 1.32 ist es ebenfalls möglich, zu prüfen, ob eine Erweiterung geladen ist und eine angegebene Composer-Versionseinschränkunge erfüllt.

Möchtest du in älteren Versionen von MediaWiki prüfen, ob eine Erweiterung geladen ist, kannst du diese Information mit der -Methode erhalten, die auch Danksagungsinformationen (Credits) für alle geladenen Erweiterungen enthält. Zum Beispiel:

Alternativ: Falls die Erweiterung B eine spezielle Konstante für diesen Zweck beim Laden definiert, ist es möglich zu überprüfen ob diese definiert ist:

Es ist eine unschöne Art und Weise, die vermieden werden sollte, zu überprüfen, ob eine bestimmte Klasse einer Erweiterung vorhanden ist oder nicht, z.B. mit diesem Code:

Es könnte zu Problemen führen, wenn die Erweiterung im Dateisystem vorhanden, jedoch nicht geladen ist, z.B. wenn Composer für das automatische Laden verwendet wurde. Wenn die Klasse umbenannt wurde oder nicht mehr besteht (zum Beispiel, weil sie nicht öffentlich ist), wird dies auch zu Problemen führen.

Im Allgemeinen wird es bevorzugt, Code über Composer-Bibliotheken anstelle von Erweiterungen zu teilen. Wenn die Klassen einer Erweiterung nur existieren müssen, aber die Erweiterung weder konfiguriert noch geladen sein muss, um das gewünschte zu tun, ist das ein starkes Indiz dafür, dass der Code in eine Composer-Bibliothek abgespalten werden sollte, zu der stattdessen eine Abhängigkeit bestehen sollte.



Konfigurationen (Erweiterungs/Skin-Einstellungen)
Standardmäßig nimmt  an, dass die Konfigurationseinstellungen mit einem "wg"-Präfix beginnen.

Wenn das nicht der Fall ist, ist es möglich das Präfix mit einem speziellen Schlüssel zu überschreiben:

Das verwendet das Präfix "eg" und setzt die globale Variable auf true.

Seit manifest version 2 stellt der Einstellungs-Abschnitt der Extension registration deutlich mehr Features zur Verfügung und erlaubt dir, die Einstellungsmöglichkeiten viel detaillierter zu beschreiben. Anstelle eines einzelnen „Schlüssel -> Wert“-Feldes für Einstellungsmöglichkeiten kannst du auch die folgenden Informationen ergänzen:

Die allgemeine Struktur der  verändert sich ein wenig zu der folgenden, stärker objektorientierten Version:

value
Der Konfigurationswert wird an diesen Ort verschoben. Dies ist der einzige notwendige Schlüssel eines Konfigurationsobjektes.

path
Der boolsche Wert des -Schlüssels gibt an, ob der Wert der Einstellungsoption als Pfad im Dateisystem interpretiert werden soll, relativ zum Wurzelverzeichnis der Erweiterung. Z. B., wenn der Wert der Einstellung  ist und   true ist, ist der tatsächliche Wert.

description
Der -Schlüssel für eine Einstellung kann einen nicht lokalisierten String erhalten, welcher verwendet werden kann, um sie anderen Entwicklern oder Benutzern (Systemadministratoren) deriner Erweiterung zu erklären. It may also be used as tooltip text on the parameters section of the extension infobox on the MediaWiki.org extension description page. Der Wert des description-Schlüssel wird normalerweise nicht im Wiki angezeigt; sieh dir allerdings den Ausblick an, um mehr Informationen darüber zu erhalten, wie dieses Feature in Zukunft verwendet werden könnte!

descriptionmsg
Es ist ebenfalls möglich, einen Nachrichten-Schlüssel als Beschreibung in MediaWikis internes Lokalisierungssystem hinzufügen, der in Zukunft verwendet werden wird, um die Beschreibung im Wiki anzuzeigen.

public / private
Diese Option ist ein boolscher Wert, der standardmäßig auf false gesetzt ist, was bedeutet, dass die Einstellung und ihr Wert als "private" markiert sind. Dieser Wert wird im Moment nirgendwo verwendet; sieh dir den Ausblick an, um mehr über diese Option herauszufinden.

Ausblick
Die oben genannten Änderungen sind auch als Vorbereitungen für ein verbresserungs Konfigurations-Management in MediaWiki zu verstehen. Die obigen Informationen erlauben unns bspw., diese Optionen von Erweiterungen im MediaWiki-Benutzerinterface anzuzeigen. Zu diesem Zweck werden die lokalisierte Beschreibung ( und  ) sowie der Hinweis, ob die Option gezeigt werden soll oder nicht  benötigt.



Automatisiertes Auffinden von Unit-Tests
MediaWiki erlaubt jeder Erweiterung, phpunit-Tests zu registrieren. Ohne Erweiterungsregistrierung wäre es nötig, einen Hook-Handler für den -Hook zu registrieren, was in etwa so aussehen würde:

(wie auf der Handbuch-Seite beschrieben). Dieser Code ist allerdings für viele Erweiterungen identisch, sodass man ihn als unnötige Codedopplung bezeichnen könnte. Wenn eine Erweiterung Erweiterungsregistrierung verwendet und die phpunit-Tests sich im -Unterverzeichnis der Erweiterung befinden, wird der phpunit-Wrapper von MediaWiki diese Unit-Tests mithilfe von Erweiterungsregistrierung automatisiert finden. Daher ist es nicht mehr nötig, diesen Hook zu registrieren und anzugeben, dass die Unit-Tests im Standardverzeichnis gespeichert sind.



Anpassen der Registrierung

 * See Manual:Extension.json/Schema#callback.



Siehe auch composer.json
Wenn eine Erweiterung oder Skin Bibliotheksabhängigkeiten hat, kann es auch eine -Datei geben, siehe. Verwende das  -Feld, damit MediaWiki das automatische Laden von Composer verwendet, wenn dies angebracht ist.

Some metadata fields overlap between  and   (discussed in ), including :
 * and
 * and



Code Stewardship


Dokumentation

 * ist das Schema für  (und skin.json).
 * Migration guide - some recommendations on updating older extensions
 * Migration guide - some recommendations on updating older extensions
 * Migration guide - some recommendations on updating older extensions
 * Migration guide - some recommendations on updating older extensions

Feedback

 * Melde Fehler dem MediaWiki-Configuration-Projekt.
 * RfC zur Umsetzung der Registrierung von Erweiterungen