WordPress-Dashboards mit DataViews: weniger Oberfläche neu erfinden
DataViews, DataForm und das neue Design System: Wie ich moderne WordPress-Verwaltungsoberflächen aufbauen würde und wo noch Vorsicht sinnvoll ist.
Eine gute Verwaltungsoberfläche fällt für mich dadurch auf, dass man sie schnell versteht. Datensatz finden, Details prüfen, etwas ändern, weiterarbeiten. Wenn ich dafür erst das Bedienkonzept eines einzelnen Plugins lernen muss, ist schon etwas verloren gegangen.
Deshalb interessiert mich die Entwicklung rund um die WordPress-Komponenten gerade besonders. Aus Werkzeugen für den Editor entsteht ein breiterer Baukasten für Verwaltungsoberflächen. Ich würde heute genauer hinschauen, bevor ich für ein Plugin wieder eine eigene Tabelle, eigene Filter und eigene Formularlayouts entwickle.
Die Pakete haben unterschiedliche Aufgaben
@wordpress/components liefert die bekannten grundlegenden React-Bedienelemente. Das Paket ist ausdrücklich auch für Oberflächen außerhalb des Block-Editors gedacht. Es bleibt ein sinnvoller Ausgangspunkt für Buttons, Hinweise und andere klassische Steuerelemente. Paketdokumentation
@wordpress/dataviews ergänzt Tabellen, Listen und Raster mit DataViews sowie Bearbeitungsformulare mit DataForm. Felddefinitionen beschreiben die Daten; deren Anbindung bleibt Aufgabe der Anwendung. DataViews-Handbuch
Für eine Projektverwaltung würde ich zuerst die Fragen aufschreiben, die Menschen beantworten wollen: Welche Projekte brauchen Aufmerksamkeit? Wer ist zuständig? Was hat sich geändert? Erst danach würde ich Spalten und Aktionen festlegen. Eine Komponente kann viel anzeigen. Das ist kein Grund, alles gleichzeitig anzuzeigen.
Was daran aktuell neu ist
Mit WordPress 7.1 kamen Grundlagen für das Theming von Verwaltungsoberflächen hinzu. Das Stylesheet wp-theme stellt semantische Gestaltungstokens bereit; ein ThemeProvider erlaubt begrenzte Anpassungen innerhalb eines Bereichs. Das betrifft die Administration, nicht die Gestaltung eines Block Themes für Besucher. Dev Note zum Design System
Parallel entwickelt sich @wordpress/ui. Hier ist die Unterscheidung wichtig: Die Dokumentation bezeichnet das Paket weiterhin als experimentell. Es wird über npm ausgeliefert und ist nicht einfach als neues window.wp.ui in jeder WordPress-Installation vorhanden. Ich würde deshalb keine pauschale Migration aller vorhandenen Komponenten empfehlen. Dokumentation zu @wordpress/ui
Meine Wahl wäre pragmatisch: stabile vorhandene Komponenten nutzen, neue Bausteine gezielt prüfen und die unterstützte WordPress-Version ausdrücklich festlegen. Ein Plugin für eine kontrollierte Installation hat andere Spielräume als eine Erweiterung, die auf vielen älteren Websites funktionieren muss.
Mit einer kleinen Übersicht anfangen
Mein erster Schritt wäre eine einzige funktionierende Liste mit wenigen Feldern. Ein Titel, ein Status, ein Änderungsdatum. Dazu eine klare Hauptaktion. Keine zusätzliche Kartenansicht, solange Bilder oder räumliche Orientierung keinen echten Nutzen bringen.
Beim Setup lohnt Genauigkeit: Für Plugins oder Themes mit @wordpress/scripts nennt das Handbuch den Importpfad @wordpress/dataviews/wp. Außerhalb von WordPress wird @wordpress/dataviews verwendet. Auch die Styles gehören dazu: In WordPress muss die Plugin-CSS von wp-components abhängen; eigenständige Anwendungen benötigen zusätzlich die dokumentierten Theme-, Components- und DataViews-Styles. Setup im Handbuch
Ich würde diese Infrastruktur einmal sauber einrichten und dann am eigentlichen Ablauf arbeiten. Eine kaputte Dropdown-Ebene oder fehlende Abstände lassen sich durch mehr Fachlogik nicht reparieren.
Ein kleiner Konfigurationsausschnitt für Datensätze mit name und status könnte so beginnen:
Diese Felder werden an DataViews übergeben; Daten, Ansichts-State und Pagination fehlen hier bewusst. Ein vollständigeres Gerüst zeigt das offizielle Plugin-Tutorial.
Ansicht und Daten bewusst verbinden
Die Ansicht ist Zustand: Suche, Sortierung, Filter und aktuelle Seite. Für größere Datenmengen würde ich daraus begrenzte Serverabfragen ableiten, statt sämtliche Einträge in den Browser zu laden. Wechseln Filter, beginnt die Liste wieder auf Seite eins. Langsame Antworten dürfen neuere Suchergebnisse nicht überschreiben.
Das sind Architekturentscheidungen meiner Anwendung. Ebenso würde ich Ladefehler, leere Ergebnisse und noch nie angelegte Datensätze unterschiedlich behandeln. „Keine Ergebnisse“ hilft wenig, wenn tatsächlich die Verbindung fehlgeschlagen ist.
Bei Formularen möchte ich einen sichtbaren Unterschied zwischen geändert und gespeichert. Ein erfolgreicher Klick allein ist noch keine erfolgreiche Speicherung. Fehlermeldungen gehören an das betroffene Feld; nach dem Speichern muss die Übersicht den tatsächlichen Stand zeigen.
Bestehende WordPress-Ansichten gezielt erweitern
Nicht jede Anforderung braucht eine eigene Admin-Seite. WordPress 7.1 bietet Filter für die View-Konfiguration von Seiten, Templates, Template-Teilen und Patterns im Site Editor. Darüber lassen sich unter anderem Vorgabeansichten und die Quick-Edit-Form konfigurieren. Das ist eine konkrete Erweiterungsmöglichkeit dieser Screens, keine universelle API für sämtliche alten Admin-Tabellen. Dev Note zu den Filtern
Wenn die Aufgabe dort hingehört, würde ich diesen Weg zuerst prüfen. Eine zweite Oberfläche für dieselben Inhalte kostet Nutzer Aufmerksamkeit und mich langfristig Wartungszeit.
Gute Komponenten ersetzen keine Berechtigungen
Ein ausgeblendeter Löschen-Button schützt keinen REST-Endpunkt. Eigene Routen brauchen passende permission_callback-Prüfungen; Berechtigungen müssen für die konkrete Aktion und gegebenenfalls den betroffenen Datensatz gelten. Eingaben werden zusätzlich serverseitig validiert. WordPress-Handbuch zu eigenen Endpunkten
Mein Fazit ist deshalb ziemlich bodenständig: Ich möchte diese Bausteine nutzen, um weniger Standardoberfläche selbst zu pflegen. Die gewonnene Zeit gehört den Arbeitsabläufen, verständlichen Zuständen und zuverlässigen Daten. Genau dort entscheidet sich für mich, ob ein Dashboard im Alltag gut ist.
Recherchestand: 29. September 2026. Paketdokumentation und unterstützte WordPress-Version vor der Umsetzung abgleichen.