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 deiner Erweiterung oder deines Skins eingetragen. 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 vorgenommen, die den gleichen Namen wie die Erweiterung trug, zum Beispiel  oder. Dieses Vorgehen ist veraltet und Entwickler von vorhandenen Erweiterungen und Skins sollten beginnen, in das neue Format zu migrieren.

Migration für Systemadministratoren
Früher hätte in  etwa folgendes eingetragen werden müssen:

Dies schreibt man jetzt so:

Wenn Sie die Erweiterungen in einem anderen Verzeichnis als  gespeichert sind, muss  geändert werden. Wenn die Skins nicht im Verzeichnis  gespeichert sind, muss das ungünstig benannte  angepasst werden. Dies muss geschehen, bevor irgendeine Erweiterung oder ein Skin geladen wird.

Seit MW 1.30 können Namensraum-IDs, die in extension.json definiert sind lokal überschrieben werden, indem die entsprechende Konstante in LocalSettings.php definiert wird, bevor die Erweiterung geladen wird. Betrachte beispielsweise die folgende Deklaration von Namensräumen in extension.json: Dies würde standardmäßig dazu führen, dass die Konstante NS_FOO so definiert wird, dass sie den Wert 1212v hat. Dies kann allerdings überschrieben werden, indem die entsprechende Konstante in LocalSettings.php definiert wird: Dies würde dazu führen, dass der „Foo“-Namensraum mit der ID 6688 anstelle der ID 1212 registriert wird. Beachte beim Überschreiben von Namensraum-IDs, dass alle Diskussions-Namensräume ungerade IDs haben müssen, und dass die ID eines Diskussions-Namensraumes immer der des Inhalts-Namensraums + 1 entsprechen muss.

Migration für Entwickler von Erweiterungen

 * Siehe auch die „wall of sadness“ (jetzt „wall of superpowers“)

Das Skript  hilft dabei, PHP-Eintrittspunkte in eine JSON-Metadaten-Datei zu migrieren. Wenn die Erweiterung ältere Versionen von MediaWiki unterstützt, sollten der PHP-Eintrittspunkt  beibehalten werden, 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, kann es nötig sein, die Erweiterung aus  zu deinstallieren.

Dokumentation erhalten
PHP-Eintrittspunkte haben in der Regel eine Dokumentation der Konfigurationseinstellungen, die nützlich ist und nicht verloren gehen sollte. Leider unterstützt JSON keine Kommentare. Es wird daher empfohlen, die Konfigurationsdokumentation in eine -Datei im Verzeichnis der Erweiterung zu übertragen. Auch onwiki sollte auf der Seite Extension:„MyExtension“ Dokumentation zur Konfiguration vorliegen. Es ist auch möglich, Dokumentation direkt in die -Datei aufzunehmen. Extension registration ignoriert alle Schlüssel, die mit ' ' beginnen, in der obersten Ebene der Struktur oder unter, so dass Sie Kommentare in diese Bereiche der JSON-Datei schreiben können. Zum Beispiel:

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 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". Normalerweise hat dies bedeutet, dass man eine Erweiterung vor einer anderen laden musste. Zum Beispiel hat VisualEditor ein, das es Erweiterungen ermöglicht ihre Module hinzuzufügen. Allerdings sieht das Array beim Laden des VisualEditors so aus:

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  etwa folgendes eingetragen:

Seit manifest version 2 müssen Attribute in einem eigenen Abschnitt  definiert werden.

Der -Knoten muss ein Objekt mit dem Erweiterunsnamen als Schlüssel und einem Objekt von Attribut-Wert-Paaren als Wer sein. Beachte dass der Schlüssel in diesem Objekt nicht den Erweiterungsnamen erhalten muss!

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

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:

Überprüfen Sie, ob eine Erweiterung geladen wird, ohne dass sie vorausgesetzt wird
Viele Erweiterungen können Funktionen bieten, die nur funktionieren, wenn eine andere Erweiterung auch geladen wird, aber ohne dass sie diese Funktion wirklich benötigen, um ihre Kernfunktionen bereitzustellen. Als Beispiel: Wenn Erweiterung B geladen ist, kann Erweiterung A einen echten WYSIWYG-Editor zur Verfügung stellen, andernfalls wird nur ein einfaches Textfeld verwendet. Erweiterung A kann von der Extension B profitieren (wenn sie geladen wird), aber B ist nicht erforderlich, damit A funktioniert. Zu diesem Zweck kann überprüft werdem, ob die Erweiterung geladen ist, anstatt sie als harte Abhängigkeit festzulegen.

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:

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 extension.json 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:

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

Pfad
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.

Beschreibung
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. 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!

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 „privat“ markiert sind. Dieser Wert wird im Moment nirgendwo verwendet; sieh dir den Ausblick an, um mehr über diese Option herauszufinden.

Outlook
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 Extension registration wäre es nötig, einen Hook-Handler für den -Hook zu registrtieren, was in etwa so aussehen würde:

(wie auf der Handbuch-Seite beschrieben). Dieser Code ist allerdings für viele Erweiterungen identischen, sodass man ihn als unnötige Codedopplung bezeichnen könnte. Wenn deine Erweiterung Extension registration verwendet und deine phpunit-Tests sich im -Unterverzeichnis deiner Erweiterung befinden, wird der phpunit-Wrapper von MediaWiki diese Unit tests mithilfe von Extension registration 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
Manchmal müssen Erweiterungen bei der Registrierung etwas tun, das nicht dem Standard entspricht, oder sind nur sehr kompliziert. Sie können einen 'callback' Schlüssel in ihrer extension.json angeben, wenn PHP-Code ausgeführt werden muss. Der Wert sollte auf einen gültigen PHP callable gesetzt werden, zum Beispiel:. wird diesen callback ausführen, nachdem es die -Datei verarbeitet hat.

Der callback ist keine normale Hook-Funktion, er wird in einer frühen Initialisierung-Phase ausgeführt.

In ist aufgeführt, für welche Dinge benutzerdefinierte Registrierung erforderlich sein kann.

Siehe auch ExtensionFunctions und die Hooks SetupAfterCache, BeforeInitialize und ApiBeforeMain für andere Wege, um beim Programmieren mit der Konfiguration zu interagieren.

Siehe auch composer.json
Wenn eine Erweiterung oder ein Skin Abhängigkeiten zu einer Bibliothek hat, kann es dort auch eine composer.json geben, siehe. Verwende das -Feld, um MediaWiki Composers Autoloading verwenden zu lassen, sofern dies angebracht ist.

Einige Felder von Metadaten überlappen sich zwischen  und   (in T89456 diskutiert), darunter:
 * und
 * und

Siehe auch

 * Melde Fehler dem MediaWiki-Configuration-Projekt.
 * Alte Versionen der Manual:Developing extensions#Setup (vor Mai 2015) und beschreiben den alten Ansatz, Erweiterungsinformationen in PHP-Code und Variablen zu deklarieren
 * ist das Schema für  (und skin.json). Es gibt ein Werkzeug, das diese Dokumentation erzeugt.
 * RfC zur Umsetzung der Registrierung von Erweiterungen
 * Extension registration wall of superpowers! — summary of which extensions are still to be converted.
 * T98668 — Tracking ticket for converting all extensions and skins on Git to use extension registration.
 * RfC zur Umsetzung der Registrierung von Erweiterungen
 * Extension registration wall of superpowers! — summary of which extensions are still to be converted.
 * T98668 — Tracking ticket for converting all extensions and skins on Git to use extension registration.