FluentUI: Einstellungs-Editor

Zurück: FluentUI: Bereichs-Shells · Bibliotheks-Übersicht

368 Einstellungen in 36 Gruppen auf einer Seite, und nichts sagte, welche vom Standard abweichen: warum DokuWikis Konfigurationsmanager ersetzt wurde und was an seine Stelle tritt.

Status: vollständig [Live] (Quelle: Screen/Settings.php, helper/settings.php, scripts/settings.js). Verwandt: Admin-Layout · Beitragsvertrag v1 · Eigenschaftsraster

DokuWikis Konfigurationsmanager zeichnet seine ganze Antwort in einem Durchgang: ein <fieldset> je Gruppe, eine Tabelle darin, jede Gruppe offen. Auf einer voll bestückten Installation sind das 368 Einstellungen in 36 Gruppen auf einer Seite (Median der Gruppengröße 8, größte 63), und nichts auf dem Bildschirm sagt, welche davon vom Standard abweichen.

Dazu kommt die Länge der Beschriftungen: jedes Paket dieser Suite schreibt einen ganzen Erklärungssatz in Setting::prompt() – und der ist die Beschriftung. Der Editor legt die Zeilen deshalb in ein Eigenschaftsraster, dessen Beschriftungsspalte gedeckelt ist und umbricht, damit kein Satz ein Steuerelement aus dem Sichtbereich schiebt.

Das ist die Voraussetzung für alles Übrige und war nicht offensichtlich.

Configuration::updateSettings($input) läuft über jede Einstellung und übergibt jeder $input[$key] ?? null. Die Basisklasse fängt null ab – vier Unterklassen tun das nicht:

Ein Formular, das nur einen Ausschnitt zeigt, schaltet also stillschweigend jeden Schalter außerhalb des Ausschnitts ab. Beim Speichern von zwölf Mail-Einstellungen würden so unter anderem useacl = 0, securecookie = 0, iexssprotect = 0, relnofollow = 0 und sneaky_index = 0 geschrieben – der erste schaltet die Zugriffsverwaltung des gesamten Wikis ab. Ohne Mitführung fällt außerdem savedir mit hinein, dessen Fehler den ganzen Vorgang verwirft; null Änderungen sähe dann aus wie Unbedenklichkeit.

Der Editor führt deshalb für genau diese Klassen verborgene Felder mit dem aktuellen Wert mit. Nur für sie: alle 368 mitzuführen wäre größer, bräuchte eine Serialisierung je Klasse und schriebe verschlüsselte Kennwörter in das Dokument.

Die Klassenliste ist ein Literal, und ein Literal, das veralten kann, ist ein Defekt, der auf eine DokuWiki-Aktualisierung wartet. _test/SettingsCarryTest.php hält sie deshalb in beide Richtungen gegen den Quelltext des Konfigurationspakets: eine fünfte solche Klasse lässt den Prüfstand fallen, und eine aufgeführte, die inzwischen eine Wache bekommen hat, ebenfalls.

Setting::shouldBeSaved() lässt einen Wert weg, sobald er der Vorgabe gleicht. „Zurücksetzen“ und „die Vorgabe senden“ sind für den Schreiber also dasselbe.

Der Verweis &wkreset=<schlüssel> löscht deshalb nur den lokalen Wert am anfrage-eigenen Objekt; das Steuerelement zeigt danach die Vorgabe, und das gewöhnliche Speichern entfernt den Schlüssel aus conf/local.php. Drei Eigenschaften folgen daraus, und jede ist der Grund für diese Form:

• es geht ohne JavaScript, für jede Setting-Klasse einschließlich der mehrwertigen, die ein Absendeknopf nicht ausdrücken könnte;
• ein GET schreibt nie – ein Vorablader, ein Lesezeichen oder ein Sammler, der dem Verweis folgt, ändert nichts;
• der Leser sieht vor dem Speichern, was er speichern wird.

&wkreset=* setzt alle Abweichungen des gezeigten Bereichs zurück, mit Rückfrage und Nennung der Anzahl.

&scope= nennt den Bereich: dokuwiki, tpl:<name>, plugin:<name>, dazu die beiden Sichten !changed und !undefined. Das Ausrufezeichen trennt sie baulich von einem Paketnamen – ein Paketverzeichnis kann so nicht heißen, weil der Manifestlader es gegen [A-Za-z0-9_-]+ prüft.

Der Bereich wird je Benutzer gemerkt, und das ist keine Bequemlichkeit. admin_plugin_config::handle() leitet nach erfolgreichem Speichern auf ?do=admin&page=config – ohne Bereich, und nichts in diesem Paket kann das ändern, weil es in preProcess() geschieht, lange bevor der Bildschirm existiert. Ohne das Merken landete jedes Speichern in den Kerneinstellungen zurück, gleich welches Paket man gerade bearbeitet hat.

Setting::prompt() liefert eine Zeichenkette, und eine Zeile braucht zwei Dinge: etwas zum Überfliegen und etwas zum Lesen.

Ein Schnitt an der ersten Klauselgrenze des Prompts ergäbe Überschriften wie „Absendername, den Empfänger sehen, z“ – der Schnitt landete in „z. B.“ – und „Verlangt den zweiten Faktor eines bereits enrollten Benutzers bei jedem“. Ein Satzfragment ist schlechter als keine Überschrift: es liest sich wie eine und ist keine. Und jede Regel, die diese beiden Fälle behebt, ist eine Regel über deutsche Abkürzungen, in einem Feld, das in fünf Sprachen existiert.

Die Überschrift ist deshalb der Schlüssel selbst – das, was die Dokumentation nennt, was der Support erfragt und was ein Administrator in die Suche tippt. Der Prompt bleibt ganz und steht als Erklärung darunter. Dieselbe Aufteilung, die der Einstellungs-Editor von VS Code trifft, aus demselben Grund: eine Kennung ist stabil, ein Satz nicht.

Kein „veraltet“-Filter. DokuWiki hat kein solches Feld. Das Wort aus einem Prompt zu lesen wäre eine Vermutung im Gewand von Metadaten: sie hinge an der Übersetzung, schlüge bei jedem Satz an, der ein veraltetes Verfahren nur erwähnt, und antwortete in fünf Sprachen verschieden. Stattdessen liest der Editor einen optionalen Metadatenparameter _deprecated, den ein Paket in seiner conf/metadata.php setzen kann; die Gruppe erscheint, wenn etwas darin ist.

Dafür gibt es zwei Sichten, für die eine Quelle existiert: Geändert (Setting::isDefault()) und Unbekannte Schlüssel (Configuration::getUndefined() – Schlüssel, die in der Datei stehen und die kein Paket deklariert; sie sind nicht editierbar und bleiben beim Speichern erhalten).

Die Aktivitätsleiste bleibt eine Paketliste. Ein Umbau auf administrative Arbeitsbereiche änderte das Vokabular einer gemeinsamen Fläche – er berührte den Markenvertrag und die je Benutzer gespeicherte Anordnung – und gehört deshalb nicht zu diesem Bildschirm.

Beide Rasterspuren einer Zeile sind minmax(0, …). Keine Spur kann von ihrem Inhalt bemessen werden, und damit kann keine Beschriftung, kein Satz und kein Wert ein Steuerelement aus dem Sichtbereich schieben – das ist nicht Geschmack, sondern genau der Defekt, gegen den dieser Bildschirm gebaut wurde.

Unter 1024 px wandert das Steuerelement unter den Text; unter 768 px wird das Zeilenmenü zum Bogen und ein Kontrollkästchen 24 px groß. Die Umschaltpunkte sind die dieser Installation (768/1024/1280), nicht die 700/1200 der ursprünglichen Vorgabe: die vorhandene Leiter wird in Schale und Hausvorlage zwanzigmal verwendet und ist im Kopf von wiki-layout.css als Stufenmodell beschrieben.

• <label for> nur, wo es stimmt. Eine mehrwertige Einstellung rendert ein Eingabefeld je Auswahl, und keines davon trägt die Kennung der Einstellung selbst; ein Label, das dorthin zeigt, verknüpfte die Beschriftung mit nichts – schlechter als eine einfache Beschriftung, weil ein Screenreader die Verknüpfung ansagt.
• Zustand nie nur über Farbe. „Geändert“ ist ein Balken und eine Textmarke.
• Das Zeilenmenü ist ein <details> – mit der Tastatur bedienbar und ohne Skript.
• Meldungen laufen über eine Live-Region, auch wenn zusätzlich ein Toast erscheint: die Toast-Auszeichnung dieser Suite ist keine.
• Trefferflächen mindestens –wk-touch-min (40 px, unter grobem Zeiger 44).

• FluentUI: Admin-Bereich (vertieft) – die Regionen, in die dieser Bildschirm liefert
• Workbench Plugin Contract v1 – die vier Haken eines Ersatzbildschirms
• Vertical Grid: Grundlagen – die Spurdefinition der Beschriftungsspalte
• FluentUI: Design-Tokens – –wk-touch-min und die Berührungstoken