Projekt

Custom WordPress Admin-Dashboard

Bevor das aktuelle CMS existierte, lief der operative Kern dieser Site in WordPress: eine kuratierte Admin-Schicht über wp-admin - eigene Landingpages, Shortcuts und rollenbewusste Oberflächen, die zum Arbeitsalltag passten. Ein bewusster Mittelweg zwischen Standard-WordPress und kompletter Neuentwicklung.

← Zurück zu Projekten Kontakt zu WordPress- oder CMS-Arbeit

Was es war

Stock-wp-admin ist mächtig aber generisch. Für den Alltag - Content-Gesundheit, Sprünge zu Theme-Hooks, Plugin-Hygiene und interne Utilities - wollte ich ein Dashboard, das meinen Stack widerspiegelt, nicht jede mögliche Installation. Das Custom-Admin-Projekt trug diese Absicht: weiter WordPress darunter, aber der erste Bildschirm war meiner.

Die Landing-Erfahrung ersetzt verstreutes Menü-Suchen durch ein zielgerichtetes Overview.

Die Umsetzung blieb innerhalb unterstützter Erweiterungspunkte: Admin-Menüs, Top- und Untermenüseiten, Styles und Skripte nur wo nötig, sowie Capability-Prüfungen, damit Kund:innen oder Mitwirkende keine Tools sahen, die nicht für sie bestimmt waren. Kein Bearbeiten von Core-Dateien und kein fragiles Umschreiben von wp-admin-Markup.

Screenshots auf dieser Seite stammen aus img/projects/wordpress/custom_admin_dashboard/ - dieselben Dateien füllen die Galerie unten. Legen Sie dort PNG oder WebP ab, um die Story zu aktualisieren, ohne PHP anzufassen.

Funktionen und UX

Das Dashboard priorisierte Signale auf einen Blick: was Aufmerksamkeit braucht, wohin der nächste Klick führt, und Verbindungen zu eigenen Plugins (z. B. Task Manager) derselben Installation. Block-artige Bereiche und klare Typografie reduzierten Rauschen gegenüber dem Gefühl „alles ist eine Kiste“.

Strukturierte Blöcke halten häufige Aktionen einen Klick vom Admin-Home entfernt.

Rollentrennung spielte eine Rolle: Administrator:innen sahen operative Steuerung, Redakteur:innen inhaltsnahe Shortcuts. Das spiegelte später das Capability-Modell des eigenständigen CMS - nur die Laufzeit wechselte.

  • Eigene Admin-Top-Level-Seiten und geordnete Untermenüs
  • Rollen- und capability-gesteuerte Bereiche
  • Eingrenzendes CSS/JS, damit der Rest von wp-admin stabil bleibt
  • Deep Links zu Plugins, Tools und themebezogenen Screens
  • Platz für Status-Snippets (Updates, Warteschlangen, Hinweise)

Technische Herangehensweise

Technisch ist das klassisches WordPress-Plugin-Terrain: Bootstrap auf plugins_loaded oder admin_menu, add_menu_page / add_submenu_page sowie wp_enqueue_style / wp_enqueue_script mit Versions-Hashes für den Cache. Die Daten kamen aus bestehenden Tabellen - Options, Post-Counts, Transients - nicht aus einem parallelen Schema.

Wo AJAX oder REST halfen, blieben Endpunkte namespaced und nonce-geschützt. Ziel war immer „upgrade-sicher“: ein WordPress-Core-Update soll das Dashboard nicht still zerstören, weil private Hooks und Monkey-Patches vermieden wurden.

add_action('admin_menu', function () {
    add_menu_page(
        'Dashboard', 'Mein Dashboard',
        'manage_options', 'my-dash-home',
        'my_admin_dashboard_render', 'dashicons-layout', 2
    );
});
Registrierung über die öffentliche Admin-API hält das Verhalten über Updates hinweg nachvollziehbar.

Richtung eigenständiges CMS

WordPress war lange der richtige Gastgeber: gereiftes Ökosystem, vertraute Oberfläche, schnelle Iteration. Mit der Zeit wuchs die Produktvision über „alles in wp-content“ hinaus: engere Kontrolle über Auth, Migrationen, Multi-App-Admin und Theme-Packaging motivierten ein PHP-CMS aus dem Nichts - diese Site läuft heute darauf.

Visuelle Linie: Maßgeschneidertes Admin in WordPress vor dem dedizierten CMS-Projekt.

Das Custom-Admin-Dashboard bleibt dennoch relevant als Geschichte: Es zeigt Produktdenken in Grenzen, und viele Muster - Capabilities, Trennung von Admin-„Home“ und Roh-Screens, pragmatisches PHP - flossen direkt ein. Betreiben Sie weiter WordPress, gilt derselbe Ansatz.

Wartbarkeit

Weil der Code öffentliche APIs respektierte, war Wartung meist „Hooks aktuell halten“ und Asset-Versionen erneuern - nicht das Jagen nach WordPress-Interna. Doku in kurzen README-Abschnitten, damit ein Comeback nach Monaten ohne Archäologie auskommt.

API-getriebener Scope zahlt sich bei jedem Core-Update-Zyklus aus.

Wenn Sie Ähnliches einführen, behandeln Sie das Dashboard wie ein Produkt: versionieren, auf Staging gegen Beta-WordPress testen und Interaktionen mit Drittanbieter-Plugins explizit halten.

Screenshots