BizWay (Hausvorlage)

BizWay ist die Hausvorlage des Wikis: Farbtokens, drei Farbschemata, das Seitenraster beider Schalen, Kopf- und Fußbereich sowie die optionsgesteuerten Blöcke des öffentlichen Bereichs. Sie liefert Aussehen, keine Struktur — Verwaltungswerkbank, Regionen und Weiterleitungen gehören wkfluentui. Gedacht ist sie für Verwalter, die Erscheinungsbild und Seitentypen festlegen, und für Autoren, die Marker-Seiten und Abschnittsblöcke pflegen.

Schnelleinstieg: Die Vorlage aktivieren und einen Bereich trennen — der kürzeste Weg zum ersten Ergebnis, in drei Schritten.

Theme-Optionen setzen → Farbschema wählen → Bereichsprofil prüfen

Bis 2026-07-09 bestand das Bundle aus einer Vorlage (lib/tpl/wvdsbizway, reines Chrome/Layout/Skin) und einem Plugin (lib/plugins/wvdsbizway, Options-Store + Admin-Seite + Rendering-Logik). Beide Verzeichnisse existieren nicht mehr: die komplette Rendering-Logik wanderte in die Vorlage selbst, weil eine Vorlage in DokuWiki keine eigene Admin-Seite besitzen kann und ein Paar, das nur zusammen funktioniert, im Erweiterungsmanager auch nur zusammen installiert und aktiviert werden kann.

Das Begleit-Plugin wvdspremiumnavyivory hielt danach noch zwei DOKUWIKI_STARTED-Hooks und drei Helfer. Auch das ist seit 2026-08-01 aufgelöst: die Weiterleitungen liegen in wkfluentui, wo die Haken, die sie brauchen, hingehören; die Area-Auflösung ist in die Vorlage zurückgekehrt; der Style.ini-Abgleich lebt als Funktion in main.php. Der Grund, warum die Weiterleitung nie Vorlagencode sein konnte, gilt unverändert: DokuWiki bindet die aktive Vorlage erst ein, nachdem act_dispatch() die Aktion aufgelöst hat — für einen Redirect ist es dann zu spät. Nur ein Action-Plugin auf DOKUWIKI_STARTED kommt früh genug.

Die damalige Konstruktion: nur eine Richtung (Vorlage → Plugin), kein Rück-depends im Plugin, da das Plugin ohne Vorlage weiterhin folgenlos bleiben sollte (jeder plugin_load('helper', …)-Aufruf in der Vorlage war gegen ein fehlendes oder deaktiviertes Plugin abgesichert). DokuWikis Extension-Manager unterstützt dieses Feld offiziell (Extension::getDependencyList()/getDependants(), Installer.php soll damit Deinstallieren/Deaktivieren einer Extension blockieren, solange ein Dependant existiert) und erkennt außerdem jede plugin.info.txt/template.info.txt in einem gemeinsamen Release-ZIP unabhängig von diesem Feld automatisch als eigene Extension (Installer::findExtensions()) — ein Release-ZIP mit Template- und Plugin-Ordner als Unterordner installiert daher schon ohne das depends-Feld beide Extensions in einem Schritt.

Bekannter DokuWiki-Core-Bug (Version 2025-05-14b „Librarian“, lib/plugins/extension): Ein lokal — also nicht über das offizielle dokuwiki.org-Repository, sondern per *.info.txt auf dieser Instanz — gesetztes depends-Feld mit genau einem Wert wird von linesToHash() (inc/confutils.php) als String geparst, nicht als Array. Das bringt zwei Folgen mit sich, live gegen diese Instanz verifiziert (Playwright, Superuser-Login, do=admin&page=extension):

Konkret bedeutete das: solange die depends-Zeile gesetzt war, ließ sich das Plugin nicht mehr über die Erweiterungsverwaltung deaktivieren — der Klick wirkte entweder gar nicht oder zeigte eine Fehlerseite. Einziger funktionierender Weg war, die Zeile vorübergehend zu entfernen oder conf/plugins.local.php direkt im Editor zu bearbeiten (nicht über einen $plugin_controller-Aufruf aus einem Skript — bekanntes Korruptionsrisiko).

Die Einschränkung wurde damals bewusst in Kauf genommen: der Nutzen der formalen Sichtbarkeit wog höher als das Risiko. Kein Patch am DokuWiki-Kern — das widerspräche dem Grundsatz, den Kern dieser Instanz nie zu verändern, und müsste nach jedem Kern-Update erneut geprüft werden.

Was daraus bleibt: ein depends-Feld mit genau einem Wert ist in dieser DokuWiki-Version eine Falle. Wer es setzt, setzt es mit zwei Werten oder gar nicht — und prüft die Wirkung nicht im Info-Panel, sondern indem er das Deaktivieren tatsächlich versucht. Der stille Teil (HTTP 200 auf einer Fehlerseite, die jQuery als Erfolg liest) ist die eigentliche Gefahr: die Oberfläche meldet nichts.

Store: natives DokuWiki-Konfigurationssystem — lib/tpl/wkbizway/conf/default.php (54 Vorgabewerte) + conf/metadata.php (Feldtypen fürs Admin-Formular), Überschreibungen landen wie bei jeder anderen Kern-/Plugin-Einstellung in conf/local.php unter dem Schlüssel $conf['tpl']['wkbizway'][…]. Beschriftet sind alle 54 in fünf Sprachen (de/en/hr/it/sl).

Bis 2026-07-09 lagen dieselben Werte in einem eigenen JSON-Store (conf/wvdsbizway.json) mit eigener Admin-Seite und Remote-API (plugin.wvdsbizway.getOptions/setOptions). Diese Sonderlösung wurde ersatzlos entfernt: die Migration übernahm die zuletzt gültigen JSON-Werte 1:1 als neue conf/default.php-Vorgaben (siehe Kommentar dort), seitdem gilt für diese Optionen derselbe Schreibweg wie für jede andere Template-Einstellung:

• Verwaltung → Konfiguration (Konfigurationsmanager, nativer DokuWiki-Bildschirm, kein eigenes Dashboard mehr) — Abschnitt „wkbizway„
• Datei direkt — conf/local.php von Hand editieren (z. B. für Werte mit echten Zeilenumbrüchen)
• Es gibt keine eigene Remote-API mehr — die generische Core-Remote-API (core.getConf/core.setConf, sofern aktiv) deckt denselben Bedarf ab

Sicherheitsmodell unverändert gegenüber der alten JSON-Lösung: rawhtml-Felder (analytics, slideembed1/2, map_embed, customcss) werden unescaped ausgegeben (WP wp_head/wp_footer-Parität); einziger Schreibweg ist der Config Manager, der wie jede Core-Einstellung nur für den Superuser beschreibbar ist. Medien-IDs laufen durch cleanID() (CWE-22), interne/http(s)-Links durch eine Allowlist-Prüfung (CWE-79), siehe inc/wkbizway-render.php::wkbizway_media_src()/wkbizway_link_href().

Slider-/Feature-/Social-Felder sind globale Vorgaben; einzelne Namespaces können Hero/Features über eine Marker-Seite pro Namespace überschreiben (siehe „Marker-Seiten“ unten) — Hybrid-Modell: Admin-Optionen liefern den Standardfall, die Marker-Seite den lokalen Sonderfall.

DokuWikis eigene Vorlage setzt in den Fuß zwei Blöcke, div.license und div.buttons. Diese Vorlage führt beide unter denselben Klassennamen weiter – wer DokuWiki kennt, findet die Auszeichnung, die er erwartet.

Der Rechtehinweis war leer, und die Vorlage war nicht die Ursache. Am 6. August 2026 gemessen: der Fuß sagte in keiner Sprache etwas über Rechte – kein Copyright, keine Lizenz, kein Vorbehalt. Der Aufruf stand da und lieferte nichts, weil $conf['license'] auf 0 steht und tpl_license() eine nicht gewählte Lizenz mit einer leeren Zeichenkette beantwortet, in beiden Formen. Auf einer Firmenwebsite ist das dieselbe Klasse Lücke wie ein leeres Impressum: eine Abwesenheit, die wie eine Entscheidung aussieht.

Der Hinweis kommt jetzt aus drei Quellen, die spezifischste zuerst:

1. footertext, wenn gesetzt – der Betreiber hat es selbst gesagt.
2. eine konfigurierte DokuWiki-Lizenz, wenn vorhanden – wer CC wählt, meint es, und der Kern rendert sie übersetzt samt Abzeichen und Verweis.
3. sonst ein Rechtevorbehalt, gebaut aus Jahr und Seitentitel: © 2026 The White Knight Labs · Alle Rechte vorbehalten. Gebaut und nicht getippt – eine feste Jahreszahl ist jeden Januar falsch, ein fester Name am Tag der Umbenennung.

Die Wortwahl des dritten Falls ist ein Sprachschlüssel (rights_reserved), kein Literal: ein Rechtehinweis, den der Leser nicht lesen kann, ist keiner.

Die Abzeichenreihe trägt vier der fünf Abzeichen der mitgelieferten Vorlage: PHP, HTML5, CSS und DokuWiki. Der Spenden-Knopf entfällt auf ausdrückliche Entscheidung – er bittet einen Besucher einer Firmenwebsite um Geld für einen Dritten. Die Bilddateien liegen als Kopien unter assets/images/buttons/ und stammen aus der mitgelieferten DokuWiki-Vorlage (GPL-2.0-only); kopiert und nicht über deren Pfad eingebunden, weil ein Pfad in die Bestände eines fremden Pakets an dem Tag bricht, an dem jenes Paket aktualisiert oder entfernt wird.

Die Fußspalten gab es nur auf Deutsch. Über der Streifenzeile stehen die Spalten aus der Seite footerPage (Vorgabe footer), aufwärts gesucht wie das Menü. Es existierte nur de:footer; die vier übrigen Sprachen fielen auf die wikiweite Seite footer zurück, und deren gesamter Inhalt war eine Zeile <lastcomments count="5" /> – die Auszeichnung eines Plugins, das hier nicht installiert ist. DokuWiki scheitert an einem unbekannten Tag nicht, es maskiert ihn und druckt ihn: vier öffentliche Sites zeigten diese Zeile als Rohtext über ihrem Fuß, auf jeder Seite. Seit dem 6. August 2026 hat jede Sprache eigene Spalten, und die wikiweite Seite ist geleert – sie wäre nur noch von Seiten außerhalb jedes Sprachraums erreichbar, und es gibt keine Sprache, in der man ihre Überschriften schreiben könnte.

Ein Block, zwei Bereiche. Der Fußstreifen stand zweimal im Quelltext – einmal für den Seitenbereich, einmal für den Dokumentationsbereich –, als acht Zeilen, die gleich bleiben mussten und nichts hatte, was sie gleich hielt. Er kommt jetzt aus einer Funktion. Ein Rechtehinweis, der auf der einen Hälfte einer Website steht und auf der anderen nicht, ist schlimmer als keiner: die fehlende Hälfte bemerkt niemand.

Der Kopfbereich der site-Hülle zeigt zwei Dinge nebeneinander: die Bildmarke (logo) und den Seitentitel (DokuWikis $conf['title']). Ob beide zugleich richtig sind, entscheidet das Bildmaterial und nicht die Vorlage – ein Banner, das den Firmennamen ausschreibt, wiederholt ihn, sobald der Titel daneben steht; ein reines Emblem tut das nicht. Deshalb sind beide Teile einzeln schaltbar, und beide Vorgaben stehen auf an: eine Installation, die nichts setzt, sieht aus wie vorher.

Der Verweis behält in jedem Fall einen zugänglichen Namen. Er ist der Startseiten-Verweis mit der Zugriffstaste h; ein Verweis ohne Namen verstößt gegen WCAG 2.2 Erfolgskriterium 2.4.4. Solange der Titel sichtbar ist, benennt er den Verweis, und das Bild bleibt bewusst ohne alt-Text – sonst sagt eine Vorleseanwendung den Namen zweimal an. Fällt der Titel weg, übernimmt das Bild ihn in seinen alt-Text. Sind beide Teile aus, trägt ihn optisch verborgener Text: eine Zierde abzuschalten ist nicht dasselbe, wie den Startseiten-Verweis aufzugeben. Ist $conf['title'] selbst leer, kann hier kein Name entstehen – dann fehlt er, und die Vorlage erfindet keinen.

Zwei Dinge ändern diese Schalter nicht:

• Den Titel der Browser-Registerkarte. Er kommt aus $conf['title'] und ist von der Kopfdarstellung unabhängig – wer die Textmarke abschaltet, verliert den Namen also nicht aus der Lesezeichenliste.
• Die Wiki-Hülle. Ihr Kopfband führt eine eigene, kompakte Marke mit eigenem Medienpfad (:wiki:header-logo.svg bzw. .png) und einem Text-Rückfall, der den Seitentitel gar nicht verwendet; ein Titelschalter hätte dort nichts, worauf er wirken könnte.

Umgesetzt in inc/wkbizway-render.php::wkbizway_render_brand(). Die Funktion wird von main.php und detail.php gemeinsam benutzt. Vorher trug jede der beiden eine eigene Fassung, und die der Medienansicht hatte die Einstellung logo verloren: eine eingestellte Bildmarke erschien auf jeder Seite außer dieser. Nichts schlug dabei fehl – ein Kopfbereich, der nur den Namen zeigt, liest sich wie eine Gestaltungsentscheidung.

Die Landing- und die Namensraum-Index-Weiterleitung gehörten bis 2026-08-01 zum Begleit-Plugin dieser Vorlage. Sie liegen seitdem in wkfluentui, zusammen mit ihren fünf Einstellungen, und sind dort vollständig beschrieben: zusammenspiel_der_fuenf_einstellungen erklärt das Zusammenspiel, die Konfigurationsreferenz nennt Typ und Vorgabewert je Einstellung.

Warum sie nie Vorlagencode sein konnten: DokuWiki bindet die aktive Vorlage erst ein, nachdem act_dispatch() die Aktion aufgelöst hat. Zu diesem Zeitpunkt ist es für eine Weiterleitung zu spät; nur ein Action-Plugin auf DOKUWIKI_STARTED kommt früh genug. Eine Vorlage, die eine Weiterleitung verspricht, kann sie nicht halten.

Dasselbe Template rendert zwei grundverschiedene Seiten-Hüllen, abhängig vom Bereichsprofil der aufgerufenen Seite (wkbizway_resolve_area() in inc/area.php):

Die site-Hülle rendert keine Wiki-Möbel. Seiten-Werkzeuge, Site-Werkzeuge, die Seiteninformation (Dateiname und letzter Bearbeiter) und die Brotkrumenspur entfallen dort – für alle, auch für angemeldete Redakteure, und bei jeder Aktion, nicht nur beim Lesen. Der Marketing-Bereich ist eine Website; der Dateiname einer Seite und der Anmeldename dessen, der sie zuletzt angefasst hat, sind Angaben darüber, wie diese Site hergestellt wird, nicht darüber, was sie anbietet.

Redakteure verlieren damit nichts: der Eintrag „Diese Seite bearbeiten“ steht im Benutzermenü der Kopfleiste, sichtbar nur für Angemeldete mit Schreibrecht auf der aufgerufenen Seite. Auf do=edit, do=diff und jeder anderen Aktion wird daraus „Seite anzeigen„ – der Rückweg, den vorher die Werkzeugleiste bot.

Die Regel hängt an beiden Bedingungen: Profil site und enableAreaProfiles eingeschaltet (wkbizway_area_is_public_site()). Das ist kein doppelter Boden, sondern notwendig – bei abgeschaltetem enableAreaProfiles bekommt jede Seite das Profil site, und eine Prüfung allein auf das Profil nähme einer solchen Installation die Seitenwerkzeuge wikiweit, lautlos.

Auflösung: Die Einstellung siteNamespaces listet die Namensräume mit Seiten-Hülle, einen je Zeile. Eine Seite gehört dazu, wenn sie im Namensraum selbst oder irgendwo darunter liegt; bei mehreren Treffern gewinnt der längste, sodass ein engerer Eintrag später ergänzt werden kann, ohne auf die Zeilenreihenfolge zu achten. Alles Übrige bekommt die Docs-Hülle.

de:site
en:site

Leere Zeilen und Zeilen, die mit # beginnen, werden übergangen – so lässt sich neben einem Eintrag notieren, warum er dasteht. Eine Zeile, die kein plausibler Namensraum ist, wird verworfen statt gemeldet: ein Tippfehler kostet einen Eintrag, nie die Hülle der ganzen Site.

Namensraumgrenze, nicht Präfixvergleich: de:sitemap fällt nicht unter de:site, obwohl die Zeichenkette so beginnt. Verglichen wird an der Doppelpunkt-Grenze.

Das Bereichsprofil ist unabhängig vom Seiten-Layout (nächster Abschnitt): der Bereich entscheidet über die Hülle (site/wiki), das Layout über den Seitentyp innerhalb der site-Hülle. Liegt eine Seite im wiki-Profil, wird ihr Layout in main.php hart auf default erzwungen – Hero-, Gallery- und Contact-Markup wird dort nie gerendert, selbst wenn eine Hero-Markierungsseite zufällig darüber existiert.

Hero-Inhalt und Feature-Boxen konnten bis 2026-07-09 direkt als Auszeichnung in der jeweiligen Inhaltsseite stehen, verarbeitet von einem eigenen Syntax-Plugin. Dieses Plugin gibt es nicht mehr; dieselbe Schreibweise auf einer öffentlich sichtbaren Seite erschiene seitdem als unverarbeiteter Rohtext. Deshalb leben diese Deklarationen auf eigenen, nicht für Leser bestimmten Markierungsseiten, deren Rohtext direkt per regulärem Ausdruck ausgelesen wird (wkbizway_parse_marker_attributes()), ohne über den Seiten-Renderer zu laufen – die Markierungsseite selbst wird nie als Inhalt angezeigt.

Beide werden nach demselben Muster aufwärts gesucht: nächstgelegene <namensraum>:<markername>-Seite, sonst die bare <markername>-Seite an der Wiki-Wurzel, sonst „nicht vorhanden„.

Je Sprache eine eigene Markierungsseite. Seit dem 6. August 2026 gibt es hero und features fünfmal, unter de:site:, en:site:, sl:site:, hr:site: und it:site:. Sie tragen Text, und Text ist je Sprache verschieden – die Aufwärtssuche endet damit im eigenen Sprachraum, statt auf eine fremdsprachige Seite weiter oben durchzufallen.

Das Folienbild ist Hausgestaltung, die Bildunterschrift ist es nicht. Alle fünf Kopfbereiche verweisen auf dieselben zwei Bilddateien unter de:site:, während Überschrift, Bildunterschrift und Verweisziel je Sprache eigene sind. Das ist ein bewusster Zwischenstand: sobald echte Bilder vorliegen (Schieber 1920 × 770, Karten 600 × 300), ist zu entscheiden, ob sie in einen sprachneutralen Medien-Namensraum wandern. Bis dahin macht der deutsche Namensraum die Hausbilder faktisch zu seinem Eigentum.

Der Folienverweis braucht einen eigenen Namen. Er umschließt nur ein Bild mit leerem Alternativtext; die Bildunterschrift, die ihn erklärt, ist ein Geschwister dahinter, weil FlexSlider sie über das Bild legt. Am 6. August 2026 am gerenderten Bildschirm gemessen: vier Verweise im Karussell ohne jeden zugänglichen Namen – zwei Folien und die zwei Klone, die FlexSlider anhängt. WCAG 2.2 Erfolgskriterien 2.4.4 und 4.1.2, Stufe A, am ersten Bedienelement, dem ein Besucher begegnet. Der Renderer setzt seitdem die Bildunterschrift als aria-label des Verweises; fehlt sie, tritt der Seitenname des Ziels an ihre Stelle; fehlt auch der, wird das Bild ohne Verweis ausgeliefert – ein Verweis, den niemand benennen kann, ist schlechter als ein Bild, das niemand anklicken kann.

Eine area-Markierungsseite hat seit dem 4. August 2026 keine Wirkung mehr. Die bestehenden fünf wurden im selben Arbeitsschritt entfernt; ein Prüflauf des Repositories meldet es, falls wieder eine angelegt wird, denn eine wirkungslose Seite, die wie Konfiguration aussieht, ist schlimmer als keine.

Beispiel einer Hero-Marker-Seite (überschreibt nur die zweite Überschrift, alles andere fällt auf die globalen Admin-Optionen zurück):

{{wkbizway:hero heading2="Sicherheit, die mitdenkt"}}

Der Seitentyp einer Seite wird nicht mehr per Syntax deklariert, sondern per Namenskonvention bestimmt (inc/area.php::wkbizway_get_layout()) — aus demselben Grund wie bei den Marker-Seiten: ohne SyntaxPlugin gäbe es keinen Parser mehr, der ein page-eingebettetes {{wvdsbizway:layout type="..."}}-Tag verarbeiten könnte (dieser „layout“-Tag existierte nur bis 2026-07-09 und wurde nie auf eine Marker-Seite migriert, anders als area/hero/features oben — daher trägt er hier bewusst weiterhin den alten Namen).

fullwidth bleibt als gültiger Wert bestehen, hat aber keine Namenskonvention, die ihn auslöst (historisch, keine aktive Verwendung).

Ausnahme: <footercol>…</footercol>-Blöcke sind die einzige noch verbliebene, direkt in echtem Seiteninhalt stehende Syntax — weil wkbizway_render_footer_page() die konfigurierte Footer-Seite selbst ebenfalls per Roh-Regex liest (nicht über den normalen Renderer), funktioniert diese Container-Syntax weiterhin unverändert. Eine Footer-Seite mit vier <footercol>-Blöcken ergibt vier Footer-Widget-Spalten; keine ======-Überschriften innerhalb eines Blocks (nur Basissyntax), die fett gesetzte erste Zeile dient als Spaltentitel.

Das Aussehen der öffentlichen Seiten – Startseite, Leistungsseiten, Kontaktseite, die beiden Selbstbewertungen, deren Auswahlseite und die Referenzseite – liegt seit dem 6. August 2026 vollständig in lib/tpl/wkbizway/css/site-sections.css. Die Seiten selbst bestehen aus HTML-Bausteinen des Pakets wksnippet; diese tragen nur Markup und Klassennamen.

Vor dieser Trennung trugen die Bausteine ihr Aussehen als style-Attribute im Markup – gemessen 405 Stück, davon 299 allein auf den hier genannten Seiten. Das ist ein zweites Gestaltungssystem neben dem Token-Vertrag, und es versagt auf eine Art, die ein Stilblatt nicht hat: eine Formatierung im Markup ist für Schema, Haut, Akzent und Dichte unerreichbar. Sie hört still auf, zum Rest des Produkts zu passen, sobald eine dieser Achsen bewegt wird.

Zwei Bauformen sind dabei besonders teuer, weil sie keinen Fehler erzeugen:

• Ein eingebettetes <style> im Baustein wird von einer Prüfung auf style-Attribute nicht gesehen. Die beiden Selbstbewertungen trugen 1883 Byte davon, zeichengleich in zwei Dateien, und gestalteten damit Markup, das in einer dritten Datei steht.
• Ein on…-Attribut, das aus dem Markup heraus element.style schreibt. Auf der Auswahlseite der Selbstbewertungen standen vier davon; ihre Wirkung war zusätzlich nur mit der Maus auslösbar.

Beides ist heute maschinell ausgeschlossen. Der Prüflauf zählt die Bausteine des Bereichs und lässt keinen mit Stilblatt, Skript oder Ereignis-Attribut durch.

Auf hellen Flächen schreibt der öffentliche Bereich mit der gewöhnlichen Seitenfarbe. Es gibt genau eine Betonungsfläche, das dunkle Band, und Gold und Akzent sind Zierde – Haarlinie, Rahmen, Ikone –, nie eine Fläche unter Text. Der Grund steht in Zahlen im Kopf der Datei; die beiden Werte, an denen es hängt, sind Gold auf Weiß mit 3,20:1 und der Akzent auf Weiß mit 4,43:1, gegen die 4,5:1, die WCAG 2.2 Erfolgskriterium 1.4.3 für Fließtext verlangt.

Daraus folgt eine Konstruktion, die auf allen Seiten wiederkehrt: die Hauptaktion ist umgekehrt – helle Fläche, dunkle Schrift, 14,07:1 – statt gold gefüllt. Gold gefüllt scheitert in beide Richtungen, mit weißer wie mit dunkler Schrift.

Die Antwortknöpfe einer Selbstbewertung sehen aus wie Schaltflächen und sind in Wirklichkeit ein gewöhnliches Optionsfeld mit einer gezeichneten Hülle daneben. Das Feld ist unsichtbar gemacht, nicht entfernt: opacity: 0 auf einem absolut gesetzten Ein-Pixel-Kasten. Der Unterschied ist der ganze Punkt – display: none nimmt ein Bedienelement aus der Tabulatorreihenfolge und aus dem Barrierefreiheitsbaum. Genau das stand hier bis zum 6. August 2026: 30 Optionsfelder, keines davon fokussierbar, der gesamte Fragebogen ausschließlich mit einem Zeigegerät bedienbar (Erfolgskriterium 2.1.1, Stufe A).

Zwei weitere Festlegungen hängen daran:

• Der Auswahlzustand wird über input:checked + … ausgedrückt, also über den Nachbarschafts-Kombinator und nicht über :has(). Deshalb ist die Hülle ein Kind der Beschriftung. In einem Browser ohne :has() bliebe sonst gar keine Auswahl sichtbar, und ein Fragebogen, der die gegebene Antwort nicht anzeigen kann, ist schlechter als ein ungestalteter.
• Die gewählte Antwort unterscheidet sich nicht allein durch Farbe: das gezeichnete Optionsfeld füllt sich, also ändert sich die Form. Farbe als einziges Unterscheidungsmerkmal ist nach Erfolgskriterium 1.4.1 unzulässig.

Jede Frage ist eine <fieldset> mit <legend>. Damit gehört der Fragetext zum zugänglichen Namen jeder Antwort – ohne ihn hört ein Screenreader zehnmal „Ja, Teilweise, Nein„ ohne Bezug.

Die Arithmetik der beiden Selbstbewertungen steht in lib/tpl/wkbizway/script.js, nicht im Baustein: vorher lag sie zweimal dort, in zwei Fassungen, die sich in einem Variablennamen unterschieden. Die Fassung in der Vorlage bedient beide Checks; welcher gemeint ist, sagt das Attribut data-wk-sa am Fragebogen und am Ergebnisblock.

Zwei Werte stehen bewusst im Markup statt im Skript:

• Die Zahl der Fragen wird beim Auswerten aus dem Dokument gezählt. Die frühere Fassung führte eine Konstante 10 neben zehn Fragen; eine elfte hätte den Fragebogen dauerhaft ein Ergebnis schuldig bleiben lassen, ohne dass irgendetwas den Grund genannt hätte.
• Die Schwellen der drei Bänder stehen als data-wk-sa-min an dem Band, das den Bereich auch für den Leser benennt. Vorher stand jede Zahl zweimal da.

Ohne JavaScript sind die Fragen beantwortbar und die drei Bänder erklären, was ein Wert bedeuten würde; es fehlt allein die Rechnung. Vorher war der gesamte Ergebnisblock ausgeblendet, also sah ein Leser ohne Skript die Erklärung überhaupt nicht – und ein Leser mit Skript erst, nachdem er sich auf zehn Antworten festgelegt hatte.

Die Vorlage liefert eine Teilmenge von Font Awesome 4.7 aus und erklärt jeden Zeichennamen einzeln in css/icons.css. Ein nicht erklärter Name erzeugt keine Fehlermeldung: die Regel für den erzeugten Inhalt existiert schlicht nicht, das Element rendert null Pixel breit, und eine fehlende Ikone sieht aus wie eine, die niemand wollte. Am 6. August 2026 traf das 16 Namen – unter anderem waren dadurch fünf Personenkarten mit leerem Kreis und jede Telefonnummer mit unsichtbarer Markierung versehen. Wer einen neuen Namen benutzt, trägt ihn dort ein; der Prüflauf lässt keinen unerklärten mehr durch.

Der Bereich erscheint in fünf Sprachen. Seit dem 6. August 2026 tragen alle fünf dieselbe Bauform, und die Gleichheit ist keine Absichtserklärung, sondern eine Zusicherung des Prüflaufs site-area-probe.

Was die Startseite ist. Kopfbereich (Überschrift, Unterzeile, zwei Folien), drei Merkmalkarten, ein Vertrauensabschnitt, ein Abschluss mit einer Handlungsaufforderung. Kopfbereich und Karten kommen aus den Markierungsseiten hero und features, die beiden Abschnitte aus den Bausteinen trust_section und cta_final, die alle fünf Sprachen in einem einzigen Sprachschalter führen.

Was dabei entfallen ist. Neun Bausteine, die nur noch die vier fremdsprachigen Startseiten benutzten – Kompetenz-, Empathie-, Statistik-, Logo-, Leistungsraster-, Übergangs-, Referenz- und Kopfbereichs-Blöcke. Sie waren mit dem letzten Verbraucher zugleich der letzte Ort mit Formatierung im Seiteninhalt. Der Prüflauf hält seitdem fest, dass kein Baustein ohne Verbraucher zurückbleibt, den nicht jemand ausdrücklich benannt hat.

Gemessen am 24. August 2026 auf der Live-Instanz: fünf Sprachfassungen, und keine einzige Seite sagte einem Crawler, dass die anderen vier dieselbe Seite in einer anderen Sprache sind. rel=„canonical“ und <html lang> standen beide — nur beschreibt jedes von beiden eine Seite, und keines Gleichwertigkeit.

Seitdem gibt inc/hreflang.php zu jeder Seite des öffentlichen Bereichs den vollständigen Satz ihrer Sprachfassungen aus: die vier anderen, die eigene, und x-default auf die englische. Ausgegeben wird im Kopfbereich von main.php, nur wenn $bwPublicSite gilt und die Aktion show ist. Jede andere Aktion trägt ohnehin noindex, und ein Crawler, der hreflang auf ?do=edit anträfe, bekäme gesagt, ein Bearbeitungsformular sei die italienische Fassung einer Seite.

Warum das eine Tabelle ist und keine Regel. Drei der vierzehn Gruppen heißen in jeder Sprache anders:

Eine Ableitung nach „gleicher Name im Nachbar-Namensraum“ hätte für genau die Seiten nichts ausgegeben, auf denen ein Interessent Kontakt aufnimmt — und hätte dabei nichts gemeldet. Die elf Namen, die tatsächlich in allen fünf Sprachen gleich lauten, stehen deshalb in einer Liste, die drei abweichenden in einer zweiten, je eine Zeile.

Jeder ausgegebene Verweis ist mit page_exists() abgesichert. hreflang muss wechselseitig sein; ein Verweis auf eine Seite, die nicht antwortet, entwertet den ganzen Satz. Der Bestand ist nicht symmetrisch — de:site:projekte und den Blog gibt es nur auf Deutsch — und er wird es nicht werden.

Die Markierungsseiten hero und features sind ausgenommen. Sie sind Bausteine, die andere Seiten einbinden, und keine Ziele.

Dieselbe Liste speist seit dem 25. August 2026 auch eine sichtbare Sprachwahl. Bis dahin standen die fünf Sprachen ausschließlich als <link rel="alternate"> im Kopfbereich des Dokuments — für Suchmaschinen. Im gesamten Rumpf kam auf keiner Breite ein Verweis auf en:, it:, hr: oder sl: vor: ein Leser konnte die Sprache nicht wechseln, weder am Schreibtisch noch am Telefon. Bemerkt worden war das nicht, weil ein Crawler tadellos bedient wurde.

Die Existenzregel — im Index und page_exists() und mehr als eine überlebende Fassung — liegt dafür in wkbizway_hreflang_alternates() und hat jetzt zwei Verbraucher statt einem. Zwei Kopien davon würden auseinanderlaufen, und die Richtung, in die sie auseinanderlaufen, wäre ein sichtbarer Verweis auf eine Seite, die es nicht gibt.

Die Wahl steht als ein Steuerelement in der Dienstleiste der Kopfzeile, neben dem Konto-Symbol: ein Globus mit dem Kürzel der aktuellen Sprache, der ein Menü mit den Eigennamen öffnet. Im geschlossenen Zustand ist das Kürzel eine Platzkonvention und trägt den vollen Namen als zugänglichen Namen daneben; im geöffneten Menü steht das Wort ausgeschrieben, nach dem ein Leser sucht. Die aktuelle Sprache ist dort kein Verweis, sondern Text mit aria-current — ein Verweis auf die Seite, auf der man steht, ist eine kleine Unwahrheit.

Nicht in der Menüleiste, und das ist gemessen und nicht gewählt: eine erste Fassung setzte fünf dauerhafte Kürzel-Schaltflächen dorthin. .menu-inner steht auf nowrap mit fest 960 px Inhaltsbreite, und ihre Kinder belegten bereits genau 960 px. Die zusätzlichen rund 175 px lösten sich über das einzig Nachgiebige auf — die Navigationsliste brach auf eine zweite Zeile, in Englisch und Slowenisch sichtbar, in Deutsch mit 21 px Reserve knapp nicht. Ein Leser sah es auch in Deutsch. Fünf Dauerschaltflächen in einer Hauptnavigation behandeln außerdem eine Entscheidung, die ein Leser einmal trifft, wie einen Bereich der Website.

Das Aufklappen benutzt dieselbe Umsetzung wie das Konto-Menü — Umschalten, Klick außerhalb, Esc mit Fokusrückgabe, aria-expanded im Gleichschritt. script.js führt dafür eine Liste von Auslöser-Panel-Paaren statt eines fest verdrahteten Paares und schließt beim Öffnen die jeweils anderen: zwei offene Klappen in dieser schmalen Zeile überlappen sich, und die untere nimmt Klicks entgegen, die der oberen galten.

Der Prüflauf site-area-probe hält in Abschnitt 19 fest, dass jede Gruppe wechselseitig ist, dass keine auf weniger als zwei vorhandene Seiten schrumpft und — der einzige Test, der Drift findet — dass kein Seitenname, den es in mehr als einer Sprache gibt, in der Tabelle fehlt.

Option colorscheme. Ein Schema ist eine Datei lib/tpl/wkbizway/css/schemes/<name>.css mit zwei Hälften (seit dem 10.08.2026): die neutralen Werte auf :root → html verschoben und damit Rückfall, die Markenwerte weiter auf :root und damit Übersteuerung (Styles-Contract, siehe Styles-Contract (--wk-*)) — die zulässigen Werte im Admin-Formular werden automatisch aus den vorhandenen Dateien in diesem Ordner ermittelt (conf/metadata.php), keine Hand-Pflege einer Liste nötig.

Seit 2026-07-10 gibt es genau drei Schemata, die drei offiziellen WvdS-Marken-Akzente (analog zu den drei offiziellen „MED NAMI“-Facebook-Vorlagen desselben Brand-Eigentümers):

• riviera (Standard, vormals navy-ivory) — Ivory-Grund, Navy/Steel-Azure als Akzent, Gold als Rahmenfarbe. Passend für ruhige, vertrauensbildende Site-Inhalte.
• night — vollflächig dunkle Navy-Leinwand, Gold als vorherrschende Link-/Typografiefarbe, Goldrahmen, keine Haarlinie. Passend für schwerere, autoritätsbetonte Site-Inhalte.
• white — helle, nahezu weiße Leinwand, dieselbe Akzentfamilie wie riviera, aber Navy-Rahmen statt Gold. Rote Haarlinie wie bei riviera.

Es gibt kein Schema namens default mehr — vor der Umbenennung war das BizWay-Originalblau der Standard (default.css), diese Datei wurde beim Rebranding durch navy-ivory.css/heute riviera.css ersetzt. Die drei früheren, markenfremden WP-BizWay-Farboptionen green/red/meadow (reine 1:1-Ports der zehn WP-Farbvarianten) wurden bei dieser Gelegenheit entfernt.

Wichtige Ausnahme — Wiki-Bereich immer white: Das Area-Profil wiki (siehe Abschnitt „Area-Profile: site vs. wiki“ oben) rendert ausnahmslos mit dem Schema white, unabhängig vom Wert der Option colorscheme (main.php, Abschnitt „color scheme“: $bwScheme = $bwArea['profile'] === 'wiki' ? 'white' : (string)tpl_getConf('colorscheme');). Die colorscheme-Konfiguration wirkt sich also ausschließlich auf das Area-Profil site aus — eine Änderung dieser Einstellung verändert niemals das Erscheinungsbild des Wiki-Bereichs.

Marken-Haarlinie (nur Wiki-Bereich): Jedes der drei Schemata definiert zusätzlich den Extension-Token –wk-brand-hairline (dünne Trennlinie, bei night transparent). Er wird von der Komponente css/brand-accent.css konsumiert: eine zusätzliche Haarlinie unter der Wiki-Kopfzeile im Wiki-Profil. Details und Token-Tabelle: Styles-Contract (--wk-*).

Roter Rahmenstreifen (Site-Bereich): Der obere Rahmenstreifen der Site-Seitenhülle (#dokuwiki__top.site) ist fest rot (–wk-error), unabhängig vom aktiven Farbschema — der einzige Akzent im Site-Header. Nutzerkorrekturen 2026-07-10 (zwei aufeinanderfolgende Sichtprüfungen): Eine frühere Fassung dieser Komponente zeichnete zusätzlich ein Gold-Wellenband mit Haarlinie an der Nahtstelle zwischen Kopfzeile (.header-container) und Menüleiste (.menu-container) sowie einen schemaabhängigen (Gold/Navy) oberen Rahmenstreifen — das wirkte zunächst „zu viel Gold“, nach Entfernen des Wellenbands wirkte eine rote Linie direkt an dieser Nahtstelle immer noch nicht stimmig. Beides ist jetzt entfernt: keine Akzentlinie mehr an der Header/Menü-Nahtstelle, stattdessen der eine rote Streifen ganz oben auf der Seite. Der frühere Token –wk-brand-frame hat seitdem keinen Verbraucher mehr und wurde aus allen drei Schema-Dateien entfernt.

Ivory-Identitätszonen (unabhängig vom Farbschema): Die Kopfzeile (.header-container), der Landing-Hero (.slider-wrapper-container) und die Wiki-Kopfzeile (.wkbizway-topbar, seit dem 10.08.2026 ausgenommen — sie folgt der erhabenen Stufe der aktiven Welt, weil ihre Schriftfarben es tun und ein festes Elfenbein unter einem dunklen Schema 1,05:1 ergab) zeigen denselben festen Ivory-Hintergrund (#F7F5EF), nicht das schemaabhängige –wk-paper/–wk-surface.

DW-Contract-Sync (style.ini): Neben dem –wk-*-Kontrakt oben kennt DokuWiki einen zweiten, unabhängigen Farbkontrakt: die [replacements]-Platzhalter in style.ini (__text__, __link__, __theme_color__ usw.), die als @ini_*-LESS-Variablen von jedem Plugin konsumierbar sind, nicht nur von –wk-*-Verbrauchern. Bei Einführung der drei Farbschemata (2026-07-10) wurde dieser zweite Kontrakt zunächst übersehen und zeigte weiterhin die alte, nicht mehr aktive BizWay-Palette.

wkbizway_sync_style_ini_replacements() in main.php (aufgerufen bei jeder Anfrage; die Funktion lag von 2026-07-12 bis 2026-08-01 als Helfer im Begleit-Plugin und ist mit dessen Auflösung hierher zurückgekehrt) gleicht das automatisch ab: die lokale Override-Datei conf/tpl/wkbizway/style.ini wird — nur bei tatsächlicher Abweichung — neu geschrieben und enthält dann genau die elf Platzhalter, die tatsächlich schemaabhängig sind (__text__, __background__, __background_alt__, __background_neu__, __border__, __highlight__, __link__, __background_site__, __theme_color__, __text_neu__). Alle anderen Platzhalter (__existing__, __missing__ und die __*_width__-Layout-Werte) bleiben unverändert aus der mitgelieferten lib/tpl/wkbizway/style.ini wirksam.

Seit dem 10.08.2026 kommen die Werte aus der aktiven Haut, nicht mehr aus den Stilblättern dieser Vorlage. Die Brücke las sie zuvor per Mustersuche aus css/tokens.css und den Schemadateien — seit der Übergabe der Neutralen ist das die Rückfallschicht, sie veröffentlichte also die Palette einer Konfiguration, die niemand fährt. Sie fragt jetzt das Design-System-Plugin nach der Neutralen-Rampe der aktiven Welt und bildet die DokuWiki-Platzhalter auf Rollen ab (Grund, erhabene Fläche, versenkte Fläche, Regel, Tinte, gedämpfte Tinte); nur die drei akzenttragenden Platzhalter kommen weiter aus den eigenen Deklarationen dieser Vorlage. Ein Wert, der kein Farbliteral ist, wird abgewiesen — er landet in LESS-Arithmetik und in einem theme-color-Metatag, und ein var(…) überlebt beides als Zeichenkette, die nichts bedeutet.

__text_alt__ war bis dahin ausdrücklich nicht im Abgleich und stand damit dauerhaft auf dem Auslieferungswert #999999 — 2,85:1 auf Weiß, während DokuWikis eigenes LESS ihn an elf Stellen liest. Die Begründung stimmte über den Namen und ging über die Rolle fehl: der Wert ist per Wertabgleich die gedämpfte Tinte, und die ist eine Rampenrolle wie jede andere. Er wird jetzt mit abgeglichen.

Wichtig für den Betrieb: manuelle Einträge in conf/tpl/wkbizway/style.ini werden bei der nächsten Anfrage überschrieben, sobald sie von der konfigurierten Erscheinung abweichen — die Datei gilt als automatisch verwaltet.

Die Brücke bekommt seit dem 10.08.2026 die konfigurierte Schemaeinstellung und nicht die der gerade gerenderten Seite. Die beiden sehen austauschbar aus und sind es nicht: der Seitenwert ist bereichsabhängig, diese Datei ist installationsweit, und sie ist eine Cache-Abhängigkeit des Stilblatt-Bauers. Mit dem Seitenwert kippte sie bei jedem Wechsel zwischen Dokumentations- und Seitenbereich, und jeder Kippvorgang baute das gesamte Stilblatt-Bündel neu — gemessen 0,07 s warm gegen 0,89 s nach einem Bereichswechsel. Die Folge ist benannt statt entdeckt zu werden: dieser Vertrag kann zwei Bereiche nicht ausdrücken. Steht der Seitenbereich auf night, folgt DokuWikis eigene Chrome dem Seitenbereich, während der Dokumentationsbereich hell darum herum rendert. Die mitgelieferte lib/tpl/wkbizway/style.ini bleibt davon unberührt.

• Horizontale Menüleiste: nearest-page-Vererbung über die Option navPage (Vorgabe nav), gerendert als verschachtelte Liste mit Hover-/Fokus-Flyouts. Das Home-Icon links außerhalb der Leiste ist fest in main.php verankert, kein Bestandteil der nav-Seite selbst.
• Eine nav-Seite je Sprache, seit 2026-08-06. Findet die Aufwärtssuche keine, zeichnet main.php eine Leiste mit einem Eintrag – dem Home-Verweis. Bis zu diesem Datum existierte nur de:nav; die englische, slowenische, kroatische und italienische Startseite boten ihren Besuchern also genau diesen einen Verweis, und die drei Merkmalkarten auf der Seite waren der einzige Weg irgendwohin. Es schlug dabei nichts fehl und es wurde nichts protokolliert: eine Leiste mit einem Eintrag liest sich als bewusst sparsames Menü, nicht als Seite, die niemand geschrieben hat. Ein Prüflauf hält seitdem fest, dass jede konfigurierte Sprache des Bereichs eine Menüseite hat und dass kein Menüeintrag ins Leere zeigt.
• Dynamisches Flyout: Ein Zusatz-Untermenü wird automatisch in die gerenderte nav-Seite eingefügt, sofern die passende Startseite existiert — die Blog-Kategorien unter <Sprache>:site:blog:start (benötigt das Plugin wkblog). Gebaut und eingefügt wird es von inc/nav.php im Template selbst; 30 Minuten gecacht, und der Cache-Schlüssel enthält die Gruppenzugehörigkeit des Besuchers, damit ein ACL-gefilterter Baum nicht aus dem Cache einer Gruppe an eine andere gerät. Der Cache hängt zusätzlich an data/meta/wkblog.sqlite3, damit ein neu gesetztes Schlagwort nicht bis zu 30 Minuten unsichtbar bleibt.
• Kategorien ja, einzelne Beiträge nein, seit 25. August 2026. Unter jeder Kategorie hing bis dahin ihre Beitragsliste, jeder Eintrag mit voller Überschrift. Am gerenderten Bild bei 390 px gemessen: 22 Einträge, drei Ebenen gleichzeitig offen, 1105 px Menühöhe in einem 900 px hohen Sichtfeld — das Menü lief also über, bevor der letzte Bereich erreicht war, und vier der Einträge waren zweizeilige Artikelüberschriften. Danach 17 Einträge und 783 px, damit erstmals vollständig im Sichtfeld. Eine Kategorie ist Struktur und bleibt; ein Beitrag ist eine einzelne Seite, veraltet und wird in seinem Bereich gefunden. inc/nav.php liest seitdem nur noch die Kategorienamen. Eine Leerprüfung steht dort bewusst nicht, weil getCategoryTree() die Leseberechtigung prüft, bevor es den Schlüssel anlegt — eine Kategorie ohne lesbaren Beitrag taucht gar nicht erst auf, und eine Prüfung, die nie auslösen kann, liest sich wie ein Fall, den jemand erlebt hat.
• Eigener Umbruchpunkt der Leiste bei 1023 px, seit 25. August 2026. Die Leiste liegt in .container_24 und ist damit auf höchstens 980 px festgelegt; ihr Inhalt bleibt gleich, während sie nach unten hin enger wird. Was hineinpasst, entscheidet deshalb nicht die Fensterbreite, sondern die Länge der Beschriftungen — und die hängt an der Sprache. Gemessen in Slowenisch, der längsten der fünf: Navigationsliste 599 px, daneben Home 50 px, Suchfeld 162 px und der Rand des eingeklappten Umschalters 12 px. Daraus bleiben bei 1024 px 157 px Reserve, bei 900 px noch 57 px; bei 820 px fehlen 23 px und bei 768 px fehlen 75 px. Der Hamburger erschien bis dahin erst bei 767 px, weshalb genau auf dem alten Umbruchpunkt die ungünstigste Breite lag: der Platz war fort und das Schubfach noch nicht da. css/mobile.css schaltet die Leiste deshalb bereits ab 1023 px vollständig ins Schubfach; der übrige Inhalt der Datei bleibt bei 767 px, denn das ist die Breite, ab der die Seite eine Telefonseite wird. 1024 px und nicht 900 px, obwohl 900 noch getragen hätte: 57 px sind weniger als ein Menüeintrag. Dieselbe Stufe schaltet ohnehin die Wiki-Shell, es kommt also kein weiterer Umbruchpunkt hinzu. style.ini nennt seitdem dieselben Werte — die Platzhalter __tablet_width__ und __phone_width__ standen auf 800 px und 480 px und deckten sich mit keiner einzigen Medienabfrage dieser Vorlage; wkacmenu hatte ihnen geglaubt und seine Berührungsregeln danebengelegt. Der tragende Grund ist aber nicht die Zahl 57, sondern ihre Herkunft. Sie gilt für Slowenisch, und Slowenisch ist die längste Sprache von heute. Sie hängt an fünf Beschriftungen, die jederzeit umbenannt werden können, und an einer sechsten Sprache, die es noch nicht gibt. Ein Umbruchpunkt, der von der Wortlänge eines Menüeintrags abhängt, ist kein Umbruchpunkt, sondern eine Wette. 1024 px ist von der Sprache unabhängig, weil es unterhalb der Breite liegt, ab der die Leiste überhaupt eng wird — deshalb wäre 900 px auch dann nicht gewählt worden, wenn die Reserve dort 150 px betragen hätte.
• Überlaufregel: einzeilig, solange es mit Reserve geht, darunter vollständig ins Schubfach — nicht „umbrechen, wenn es eng wird“. Der Umbruch war der vorherige Zustand und entstand ungewollt: die Menüeinträge tragen white-space:nowrap, also ist flex-wrap auf der Liste das einzig Nachgiebige im ganzen Kasten, und ein zweiter Streifen liegt außerhalb der 45 px hohen Bitmaptextur von .menu-container. Die Regel steht als Kommentar an .menu_wrapper ul in css/design.css, zusammen mit der gemessenen Reserve je Sprache und einer Untergrenze von 100 px für alles, was künftig in diese Leiste soll. Abgenommen wird die Reserve, nicht der Augenschein: eine Fassung mit 21 px Reserve galt im Prüfstand als einzeilig und brach im Browser eines Lesers, weil der Unterschied zweier Schriftrasterungen größer war als der Rest. Diese Untergrenze ist eine Verabredung, keine erzwungene Regel: sie steht als Kommentar an .menu_wrapper ul in css/design.css, zusammen mit der Reserve je Sprache. Keine Stilregel prüft sie, kein Prüflauf bricht daran ab. Wer etwas in diese Leiste einbaut, misst sie von Hand nach — in allen fünf Sprachen, bevor er einbaut.
• Was hier nicht mehr steht, und warum: Bis zum 24. August 2026 wurden zusätzlich der volle Wiki-Seitenbaum unter <Sprache>:wiki:start und der Projektbaum unter <Sprache>:projects:start eingehängt, beide über wkacmenu. Gemessen brachte das 199 Dokumentationsseiten in 42 Ordnern und den internen Arbeitsbereich (Plugins, Repositories) in die Menüleiste des öffentlichen Auftritts – ein Besucher traf das Entwickler-Wiki, bevor er das Angebot sah. Die beiden Menüpunkte „Dokumentation„ und „Projekte“ stehen weiterhin in der nav-Seite und führen dorthin; nur der aufklappende Baum darunter ist fort. Der Blog-Baum ist nicht derselbe Fall und bleibt: seine Einträge sind veröffentlichte Kategorien, also genau das, was jemand sucht, der „News„ anklickt.
• nav-flyout.js (nur auf site-Profil-Seiten geladen): löst ein reines CSS-Problem großer, generierter Flyout-Panels (z. B. 20+ Wiki-Namespaces) — overflow/max-height auf einem Flyout-Panel würde auch tiefer verschachtelte, absolut positionierte Untermenüs abschneiden. Statt overflow blendet das Skript bei zu langen Panels nur ein Fenster aufeinanderfolgender Einträge ein und ergänzt kleine Pfeil-Buttons zum Verschieben dieses Fensters.

Vier-Spalten-Layout im Stil von Google-Developers/Microsoft-Learn-Dokumentationsseiten, gerendert anstelle der BizWay-Site-Hülle, sobald das Area-Profil wiki ist — ab 1024px Breite kommt eine fünfte Spalte hinzu (siehe „Rechte TOC-Rail“ unten):

[Linke Action Rail] [Doc-Sidebar] [Hauptinhalt] [Seiten-Inhaltsverzeichnis] [Rechte TOC-Rail]

• Linke Action Rail (Option wikiEnableLeftActionRail): Bearbeiten/Verlauf/Backlinks/Medien/Admin/Login sowie ein Sichtbarkeits-Umschalter (Sidebar ein-/ausblenden) sind hier statt in einer separaten „Seitenwerkzeuge„-Leiste untergebracht. Der TOC-Umschalter lebt seit 2026-07-13 nicht mehr fest hier, siehe „Rechte TOC-Rail“ unten.
• Doc-Sidebar (Option wikiEnableDocSidebar), dreistufiger Fallback: (1) explizite wikiSidebarPage-Seite, aufwärts gesucht, aber begrenzt auf die eigene Area-Wurzel (wkbizway_area_find_bounded_page() in inc/wiki-shell.php — anders als DokuWikis eigenes page_findnearest(), das unbegrenzt bis zur Wiki-Wurzel sucht und dabei fälschlich die site-weite globale Sidebar treffen würde, bevor Stufe 3 überhaupt zum Zug käme); (2) wkacmenu im ns=auto-Modus (ACL-bewusste automatische Namespace-Navigation); (3) ein Hinweistext, sichtbar nur für Nutzer mit Schreibrecht auf die aktuelle Seite, wenn beides fehlt.
• Seiten-Inhaltsverzeichnis (Option wikiEnablePageToc): eine leere TOC (kurze Seite ohne Überschriften) blendet die Spalte komplett aus, statt sie leer anzuzeigen.
• Rechte TOC-Rail (seit 2026-07-13, .wkbizway-action-rail–right, id dokuwiki__tocrail): spiegelbildliche Icon-Spalte zur linken Action Rail, nur ab 1024px Breite gerendert ($wikiEnableToc && $wikiTocHtml !== '' && !$wikiIsAdminScreen-Bedingung in inc/wiki-shell.php) und trägt bisher ausschließlich den TOC-Sichtbarkeits-Umschalter. Unterhalb von 1024px — wo für ein zweites Rail-Spalte kein Platz mehr ist und die Desktop-TOC-Spalte ohnehin durch das mobile Inline-TOC ersetzt wird — fällt derselbe Umschalter auf seine ursprüngliche Position in der linken Action Rail zurück (zweite DOM-Kopie desselben Buttons, id=„wiki-toc-toggle-mobile“ statt id=„wiki-toc-toggle-rail“; css/wiki-layout.css zeigt per Breakpoint nie beide Kopien gleichzeitig). js/wiki-area.jss initDrawer() akzeptiert seitdem ein oder mehrere Trigger-Buttons statt genau eines und hält aria-expanded auf allen aktuell im DOM vorhandenen Kopien synchron.
• Spalten-Abstände (asymmetrisches Margin-Ownership-Modell, seit 2026-07-13): Zwei Tokens in css/tokens.css steuern die Abstände der fünf Spalten: --wk-wiki-gap (1.25rem/20px, im Breakpoint 1024–1279px auf 1rem/16px reduziert; bis zum Nutzer-Feedback vom 2026-07-13 doppelt so groß) als Lesabstand an den Hauptinhalt-Kanten und --wk-wiki-gap-rail (0.75rem/12px, in keinem Breakpoint verändert) an den rail-zugewandten Kanten (Action-Rail↔Doc-Sidebar links, Seiten-TOC↔TOC-Rail rechts) — die 52px schmalen Icon-Rails brauchen keinen Lesabstand; das frühere uniforme 40px-Gap ließ dort einen optisch toten weißen Korridor stehen (Canvas, Panels und Rails teilen dieselbe Hintergrundfarbe). Technisch liegen die Abstände nicht auf der Grid-gap-Property (die reserviert ihren Wert auch neben zur Laufzeit auf 0px kollabierten Spalten), sondern als Margins der beiden kollabierbaren Spalten Doc-Sidebar/Seiten-TOC; beim Einklappen (sidebar-collapsed/toc-collapsed) fallen deren Margins auf 0 und der Hauptinhalt übernimmt an der Rail-Kante genau den einen --wk-wiki-gap-rail-Abstand (css/wiki-layout.css, @media (min-width: 1024px)-Block mit Erläuterungskommentar). Die Außenkanten der Shell sind ab 1024px bündig (horizontales Padding 0 — beide Icon-Rails liegen wie die VS-Code-/Azure-Data-Studio-Activity-Bar direkt an der Viewport-Kante); unterhalb 1024px gilt weiterhin 1em Randabstand (bzw. 16px unter 768px), weil die Rail dort zur horizontalen Leiste wird und der Inhalt einen Lesabstand zum Rand braucht.
• TOC-Flattening (seit 2026-07-13, css/dokuwiki-overrides.css): Hat der Seiten-TOC genau einen Level-1-Eintrag, ist das (bei toptoclevel=1, Instanz-Default) immer ein Duplikat des direkt daneben sichtbaren H1-Seitentitels — seine Titelzeile wird per CSS versteckt und die Kindliste beginnt ohne Einzug (Muster „On this page„ der Google-Developers-Doku); zusätzlich entfällt das horizontale Core-Padding des #dw__toc-Wrappers. Level ≥3 behält den relativen 1em-Einzug. Zwei Schutzbedingungen: :only-child lässt Mehr-H1-Seiten unberührt, :not(.mode_admin) lässt Admin-TOCs unberührt (deren einziger Level-1-Eintrag ist ein echtes Label, kein Titel-Duplikat — z. B. die „Datenbank:“-Beschriftung über der sqlite-Datenbankliste). Es wird nur die Titelzeile versteckt, nie eine Kindliste — kein Eintrag kann verloren gehen. Wirkt bewusst auch auf das mobile Inline-TOC (gleiches Markup, gleiche Redundanz).
• wikiStickyHeader / wikiStickySidebars: Kopfzeile bzw. Action-Rail/Doc-Sidebar/TOC/TOC-Rail bleiben beim Scrollen sichtbar (nur Desktop-Breite).
• wiki-area.js (nur auf wiki-Profil-Seiten geladen): öffnet/schließt Doc-Sidebar-Drawer, Action-Rail und mobiles TOC-Drawer, inklusive Escape-zum-Schließen, ARIA-Wiring und optionaler Merkfunktion des Offen/Zu-Zustands über localStorage.
• Die beiden Ansichts-Umschalter stehen unterhalb 768 px offen in der Leiste und tragen ihren Text, seit 25. August 2026. Der Namensraumbaum war auf dem Telefon erreichbar, aber nicht auffindbar. Die Kette wurde bei 390 px angeklickt und nach jedem Schritt nachgezählt: im Ruhezustand misst die Doc-Sidebar 358 × 0 px bei neun ausgelieferten Baumzeilen und keiner sichtbaren; nach dem Werkzeug-Knopf unverändert 358 × 0; erst nach dem Seitenleisten-Knopf 358 × 542 px mit allen neun Zeilen. Zwei Taps also, beide hinter Symbolen: der erste 38 × 40 px groß und für ein Vorleseprogramm „Seiten-Werkzeuge„ — das verspricht Werkzeuge, nicht Seiten —, der zweite 52 × 52 px und „Seitenleiste“, was das Gefäß benennt und nicht seinen Inhalt. Auf einem Berührungsbildschirm gibt es keinen Tooltip, der das nachreicht. Die beiden Ansichts-Umschalter kommen deshalb hinter dem Werkzeug-Knopf hervor; die Seiten- und Site-Aktionen bleiben dahinter, weil sie auf die eine Seite wirken und „was liegt sonst noch in diesem Bereich„ das häufigere Anliegen ist. Danach gemessen: der Knopf ist ohne vorherigen Tap sichtbar, misst 95 × 44 px und öffnet mit einem Tap neun Baumzeilen zu je 52 px.
• Beschriftung „Seiten“ statt „Seitenleiste„. Der Umschalter stand auf dem Kernstring $lang['sidebar']. Das ist ein Begriff aus dem Aufbau der Vorlage, kein Begriff der Lesenden — derselbe Fehler, den der Hamburger der site-Hülle mit nav_toggle schon einmal bekommen hat. Die Vorlage führt dafür wiki_sidebar_toggle in allen fünf Sprachen. Kurzform, weil der Knopf auf dem Telefon direkt neben wiki_toc_toggle steht: „Seiten“ neben „Auf dieser Seite„ sagt in zwei Wörtern, dass der eine den Baum des Bereichs öffnet und der andere die Gliederung dieser einen Seite. Die Beschriftung trägt dabei nicht die Klasse a11y: DokuWiki erklärt dort jede Eigenschaft für wichtig, sodass kein Selektor den Text für die schmale Darstellung zurückholen kann. Die Leiste hat ihre eigene, übersteuerbare Fassung desselben Verstecks, und die genügt einem Vorleseprogramm genauso.
• Trefferflächen über --wk-touch-min, nicht über eigene Zahlen. Der Name ist die einzige Zusicherung der Suite für eine Trefferfläche; wkfluentui setzt ihn auf 40 px und unter (pointer: coarse) auf 44 px. Eigene Zahlen an der Verbrauchsstelle sind genau die Spaltung, die den Namen vorher unzuverlässig gemacht hatte — er war einmal mit 32 px definiert und wurde in fünf fremden Paketen mit dem Rückfallwert 40 px aufgerufen, sodass die Trefferfläche davon abhing, welche Stylesheet-Datei zufällig auf der Seite lag. Wo die Datei nicht geladen ist, gilt der Rückfallwert 44 px, weil das der Telefonfall ist.

Kopf- und Fußzeile (Logo, Benutzer-Menü, Footer-Widgets, Lizenzzeile, Social-Icons) sind bewusst identisch zur site-Hülle aufgebaut — nur der Bereich zwischen Kopf- und Fußzeile unterscheidet sich, damit die Marke über beide Profile hinweg konsistent wirkt. Konkretes Beispiel dieser Konsistenz: Der runde Avatar-/Benutzer-Menü-Button oben rechts im Header (.premiumnavyivory-user-menu-toggle) misst in beiden Hüllen einheitlich 48px — css/design.css für die site-Hülle, css/area-wiki.css für die Wiki-Area-Shell (behoben 2026-07-10: die site-Hülle zeigte zuvor eine 72px große Button-Kachel um ein bereits 48px großes Avatarbild, sichtbar als weißer Ring).

Der Admin-Bereich läuft seit 2026-07-09 durchgehend über DokuWikis eigenes, natives Admin-Chrome (Konfigurationsmanager, ACL-Manager, Benutzerverwaltung, Erweiterungsverwaltung) — keine eigene, WordPress-gestylte „BizWay Admin“-Oberfläche mehr. Grund: Ein eigenständiges Admin-Dashboard kann in DokuWiki ausschließlich über ein AdminPlugin bereitgestellt werden; mit der Auflösung des Options-Plugins in Richtung native Vorlagen-Konfiguration entfiel damit zwangsläufig auch die Grundlage für ein eigenes Dashboard.

Die folgenden, früher auf dieser Seite dokumentierten Bestandteile existieren nicht mehr im Code — wer danach sucht, sucht nach etwas, das absichtlich entfernt wurde, kein Hinweis auf einen Dokumentationsfehler:

• Eigenes WP-Look'n'Feel-Admin-Dashboard („BizWay Admin„) mit Top-Bar/Seitenmenü und Umschalter zur klassischen DokuWiki-Admin-Ansicht.
• Fest verdrahtetes WordPress-Admin-Farbschema (admin-chrome.css, dunkle Sidebar, Blau-Akzent #2271b1), unabhängig vom gewählten colorscheme.
• Clientseitige Tabellen-Anreicherung im Admin-Bereich (Sortierung per Spaltenklick, Freitext-Filter über User-Manager/ACL/Extension-Karten).
• Benutzer-Flyout-Detailkarte im User-Manager (Klick auf eine User-ID).
• „+ Neu“-Content-Erstellungs-Drawer in der Top-Bar (Namespace-Baum, Editor-Wahl, Sofort-Speichern von Markdown-Stubs, Blog-Eintrag-Anlage).
• Eigener Admin-Media-Picker.

Statt eines eigenen Dashboards restyled css/_admin-forms.css das unveränderte native Admin-Markup rein strukturell, ohne eine einzige Core- oder Core-Plugin-Datei zu berühren — reine additive CSS-Kaskade über Selektor-Spezifität und Ladereihenfolge (nach dem unveränderten Core-Partial css/_admin.less, vor der Design-Ebene, siehe style.ini). Gestaltungssprache angelehnt an Microsoft Fluent/Azure-DevOps/Windows-Settings (nur Struktur, keine neuen Farben oder Schriftarten — ausschließlich bereits vorhandene –wk-*-Tokens aus Styles-Contract (--wk-*)):

• Felder: Label über dem Eingabefeld, klein/halbfett, gedämpfte Textfarbe — dieselbe Konvention wie bei den Auth-Formularen (css/_forms.css).
• Fieldsets/Panels als weiße Karte (–wk-surface/–wk-border, abgerundet, mit Innenabstand); Legenden/Panel-Header halbfett mit dünnem Trenner.
• Einstellungszeilen (Config Manager, ACL-Baum): volle Breite mit dünner Trennlinie, Hover über –wk-admin-hover statt vollflächiger Farbfüllung; Status wie „geschützt„ oder „Validierungsfehler“ bekommt einen 3px-Akzentbalken links plus Badge statt einer Volltonfarbe — der Normalfall („Wert entspricht dem Standard„) bleibt bewusst unauffällig.
• Tabellen/Listen (User-Manager, ACL-Baum): DataGrid-Optik, nur horizontale Trennlinien, keine Zellgitter, gedämpfte halbfette Kopfzeile.

Wichtiger Unterschied zur alten Lösung: Der Admin-Akzent folgt jetzt dem gewählten colorscheme (über die Tokens –wk-admin-accent/-accent-light/-hover, die zuvor definiert, aber von keiner CSS-Regel gelesen wurden) — bewusste Abkehr vom früheren „Admin sieht immer gleich aus, egal welches Farbschema die Site nutzt“.

Vom alten script.js der Admin-Erweiterungen ist nur die Gallery-Lightbox über .wkbizway-gallery-Rastern (Seitentyp gallery, s. o.) als eigenständiges, weiterhin genutztes Stück übrig geblieben.

Auf Admin-Bildschirmen (do=admin) füllt sich dieselbe linke Icon-Spalte, die auf normalen Wiki-Seiten die Seiten-Werkzeuge trägt (Abschnitt „Wiki-Area-Shell„ oben, .wkbizway-action-rail), jetzt mit einer VSCode/Azure-Data-Studio-artigen Aktivitätsleiste aller Admin-Module, die der angemeldete Benutzer laut ACL erreichen kann — statt dort wie zuvor leer/eingeklappt zu bleiben. Option wikiEnableAdminActionBar (Standard: an, ohne Wirkung, wenn wikiEnableLeftActionRail bereits aus ist).

• Modul-Liste: helper_plugin_wkfluentui_adminrail::getAdminRailItems() (Plugin wkfluentui, generisch/template-unabhängig — seit 2026-07-12 nicht mehr Template-Code, siehe FluentUI: Öffentliche Helper-API) bildet dieselbe Auswahl-/Sortierlogik wie DokuWikis eigene Admin-Übersichtsseite nach (dokuwiki\Ui\Admin::getPluginList(), dort protected und daher nicht direkt aufrufbar) — dieselbe ACL-Prüfung (isAccessibleByCurrentUser()/showInMenu()), dieselben drei Gruppen (admin/manager/other), dieselbe Sortierung. Das aktuell geöffnete Modul wird als aktiv markiert (Akzent-Balken links).
• Neuanordnung: Icons lassen sich per Maus (natives HTML5-Drag-and-Drop) oder Tastatur (Alt+Pfeil-hoch/Alt+Pfeil-runter bei fokussiertem Icon, inklusive Sprachausgabe-Ansage) neu anordnen — js/admin-rail.js, nur auf Admin-Bildschirmen geladen.
• Persistenz: Die gewählte Reihenfolge wird ausschließlich clientseitig in localStorage gespeichert, mit einem je Benutzer-Login skalierten Schlüssel (kein neues serverseitiges Datenformat, analog zu VS Code/Azure Data Studios eigener, ebenfalls rein clientseitiger Activity-Bar-Anordnung). Welche Module überhaupt erscheinen, bleibt davon unberührt und vollständig serverseitig durch die ACL-Prüfung bestimmt — ein manipulierter localStorage-Wert kann höchstens die Anzeigereihenfolge verändern, nie ein nicht erlaubtes Modul sichtbar machen.

Der Admin-Bereich kennt zusätzlich zur strukturellen Fluent-Optik oben eine dritte Dimension: eine 3-Farben-Aktionssemantik für Buttons, unabhängig vom sitweiten primär(blau)/sekundär(Outline)-Kontrakt aus css/design.css (der weiterhin unverändert Login/Profil/Wiki-Editor bedient). Vollständige Token-/Klassen-Referenz: Contract v3.

• Neutral/weiß — jede gewöhnliche Aktion, ausdrücklich inklusive Speichern. Anders als beim sitweiten Formular-Kontrakt gibt es im Admin-Bereich keinen automatisch hervorgehobenen „Haupt-CTA“ mehr.
• Blau (accent) — Sonderaktionen: Export, Datei-Import, Konvertierung.
• Rot (danger) — destruktive/sicherheitsrelevante Aktionen: Löschen, Zurücksetzen.

Referenzumsetzung: wkidentity (WvdS-eigenes Plugin, PHP editierbar — Klasse direkt im Markup) sowie usermanager (Toolbar-Gruppierung mit Trennlinien: weiß→blau→rot, DOM-Reihenfolge nicht nur Farbe) und die übrigen 9 mit DokuWiki mitgelieferten Admin-Screens (ACL, Config, Extension, Logviewer, Styling, Popularity, Revert, Discussion, SQLite — ID-/Attribut-gescopte CSS-Regeln, da deren PHP nicht editiert wird).

Im selben Feature zusätzlich nachgebessert: Titel-Dopplungen auf mehreren Screens (Logviewer, UserManager, Extension Manager, Discussion), das im Normalzustand ungestylte „Benutzer hinzufügen“-Panel des UserManagers (nur im No-JavaScript-Fallback wirksam — die JS-aktivierte Drawer-Ansicht war bereits korrekt gecardet), die Post-Revert-Bestätigungsliste, das ACL-Regel-Fieldset sowie die Admin-Basis-Schriftgröße (13px→14px) und eine konsolidierte Monospace-Token-Referenz (–wk-admin-font-mono).

Nach dem ersten Praxiseinsatz der Admin-Aktions-Farbsemantik meldete der Auftraggeber acht konkrete Bugs/UX-Wünsche:

• Config Manager: drei simulierte Spalten (Name/Beschreibung/Wert) mit auf der gesamten Seite garantiert identischer Breite (feste statt flexible Flex-Basen) und align-items:flex-start je Zeile (Flexbox-Äquivalent zu vertical-align:top).
• Styling Manager: die vier Aktions-Buttons wandern per neuem js/styling-toolbar.js aus drei <p>-Zeilen unterhalb der Farbtabelle in eine Command-Bar oberhalb — „Auf Standard zurücksetzen“ (löscht laut runRevert() tatsächlich alle lokalen Anpassungen) rot, die übrigen drei neutral.
• UserManager: der „Hinzufügen“/„Speichern“-Button hatte nie eine eigene Farbregel und blieb blau; der CSV-Upload-Datei-Input war komplett unstyled; die Grid- Navigationsbuttons (Anfang/Vorherige/Nächste/Ende) waren blau und ohne Icon — alle drei behoben.
• Logviewer: Datum-Formular, Tab-Leiste und die von script.js injizierte Filterzeile hatten keine gegenseitige Ausrichtung — auf ein Fluent-Unterstrich- Tab-Muster (Vorbild wkidentity) umgestellt, gescoped auf #plugin__logviewer (die geteilte css/_tabs.css-Komponente selbst bleibt unverändert, andere Konsumenten wie der Extension Manager sind nicht betroffen).
• Discussion: die Status-Combobox (bare <select>, kein class=„edit“) erhielt dieselbe Feldmetrik wie die übrigen Admin-Formularfelder.
• sqlite — bemerkenswertester Einzelfund: „nur Text sichtbar, keine Funktionalität“ war kein Plugin-Bug, sondern eine Template-Lücke: lib/plugins/ sqlite/admin.php implementiert getTOC() (DokuWikis eigener, in tpl_toc() bereits vorgesehener Mechanismus für eine Admin-Screen-Datenbankliste), aber inc/wiki-shell.php rief tpl_toc() nie für $ACT==='admin' auf. Nach der Korrektur zeigte sich ein zweiter Teilbefund: die Desktop-TOC-<aside> ist ein standardmäßig geschlossenes Drawer-Element (.is-open wird normalerweise per Rail-Toggle-Icon gesetzt) — Admin-Bildschirme haben aber gar kein solches Icon (die Admin-Aktivitätsleiste ersetzt das normale Rail vollständig), weshalb is-open für Admin-Bildschirme jetzt serverseitig direkt mitgerendert wird.
• wkidentity: ein gemeldeter „wieder blauer Button“ erwies sich beim Live-Test in einer frischen Browser-Session als bereits korrekt gefärbt — Root Cause war ein fehlender Cache-Buster in action.php::injectAssets()s admin.css-Link (siehe wkidentity), kein CSS-Bug.
• Extension Manager (nur untersucht, kein Fix): die bereits bekannte RuntimeException: Invalid remote data hat einen doppelten Root Cause — ein Namespace-Catch-Typ-Mismatch in DokuWikis eigenem lib/plugins/extension/ GuiAdmin.php (Core-Plugin, nicht zu editieren) plus eine fehlende curl.cainfo/ openssl.cafile-Konfiguration in dieser PHP-Umgebung (direkte curl-Erreichbarkeit von dokuwiki.org ist gegeben, das PHP-eigene HTTPS-Verhalten ist ohne CA-Bundle inkonsistent) — beides außerhalb des Änderungsbereichs dieses Templates.

Menüleisten-Textur, Slider-Schatten, Sidebar-/Footer-Textur und der Datums-Badge auf Blog-Einträgen sind unverändert die Original-PNG/JPG-Grafiken aus dem BizWay-WordPress-Theme (lib/tpl/wkbizway/assets/images/, GPL laut readme.txt des Originals), Variante -blue. Bekannte Grenze, weiterhin bestehend: diese Bitmaps sind fest blau eingefärbt und folgen nicht dem gewählten colorscheme — bei keinem der drei Marken-Akzente (riviera/night/white) recolort sich die Menüleisten-/Sidebar-/Footer-Textur. Passende Bildvarianten pro Schema sind ein offenes, noch nicht terminiertes Vorhaben. Die Brand-Accent-Komponente (siehe Abschnitt „Farbschemata“) umgeht diese Grenze bewusst, statt sie zu beheben: die Haarlinie wird als eigenständiges, token-eingefärbtes CSS-Element auf der Kopfzeile gezeichnet, nicht als Versuch, die feste blaue Bitmap-Textur farblich zu treffen.

Arimo self-hosted als Variable Font (woff2, wght 400–700, latin + latin-ext für sl-Diakritika, SIL OFL 1.1) → echtes Bold/Italic, keine synthetische Fettung. Token: –wk-font-body/-heading/-display; der WP-Original-Slot „Museo 500“ wird bewusst nicht mitgeliefert (Lizenzgründe) und fällt wie im Original auf Arimo zurück.

PHP-Syntaxprüfung direkt per CLI (C:\PHP\8.3\php.exe -l) plus HTTP/Browser-Smoke-Tests gegen den jeweiligen Dev-Server (aktuell localhost:8880 primär, localhost:8800 Altbestand) — Seiten sowie css.php/js.php mit purge=true.

Cache-Falle (richtiggestellt 2026-07-10): Der tseed-Cache-Buster in der css.php/js.php-URL wird in DokuWikis Core-Funktion tpl_metaheaders() (inc/template.php) als MD5-Hash über die Änderungszeitpunkte (filemtime()) mehrerer Dateien gebildet — nicht nur über conf/tpl/premium-navy-ivory/style.ini, sondern über alle Dateien der Config-Kaskade main (inc/config_cascade.php): conf/dokuwiki.php, conf/local.php und conf/local.protected.php, zusätzlich style.ini. Die eigentlichen Template-CSS-/JS-Quelldateien (css/*.css, assets/js/*.js) fließen nicht in diesen Hash ein — reines Bearbeiten dieser Dateien ändert den tseed also nicht, wodurch Browser (css.php/js.php senden Far-Future-Expires-Header) weiterhin die alte, zwischengespeicherte Fassung ausliefern.

Abhilfe: Nach jeder Template-CSS-/JS-Änderung eine beliebige Datei der Config-Kaskade mit neuem Zeitstempel überschreiben, z. B. touch conf/local.php (mtime-Änderung reicht, Dateiinhalt bleibt unverändert) — das ändert die css.php/js.php-URL im Seiten-HTML (&tseed=…) und ein normaler Reload genügt für alle Browser. Alternativ: Nutzer macht Hard-Refresh (Strg+F5), umgeht den Browser-Cache aber nur für diesen einen Browser, ohne den tseed selbst zu ändern. Verifikation, dass wirklich frisches CSS ausgeliefert wird: curl gegen die aktuelle css.php-URL aus dem Seiten-HTML und die betroffene Regel darin grep(pen).

Frühere Fassung dieses Abschnitts behauptete fälschlich, conf/local.php wirke sich nicht auf den tseed aus und nur style.ini zähle — das widerspricht dem oben zitierten Core-Quellcode und wurde empirisch widerlegt (per curl-Vergleich des kompilierten CSS vor/nach touch conf/local.php).

• 2026-08-25: Die Sprachwahl ist aus der Navigationsleiste in die Dienstzeile des Kopfbereichs gezogen und dort ein Aufklapp-Steuerelement (Globus mit dem aktuellen Kürzel, inc/hreflang.php). In der Leiste hatte sie rund 175 px gekostet, die dort nicht frei waren: die Leiste brach in Englisch und Slowenisch auf zwei Zeilen, in Deutsch hielt sie mit 21 px Reserve im Prüfstand und brach im Browser eines Lesers. Die Leiste hat seitdem einen eigenen Umbruchpunkt bei 1023 px, eine benannte Überlaufregel und eine verabredete Mindestreserve. Abgenommen in fünf Sprachen über sieben Breiten von 390 px bis 1920 px, gegen die Live-Instanz, am gerenderten Bild.
• 2026-08-06 (Fußbereich): div.license und div.buttons wieder aufgenommen, unter DokuWikis eigenen Klassennamen. Auslöser war eine Rückmeldung des Nutzers, die Vorlage habe vom Fuß der DokuWiki-Seite „eine Menge abgeschnitten„; nachgemessen war die Ursache eine andere: der Aufruf der Lizenzzeile stand seit jeher da und lieferte nichts, weil keine Lizenz konfiguriert ist. Der Fuß sagte damit in keiner Sprache etwas über Rechte. Jetzt: eigener Fußtext, sonst konfigurierte Lizenz, sonst ein aus Jahr und Seitentitel gebauter Rechtevorbehalt in fünf Sprachen. Die Abzeichenreihe trägt vier der fünf Abzeichen (ohne Spenden), abschaltbar über die neue Einstellung footerbuttons. Dabei fiel auf, dass der ganze Fußstreifen dreimal im Quelltext stand – Seitenbereich, Wiki-Bereich und Medienansicht –, und die dritte Kopie war die ärmste: sie trug die Namensnennung der Software und nichts über Rechte. Er kommt jetzt aus einer Funktion; gefunden hat die dritte Kopie die neue Zusicherung, nicht ein Blick. Ebenfalls in diesem Zug: die Fußspalten gab es nur auf Deutsch, die vier übrigen Sprachen zeigten stattdessen die Auszeichnung eines nicht installierten Plugins als Rohtext; und die Reihe der Social-Ikonen hatte keine einzige Stilregel und erschien als aufgezählte Liste mit Punkt und 40 Pixeln Einzug.
• 2026-08-06: Der öffentliche Bereich ist in allen fünf Sprachen gleich gebaut. Die englische, slowenische, kroatische und italienische Startseite sind von zehn bis elf Blöcken auf dieselben vier Abschnitte gebracht wie die deutsche; dafür haben die vier Sprachen erstmals eigene hero- und features-Markierungsseiten bekommen. Die neun Bausteine, die danach keinen Verbraucher mehr hatten, sind entfernt – mit ihnen die letzten 124 Formatierungsangaben und 130 Ersatzwerte im Seiteninhalt. Dabei kamen drei Befunde ans Licht, die niemand gemeldet hatte: die vier fremdsprachigen Sites hatten überhaupt kein Menü (nur de:nav existierte; die Vorlage zeichnet dann eine Leiste mit dem Home-Verweis, was wie ein sparsames Menü aussieht), die Folienverweise des Kopfbereichs hatten keinen zugänglichen Namen (WCAG 2.2, Stufe A, in allen fünf Sprachen), und die Richtungspfeile des Schiebers ebenfalls nicht – script.js setzt prevText/nextText absichtlich leer, damit das Zeichen der Stilvorlage sichtbar wird, und leer heißt eben auch namenlos. Alle drei behoben; die Klone, die FlexSlider für den nahtlosen Umlauf anhängt, sind zusätzlich aus der Tabulatorreihenfolge genommen. Sechzehn Seiten in hr:site: und it:site: nennen sich seither beim Namen statt mit ihrer Kennung, und verlorene diakritische Zeichen in kroatischen und italienischen Texten (drzi, sto, racunala ugroiavaju, conformita) sind wiederhergestellt. Der Prüflauf site-area-probe ist von 17 auf 25 Zusicherungen gewachsen und misst seitdem auch die Bausteine der Schale, Bausteine ohne Verbraucher und die Menüseite je Sprache; sechs Gegenproben in beide Richtungen.
• 2026-08-04: Seite von de:wiki:dwe:premiumnavyivory hierher verschoben — samt Attic, Changelog und allen eingehenden Verweisen, in allen fünf Sprachen. Anlass war kein Aufräumen, sondern ein toter Link: die url-Zeile in template.info.txt zeigte auf de:wiki:dwe:wkbizway, und genau diesen Verweis bietet DokuWikis Erweiterungsverwaltung dem Betreiber als Dokumentation der Vorlage an. Die Seiten-Kennung trug bis dahin den Namen des Plugins, das es seit 2026-08-01 nicht mehr gibt. Im selben Durchgang: Kopf, Aufbau-Abschnitt, Theme-Optionen, Farbschemata, Style.ini-Abgleich und Wiki-Shell auf die heutigen Pfade und Präfixe (lib/tpl/wkbizway, wkbizway_/.wkbizway-) gezogen; der Weiterleitungs-Abschnitt ist nach zusammenspiel_der_fuenf_einstellungen gewandert, weil die Weiterleitungen dorthin gewandert sind — er stand hier als einzige Beschreibung eines Mechanismus, den diese Vorlage nicht mehr besitzt. Die Vorlage hat außerdem erstmals eine eigene README.md samt fünf docs/-Dokumenten bekommen und ist seither Prüfling der Abnahmetore, für die sie zuvor unsichtbar war (sie führt ihr Manifest als template.info.txt, die Tore suchten ausschließlich plugin.info.txt).
• 2026-08-03: Paketumbenennung des Hauses: Vorlage premium-navy-ivory → wkbizway, Funktions- und Klassenpräfix premiumnavyivory_ → wkbizway_, CSS-Klassen .premiumnavyivory- → .wkbizway-, Marker-Syntax {{wkbizway:…}} → {{wkbizway:…}}. Dabei blieb einmal ein Aufruf umgeschrieben und die Datei nicht (inc/wkbizway-render.php): jede Seite lieferte einen Fatal, während 1062 Prüfungen grün meldeten und beide CSS-Bündel HTTP 200 gaben — css.php lädt main.php nie. Seitdem gehört zu jeder Umbenennung ein echter Seitenabruf, nicht nur der Bündel-Abruf.
• 2026-08-01: Begleit-Plugin wvdspremiumnavyivory aufgelöst. Weiterleitungen samt ihren Einstellungen nach wkfluentui, Area-Auflösung zurück in die Vorlage, Style.ini-Abgleich als Funktion in main.php. Damit entfiel auch die depends-Zeile und mit ihr die weiter oben dokumentierte Kern-Falle.
• 2026-07-13 (Abstände Runde 2): Auf Nutzer-Feedback zum Ergebnis der vorherigen TOC-Gap-Anpassung: Shell-Außenkanten ab 1024px bündig (horizontales Padding 0, VS-Code-/ADS-Muster; darunter unverändert), Lesabstand --wk-wiki-gap halbiert (2.5rem→1.25rem, 1279px-Override 1.75rem→1rem); Rail-Gap und Kollaps-Mechanik unverändert. Live vermessen: 0/12/20/20/12/0 bei 1920px, 0/12/16/16/12/0 bei 1120px. Zusätzlich die eckigen Mat-/Karten-Ecken aus der vorherigen Regression wiederhergestellt (border-radius: 0 an vier Stellen in css/area-wiki.css) — der ursprüngliche Fix lag ausschließlich auf dem nie gemergten Branch bugfix/083 und ging beim Branch-Wechsel auf master live verloren („ADO-Closed ≠ live gemergt“); jetzt per Cherry-Pick im regulären Arbeits-Branch.
• 2026-07-13: Horizontale Platzverschwendung im TOC-Bereich behoben: neues Token --wk-wiki-gap-rail (0.75rem/12px) macht das Margin-Ownership- Modell asymmetrisch — Lesabstand 40px (bzw. 28px bei 1024–1279px) nur noch an den Hauptinhalt-Kanten, 12px an den rail-zugewandten Kanten inkl. Kollaps-Verhalten (css/tokens.css, css/wiki-layout.css). Zusätzlich TOC-Flattening in css/dokuwiki-overrides.css: redundanter Level-1-Eintrag (Seitentitel-Duplikat) versteckt, Kindliste ohne Einzug, Wrapper-Padding entfernt; Ausnahmen :only-child (Mehr-H1-Seiten) und :not(.mode_admin) (Admin-TOCs, z. B. sqlite-„Datenbank:„-Label). Details Abschnitt „Wiki-Area-Shell“ oben. Live vermessen (Playwright): Gaps 12/40/40/12 bei 1440px, 12/28/28/12 bei 1120px, Kollaps-Zustände 12px an der Rail; Gegenproben Mehr-H1-Seite, Admin-TOC, mobiles Inline-TOC.
• 2026-07-13: Rechte TOC-Rail ergänzt (.premiumnavyivory-action-rail–right, id dokuwiki__tocrail), spiegelbildlich zur linken Action Rail, ab 1024px Breite als fünfte Grid-Spalte (css/wiki-layout.css, –wiki-tocrail-col). Der TOC-Sichtbarkeits-Umschalter zieht dort hinein um; unterhalb von 1024px fällt er auf seine ursprüngliche Position in der linken Action Rail zurück (zweite DOM-Kopie desselben Buttons, js/wiki-area.jss initDrawer() unterstützt seitdem mehrere Trigger-Buttons pro Drawer statt genau eines). Page-TOC- und ACMenu/Doc-Sidebar- Schriftgröße von 0.85em auf feste 13px umgestellt (Font-Family unverändert über var(–wk-wiki-font-body)). Details Abschnitt „Wiki-Area-Shell„ oben. Verifiziert per php -l, node –check sowie Playwright über alle vier Breakpoints (>=1280px, 1024–1279px, 768–1023px, <768px), inkl. localStorage-Zustands- synchronisation zwischen beiden Button-Kopien.
• 2026-07-12: Komponenten-SoC-Refactoring: Business-/ACL- Logik, die seit der wvdsbizway-Auflösung (2026-07-09) im Template selbst lag, verschoben in Helper-Komponenten. inc/routing.php und inc/area.php gelöscht — ihr Inhalt lebt jetzt als helper_plugin_wvdspremiumnavyivory_{routing,area} im eigenen Plugin (behebt die zuvor invertierte Abhängigkeit: wvdspremiumnavyivory/action.php lud vorher aktiv Template-interne Dateien nach). main.phps Style.ini-Sync-Funktionen wurden zu helper_plugin_wvdspremiumnavyivory_styleini. Admin-Rail-Enumeration, Galerie-Datenlogik, Nav-Fragment-Orchestrierung und Avatar-Initialen-Berechnung (zuvor dupliziert zwischen main.php und inc/wiki-shell.php) wanderten in das neue, generische, template- unabhängige Plugin wvdsfluentui (siehe FluentUI (Design-System-Bibliothek)), das außerdem site-weite –wk-*-Token-Defaults über DokuWikis Plugin-CSS-Bundling liefert — ein Template-Wechsel bricht seitdem das Erscheinungsbild anderer WvdS-Plugins (z. B. wvdstotp) nicht mehr. Reines Refactoring, keine Verhaltensänderung; jeder plugin_load()-Aufruf ist null-tolerant. Vollständige Methodenverträge: FluentUI: Öffentliche Helper-API.
• 2026-07-12: Acht Nutzer-Feedback-Punkte nach dem ersten Praxiseinsatz der Admin-Aktions-Farbsemantik behoben (Details Abschnitt „Admin-Bereich“ oben): Config-Manager-3-Spalten-Layout, Styling-Manager-Toolbar, UserManager-Restlücken (Speichern-Button/Upload/Grid-Navigation), Logviewer- Tab-Neugestaltung, Discussion-Combobox, sqlite-Datenbankliste (Page-TOC- Reaktivierung) sowie die Untersuchung der Extension-Manager-Fehlermeldung (Root Cause dokumentiert, kein Fix möglich).
• 2026-07-11: Admin-Aktions-Farbsemantik eingeführt (Details Abschnitt „Admin-Bereich„ oben): drei verbindliche Button-Farben (neutral/blau/rot), Referenz- umsetzung wvdstotp + usermanager-Toolbar-Gruppierung, Nachbesserung von 7 bereits „geschlossen“ markierten Admin-Screens (Titel-Dopplungen, ungestyltes UserManager-Add- Formular im No-JS-Fallback, Post-Revert-Liste, ACL-Fieldset), erste Fluent-Abdeckung für discussion/sqlite, Admin-Basisschriftgröße 13px→14px, neuer –wk-admin-font-mono-Token. Vollständiger Contract: Styles-Contract (--wk-*).
• 2026-07-11: Ungewollter horizontaler Scrollbalken an sticky Action Rail/Doc-Sidebar/ Page-TOC behoben: overflow-y: auto allein ließ den Browser die unspezifizierte overflow-x-Achse spec-konform ebenfalls zu auto auflösen (CSS Overflow Module Level 3), wodurch der wenige Pixel breite vertikale Scrollbalken selbst genug Überlauf erzeugte, um dauerhaft einen funktionslosen horizontalen Scrollbalken einzublenden — betraf sowohl die neue Admin-Aktivitätsleiste als auch die bestehende Seiten-Werkzeugleiste auf normalen Wiki-Seiten. Fix: overflow-x: hidden in css/wiki-layout.css explizit ergänzt, vertikales Scrollen bleibt unverändert funktionsfähig. Verifiziert per getComputedStyle()-Messung vor/nach Fix auf beiden betroffenen Bildschirmtypen.
• 2026-07-11: Admin-Aktivitätsleiste ergänzt (Abschnitt „Admin-Bereich“ oben): Die linke Icon-Spalte der Wiki-Area-Shell zeigt auf Admin-Bildschirmen jetzt eine VSCode/Azure-Data-Studio-artige, per Drag-and-Drop oder Tastatur frei anordenbare Aktivitätsleiste aller erreichbaren Admin-Module, statt dort leer/eingeklappt zu bleiben. Neue Option wikiEnableAdminActionBar (Standard: an). Verifiziert per Playwright (eingeloggt) über vier Bildschirme (Konfigurations-Manager, Admin-Übersicht, Benutzerverwaltung, normale Wiki-Seite).
• 2026-07-11: DW-Contract-Sync ergänzt: main.php schreibt conf/tpl/premium-navy-ivory/style.ini (Abschnitt „Farbschemata" oben) ab sofort automatisch passend zum aktiven Farbschema, statt der bis dahin stale mitgelieferten BizWay-Palette. Nur bei tatsächlicher Abweichung wird geschrieben (Diff-Guard); der Schreibvorgang rotiert dabei automatisch den tseed-Cache-Buster mit (style.ini steht bereits in dessen Abhängigkeitsliste, inc/template.php Zeile 245), ein manueller Hard-Refresh ist für diesen Fix — anders als bei reinen CSS-/JS-Quelländerungen (siehe Abschnitt „Verifikation„) — nicht nötig; per curl-Vergleich des tseed-Werts vor/nach Schemawechsel verifiziert. Verifiziert per php -l sowie manuellem Abgleich der generierten style.ini-Werte gegen alle drei Schema-Dateien und das erzwungene white im Wiki-Bereich.
• 2026-07-10: Brand-Accent-Komponente vereinfacht (zwei aufeinanderfolgende Nutzerkorrekturen nach Sichtprüfung): Gold-Wellenband am Header/Menü-Übergang entfernt, danach auch die verbliebene Haarlinie an dieser Nahtstelle entfernt (eine rote Linie dort wirkte optisch nicht stimmig). Der obere Rahmenstreifen der Site-Seitenhülle ist jetzt der einzige Akzent im Site-Header — fest rot (–wk-error), nicht schemaabhängig. Token –wk-brand-frame hat dadurch keinen Verbraucher mehr und wurde aus allen drei Schema-Dateien entfernt; –wk-brand-hairline wird jetzt nur noch von der Wiki-Kopfzeile konsumiert. Zusätzlich zeigen Kopfzeile, Landing-Hero und Wiki-Kopfzeile einheitlich denselben festen Ivory-Hintergrund statt der schemaabhängigen –wk-paper/–wk-surface-Tokens.
• 2026-07-10: Farbschemata auf die drei offiziellen WvdS-Marken-Akzente konsolidiert: green/red/meadow entfernt, navy-ivory.css zu riviera.css umbenannt, neue Schemata night.css (volle dunkle Leinwand) und white.css (helle Leinwand, Navy-Rahmen) ergänzt. Neue Extension-Tokens –wk-brand-frame/–wk-brand-hairline je Schema, konsumiert von der neuen Komponente css/brand-accent.css (Wellenmotiv + Haarlinie an der Header/Menü-Nahtstelle im Site-Profil, oberer Rahmenstreifen auf der Site-Seitenhülle, zusätzliche Haarlinie unter der Wiki-Kopfzeile). Das Area-Profil wiki rendert seitdem ausnahmslos mit white, unabhängig vom Wert der Option colorscheme (main.php); diese Option wirkt sich nur noch auf das Area-Profil site aus. Standard-Farbschema von navy-ivory auf riviera umbenannt (reines Rename, Palette unverändert). Verifiziert per php -l und Playwright-Screenshots (Site-Header, Wiki-Kopfzeile).
• 2026-07-10: Interner Rename bizway → premiumnavyivory vollständig abgeschlossen: alle 34 PHP-Funktionsnamen/-Konstanten (bizway_*/BIZWAY_* → premiumnavyivory_*/ PREMIUMNAVYIVORY_*) und 32 CSS-Klassen (.bizway-* → .premiumnavyivory-*) im Template sowie die JS-Selektoren in script.js/js/wiki-area.js umgestellt; die Datei inc/bizway-render.php wurde zu inc/premiumnavyivory-render.php. Die Marker-Tag-Syntax ({{wvdsbizway:...}} → {{wkbizway:...}}) wurde zusammen mit den beiden Regex-Stellen in inc/area.php und allen 7 betroffenen Wiki-Seiten in einem Arbeitsschritt geändert. Der BlogTNG-Style-Ordner lib/plugins/wvdsblog/tpl/wvdsbizway/ wurde zu tpl/premiumnavyivory/ umbenannt. Diese Seite selbst wurde von der Seiten-ID de:wiki:dwe:wvdsbizway hierher verschoben; an der alten ID liegt seitdem ein Verweis-Stub. Verwaiste conf/wvdsbizway.json entfernt. Ausgenommen blieben bewusst: die zwei WP-Options-Namen bizway_footertext/bizway_customcss (echte Feldnamen des ursprünglichen WordPress-Themes) sowie der Ordner lib/plugins/blogtng/tpl/bizway/ (unabhängiger Ordner des fremden, deprecated Kern-Plugins blogtng, nicht Teil dieses Bundles). Verifiziert per php -l und Playwright-Browsertest (localhost:8880, alle 5 Sprachen).
• 2026-07-10: Neuer Abschnitt „Formale Abhängigkeitsdeklaration (depends)“: template.info.txt erhielt die Zeile depends wvdspremiumnavyivory. Dabei wurde ein DokuWiki-Core-Bug entdeckt und live verifiziert (Version 2025-05-14b „Librarian„): ein lokal gesetztes depends-Feld mit einem Wert wird als String statt Array geparst, wodurch Deaktivieren/Deinstallieren des Plugins über das Admin-UI nicht mehr sauber funktioniert (TypeError statt Blockade). Details, Testprotokoll und Fälle-Tabelle im neuen Abschnitt.
• 2026-07-10: Abschnitt „Verifikation“ korrigiert: Die bisherige Aussage, touch conf/local.php wirke sich nicht auf den tseed-Cache-Buster aus, war falsch — laut DokuWiki-Core-Quellcode (inc/template.php, tpl_metaheaders()) fließt conf/local.php über die Config-Kaskade main direkt in die tseed-Berechnung ein, ebenso wie style.ini. Richtigstellung entstand während einer Verifikation per curl-Vergleich vor/nach touch conf/local.php.
• 2026-07-10: Header-Avatar-/Benutzer-Menü-Button (.premiumnavyivory-user-menu-toggle, damals noch .bizway-user-menu-toggle) in der site-Hülle von 72px auf 48px verkleinert (css/design.css), passend zum bereits 48px großen Avatarbild und zur seit jeher korrekten Wiki-Area-Shell.
• 2026-07-09: Seite vollständig neu geschrieben nach der Trennung/Umbenennung wvdsbizway → Template premium-navy-ivory + Plugin wvdspremiumnavyivory. Neue Abschnitte: Area-Profile (site/wiki), Marker-Seiten-Mechanismus, Weiterleitungen (Landing- + Namespace-Index-Redirect, inkl. dokumentiertem Fehlerfall bei der Landing-Weiterleitung), Wiki-Area-Shell, dynamische Nav-Flyouts. Entfernt: alle Abschnitte zum inzwischen abgeschafften WP-Admin-Dashboard, Tabellen-Anreicherung, Benutzer-Flyout, „+ Neu„-Drawer (jetzt unter „Was seit 2026-07-09 entfallen ist“ nur noch als Negativ-Hinweis benannt). Farbschema-Standard von default (BizWay-Blau) auf navy-ivory aktualisiert.
• Frühere Historie (bis Version, vor der Umbenennung, als „BizWay Bundle„): siehe Seitenverlauf dieser Wiki-Seite (Reiter „Verlauf alter Versionen“).

Vorlage: lib/tpl/wkbizway (GPLv3, Design abgeleitet aus dem BizWay-WordPress-Theme 1.8.4, InkThemes.com)
Begleit-Plugin: keines — die Vorlage ist seit 2026-07-09 eigenständig, seit 2026-08-01 ohne jeden Plugin-Anteil
Autor: Wolfgang van der Stille Wolfgang.van.der.Stille@gmail.com (The White Knight Labs)
Styles-Contract: Styles-Contract (--wk-*) · Workbench und Schale: FluentUI (Design-System-Bibliothek)

Die Vorlage liefert Aussehen: Farbtokens, drei Schemata, das Seitenraster beider Schalen, Kopf- und Fußbereich sowie die optionsgesteuerten Blöcke der Site-Schale. Sie liefert keine Struktur — Verwaltungswerkbank, Regionen und Weiterleitungen gehören wkfluentui. Der Prüfstand dazu ist eine Hausregel: ist das BizWay-Thema abgeschaltet, läuft der Workbench unverändert.

Namenshinweis (drei Umbenennungen, alle mit Grund). Diese Seite hieß ursprünglich „BizWay Bundle„ und beschrieb Template und Plugin unter dem gemeinsamen Namen wvdsbizway. Am 2026-07-09 wurden beide getrennt: Die Vorlage hieß seitdem premium-navy-ivory, das Plugin wvdspremiumnavyivory. Am 2026-07-10 wurde der interne Rename abgeschlossen (Funktionsnamen und CSS-Klassen trugen fortan premiumnavyivory_/.premiumnavyivory-). Am 2026-08-03 wurde mit der Paketumbenennung des Hauses daraus wkbizway mit den Präfixen wkbizway_/.wkbizway-, und die Marker-Syntax heißt seitdem {{wkbizway:...}}. Am 2026-08-04 ist diese Seite von de:wiki:dwe:premiumnavyivory hierher verschoben worden — samt Historie, denn ihre Kennung trug bis dahin den Namen eines Plugins, das es nicht mehr gibt.

Diese Seite beschreibt den heutigen Stand. Was es einmal gab und heute nicht mehr, steht absichtlich weiter unten statt gelöscht zu werden: die Abschnitte „Was seit 2026-07-09 entfallen ist“ und „Aufgelöste Konstruktionen„ nennen jede Sackgasse samt der Messung, an der sie gescheitert ist — damit niemand danach sucht und niemand sie ein zweites Mal baut.