Wenn Sie eine WordPress-Website an einen Kunden übergeben, ist das Standard-Dashboard oft überwältigend. Es ist voll mit Upsell-Hinweisen, Menüs wie Kommentare (obwohl Kommentare deaktiviert sind) und technischem Fachjargon, den Redakteure nicht brauchen.
Ein generisches Dashboard sagt: Ich habe ein Theme installiert. Ein angepasstes Dashboard sagt: Ich habe eine Anwendung gebaut, die zu eurem Arbeitsablauf passt.
Auf WordCamp Rhein/Ruhr hörte man in den Agency-Tracks immer wieder dieselbe Klage: Der Kunde ruft nicht wegen Content, sondern weil er im Backend nicht findet, was gestern noch unter einem anderen Menü lag. Admin-UX ist Support-Prävention. In diesem Leitfaden geht es um Menüs, Toolbar, Dashboard-Widgets und leichtes White-Labeling mit den Core-APIs aus dem Customize Admin Handbook.
Aufräumen des Admin-Menüs
Der erste Schritt ist remove_menu_page. Die meisten Kunden müssen Werkzeuge oder Einstellungen nicht sehen. Prüfen Sie Capabilities, nicht Benutzer-IDs. Verstecken Sie niemals Menüs vor Administratoren, sonst verlieren Sie selbst den Überblick auf Staging.
/**
* Admin-Menü für Nicht-Admins bereinigen
*/
function wppoland_clean_admin_menu() {
if ( current_user_can( 'manage_options' ) ) {
return;
}
remove_menu_page( 'tools.php' );
remove_menu_page( 'options-general.php' );
remove_menu_page( 'edit-comments.php' );
remove_menu_page( 'edit.php?post_type=acf-field-group' );
remove_submenu_page( 'themes.php', 'theme-editor.php' );
remove_submenu_page( 'plugins.php', 'plugin-editor.php' );
}
add_action( 'admin_menu', 'wppoland_clean_admin_menu', 999 );Priorität 999 ist Absicht: Viele Plugins registrieren ihre Menüs spät. Wer zu früh entfernt, trifft leere Slots und lässt die Einträge später wieder auftauchen. Die Administration Menus-Doku listet Top-Level- und Submenu-Hooks sauber; halten Sie sich an die dortigen Slugs statt an übersetzte Labels.
remove_menu_page blendet den Link nur aus. Ein kluger Benutzer kann weiter /wp-admin/options-general.php öffnen. Um den Zugriff wirklich zu blockieren, prüfen Sie auf admin_init oder current_screen die Capability und brechen mit wp_die ab. Menü-Kosmetik und Zugriffskontrolle sind zwei Schichten.
Deutsche Agenturen treffen oft auf gemischte Rollen: Redaktion mit edit_pages, Shop-Manager mit WooCommerce-Capabilities, Marketing mit ACF-Optionsseiten. Eine pauschale Liste ohne Capability-Check erzeugt Tickets der Form „Plugin X fehlt“ - obwohl nur der Menüpunkt fehlt. Dokumentieren Sie pro Rolle, was sichtbar bleibt, und prüfen Sie das nach jedem Plugin-Update erneut.
Eigene Menüseiten hinzufügen
Verwenden Sie keine Theme-Options-Frameworks, wenn eine einfache Seite reicht. Die native API ist leicht und landet im Core-Menü ohne Extra-Dependency.
function wppoland_register_support_page() {
add_menu_page(
'Kundensupport',
'Support',
'edit_posts',
'wppoland-support',
'wppoland_render_support',
'dashicons-sos',
90
);
}
add_action( 'admin_menu', 'wppoland_register_support_page' );
function wppoland_render_support() {
?>
<div class="wrap">
<h1>Brauchen Sie Hilfe?</h1>
<div class="card">
<h2>Kontaktieren Sie Ihren Entwickler</h2>
<p>E-Mail: <a href="mailto:[email protected]">dev@wppoland.com</a></p>
<p>Kurzvideos zur Pflege liegen im gemeinsamen Drive; Ticket-System: Link im Projekt-Handbuch.</p>
</div>
</div>
<?php
}add_menu_page erwartet Capability, Slug und Callback. Position 90 sitzt weit unten und kollidiert seltener mit WooCommerce oder Yoast. Für Unterseiten nutzen Sie add_submenu_page mit dem Parent-Slug Ihrer Support-Seite, statt alles in eine lange Callback-Datei zu pressen.
Inhalt der Support-Seite: SLA-Zeiten, Link zum Ticket-Tool, zwei Absätze „So aktualisieren Sie Beiträge“, kein Marketing-Banner. Redakteure öffnen diese Seite, wenn sie unsicher sind - dann soll sie Antworten geben, keine Upsells.
Anpassen der Toolbar
Die Toolbar ist im Frontend für eingeloggte Benutzer sichtbar. Sie eignet sich für Schnellaktionen wie Cache leeren oder Im Page Builder bearbeiten. Über den Hook admin_bar_menu entfernen und ergänzen Sie Nodes.
function wppoland_customize_toolbar( $wp_admin_bar ) {
$wp_admin_bar->remove_node( 'wp-logo' );
$wp_admin_bar->add_node( [
'id' => 'clear-redis',
'title' => 'Cache leeren',
'href' => admin_url( 'admin-post.php?action=wppoland_clear_cache' ),
'meta' => [ 'title' => 'Redis Object Cache leeren' ],
] );
}
add_action( 'admin_bar_menu', 'wppoland_customize_toolbar', 999 );Das WordPress-Logo in der Toolbar ist für Kunden oft der Einstieg in „Über WordPress“ und externe Links. Entfernen Sie es, wenn die Marke des Kunden im Vordergrund stehen soll. Für die Cache-Aktion brauchen Sie zusätzlich einen admin_post_-Handler mit Nonce und Capability-Check - die Toolbar liefert nur den Einstieg.
Auf deutschsprachigen Projekten sehen Redakteure die Toolbar oft auf dem Live-Frontend während Freigaberunden. Halten Sie Labels kurz und deutsch; vermeidet Rückfragen à la „Was ist Redis?“. Technischen Kontext legen Sie in meta.title oder in die Support-Seite.
Dashboard-Widgets: der Willkommensbildschirm
Wenn sich ein Kunde einloggt, landet er im Dashboard. Standard-Widgets wie WordPress-Veranstaltungen oder Schneller Entwurf helfen Redaktionsteams selten. Ersetzen Sie sie durch ein Status-Widget mit den Dingen, die Sie wöchentlich ohnehin erklären.
function wppoland_dashboard_widgets() {
remove_meta_box( 'dashboard_primary', 'dashboard', 'side' );
remove_meta_box( 'dashboard_quick_press', 'dashboard', 'side' );
wp_add_dashboard_widget(
'wppoland_status_widget',
'Website-Status',
'wppoland_render_status_widget'
);
}
add_action( 'wp_dashboard_setup', 'wppoland_dashboard_widgets' );
function wppoland_render_status_widget() {
echo '<p><strong>WordPress Core</strong>: Status über Site Health prüfen</p>';
echo '<p><strong>Backups</strong>: laut Hosting-Plan (Uhrzeit im Projekt-Handbuch)</p>';
echo '<p><strong>Traffic</strong>: Analytics-Link aus dem Übergabe-Dokument</p>';
}Schreiben Sie keine erfundenen Ampeln und keine Fake-Traffic-Zahlen in Widgets. Verlinken Sie auf Site Health, auf das reale Backup-Dashboard des Hosters und auf Analytics, das der Kunde bereits nutzt. Das Widget ist Navigation, kein Reporting-Ersatz.
Wenn mehrere Plugins eigene Dashboard-Boxen registrieren, priorisieren Sie: Support-Widget und Site Health oben, Marketing-Feeds von Plugins weg. remove_meta_box braucht die korrekte Context-Position (normal, side, column3); bei Fehlschlägen hilft ein Blick in den HTML-Quelltext der Meta-Box-ID.
White Labeling via CSS
Zum Schluss Feinschliff. Laden Sie eigene Admin-CSS, die zum Branding des Kunden oder der Agentur passt. Inline-Styles wie unten eignen sich für Prototypen; in Produktion gehört die Datei über wp_enqueue_style mit admin_enqueue_scripts und Dependency auf wp-admin.
function wppoland_admin_styles() {
echo '<style>
#wpadminbar { background: #2c3e50; }
#toplevel_page_wppoland-support .wp-menu-image { color: #e74c3c !important; }
/* Plugin-Hinweise gezielt ausblenden, nicht alle Notices */
</style>';
}
add_action( 'admin_head', 'wppoland_admin_styles' );Pauschales Ausblenden von .notice.is-dismissible ist riskant: Core-Warnungen zu PHP, Datenbank und kritischen Updates verschwinden mit. Filtern Sie Notices über Plugin-Klassen oder den Hook admin_notices. Farbänderungen an der Admin Bar reichen oft; Login-Logo und Favicon gehören in separate Hooks (login_enqueue_scripts, Site Icon).
Datenschutz-Hinweise im Admin sind selten nötig, außer Sie zeigen personenbezogene Ticket-Daten auf der Support-Seite. Dann reicht ein kurzer Satz, dass Support-Inhalte der Auftragsverarbeitung unterliegen - ohne den Beitrag in eine DSGVO-Checkliste zu verwandeln.
Untermenüs und Plugin-Chaos
Top-Level-Aufräumen reicht selten. SEO-Plugins, Formular-Plugins und Page Builder hängen Unterpunkte unter Beiträge, Medien oder Einstellungen. remove_submenu_page( $parent, $child ) braucht exakte Child-Slugs; geratene Strings schlagen still fehl.
Pragmatischer Workflow in Agenturen: einmal als Redakteur einloggen, jeden Menüpunkt notieren, den niemand braucht, dann die IDs aus dem HTML der Admin-Sidebar lesen (#menu-posts, #toplevel_page_...). Danach erst den Cleanup-Code schreiben. Nach jedem Major-Update von Yoast, Rank Math oder Elementor denselben Rundgang - Plugin-Hersteller verschieben Slugs gelegentlich.
Für wiederkehrende Kundenprojekte lohnt ein kleines Must-Use-Plugin mit Feature-Flags pro Environment: auf Staging bleiben Theme- und Plugin-Editor sichtbar, auf Live verschwinden sie für Nicht-Admins. Dieselbe Codebasis, unterschiedliche Flags in wp-config.php oder Hosting-Env-Vars. So vermeiden Sie Drift zwischen „was wir entwickelten“ und „was der Kunde sieht“.
Reihenfolge der Hooks
admin_menu und admin_bar_menu feuern für viele Plugins. Wer mit Priorität 10 entfernt, verliert gegen Registrierungen bei 20 oder 99. Deshalb 999 für Cleanup und eigene Nodes - nicht aus Magie, sondern weil späte Registrierung der Default vieler Plugins ist.
Dashboard-Setup läuft über wp_dashboard_setup. Dort gilt dasselbe: erst fremde Meta-Boxen entfernen, dann die eigene registrieren. Wenn ein Widget „wieder auftaucht“, liegt meist eine zweite Registrierung später im Request, nicht an Caching.
Praxischeck vor der Übergabe
Vor Go-Live einmal mit der Kundenrolle einloggen (nicht als Super-Admin):
- Menü: nur die Einträge, die Redaktion braucht; keine ACF-Field-Groups, kein Theme-Editor.
- Toolbar: Cache-Aktion nur für Rollen mit der passenden Capability; kein WP-Logo, wenn Branding gewünscht.
- Dashboard: ein Status-Widget, keine Plugin-Feeds; Links im Übergabe-Dokument geprüft.
- Support-Seite: aktuelle Mail, Ticket-URL, zwei Pflege-Schritte in Deutsch.
- Staging vs. Live: dieselben Hooks, unterschiedliche Feature-Flags, damit Debug-Menüs nicht auf Produktion landen.
Zusätzlich: ein zweiter Browser ohne Adblocker, weil manche Notices und Menü-Icons sonst anders wirken. Und ein kurzer Screencast (fünf Minuten) für die Redaktion: wo liegt Support, wo liegen Seiten, wo liegen Produkte. Der Screencast ersetzt kein Handbuch, reduziert aber die ersten Tickets nach Launch.
Dieser Check dauert oft weniger als eine Stunde und spart die ersten Wochen Support. Wenn Sie Admin-Anpassung als festen Teil der Übergabe planen, gehört sie in denselben Scope wie CPT-Registrierung und Capability-Mapping - nicht als „nice to have“ in der Restzeit nach Design-Freeze.
Typische Fehler aus Projekten
Menü versteckt, Capability bleibt. Redaktion bookmarkt /wp-admin/options-general.php und landet trotzdem in den Einstellungen. Cleanup ohne admin_init-Guard ist unvollständig.
Alle Notices tot. Ein CSS-One-Liner blendet auch die PHP-Versionswarnung aus. Monate später scheitert ein Update, und niemand hat die gelbe Box gesehen.
Toolbar-Aktion ohne Nonce. admin-post.php?action=... ohne check_admin_referer und ohne Capability ist ein Einladungsschreiben. Die Toolbar ist nur UI; der Handler braucht die übliche Absicherung.
White-Label-Plugin von der Stange. Viele White-Label-Plugins ändern Login, Footer-Text und Branding global - und kollidieren mit Multisite oder mit Hosting-Panels. Für Menü und Dashboard reichen die Core-Hooks; schwere White-Label-Suites brauchen Sie nur, wenn Login-Branding und E-Mail-From wirklich Teil des Auftrags sind.
Deutsche Labels, englische Plugin-Reste. Nach dem Cleanup bleiben gemischte Sprachen im Menü. Entweder alle sichtbaren Labels über gettext-Filter angleichen oder akzeptieren, dass Drittanbieter-Strings Englisch bleiben - und das im Handbuch erwähnen, damit niemand „kaputte Übersetzung“ meldet.
Was Admin-Anpassung nicht ersetzt
Menü-Bereinigung ersetzt keine Rollenkonzepte. Wer Redakteuren manage_options gibt und dann Menüs versteckt, baut Theater. Besser: eigene Rolle mit den nötigen Caps, Menü nur als zweite Schicht.
Toolbar-Links ersetzen keine dokumentierten Runbooks. Ein Button Cache leeren ohne Logging und ohne Hinweis, wann man ihn nicht drücken soll, erzeugt mehr Schaden als Nutzen. Schreiben Sie in die Support-Seite zwei Sätze: vor Deploy Cache leeren, während Lasttests nicht spam-klicken.
CSS-White-Label ersetzt keine Barrierefreiheit. Kontrast der Admin Bar prüfen; Dashicons allein reichen nicht als einzige Hinweisgeber für Status. Tastaturfokus in eigenen Admin-Seiten testen, besonders wenn Sie .card und Custom-Markup mischen.
Admin-Anpassung ersetzt auch keine Schulung. Ein aufgeräumtes Backend hilft; ohne fünf Minuten Walkthrough suchen Redakteure trotzdem unter Medien, was unter Seiten liegt.
Kurzfazit
Die Anpassung des Admin-Bereichs ist User Experience für Redaktion und Shop-Teams. Unordnung weg, Arbeitswege hervorheben, Support-Seite als festen Anker. Nutzen Sie Core-Hooks statt schwerer Options-Frameworks, prüfen Sie Capabilities zweimal (Menü und URL), und halten Sie Widgets ehrlich.
Orientierung für APIs und Hook-Reihenfolge bleibt das Customize-Admin-Handbook und die Reference zu add_menu_page sowie admin_bar_menu. Der Rest ist Projekthandwerk: Rollen, Flags, Übergabe-Check.
Solche Anpassungen sind fester Teil unserer Entwicklungsarbeit an WordPress-Backends.
