Das WordPress Admin Dashboard wirkt auf den ersten Blick wie „etwas aus der Mode gekommen“. Die Grundstruktur mit der linken Navigation und der oberen Admin-Leiste hat sich seit einigen Jahren kaum verändert. Zugegeben, es gab immer wieder Neuerungen, die das Arbeiten im Dashboard stark geprägt haben: visuelle Modernisierungen, der Wechsel zum Block-Editor und später die Ausweitung der Block-Philosophie auf das gesamte Website-Design.

Vielleicht gerade deshalb stellt sich das WordPress-Backend an manchen Stellen gerade wie ein Flickenteppich dar. Besonders deutlich zeigt sich das im Vergleich des modernen Site-Editors mit den klassischen Verwaltungsoberflächen wie den Listen von Beiträgen, Seiten, Benutzern oder im Multisite-Kontext von Sites, Plugins und Themes. Diese Bereiche sind seit langem nahezu unverändert geblieben.
Sie basieren auf einer inzwischen veralteten technischen Grundlage, die nur schwer erweiterbar ist und deren Grenzen immer offensichtlicher werden.
Genau da soll meine Diskussion beginnen: Für meine Multisite-Präsentation auf dem WordCamp US 2025 in Portland habe ich die Herausforderungen und Chancen ausgearbeitet. Mit neuen Komponenten wie DataViews und DataForm gibt es endlich eine moderne Basis, um diese Oberflächen konsistenter, flexibler und benutzerfreundlicher zu gestalten; auch und gerade im Network-Admin-Dashboard.

Die listenartigen Verwaltungsoberflächen in WordPress basieren bis heute auf der PHP-Klasse WP_List_Table. Dies ist über die Jahre stabil geblieben, bietet aber kaum echte Erweiterungsmöglichkeiten. Deshalb stellt sich mir die Frage: Machen Tickets, die auf Verbesserungen an diesen alten Admin-Listen abzielen, überhaupt noch Sinn? Langfristig braucht es nicht noch mehr Ausarbeitung des Bestehenden, sondern eine moderne und leicht zu erweiternde Basis für alle Admin-Screens.
DataViews und DataForm liefern eine einheitliche Oberfläche für das Darstellen und Bearbeiten von Daten. Damit sie sinnvoll eingesetzt werden können, brauchen sie eine solide Datenquelle: die REST API. Für Standard-Post- und Taxonomie-Listen ist die REST API weitgehend vorhanden. Für Multisite- und Netzwerk-Screens fehlen jedoch zentrale Endpoints. Deshalb ist die Weiterentwicklung der REST API eine entscheidende Voraussetzung.

An diesem Punkt zeigt sich ein klassisches Dilemma. In der Core-Entwicklung sollen die obengenannten Komponenten langfristig einen Standard bilden, doch dafür fehlen noch viele notwendige REST-Endpoints. Im Gutenberg-Projekt werden sie zwar bereits getestet, aber nur im Kontext des Block-Editors – nicht im Network Admin. Gerade Multisite bräuchte dringend modernisierte Screens, kann aber ohne die neuen React-Komponenten kaum sinnvoll starten.
Das Ergebnis ist Stillstand: API und Interface hängen gegenseitig voneinander ab. Tatsächlich ist es so, dass die fehlenden Endpoints in einem sogenannten Feature Plugin bereitstehen. Allerdings ist der letzte Commit in dem Repository mehr als 6 Jahre alt. Die fehlende Notwendigkeit (oder ist es der zu kleine Interessentenkreis?) hat dem Projekt nicht geholfen. Hier könnte das MultiSyde-Plugin helfen, in dem ich einen Proof of Concept untergebracht habe.
Damit wird MultiSyde zu der Art Brücke, die meine Kollegen der WordPress Agentur Syde und ich gleich zu Anfang des Projekts vorhergesehen haben: ein Experimentierfeld, um Ideen praktisch auszuprobieren und ihre Machbarkeit zu beweisen. Die gewonnenen Erkenntnisse können wiederum helfen, realistische Core-Features zu definieren. Denkbar ist auch, dass MultiSyde mittelfristig als Inkubator dient, um bestimmte Funktionalitäten später in den Core zu überführen.
All diese Überlegungen laufen übrigens nicht gegen die offizielle WordPress-Roadmap, im Gegenteil:
Sie sind Teil der erklärten Ziele von Phase 3 des Gutenberg-Projekts, das sich dem Redesign des Admin-Dashboards widmet. Im entsprechenden Beitrag im Core-Blog wird ausdrücklich hervorgehoben, dass die klassischen Verwaltungsoberflächen eine moderne, konsistente Grundlage brauchen. DataViews und DataForm sind so betrachtet also keine Nebenschauplätze, sondern Bausteine dieser Vision und im Multisite-Kontext besonders wichtig.
Erwähnungen