Core Plugin

Core ist die Wurzel der WvdS-Paketfamilie: eine Dienst-Registry über DokuWikis Ereignisbus, über die sich die übrigen Pakete gegenseitig finden, und ein gemeinsamer Parser für beide Schreibweisen der Hausmarken. Es liefert selbst keine Oberfläche und keine eigene Marke. Gedacht ist das Paket für Plugin-Entwickler, die einen Dienst anbieten oder verbrauchen wollen, und für Verwalter, die prüfen, welche Dienste auf dieser Installation laufen.

Erste Schritte

Schnelleinstieg: Den ersten Dienst anmelden und abrufen — der kürzeste Weg zum ersten Ergebnis, in drei Schritten.

Laufende Dienste ansehen → Anbieter nachschlagen → Eigenen Dienst registrieren

Häufige Aufgaben

Was Sie wollen	Für wen	Wo Sie das tun	Anleitung
prüfen, welche Dienste registriert sind	Verwaltung	`do=wkcore_diag`	Diagnose
nachschlagen, welches Paket welchen Dienst anbietet	Entwickler	–	Wer was anbietet
einen eigenen Dienst anbieten	Entwickler	Ereignis `WKCORE_REGISTER_SERVICES`	Die Dienst-Registry
einen Dienst verbrauchen, ohne ihn fest zu verdrahten	Entwickler	–	Die Dienst-Registry
die beiden Schreibweisen der Hausmarken auseinanderhalten	Autor	–	Zwei Schreibweisen, ein Ergebnis
eine Einstellung ändern	Verwaltung	Konfigurationsmanager	Konfiguration

Zweck

Die Wurzel der WvdS-DW-Familie. Das Plugin liefert selbst keine Oberfläche und keine Syntax, sondern zwei Dinge, auf die alle anderen aufbauen:

eine Dienst-Registry über dem Ereignisbus von DokuWiki — kein Kern-Fork,
den gemeinsamen Parser für beide Schreibweisen unserer Seitenkonstrukte.

Ohne dieses Plugin finden die übrigen WvdS-DW-Plugins einander nicht; jedes fällt dann laut eigenem Vertrag auf schlichtes Verhalten zurück, statt zu scheitern.

Die Dienst-Registry

Ein Plugin trägt seine Dienste ein, indem es sich an das Ereignis WKCORE_REGISTER_SERVICES hängt; $event→data ist die Registry. Sie feuert einmal und träge — beim ersten Mal, wenn irgendjemand die Registry etwas fragt.

Aufruf	Bedeutung
`has('name')`	Ist der Dienst vorhanden? Immer zuerst fragen — ein Verbraucher darf nie annehmen, dass ein Anbieter installiert ist.
`get('name')`	Den Dienst holen. Bei einer Factory wird sie beim ersten `get()` ausgeführt und das Ergebnis gemerkt.
`register('name', $wert)`	Fertige Instanz oder Wert eintragen.
`registerFactory('name', $fn)`	Erzeugung aufschieben, bis der Dienst wirklich gebraucht wird.

Die Anmeldung überschreibt nicht. Melden zwei Plugins denselben Namen an, gewinnt das erste — statt dass eines das andere still verdrängt.

Wer was anbietet

Dienst	Anbieter	Inhalt
`core.info`, `core.ready`, `core.clock`, `core.context`	wkcore	Basisdienste
`storage.sqlite`	Storage Plugin	SQLite-Zugriff
`dwdo.storage`, `dwdo.repos`, `dwdo.export`	DevOps Storage Plugin	DWDO-Datenhaltung
`dwdo.context`, `dwdo.projects`, `dwdo.permissions`, `dwdo.hubs`, `dwdo.nav`	DevOps Core	DWDO-Domäne
`source.providers`	Source Viewer Plugin	Quell-Anbieter (`page`, `media`, `git`, `ado`)
`git.runner`	Git Plugin	gehärtete git-Ausführung
`ado.client`	Azure DevOps Connector	ADO-REST-Client
`ui.components`, `ui.icons`, `ui.tokens`	wkfluentui	Oberflächenbausteine

Zwei Schreibweisen, ein Ergebnis

Historisch wuchsen drei Notationen nebeneinander ({{wk:name>…}}, <wk:name …/>, ~~TOKEN~~), und welche ein Plugin nutzte, war eine Frage seines Entstehungsdatums. Die Entscheidung lautet: die DokuWiki-artige und die XML-artige Form sind überall gleichwertig. Beide dürfen geschrieben werden, beide ergeben dasselbe.

Dieses Versprechen hält nur, wenn ein Parser alle Plugins bedient — sechs handgeschriebene Paare driften beim ersten Sonderfall auseinander (ein Pipe in Anführungszeichen, ein leeres Attribut, ein mehrzeiliger Wert), und „gleichwertig„ würde still zu „ähnlich“.

XML-Form: ein Attribut je Parameter. Für einen Wert, der in einem Attribut nicht mehr lesbar ist, ein Kindelement gleichen Namens — das Kind gewinnt gegenüber dem Attribut, weil es die bewusstere Angabe ist.
DokuWiki-Form: {{wk:name>subjekt|schluessel=wert|…}}. Das erste Segment trägt keinen Schlüssel, weil es das Subjekt des Konstrukts ist (Medien-ID, Übersetzungsschlüssel, Snippet-Name). Der Parser liefert es unter _; welches eigene Attribut damit gemeint ist, weiß nur das Plugin.

XML-Eingabe ist Seitentext und damit überall dort angreiferbeeinflusst, wo das Wiki beschreibbar ist. Der Parser weist jede Eingabe mit DOCTYPE oder ENTITY rundweg ab, schaltet Netzwerkzugriff ab und setzt einen Null-Lader für externe Entitäten — externe oder aufgeblähte Entitäten können damit nie aufgelöst werden (XXE, „billion laughs„).

Verbraucher greifen über ein class_exists()-Gitter zu. Fehlt wkcore, behält ein Plugin seine ursprüngliche Notation und bietet die zweite schlicht nicht an — die alternative Schreibweise ist eine Zugabe, nie eine Voraussetzung.

Diagnose

?do=wkcore_diag zeigt die angemeldeten Dienste. Nützlich vor allem, um zu sehen, ob ein erwarteter Anbieter überhaupt registriert ist — der häufigste Grund für eine unerwartet schlichte Oberfläche ist ein deaktiviertes Anbieter-Plugin, nicht ein Fehler im Verbraucher.

Konfiguration

Keine. Das Plugin hat bewusst keine Einstellungen: eine Registry, die sich konfigurieren ließe, wäre eine zweite Stelle, an der über Verhalten entschieden wird.

Paketangaben

Plugin: wkcore
Namespace: lib/plugins/wkcore/
Autor: Wolfgang van der Stille Wolfgang.van.der.Stille@gmail.com (The White Knight Labs)
Lizenz: GPL 2