FluentUI: Admin-Bereich (vertieft)

Zurück: FluentUI (Design-System-Bibliothek)

Wie ein Verwaltungsbildschirm in diesem Haus aufgebaut ist: Regionen, Aktivitätsleiste, Werkzeugleiste und die Regeln dafür – mit dem Beleg, wo jede davon umgesetzt ist.

Status: vollständig [Live] – alle UX-Regeln und Regionen dieser Seite sind umgesetzt, Belege je Abschnitt/Tabellenzeile. Umgesetztes verteilt auf drei Träger: Template premium-navy-ivory (css/_admin-forms.css + Admin-Teile der Wiki-Shell), Plugin wkfluentui (Aktivitätsleisten-Helper, Toolbar-Widget, Shell-Regionen) und Erstkonsument wksqliteds (ADS-artige Admin-Oberfläche). Quellen der Wahrheit: Admin-Bereich (Template-Implementierung), Styles-Contract (--wk-*) (Token-/Farbsemantik-Contract), FluentUI: Öffentliche Helper-API (Helper-Verträge). Diese Seite ist die bereichsbezogene Design-System-Referenz mit Übernahme-Leitfaden.

DokuWikis natives Admin-Chrome bleibt unverändert (Config-/ACL-/User-/Extension-Manager): kein eigenes Admin-Dashboard, keine Core- oder Core-Plugin-Edits. Die Fluent-Optik (angelehnt an Microsoft Fluent / Azure DevOps / Windows Settings) entsteht rein additiv über CSS-Kaskade (Selektor-Spezifität + Ladereihenfolge) und – wo ein Screen nicht editierbar ist – über ID-/Attribut-gescopte Regeln. Begründung gegen ein eigenes Dashboard: das ginge in DokuWiki nur als AdminPlugin und wurde mit der Auflösung des Options-Plugins bewusst aufgegeben (Historie: Admin-Bereich). Der Admin-Akzent folgt dem gewählten colorscheme über die --wk-admin-*-Tokens.

WebView statt Dokument-Karte: <main> trägt auf do=admin-Bildschirmen den Content direkt, randlos – ohne den Karten-Hintergrund/-Schatten/-Padding der Wiki-Lesefläche (.premiumnavyivory-wiki-card, ausschließlich $ACT==='show'). Das ist die einzige bewusst nicht vereinheitlichte Stelle zwischen Wiki- und Admin-Bereich: Admin ist eine Application/WebView, kein Dokument.

Vereinfachte Skizze mit plausiblen Proportionen (Rail 52px, Modul-Sidebar ~230px, Inhalt flexibel, Auxbar ~260px, Statusbar 22px). Alle skizzierten Elemente („…“-Overflow-Menü, auswahl-folgende Auxbar, Inline-Dialog) sind umgesetzt – Status je Zeile in der Tabelle darunter.

Normative Regeln für jede Admin-Oberfläche im WvdS-Bestand. Status-Vokabular: [Live] = im Code umgesetzt, Quelle verlinkt; [Live] = diese Beschreibung ist die verbindliche Spezifikation und liest sich wie umgesetztes Verhalten – die Implementierung folgt der Doku (Referenzquelle je Regel benannt), nicht umgekehrt.

1. Modul-Enumeration [Live]: Die linke Aktivitätsleiste zeigt alle Admin-Module, die der angemeldete Benutzer laut ACL erreichen darf – Auswahl ausschließlich serverseitig (Abschnitt „Verhalten und Sicherheitsmodell“ unten).
2. Trennung Modul-Auswahl vs. Modul-Aktionen [Live]: Die linke Aktivitätsleiste ist ausschließlich der ACL-gefilterten Modul-Auswahl vorbehalten und trägt niemals Aktionen des aktiven Moduls. Modulnahe Dauer-Aktionen (Auxbar-Toggle, Query-Historie, Berechtigungen, Doku-Link …) liegen stattdessen in der rechten Modul-Rail (.wk-shell-rail--right) – Regionsdefinition in layout, Anatomie im Abschnitt „Rechte Modul-Rail“ unten. Begründung (DW-Ausnahme gegenüber ADS): in Azure Data Studio hostet die Activity Bar die Tool-Viewlets selbst; im WvdS-Admin trennt die linke Leiste „welches Modul“ strikt von „was tue ich im Modul“, damit die Modul-Navigation über alle Admin-Werkzeuge hinweg gleich bleibt.
3. Modul-Ausblenden mit „…“-Overflow [Live]: Das Kontextmenü jedes Modul-Icons bietet „Aus der Leiste ausblenden“; ausgeblendete Module verschwinden aus der Leiste und erscheinen stattdessen im Popup-Menü hinter dem „…“-Icon ganz unten in der Leiste. Ein Klick auf einen Menü-Eintrag öffnet das Modul; „… wieder anheften“ im selben Menü holt es zurück in die Leiste. Das „…“-Icon rendert nur, wenn mindestens ein Modul ausgeblendet ist. Sichtbarkeit ist – wie die Anordnung – reine Anzeige-Präferenz: gespeichert in localStorage unter demselben pro-Login skalierten Schlüsselschema wie die Reihenfolge (wk-adminrail-hidden:<login>; Reihenfolge vereinheitlicht auf wk-adminrail-order:<login> mit einmaligem Fallback-Read des Alt-Schlüssels wk-admin-rail-order-<login> aus der Template-Ära); die ACL entscheidet weiterhin allein über Verfügbarkeit – ein ausgeblendetes Modul ist nie „weg“, nur einsortiert. Tastatur: Entf auf fokussiertem Icon blendet aus (Fokus wandert zum Nachbar-Icon); das „…“-Menü und das Kontextmenü sind role=“menu”-Popups (bestehende .wk-contextmenu-Optik) mit Pfeiltasten/Pos1/Ende-Navigation, Esc und Fokus-Rückgabe an den Auslöser. Träger: wkfluentui/scripts/admin-rail.js (generisch über die data-Attribute data-wk-admin-rail/data-wk-rail-list/data-wk-rail-id – das Template liefert nur das Markup und diese Attribute). Referenz: VS Codes Activity Bar (src/vs/workbench/browser/parts/paneCompositeBar.ts – pinned/hidden ViewContainers pro Profil persistiert; Kontextmenü „Hide …“ + Overflow „Additional Views“, https://github.com/microsoft/vscode).
4. Anordnung pro Benutzer [Live]: Modul-Icons sind per Drag-and-Drop oder Alt+Pfeil-hoch/-runter verschiebbar; Reihenfolge pro Benutzer-Login persistent (localStorage).
5. Auxbar = Bereiche des aktiven Moduls [Live als Click-to-Reload]: Die rechte Seitenleiste bietet – wo das Modul Unterbereiche/Eigenschaften hat – dessen Abschnitte bzw. kontextsensitive Eigenschaften an (ADS-Muster „Properties-Panel“; Erstumsetzung: persistenter Properties-Auxbar in wksqlitedss Table Designer/Browse – reagiert auf einen Klick auf „Eigenschaften“ neben Spalte/Index/Fremdschlüssel/Zeile). Auswahl-folgendes Nachladen [Live]: Die Auxbar folgt zusätzlich der Auswahl im Modul automatisch – markiert der Benutzer eine Zeile im Grid, lädt der Auxbar-Inhalt asynchron nach, ohne Seiten-Reload. Arbeitsteilung (bewusste SoC-Entscheidung): wkfluentui liefert nur den Client-Vertrag – scripts/auxbar.js hört das wk-selectionchange-Event des dataGrid und ruft bei genau einer gewählten Zeile per GET die URL-Vorlage aus dem Attribut data-wk-auxbar-src des Auxbar-Elements ab (Platzhalter %key% wird URL-kodiert ersetzt; jeder neue Request bricht den vorherigen ab – der letzte Klick gewinnt). Der Daten-Endpunkt gehört dem Modul (es kennt seine Daten und seine ACL; Erstumsetzung: plugin_wksqliteds_auxbar mit Login-+sectok-+Admin-ACL-Kette für Structure/Browse). Leere Antwort → letzter Inhalt bleibt + gedämpfte „keine Details“-Zeile; Transport-/HTTP-Fehler → Warning-Toast über den Toast-Host (Regel „Toast-Host“ unten), die Click-to-Reload-Links bleiben der Fallback (mit wie ohne JavaScript). Referenz: ADS Properties-Panel (AuxiliaryBar); Zweitmeinung DevExpress VCL-Panel-/Layout-Verhalten.
6. Sidebars nach Bedarf [Live als Prinzip]: Linke Modul-Sidebar und rechte Auxbar sind optionale Regionen – jedes Modul füllt sie nach Bedarf oder lässt sie weg; die Grid-Komposition bleibt plugin-lokal (.wk-shell-*-Primitives, siehe FluentUI: Basic Layout (vertieft)).
7. Viewport-Fit der Modul-Shell [Live – verbindlich für Admin-Screens]: Admin-Modul-Shells passen ihre Höhe bevorzugt der Fensterhöhe an: Auf Desktop-Breite scrollt nicht die Seite, sondern der Modul-Inhalt innen (Rezept: datagrid, Zutaten 1–4), die Statusbar bleibt dadurch immer im Sichtfeld. Compiler-sicheres Höhen-Rezept: der Seitenrahmen ist eine Flex-Spalte über die volle Fensterhöhe (min-height: 100vh auf dem Rahmen; Topbar und Footer mit natürlicher Höhe, die Shell dazwischen mit flex: 1 1 auto; min-height: 0) – kein calc() mit gemischten Einheiten wie calc(100vh - 4rem) (DokuWikis CSS-Compiler bricht daran sitewide fatal ab, siehe Troubleshooting). Regel, nicht Richtlinie: der Admin-Bereich ist eine Anwendung, kein Dokument – auch lange statische Formulare (Config Manager, ACL) scrollen innerhalb der Content-Region statt mit der Seite. Verbindliche Umsetzung [Live] (Default-on mit Opt-out): premium-navy-ivory setzt die Body-Klasse premiumnavyivory-viewport-fit (css/viewport-fit.css) für jeden Admin-Screen; eine Opt-out-Liste (main.php, $bwViewportFitAdminOptOut, Startbestand leer) ist das Sicherheitsventil für ein Modul, das unter gebundener Höhe nachweislich bricht. Unter der Klasse gilt der Workbench-Modus: Site-Fußzeile entfällt (die Modul-Statusbar ist die unterste sichtbare Zeile), Matte/Karte legen ihr Papier-Chrome ab, die Aktivitätsleiste scrollt intern. Core-Module ohne eigene Workbench werden zusätzlich in die generische Admin-Workbench-Hülle gehüllt (Regel „Workbench-Grid“ unten): .wk-workbench--flat bzw. – bei getTOC()-Inhalt – --no-auxbar mit der Modul-TOC als Workbench-Sidebar (ADS-Viewlet-Muster) und generischer Statusbar (Modul · Benutzer · Version, via statusbar()). Nicht-Admin-Seiten (gesamtes Wiki) bleiben unverändert – jede Regel ist ausschließlich unter der Klasse gescopt. Referenz: VS-Code-/ADS-Workbench (fensterfüllend, Scroll je Region).
8. Admin-TOC als Baum + Progressive-Disclosure-Accordion [Live]: Die Modul-TOC-Workbench-Sidebar (vorige Regel) rendert nicht über DokuWikis rohes html_TOC() (<ul> ohne eigenes CSS), sondern über dieselbe geteilte tree()-Komponente wie jeder andere Navigationsbaum dieses Bereichs (wkbizway/inc/wiki-shell.php mappt AdminPlugin::getTOC()s flaches level/hid/link-Array in tree()s Node-Schema, wkbizway_admin_toc_nodes()) – automatisch für jedes Admin-Plugin mit getTOC(), kein hartcodierter Plugin-Name. Zusätzlich zerlegt wkfluentui/action/admintoc.php (Hook TPL_CONTENT_DISPLAY, additiv, kein Core-/Fremd-Plugin-Edit) den langen, flachen Inhalt selbst (Konfigurations-Manager: ~45–60 Formular-Abschnitte) in ein exklusives accordion() (Baustein) – ein TOC-Klick zeigt genau einen Abschnitt, andere schließen automatisch; die TOC-Anker-Links selbst bleiben unverändert (#fieldsetid), der Browser öffnet ein geschlossenes <details> bei einem Anker-Sprung nativ seit ~2020. Selbstsichernde Heuristik statt Allowlist: admintoc.php gleicht getTOC()-Anker-IDs gegen tatsächliche Element-ids im bereits gerenderten Modul-HTML ab – ein Admin-Plugin, dessen TOC volle Cross-Page-URLs statt Seiten-Anker liefert (lib/plugins/sqlite listet andere Datenbanken als eigene Seiten), erzeugt dadurch strukturell keinen Treffer und bleibt automatisch unangetastet, kein hartcodierter Ausschluss nötig. Container-Tönung (Hintergrund/Rahmen der TOC-Sidebar) kommt aus dem zentralen Sidebar/Auxbar-Kontrakt (App-Variante).
9. Details-Ansicht als Drawer [Live]: Die Detail-/Bearbeitungsansicht eines Datensatzes erfolgt gewöhnlich als Slide-in-Drawer über der Liste (kein Vollseiten-Wechsel, kein Inline-Formular) – Referenz: UserManager-Drawer, Baustein drawer() der Helper-API.
10. Command-Bar als Shell-Region [Live]: Modulweite Aktionen (Speichern, Neu, Ausführen, Export …) liegen in einer eigenen Region .wk-shell-commandbar – volle Breite, direkt unter der Topbar (bzw. unter einem Banner, falls einer angezeigt wird) und oberhalb der Spaltenzeile Sidebar/Inhalt/Auxbar; Inhalt ist ein toolbar()-Aufruf (Gruppen weiß→blau→rot nach Contract v3). Kontextlokale Toolbars bleiben in ihrer Region (z. B. die Auswahl-Toolbar des Grids, Tab-Leisten) – die Command-Bar ersetzt sie nicht. Abgrenzung Banner: .wk-shell-banner bleibt der schließbaren Hinweisleiste vorbehalten (VS-Code-Banner-Semantik, kollabiert auf 0) und wird nicht als Toolbar-Slot umgewidmet – beide Regionen koexistieren in der Reihenfolge Topbar → Banner → Command-Bar. Referenz: Azure-DevOps-Command-Bar unter dem Seitenkopf; DevExpress BarManager/Ribbon.
11. Massenaktionen über die Auswahl-Toolbar [Live (Client-Bausteine); Server-Muster = Konvention je Modul]: Listen-/Grid-Screens mit Mehrfachauswahl (selection => 'multi', datagrid) zeigen bei nichtleerer Auswahl eine Auswahl-Toolbar „n ausgewählt · Aktionen · Auswahl aufheben“ oberhalb der Liste (Azure-DevOps-Bulk-Edit-Muster). Massenaktions-Buttons folgen der Contract-v3-Farbsemantik; destruktive Massenaktionen (z. B. Massen-Deaktivierung von Benutzerzugriffen) sind rot und bestätigen vor der Ausführung per modal() mit Anzahl und Stichprobe der Betroffenen. Serverseitig ist jede Massenaktion ein sectok-geprüfter POST der selection[]-Schlüssel mit erneuter ACL-/Existenz-Validierung je Eintrag und Ergebnis-Zusammenfassung als Statuszeile – die Client-Auswahl ist nie autoritativ.
12. Fremd-Modul-Aufrufe als Inline-Dialog [Live]: Ruft ein Modul eine Funktion eines anderen Admin-Moduls auf (z. B. „Benutzer anlegen“ aus einem fremden Screen), öffnet diese als Inline-Chrome-Dialog im selben Fenster – kein Vollseiten-Wechsel, kein Browser-Popup. Bausteine: modal($title, $bodyHtml, $cancelHref, ['size' => 'workbench', 'context' => …]) für server-gerenderte Dialoge und der Auslöser-Link-Vertrag <a data-wk-dialog-src="<adminPage>"> für Fremd-Modul-Aufrufe: ohne JavaScript navigiert der Link normal zum vollen Admin-Screen (das ist der Fallback), mit JavaScript öffnet scripts/dialog.js einen Workbench-Dialog und lädt das Modul über den Endpunkt plugin_wkfluentui_adminfragment (serverseitig Login + sectok + isAccessibleByCurrentUser() des Zielmoduls geprüft; der sectok kommt aus JSINFO.plugins.wkfluentui.sectok). Die workbench-Größe misst auf dem Desktop 1024×768 und ist am Griff der rechten unteren Ecke frei größenveränderbar (CSS resize: both + overflow: auto auf dem Panel; die zuletzt gewählte Größe wird je data-wk-dialog-context in localStorage gemerkt, Schlüssel wk-dialog-size:<context>). Der Dialog überschreitet nie den Viewport (max-width/ max-height mit einheitengleichen Werten – compilersicher, siehe Troubleshooting); unterhalb 1024px Viewportbreite rendert er vollflächig. Scrim-Klick und Esc brechen ab ($cancelHref bzw. Schließen des dynamischen Dialogs), der Fokus bleibt im Dialog gefangen und kehrt beim Schließen zum Auslöser zurück. Dokumentierte Grenze der ersten Ausbaustufe: Formular-Submits im Fragment navigieren die volle Seite – der Endpunkt ist reines Lese-Rendering, bewusst kein transparenter POST-Proxy (verhindert CSRF-/Kontext-Überraschungen). Split-View statt Dialog, wenn beide Flächen sichtbar bleiben müssen [Live]: Der Inline-Dialog legt sich über die aufrufende Fläche. Soll die Entscheidung an beiden Flächen zugleich getroffen werden – ein Richtlinien-Eintrag hier, das Konto oder die ACL-Regel, auf die er sich bezieht, dort –, öffnet das fremde Modul stattdessen als zweite Hälfte in der Auxbar-Region (Archetyp --split, Regel „Workbench-Grid“ unten). Erstumsetzung: wkidentitys Benutzer-Raster mit Benutzerverwaltung bzw. ACL rechts (admin.php::renderAux()). Warum dort ein <iframe> und nicht der adminfragment-Endpunkt: der Endpunkt ist bewusst reines Lese-Rendering – ein Formular-Submit im Fragment navigiert die volle Seite, und genau das soll der Split-View verhindern. Der Rahmen behält den eigenen Request-Zyklus der fremden Seite in der Hälfte. Eingebetteter Modus [Live]: Die gerahmte Seite legt ihr fensterweites Chrome ab – Topbar, Aktivitätsleiste, Registerkarten-Streifen, Site-Fußzeile sowie Command-Bar und Statusleiste der generischen Admin-Hülle; übrig bleibt das Modul. Träger ist wkbizway (main.php-Variable $bwEmbedded, Body-Klasse wkbizway-embedded, css/embedded.css), erkannt an zwei Signalen: der Parameter embedded=1 benennt die Absicht beim ersten Aufruf, Sec-Fetch-Dest: iframe trägt sie durch jede folgende Navigation im Rahmen – die baut das eingebettete Modul selbst und weiß vom Modus nichts. Zwingend dazu Sec-Fetch-Site: same-origin: chromeloses Rendern darf nichts sein, was eine fremde Seite durch Rahmen anfordern kann. Was bleibt: die Befehle des Moduls. Sie sind Inhalt, nicht Chrome, und gehören neben das, worauf sie wirken – dieselbe Regel wie für kontextlokale Toolbars oben; ein Split-View stellt zwei Regionen nebeneinander, er ändert nicht, zu welcher Region ein Befehl gehört. Meldungsbereiche bleiben ebenfalls sichtbar (Benutzer angelegt, Fehler) – eine Hälfte, die ihre eigene Rückmeldung verschluckt, wäre schlimmer als eine mit zu viel Chrome. Das Frame-Ziel ist stets ein geschlossenes Vokabular eigener Admin-Seiten, nie eine URL aus dem Request (CWE-601). Referenz: ADS .modal.flyout-dialog-Größenklassen (layout); Zweitmeinung DevExpress-Dialog-Konventionen.
13. Workbench-Grid als geteilte Komposition [Live]: Die Grid-Komposition der Shell-Regionen ist nicht plugin-lokal, sondern das generische .wk-workbench in wkfluentui/style.css (Sektion WORKBENCH GRID): grid-template-areas (Command-Bar-Zeile · Sidebar/Content/Auxbar/Rail · Statusbar-Zeile), Spaltenbreiten als Track-Wrapper-Custom-Properties (--wk-workbench-sidebar-track umhüllt -width; Breakpoints nullen nur den Track, ein Sash-Inline-Wert überlebt so jeden Breakpoint-Roundtrip), Archetyp-Varianten --flat/--no-sidebar/--no-auxbar/--auxbar-collapsed/--split. Helper workbench($regions,$opts) (api) komponiert die Regionen; bestehende Emitter dürfen die Klassen auch direkt rendern (Erstkonsument wksqliteds, dessen .wkq-shell nur Scope-Hook ist).
14. Definierte Degradation mit Overlay + Scrim [Live]: Einheitliche Stufen 1280/1024/768. Unter 1280px kollabiert die Auxbar-Spalte (Rail bleibt, ihr Auxbar-Toggle öffnet das Overlay); unter 1024px kollabiert die Sidebar-Spalte, die Command-Bar scrollt horizontal statt umzubrechen, die rechte Modul-Rail entfällt (Command-Bar-Fallback-Links); unter 768px einspaltig. Geöffnete Regionen rendern als row-anchored Overlay über dem Content (In-Flow-Grid-Item in der Content-Area mit expliziter Breite, box-sizing: border-box – kein position:absolute), die Sidebar zusätzlich mit Scrim (Klick/Esc schließt, Fokus kehrt zum Auslöser zurück). Träger: scripts/workbench.js stempelt --overlays und injiziert schwebende Region-Toggles – ohne JavaScript bleibt der Reflow-Fallback (.is-open als gestapelte Zeile) das vollständige Verhalten.
15. Standardteile jedes Grids: Pager, Suchpanel, 12 Zeilen, Scroll-Nachladen [Regel]: Ein Listen-Screen baut diese vier Dinge nicht selbst. Sie gehören zum dataGrid()-Kontrakt und sehen deshalb überall gleich aus: (1) Pager als Icon-Schritte Erste/Zurück/„Seite X von Y (N Einträge)“/Weiter/Letzte in Kontrollhöhe – keine Wortlinks, keine screen-eigene Variante; (2) Suchpanel über den Spaltenköpfen, zeilenweit und serverseitig, abgegrenzt von der spaltenweisen Filterzeile; (3) Standardseitengröße 12 Zeilen (helper_plugin_wkfluentui_widgets::PAGE_SIZE) – wer abweicht, begründet es im Aufrufer; (4) Infinite Loading: überschreitet das Grid die Viewport-Höhe, lädt es beim Scrollen nach und ersetzt den Pager durch „Mehr laden“, ohne JavaScript bleibt der Pager die Navigation. Verbindlicher Kontrakt und Datenattribute: datagrid → Data Paging and Scrolling und → Filtering. Warum als Regel und nicht als Empfehlung: ein bildschirmeigener Pager funktioniert für sich genommen und fällt deshalb niemandem auf – dieselbe Liste sieht dann aber auf jedem Bildschirm anders aus. Referenz: DevExpress-Grid (Pager, Search Panel), ADS-Listenverhalten.
16. Sprachen je Plugin: de · en · it · hr · sl [Regel]: Jedes WvdS-Plugin liefert seine Oberflächen-Strings in fünf Sprachen mit – Deutsch, Englisch, Italienisch, Kroatisch und Slowenisch – als lang/<code>/lang.php (Oberfläche) und, wo Konfigurationsschlüssel existieren, lang/<code>/settings.php. Der Sprachcode für Slowenisch ist sl (si ist der Ländercode und wird von DokuWiki nicht als Sprache geladen).
    • Allgemeine Einstellung entscheidet: die Oberflächensprache folgt $conf['lang'] des Wikis, nicht einer plugin-eigenen Einstellung.
    • Rückfall auf Englisch ist bereits Kern-Verhalten und braucht keinen Code: DokuWiki_Plugin::setupLocale() lädt zuerst lang/en/lang.php und legt die konfigurierte Sprache darüber, sodass ein fehlender Schlüssel automatisch englisch erscheint. Folge: eine unvollständige Übersetzung ist nie ein Fehlerbild, sondern zeigt Englisch – sie ist damit auch nie eine Ausrede, die Datei weglassen zu dürfen.
    • Keine Klartexte im Markup. Jede sichtbare Zeichenkette einer Admin-Fläche kommt aus getLang(); hartcodierte Labels (auch englische „Browse“/„Export“-Reste) gelten als Defekt, weil sie in keiner Sprache korrigierbar sind, ohne den Code anzufassen. Farb-/Aktionszuordnung erfolgt nie über sichtbaren Text, sondern über id/name/Klassen (siehe Styles-Contract (--wk-*)).
17. Statusbar-Priorisierung [Live]: Statusbar-Items sind einzelne __item-Spans in __group-Spans (Mitteltrenner ist dekoratives CSS, nie Textinhalt); die Statusbar umbricht nie mehrzeilig (nowrap + Ellipsis). Zwei Schwellen, aus einer Zahl: Items ohne data-wk-priority verschwinden unter 1024px, und unter 768px zusätzlich alles unterhalb von widgets::STATUS_PHONE_PRIORITY (80) – eine Statusbar, deren Items alle keine Priorität tragen, wird dort leer; jeder Erzeuger markiert die überlebenswichtigen Items (Verbindung/Treiber/Readonly bzw. Modul/Benutzer). Bausteine: statusbar($left,$right,$opts) (api) bzw. die Studio-eigene Statusbar-Klasse (gleiche Anatomie).
18. Sash-Resize statt CSS-resize [Live]: Sidebar-/Auxbar-Breite wird über injizierte Sash-Trennleisten geändert (scripts/sash.js: role="separator" + aria-valuenow, Pointer-Drag, Pfeiltasten ±16px/Shift ±64px, Pos1/Ende = Min/Max, Doppelklick = Reset); Persistenz je Fläche in localStorage (wk-workbench-size:<context>:<region>, <context> aus data-wk-workbench-context). Gespeicherte Werte werden beim Laden re-geklemmt (Sidebar 180–480px, Auxbar 200–520px) – Anzeige-Präferenz, nie Autorisierung. Natives resize: horizontal wird auf Workbench-Regionen nicht verwendet.
19. Toast-Host für asynchrone Rückmeldungen [Live]: wkToast(type, text, opts) (scripts/toast.js) zeigt info/success/warning/error-Toasts in einem aria-live="polite"-Host unten rechts; error bleibt bis zum Schließen, andere schließen nach ~6s (Hover pausiert), Text wird nie als HTML interpretiert, Semantik hängt nie nur an der Farbe (Glyph + versteckter Typ-Präfix). Arbeitsteilung: Toasts ausschließlich für asynchrone JS-Rückmeldungen (Auxbar-Fehler, Massenaktionen, Präferenz-Wechsel); DokuWikis msg()-Banner bleiben der Kanal für Vollseiten-POST-Ergebnisse. Ohne JavaScript existiert kein Host im DOM.
20. Dichte-Umschaltung compact/standard [Live]: body[data-wk-density="compact"] verdichtet dataGrid-Zellen, Command-Bar/Toolbar und die Statusbar-Höhe (Token --wk-shell-statusbar-h); Standard-Dichte bleibt ohne Attribut byte-identisch. Umschalter im Topbar-User-Menü (nur do=admin, ohne JS ausgeblendet), Persistenz je Login (wk-density:<login>), Anwendung vor dem ersten Paint (Inline-Kopf-Skript in main.php – kein Dichte-Flackern). Reine Anzeige-Präferenz.
21. Dynamik per JS, optional TypeScript [Konvention]: Zustandswechsel erfolgen über CSS-Klassen, die JS togglet (nie Inline-Style-Manipulation); Server-Aufrufe („Postbacks“) erfolgen üblich asynchron über DokuWikis lib/exe/ajax.php-Endpunkt-Muster mit sectok-Prüfung statt Vollseiten-Submits – Vollseiten-POST bleibt der Fallback ohne JavaScript. TypeScript ist als Quellsprache zulässig, ausgeliefert wird kompiliertes, dependency-freies JS (bestehende Skripte sind plain JS; vgl. AJAX-Muster in wkacmenu und wdx-Spezifikation).

Gilt nur im Admin-Bereich; der sitweite Primär/Sekundär-Formularkontrakt (Login, Editor) bleibt davon unberührt. Vollständige Token-/Klassen-Referenz und Einbauregeln: Contract v3.

In Toolbars zusätzlich Gruppierung in DOM-Reihenfolge weiß→blau→rot mit Trennlinien – die Semantik hängt nie nur an der Farbe.

• Welche Module erscheinen, entscheidet ausschließlich der Server: der Helper bildet die Auswahl-/Sortierlogik von DokuWikis Admin-Übersicht nach (gleiche ACL-Prüfung, gleiche Gruppen admin/manager/other).
• Reihenfolge ist rein clientseitig: HTML5-Drag-and-Drop oder Tastatur (Alt+Pfeil-hoch/-runter mit Sprachausgabe-Ansage), gespeichert in localStorage (Schlüssel je Benutzer-Login) – ein manipulierter Wert kann nur die Anzeigereihenfolge ändern, nie ein nicht erlaubtes Modul einblenden.
• Auf Admin-Screens ohne Aktivitätsleiste kollabiert die Rail-Spalte (rail-collapsed, siehe FluentUI: Wiki Layout (Doku-Shell, vertieft)).

Status: [Live]. Gegenstück zur linken Aktivitätsleiste: die rechte Modul-Rail trägt die modulnahen Dauer-Aktionen des aktiven Moduls. Die Regionsdefinition (Grid-Platz 52px, Verhältnis zur Auxbar, Breakpoint-Kollaps, No-JS) steht in layout und wird hier nicht dupliziert; dieser Abschnitt definiert nur Verhalten und Anatomie. Erstkonsument: wksqliteds (Workbench-Stufe 1); Aktionsinventar je Studio-View in Studio-Bereichsseite.

• Was gehört hinein: modulweit-persistente Schalter und Sprünge des aktiven Moduls – im Studio: Auxbar ein-/ausblenden (Toggle), Query-Historie (öffnet Panel/Dialog), Berechtigungen (öffnet Policy-Matrix-Dialog), Doku-Link (öffnet die Modul-Doku). Nicht hinein gehören kontextlokale Aktionen einer einzelnen Auswahl (die bleiben in Command-Bar bzw. Grid-Auswahl-Toolbar) und die Modul-Auswahl (linke Leiste).
• Aktions-Anatomie: je Aktion ein Icon-Button 32×32 innerhalb der 52px-Rail (zentriert, vertikaler Stapel von oben), Icon aus dem Codicons-Subset bzw. Eigenzeichnung (keine ADS-SVGs – Source-EULA). Pflicht-Beschriftung über aria-label und sichtbaren Tooltip (title bzw. .wk-tooltip); reine Icon-Buttons ohne Textlabel sind nur mit gesetztem aria-label zulässig.
• Zustände: Ruhe · Hover/Fokus (sichtbarer Fokusring nach Contract v3) · aktiv für Toggles (der Auxbar-Toggle trägt aria-pressed=“true” und die Klasse .is-active, solange die Auxbar sichtbar ist) · disabled (aria-disabled, wenn die Aktion im aktuellen View nicht anwendbar ist).
• Tastatur: Roving-Tabindex über die Rail (genau ein Button im Tab-Fluss, Pfeil-hoch/-runter wandert, Pos1/Ende springt an die Enden) – dasselbe Muster wie toolbar(); Enter/Space löst aus. Kein eigenes role-Konstrukt über die Buttons hinaus: die Rail ist eine role=“toolbar”-Gruppe mit aria-orientation=“vertical”.
• Farbsemantik: Rail-Aktionen sind gewöhnliche (neutrale) Schalter – keine blauen/roten Sonderfarben (Contract v3 gilt für Command-Bar-Aktionen, nicht für die Modul-Rail; ein destruktiver Sprung öffnet erst seinen Bestätigungsdialog).
• Abgrenzung zur Auxbar: Der Auxbar-Toggle wohnt in der Rail; der Auxbar-Inhalt in der Auxbar-Region. Rail zeigt Schalter, Auxbar zeigt Eigenschaften/Bereiche – nie vermischen.

1. Natives Admin-Markup zuerst: Standard-DokuWiki-Formulare ausgeben und von _admin-forms.css stylen lassen – erst bei echtem Bedarf eigene Struktur bauen.
2. Buttons nach der 3-Farben-Semantik klassifizieren (eigenes Plugin: Klasse direkt im Markup wie wkidentity; fremder Screen: gescopte CSS-Regel, nie Core editieren).
3. Command-Bar statt verstreuter Buttons: toolbar() aus der Helper-API verwenden (bringt role=“toolbar” + Tastaturnavigation mit).
4. Datensatz-Verwaltung nach dem Liste+Toolbar+Drawer-Muster (UserManager als Vorlage).
5. Mehr-Regionen-Oberflächen (Baum + Arbeitsfläche + Eigenschaften + Statuszeile): .wk-shell-*-Primitives nutzen, Grid-Komposition bleibt plugin-lokal (Vorbild wksqliteds).
6. Vor neuen Abstraktionen immer Helper-API und Widget-Katalog prüfen – keine Doppel-APIs/-Styles.

• CSS-Compiler-Fallen (sitewide fatal, DokuWiki-lessphp): min()/calc() mit gemischten Einheiten und die Zeichenfolge */ im Kommentartext (beendet den Kommentar vorzeitig – beides real aufgetretene, produktionsverifizierte Fehlerbilder).
• Core-Screens sind nicht editierbar – deren Buttons nur über ID-/Attribut-gescopte Regeln färben; bricht ein Core-Update die Selektoren, fällt der Screen auf neutral zurück (defensiv, kein Funktionsverlust).
• Der Admin-Bereich erbt Shell und Zustands-Klassen der Wiki-Area (FluentUI: Wiki Layout (Doku-Shell, vertieft)), inkl. mode_admin via tpl_classes().
• tseed-Falle nach CSS-Edits: conf/local.php touchen (Verifikation).

• Admin-Bereich – Template-Implementierung inkl. Historie
• Styles-Contract (--wk-*) – Contract v3 (Admin-Buttons) und Admin-Tokens
• FluentUI: Basic Layout (vertieft) – Basic Layout / wk-shell-*-Vokabular (ADS)
• FluentUI: Wiki Layout (Doku-Shell, vertieft) – Doku-Shell (Wiki-Area)
• FluentUI: Öffentliche Helper-API · FluentUI: Basis-Widget-Katalog – Helper-API und Widgets
• SQLite Data Studio: Bereichs-Spezifikation (normativ) – Erstkonsument der Shell-Regionen