Wie wp-admin unter der Haube funktioniert |... | WPPoland

Mariusz Szatkowski

Inside WordPress: Anatomie des Administrationsbereichs und Templates

Zuletzt überprüft: 16. Oktober 2026

15 Min. Lesezeit

Leitfaden

500+ WP-Projekte

Full-Stack-Entwickler

#Woraus der WordPress-Adminbereich besteht

Der WordPress-Adminbereich wirkt wie eine einzige Anwendung, technisch ist er aber eine Sammlung gewöhnlicher PHP-Dateien im Verzeichnis wp-admin, die eine Startdatei und einige Dutzend Actions zusammenhalten. Wer die Reihenfolge kennt, in der diese Actions laufen, schreibt Plugins, die Skripte nur dort laden, wo sie gebraucht werden, und die Bildschirme anderer Plugins nicht beschädigen.

Dieser Artikel beschreibt das Verzeichnis wp-admin, den Weg einer einzelnen Anfrage durch den Adminbereich, die Benennung der Bildschirme ($hook_suffix, WP_Screen) und den Unterschied zur Template-Hierarchie des Themes. Dateinamen und Reihenfolge der Actions stammen aus dem Code von WordPress 7.1.3 (zum Zeitpunkt der Prüfung die aktuelle stabile Version) im Spiegel WordPress/WordPress auf GitHub.

#Wie das Verzeichnis wp-admin in WordPress aufgebaut ist

Das Verzeichnis wp-admin enthält die Backend-Dateien der Website. Auf der obersten Ebene liegt jeweils eine Datei pro Bildschirm: edit.php ist die Beitragsliste, post.php und post-new.php übernehmen das Bearbeiten, upload.php ist die Mediathek, options-general.php, options-writing.php und die übrigen options-*.php sind die Unterseiten von Einstellungen, und site-health.php ist Website-Zustand. Die Adresse in der Browserleiste verrät also, welche Datei gerade läuft. Daneben liegen die Unterverzeichnisse network/ (Netzwerkverwaltung in Multisite), user/ (Benutzerbereich in Multisite) und maint/ (Datenbankreparatur).

#Die wichtigsten Dateien im Verzeichnis wp-admin

admin.php - Die Startdatei des Adminbereichs. Jeder Bildschirm beginnt mit require_once __DIR__ . '/admin.php';. Hier wird:

die Konstante WP_ADMIN definiert und wp-load.php geladen
die Funktionen aus wp-admin/includes/admin.php eingebunden
mit auth_redirect() jeder nicht angemeldete Besucher zum Login geschickt
das Menü aufgebaut und der aktuelle Bildschirm festgelegt

index.php - Das Dashboard, die Startseite des Adminbereichs. Es zeigt:

Dashboard-Widgets
Schnellaktionen
WordPress-Neuigkeiten

menu.php - Die Definition der Menüstruktur:

Registrierung der Menüpunkte
die nötigen Berechtigungen für einzelne Bereiche
Icons und Beschriftungen der Menüpunkte

#Unterverzeichnisse von wp-admin

includes/ - Enthält alle Bibliotheksdateien:

class-wp-screen.php - die Klasse, die Admin-Bildschirme verwaltet
template.php - Hilfsfunktionen für Templates
media.php - Medienverwaltung
ajax-actions.php - AJAX-Handler

css/ - Die Stylesheets des Adminbereichs:

wp-admin.css - das Sammel-Stylesheet, das die übrigen importiert
common.css - gemeinsame Stile (der Container .wrap, Hinweise .notice)
colors/ - Farbschemata
forms.css - Formularstile

Jedes Stylesheet gibt es in vier Varianten: als Quelldatei, minifiziert (.min.css) und in zwei Fassungen für Sprachen, die von rechts nach links geschrieben werden (-rtl.css, -rtl.min.css). Dasselbe gilt für die Skripte in js/: Neben common.js liegt common.min.js. Im Produktivbetrieb liefert WordPress die .min-Versionen aus, die Konstante SCRIPT_DEBUG schaltet auf die Quelldateien um, mehr dazu weiter unten.

js/ - JavaScript-Dateien:

common.js - gemeinsame Funktionen
post.js - der Bildschirm zum Bearbeiten von Beiträgen
media-upload.js - Medien-Upload

#Was WordPress beim Aufruf einer wp-admin-Adresse tut

Nehmen wir die Anfrage wp-admin/admin.php?page=meine-seite, also einen Bildschirm, den ein Plugin hinzugefügt hat. Die Datei admin.php geht in Version 7.1.3 nacheinander diese Schritte durch:

Sie definiert WP_ADMIN und bindet wp-load.php ein, damit auch wp-config.php, die Plugins und das Theme. Ab diesem Moment liefert is_admin() den Wert true.
Sie bindet wp-admin/includes/admin.php ein, also die gesamte Admin-API, und ruft auth_redirect() auf.
Sie bindet wp-admin/menu.php ein. Diese Datei baut die Arrays $menu und $submenu mit den Einträgen des Cores und bindet am Ende wp-admin/includes/menu.php ein, das die Action admin_menu auslöst. Genau dort rufen Plugins add_menu_page() auf.
Sie löst die Action admin_init aus.
Aus dem Parameter page berechnet sie den Namen des Seiten-Hooks (get_plugin_page_hook()) und speichert ihn in der globalen Variable $hook_suffix.
Sie ruft set_current_screen() auf, das für diesen Bildschirm das Objekt WP_Screen erzeugt.
Sie löst die Action load-{$page_hook} aus, noch bevor irgendein HTML gesendet wurde.
Sie bindet admin-header.php ein, es sei denn, die Adresse enthält den Parameter noheader.
Sie löst die Action mit dem Namen $page_hook aus. Dort hat add_menu_page() zuvor den Callback des Plugins eingehängt.
Sie bindet admin-footer.php ein und beendet die Ausführung mit exit.

Aus dieser Reihenfolge folgen zwei Dinge, die in der Praxis Plugins kaputt machen. Erstens läuft admin_menu vor admin_init und nicht danach, Code zur Menüregistrierung darf also nicht davon ausgehen, dass etwas aus admin_init schon existiert. Zweitens liefert get_current_screen() bis Schritt 6 den Wert null, weil die Funktion das globale Objekt nur zurückgibt, wenn es eine Instanz von WP_Screen ist. Ein Aufruf in admin_init ergibt also null, in load-{$page_hook} dagegen schon ein funktionierendes Objekt.

Die Action load-{$page_hook} ist der beste Ort, um ein Formular zu verarbeiten, das nach dem Speichern umleitet. Die HTTP-Header sind noch nicht gesendet, wp_safe_redirect() funktioniert also, und der Code läuft nur auf diesem einen Bildschirm. Ein Kommentar in admin.php nennt ein Beispiel: Für eine Plugin-Seite unter Einstellungen heißt der Hook load-settings_page_pluginbasename.

#Was in admin-header.php und admin-footer.php ausgeführt wird

Auch der Kopf des Adminbereichs ist eine Folge von Actions, und ihre Reihenfolge entscheidet, wo Stile und Skripte eingehängt werden. In admin-header.php löst WordPress nacheinander aus:

admin_enqueue_scripts mit dem Argument $hook_suffix, der Ort für wp_enqueue_script() und wp_enqueue_style(),
admin_print_styles-{$hook_suffix} und admin_print_styles,
admin_print_scripts-{$hook_suffix} und admin_print_scripts,
admin_head-{$hook_suffix} und admin_head,
danach bindet es menu-header.php ein, das das Seitenmenü zeichnet, und löst in_admin_header aus,
zum Schluss admin_notices (bzw. network_admin_notices und user_admin_notices in Multisite) sowie all_admin_notices.

In admin-footer.php ist die Reihenfolge ähnlich: in_admin_footer, admin_footer, admin_print_footer_scripts-{$hook_suffix}, admin_print_footer_scripts und admin_footer-{$hook_suffix}. Die Varianten mit Suffix laufen nur auf einem Bildschirm und ersetzen damit eine if-Bedingung im Callback. Die Dokumentation des Hooks admin_enqueue_scripts bezeichnet ihn als den richtigen Hook zum Einbinden von Skripten und Stilen für den Adminbereich (trotz des Namens deckt er beide Typen ab) und empfiehlt, sie anhand von $hook_suffix nur auf den Bildschirmen zu laden, die sie nutzen.

Core-Bildschirme wie options-general.php machen dasselbe ohne den Parameter page: Sie beginnen mit require_once __DIR__ . '/admin.php';, bereiten die Daten vor, binden selbst admin-header.php ein, geben das Formular aus und binden admin-footer.php ein.

#Wie das Template-System des Adminbereichs funktioniert

WordPress nutzt im Adminbereich kein klassisches Template-System wie im Frontend. Stattdessen baut es die Ansichten aus Callback-Funktionen und Hooks auf.

#Aufbau eines Admin-Bildschirms

Jeder Admin-Bildschirm besteht aus drei Hauptteilen. Die folgende Skizze zeigt den Aufbau eines Core-Bildschirms, der Kopf und Fuß selbst einbindet. Der Callback einer Plugin-Seite tut das nicht, weil admin.php Kopf und Fuß für ihn einbindet (Schritte 8 und 10 oben). admin.php bindet den Kopf mit require_once ein, ein zweites require_once im Callback bewirkt also nichts, ein einfaches require oder include gibt den Kopf des Adminbereichs jedoch ein zweites Mal aus.

// Beispielaufbau eines Core-Bildschirms, z. B. wp-admin/options-general.php
require_once __DIR__ . '/admin.php';

// 1. Kopf (Header)
require_once ABSPATH . 'wp-admin/admin-header.php';

// 2. Seiteninhalt (Content)
?>
<div class="wrap">
    <h1><?php echo esc_html(get_admin_page_title()); ?></h1>
    <!-- Hier steht der eigentliche Inhalt -->
</div>
<?php

// 3. Fuß (Footer)
require_once ABSPATH . 'wp-admin/admin-footer.php';

#Callback-Funktionen für Admin-Seiten

Jeder Admin-Seite ist eine Callback-Funktion zugeordnet, die ihren Inhalt ausgibt:

// Admin-Seite registrieren
add_action('admin_menu', function() {
    add_menu_page(
        'Meine Seite',           // Seitentitel
        'Meine Seite',           // Menübeschriftung
        'manage_options',        // Berechtigung
        'meine-seite',           // Slug
        'meine_seite_callback',  // Callback-Funktion
        'dashicons-admin-generic',
        30
    );
});

// Callback-Funktion, die den Inhalt ausgibt
function meine_seite_callback() {
    ?>
    <div class="wrap">
        <h1><?php echo esc_html(get_admin_page_title()); ?></h1>
        <form method="post" action="options.php">
            <?php
            settings_fields('meine_optionsgruppe');
            do_settings_sections('meine-seite');
            submit_button('Änderungen speichern');
            ?>
        </form>
    </div>
    <?php
}

#Wie WordPress den hook_suffix von Plugin-Seiten benennt

Der Rückgabewert von add_menu_page() und add_submenu_page() ist der $hook_suffix des neuen Bildschirms. Derselbe String landet in admin_enqueue_scripts, in den load-*-Hooks und in WP_Screen, deshalb lohnt es sich zu wissen, woher er kommt. Berechnet wird er von der Funktion get_plugin_page_hookname() in wp-admin/includes/plugin.php nach dem Schema {typ}_page_{slug}:

eine Seite der obersten Ebene, die add_menu_page() hinzufügt, bekommt den Typ toplevel, also toplevel_page_meine-seite,
eine Unterseite unter einem Core-Menü bekommt einen Typ, der aus dem Dateinamen des Elternmenüs abgeleitet wird, etwa settings_page_meine-seite unter Einstellungen,
eine Unterseite unter dem Menü eines anderen Plugins bekommt ihren Typ aus dem Array $admin_page_hooks, in dem add_menu_page() den Wert sanitize_title( $menu_title ) speichert.

Der letzte Punkt ist eine Falle für übersetzte Installationen. Läuft der Titel des Elternmenüs durch __(), ändert sich mit der Sprache der Website auch das Suffix aller seiner Unterseiten. Ein Menü mit dem Titel __( 'Reports' ) gibt seiner Unterseite das Suffix reports_page_meine-berichte, doch sobald die Übersetzung des Plugins den Titel auf einem deutschen Adminbereich zu “Berichte” macht, wird daraus berichte_page_meine-berichte. Code, der $hook mit dem zuerst fest eingetragenen Wert vergleicht, funktioniert dann nicht mehr. Sicherer ist es, den Rückgabewert von add_submenu_page() in einer Klasseneigenschaft zu speichern und damit zu vergleichen oder get_current_screen()->id zu prüfen.

#Wofür WP_Screen und get_current_screen gedacht sind

Das Objekt WP_Screen beschreibt den aktuellen Admin-Bildschirm. Zu seinen öffentlichen Eigenschaften gehören unter anderem id, base, parent_base, post_type, taxonomy und action. Für die Seitenliste ist id gleich edit-page, base gleich edit und post_type gleich page, eine einzige Bedingung auf post_type deckt also Liste, Bearbeitung und Neuanlage eines Inhaltstyps ab.

An diesem Objekt hängen auch zwei Oberflächenelemente, die oft ohne Not von Grund auf neu geschrieben werden: Hilfe-Tabs (add_help_tab()) und Bildschirmoptionen (add_option(), etwa die Zahl der Einträge pro Seite einer Liste). Beide gehören in die Action load-{$page_hook}, denn erst dann existiert das Bildschirmobjekt, während der Kopf mit den Schaltflächen “Hilfe” und “Ansicht anpassen” noch nicht ausgegeben wurde.

#Welche body-Klassen ein Admin-Bildschirm bekommt

admin-header.php setzt das Attribut class des body-Tags aus mehreren Quellen zusammen. Die erste Klasse ist $hook_suffix, in dem jedes Zeichen außerhalb von a-z0-9_- durch einen Bindestrich ersetzt wird, ein Plugin-Bildschirm trägt also die Klasse toplevel_page_meine-seite am body. Dazu kommen unter anderem post-type-{typ} und taxonomy-{taxonomie} aus dem Bildschirmobjekt, admin-color-{schema} aus den Profileinstellungen des Benutzers, locale-{sprache}, branch-{version} und version-{version}, multisite und network-admin im Netzwerk sowie wp-theme-{theme} mit dem Namen des aktiven Themes. Eigene Klassen kommen über den Filter admin_body_class hinzu. So kann das CSS eines Plugins über einen Klassenselektor einen einzelnen Bildschirm ansprechen, ohne ein eigenes Stylesheet zu laden.

#Wie Hooks im WordPress-Adminbereich funktionieren

Hooks sind der Mechanismus, mit dem sich das Verhalten des Adminbereichs ändern lässt, ohne Core-Dateien von WordPress anzufassen.

#Actions im Adminbereich

Actions führen Code zu einem bestimmten Zeitpunkt aus:

// Skript nur im Adminbereich einbinden
add_action('admin_enqueue_scripts', function($hook) {
    // $hook enthält die Kennung der aktuellen Seite
    if ($hook === 'toplevel_page_meine-seite') {
        wp_enqueue_script(
            'meine-seite-js',
            plugin_dir_url(__FILE__) . 'js/admin.js',
            ['jquery'],
            '1.0.0',
            true
        );
    }
});

// Admin-Kopf anpassen
add_action('admin_head', function() {
    ?>
    <style>
        #wpadminbar { background: #1d2327; }
    </style>
    <?php
});

// Hinweis ausgeben
add_action('admin_notices', function() {
    ?>
    <div class="notice notice-success is-dismissible">
        <p>Ihre Änderungen wurden gespeichert.</p>
    </div>
    <?php
});

#Filter im Adminbereich

Filter verändern Daten, bevor sie angezeigt oder gespeichert werden:

// Titel der Admin-Seite anpassen
add_filter('admin_title', function($admin_title, $title) {
    return $title . ' | Meine Website';
}, 10, 2);

// Text im Fuß des Adminbereichs ändern
add_filter('admin_footer_text', function($text) {
    return 'Erstellt mit <a href="https://wordpress.org">WordPress</a> | Technischer Support: Meine Firma';
});

// Spalten der Beitragsliste anpassen
add_filter('manage_posts_columns', function($columns) {
    $new_columns = [];
    foreach ($columns as $key => $value) {
        $new_columns[$key] = $value;
        if ($key === 'title') {
            $new_columns['meine_spalte'] = 'Meine zusätzliche Spalte';
        }
    }
    return $new_columns;
});

#Welche CSS-Klassen der WordPress-Adminbereich verwendet

WordPress bringt einen Satz CSS-Klassen mit, der für ein einheitliches Erscheinungsbild des Adminbereichs sorgt.

#CSS-Klassen für Container im Adminbereich

/* Hauptcontainer der Seite */
.wrap {
    margin: 10px 20px 0 2px;
}

/* Seitenüberschrift */
.wrap h1 {
    font-size: 23px;
    font-weight: 400;
    margin: 0;
    padding: 9px 0 4px;
    line-height: 1.3;
}

/* Metaboxen */
.postbox {
    min-width: 255px;
    border: 1px solid #c3c4c7;
    box-shadow: 0 1px 1px rgba(0,0,0,.04);
    background: #fff;
}

/* Formulare */
.form-table {
    border-collapse: collapse;
    margin-top: 0.5em;
    width: 100%;
    clear: both;
}

.form-table th {
    vertical-align: top;
    text-align: left;
    padding: 20px 10px 20px 0;
    width: 200px;
    line-height: 1.3;
    font-weight: 600;
}

#CSS-Klassen für Buttons und UI-Komponenten

/* Buttons (wp-includes/css/buttons.css) */
.wp-core-ui .button-primary {
    background: var(--wp-admin-theme-color, #3858e9);
    border-color: var(--wp-admin-theme-color, #3858e9);
    color: #fff;
    text-decoration: none;
    text-shadow: none;
}

/* Hinweise (wp-admin/css/common.css) */
.notice {
    background: #fff;
    border: none;
    border-left: 4px solid #c3c4c7;
    box-shadow: none;
    margin: 5px 15px 2px;
    padding: 8px 12px;
}

.notice-success {
    border-left-color: #4ab866;
}

.notice-error {
    border-left-color: #cc1818;
}

Die Werte oben stammen aus den Dateien buttons.css und common.css in Version 7.1.3. Die Farbe des primären Buttons ist nicht fest eingetragen: Sie kommt aus der CSS-Variable --wp-admin-theme-color, die das gewählte Farbschema setzt, und #3858e9 ist nur der Ersatzwert. Ein Plugin, das die Buttonfarbe im eigenen Stylesheet fest einträgt, passt nicht mehr zum Adminbereich eines Benutzers, der im Profil ein anderes Schema gewählt hat. Sicherer ist es, die Core-Klassen (button button-primary, notice notice-success) zu verwenden und ihre Farben nicht zu überschreiben.

#Wie man eigene Seiten im Adminbereich erstellt

Unten steht das kürzeste funktionierende Beispiel einer Optionsseite auf Basis der Settings API. Ein vollständiger Leitfaden zum Aufräumen von Menüs, zu Kundenrollen, Farbschemata und Dashboard-Widgets steht in einem eigenen Artikel zur Anpassung des WordPress-Adminbereichs.

#Wie man eine einfache Optionsseite hinzufügt

class Meine_Optionsseite {
    
    public function __construct() {
        add_action('admin_menu', [$this, 'seite_hinzufuegen']);
        add_action('admin_init', [$this, 'einstellungen_registrieren']);
    }
    
    public function seite_hinzufuegen() {
        add_options_page(
            'Meine Einstellungen',
            'Meine Einstellungen',
            'manage_options',
            'meine-einstellungen',
            [$this, 'seite_ausgeben']
        );
    }
    
    public function einstellungen_registrieren() {
        register_setting('meine_einstellungen_gruppe', 'meine_option_1');
        register_setting('meine_einstellungen_gruppe', 'meine_option_2');
        
        add_settings_section(
            'meine_sektion',
            'Haupteinstellungen',
            [$this, 'sektion_ausgeben'],
            'meine-einstellungen'
        );
        
        add_settings_field(
            'meine_option_1',
            'Erste Option',
            [$this, 'feld_1_ausgeben'],
            'meine-einstellungen',
            'meine_sektion'
        );
    }
    
    public function seite_ausgeben() {
        ?>
        <div class="wrap">
            <h1><?php echo esc_html(get_admin_page_title()); ?></h1>
            <form action="options.php" method="post">
                <?php
                settings_fields('meine_einstellungen_gruppe');
                do_settings_sections('meine-einstellungen');
                submit_button('Einstellungen speichern');
                ?>
            </form>
        </div>
        <?php
    }
    
    public function feld_1_ausgeben() {
        $wert = get_option('meine_option_1');
        ?>
        <input type="text" name="meine_option_1" value="<?php echo esc_attr($wert); ?>" class="regular-text">
        <?php
    }
}

new Meine_Optionsseite();

#Worin sich admin-ajax.php und admin-post.php unterscheiden

Der Adminbereich hat zwei getrennte Einstiegspunkte für Anfragen, die keinen Bildschirm darstellen, und beide umgehen admin.php.

admin-ajax.php verarbeitet AJAX-Anfragen. Die Datei definiert die Konstante DOING_AJAX, lädt wp-load.php und die Admin-API, sendet den Header X-Robots-Tag: noindex, löst admin_init aus und danach die Action wp_ajax_{action} für angemeldete Benutzer oder wp_ajax_nopriv_{action} für Gäste. Fehlt der Parameter action, endet die Anfrage mit der Antwort 0 und dem Statuscode 400, fehlt ein registrierter Handler, ebenfalls mit 0 und 400. Auf Admin-Bildschirmen steht die Adresse dieser Datei sofort in der JavaScript-Variable ajaxurl bereit, die admin-header.php ausgibt. Das Plugin Handbook beschreibt den gesamten Ablauf im Kapitel über AJAX in Plugins.

admin-post.php dient Formularen, die per normalem POST gesendet werden und nach denen eine Umleitung folgen soll. Die Datei löst admin_init aus und danach admin_post_{action} für angemeldete Benutzer oder admin_post_nopriv_{action} für Gäste. Hängt an der Action nichts, endet die Datei mit einer leeren Antwort und dem Statuscode 400. Der Hook ist auf der Seite admin_post_{$action} beschrieben.

Die Gemeinsamkeit beider Dateien wirkt sich auf die Performance aus. admin_init läuft bei jeder Anfrage an admin-ajax.php, auch bei den regelmäßigen Anfragen der Heartbeat API (die Action heartbeat steht auf der Liste der Core-Actions, für Gäste gibt es wp_ajax_nopriv_heartbeat). Schwerer Code an admin_init ohne die Bedingung wp_doing_ajax() läuft also nicht nur beim Öffnen eines Bildschirms, sondern bei jedem dieser Takte.

#Wie sich der Adminbereich von der Template-Hierarchie des Themes unterscheidet

Das Wort “Template” im Titel dieses Artikels lässt sich leicht mit Theme-Templates verwechseln. Das Frontend wählt eine Datei nach der Template-Hierarchie, die das Theme Handbook so beschreibt:

“Wenn ein Besucher auf einer beliebigen Seite einer WordPress-Website landet, entscheidet WordPress anhand des Query-Strings, welches Template zur Anzeige der Seite verwendet werden soll. Der Query-String enthält Daten aus der URL, die bei dieser Entscheidung helfen.”
Theme Handbook, Template hierarchy, eigene Übersetzung

Für Block-Themes nennt dieselbe Dokumentationsseite drei Orte, an denen WordPress nach einem Template sucht, in der Reihenfolge ihrer Priorität: vom Benutzer erstellte Templates, die in der Datenbank als Inhaltstyp wp_template gespeichert sind, den Ordner /templates des Child-Themes und den Ordner /templates des Eltern-Themes.

Der Adminbereich hat keinen dieser Mechanismen. Es gibt keine Rückfalldatei wie die index.php eines Themes und keine Zuordnung nach Abfragetyp. Was angezeigt wird, entscheidet der Dateiname in wp-admin oder der Parameter page, und das Layout des Bildschirms ist immer derselbe Kopf, dasselbe Menü und derselbe Fuß aus dem Core. Das Theme hat keinen Einfluss auf das Aussehen des Adminbereichs, außer dass sein Name in der Klasse wp-theme-* am body landet. Deshalb werden Stile und Skripte des Adminbereichs über admin_enqueue_scripts eingebunden und die des Frontends über wp_enqueue_scripts. Wer die beiden Actions verwechselt, bekommt das Admin-Stylesheet im Frontend oder umgekehrt.

#Wie man den WordPress-Adminbereich absichert

#Berechtigungen des Benutzers prüfen

Prüfen Sie immer die Berechtigungen des Benutzers:

// Prüfen, ob der Benutzer die nötigen Berechtigungen hat
if (!current_user_can('manage_options')) {
    wp_die(__('Sie haben keine Berechtigung für diese Seite.', 'text-domain'));
}

// Nonce für die Aktion prüfen
if (!isset($_POST['mein_nonce']) || !wp_verify_nonce($_POST['mein_nonce'], 'meine_aktion')) {
    wp_die(__('Ungültiges Sicherheitstoken.', 'text-domain'));
}

#Formulardaten im Adminbereich bereinigen

// Text bereinigen
$titel = sanitize_text_field($_POST['titel']);

// HTML bereinigen
$content = wp_kses_post($_POST['content']);

// URL bereinigen
$url = esc_url_raw($_POST['url']);

// E-Mail bereinigen
$email = sanitize_email($_POST['email']);

#Wie man den WordPress-Adminbereich debuggt

#Wie man WP_DEBUG im Adminbereich aktiviert

// In wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', true); // Verwendet nicht minifizierte Skripte

Die Dokumentation Debugging in WordPress beschreibt SCRIPT_DEBUG als Konstante, die WordPress anweist, statt der minifizierten die Entwicklungsversionen der CSS- und JavaScript-Dateien des Cores zu verwenden, und nennt sie nützlich beim Testen von Änderungen an den eingebauten .js- und .css-Dateien. Standardmäßig steht sie auf false. Für den Adminbereich heißt das: Statt wp-admin/js/common.min.js bekommt der Browser common.js, und ein Stacktrace aus der Konsole zeigt auf eine lesbare Zeile statt auf eine einzige lange Zeile der .min-Datei. Dieselbe Seite erinnert daran, dass die Definitionen vor dem Kommentar stehen müssen, der das Bearbeiten von wp-config.php beendet.

#Ereignisse im Adminbereich in debug.log protokollieren

function log_admin_action($action, $data) {
    if (defined('WP_DEBUG') && WP_DEBUG) {
        error_log("Admin Action [{$action}]: " . print_r($data, true));
    }
}

// Verwendung
log_admin_action('user_login', ['user_id' => get_current_user_id()]);

#Was man sich zum WordPress-Adminbereich merken sollte

Fünf Punkte aus dieser Anatomie, die beim Schreiben eines Plugins zählen:

Verzeichnisstruktur: Wer weiß, wie die Dateien organisiert sind, debuggt und ändert schneller.
Template-System: Callback-Funktionen und Hooks steuern, wie ein Bildschirm dargestellt wird.
Sicherheit: Berechtigungsprüfung und Bereinigung der Daten sind die Grundlage.
CSS-Klassen: Die Core-Klassen halten Plugin-Bildschirme im Einklang mit dem übrigen Adminbereich.
Debugging: SCRIPT_DEBUG und das Debug-Log verkürzen den Weg zur Fehlerursache.

Anpassungen am Adminbereich überstehen Updates nur dann, wenn sie die eingebauten Mechanismen nutzen, statt sie zu umgehen. Solche Änderungen bereiten wir im Rahmen der WordPress-Entwicklung vor und prüfen sie auf einer Staging-Umgebung.