Optionen und Settings API

Bei der Entwicklung von Plugins ist es entscheidend, ein Control Panel anzubieten, damit die Benutzer ihr Erlebnis personalisieren können. Dieses Kapitel befasst sich mit der Persistenz globaler Daten und der Erstellung nativer Konfigurationsoberflächen.

Wir werden untersuchen, wie die Options API es ermöglicht, Einstellungen effizient in der Tabelle wp_options zu speichern. Anschließend vertiefen wir uns in die Settings API, die die Komplexität des Renderings von Formularen abstrahiert, Daten validiert und die Sicherheit automatisch verwaltet. Am Ende wirst du in der Lage sein, professionelle und sichere Einstellungs-Panels zu erstellen, die sich nahtlos in das WordPress-Ökosystem integrieren.

6.1 Verwendung von add_option und get_option

Die Options API ist der Standardmechanismus von WordPress zum Speichern globaler Daten eines Plugins oder Themes, die nicht an einen bestimmten Inhaltstyp gebunden sind (wie Beiträge, Benutzer oder Begriffe, die wir bereits in der Metadata API behandelt haben). Diese globalen Einstellungen werden dauerhaft in der Tabelle wp_options der Datenbank gespeichert.

Im Gegensatz zur Erstellung benutzerdefinierter Tabellen (Kapitel 5) übernimmt die Options API automatisch die Serialisierung komplexer Daten (wie PHP-Arrays oder -Objekte) und ist eng in das native Objekt-Cache-System (Object Cache) von WordPress integriert.

Die Tabelle wp_options

Um zu verstehen, wie diese Funktionen arbeiten, ist es hilfreich, sich die vereinfachte Struktur der zugrunde liegenden Tabelle vorzustellen:

TEXT
Copiar
+-----------+--------------------+-------------------------+----------+
| option_id | option_name        | option_value            | autoload |
+-----------+--------------------+-------------------------+----------+
| 1         | siteurl            | https://beispiel.de     | yes      |
| 2         | mi_plugin_version  | 1.0.3                   | yes      |
| 3         | mi_plugin_ajustes  | a:2:{s:5:"color"...     | no       |
+-----------+--------------------+-------------------------+----------+

Das Schlüsselfeld hier ist autoload. Wenn es auf yes eingestellt ist, lädt WordPress diese Option während der Core-Initialisierung in einer einzigen gruppierten SQL-Abfrage in den Speicher. Dies ist entscheidend für die Performance: Optionen, die bei jedem Seitenaufruf benötigt werden, sollten autoload aktiviert haben, während umfangreiche oder selten genutzte Daten auf no gesetzt werden sollten.

Daten speichern: add_option() und update_option()

Die Funktion add_option() ermöglicht es, eine neue Einstellung in der Datenbank zu registrieren. Wenn die Option bereits existiert, gibt die Funktion false zurück und überschreibt den vorhandenen Wert nicht.

Syntax:

PHP
Copiar
add_option( string $option, mixed $value = '', string $deprecated = '', string|bool $autoload = 'yes' )

• $option: Eindeutiger Name der Option (es wird empfohlen, ein Präfix deines Plugins zu verwenden, z. B.: miplugin_api_key).
• $value: Der zu speichernde Wert. Kann ein String, ein Integer, ein Array oder ein Objekt sein.
• $deprecated: Veralteter Parameter, hier sollte immer ein leerer String '' übergeben werden.
• $autoload: Definiert, ob die Option automatisch geladen wird ('yes' oder true) oder nicht ('no' oder false).

Anwendungsbeispiel:

PHP
Copiar
// Einen einfachen Wert speichern
add_option( 'miplugin_activacion_fecha', current_time( 'mysql' ), '', 'yes' );

// Ein Array speichern (WordPress serialisiert es automatisch)
$configuracion_inicial = array(
    'modo_oscuro' => true,
    'limite_items' => 10,
    'email_admin'  => '[email protected]'
);
add_option( 'miplugin_configuracion', $configuracion_inicial, '', 'no' );

In der täglichen Praxis der Plugin-Entwicklung wirst du update_option() viel häufiger verwenden als add_option().

Die Funktion update_option() prüft zuerst, ob die Option existiert. Wenn sie nicht existiert, verhält sie sich intern wie add_option(). Wenn sie existiert und der neue Wert sich vom gespeicherten unterscheidet, wird er aktualisiert.

PHP
Copiar
// Aktualisiert den Wert; wenn 'miplugin_api_key' nicht existiert, wird sie erstellt.
update_option( 'miplugin_api_key', 'NUEVA_CLAVE_12345', 'no' );

Daten abrufen: get_option()

Um auf die gespeicherten Informationen zuzugreifen, verwenden wir get_option(). Diese Funktion sucht zuerst im Arbeitsspeicher-Cache. Wenn sie die Daten dort nicht findet, führt sie eine Abfrage in der Datenbank aus (oder ruft sie aus dem Pool der vorab geladenen Daten ab, wenn autoload='yes' gesetzt ist).

Syntax:

PHP
Copiar
get_option( string $option, mixed $default_value = false )

• $option: Der Name der abzurufenden Option.
• $default_value: Der Wert, der zurückgegeben wird, wenn die Option in der Datenbank nicht existiert. Dies ist äußerst nützlich, um Standardkonfigurationen bereitzustellen, ohne sie physisch in der Installation speichern zu müssen.

Anwendungsbeispiel:

PHP
Copiar
// Einen einfachen Wert mit einem Fallback abrufen
$api_key = get_option( 'miplugin_api_key', 'standard_schluessel' );

// Ein Array abrufen (WordPress deserialisiert es automatisch)
$configuracion = get_option( 'miplugin_configuracion', array() );

if ( ! empty( $configuracion['modo_oscuro'] ) ) {
    // Dunkle Stile anwenden
}

Daten löschen: delete_option()

Um die Datenbank sauber zu halten, insbesondere während des Deinstallationsprozesses eines Plugins (wie wir in Kapitel 2 gesehen haben), ist es zwingend erforderlich, nicht mehr benötigte Optionen mittels delete_option() zu löschen.

PHP
Copiar
// Löscht die Option aus der Datenbank und aus dem Cache
delete_option( 'miplugin_configuracion' );

Best Practices und Performance

1. Gruppierung in Arrays: Anstatt 20 verschiedene Optionen zu erstellen (miplugin_color, miplugin_size, miplugin_font), speichere ein einziges assoziatives Array (miplugin_ajustes). Dies reduziert die Anzahl der Einträge in wp_options erheblich und macht Lese- und Schreibvorgänge weitaus effizienter.
2. Vorsichtiger Umgang mit Autoload: Ein häufiger Fehler bei qualitativ minderwertigen Plugins is es, alle Optionen mit autoload='yes' (dem Standardwert) speichern zu lassen. Wenn dein Plugin ein großes Verlaufsprotokoll oder einen temporären Cache in der Optionstabelle speichert, stelle sicher, dass du autoload='no' erzwingst, indem du update_option( 'opcion', 'valor', 'no' ) verwendest. Zu viele Daten im Autoload können den PHP-Speicher bei jeder Anfrage der Website überlasten.
3. Konsistente Präfixe: Verwende für deine Optionen immer ein eindeutiges Präfix, um katastrophale Kollisionen mit dem WordPress-Core oder anderen Plugins zu vermeiden (verwende z. B. niemals etwas Generisches wie get_option('color_primario')).

6.2 Die Settings API im Detail

Während uns die Options API (die im vorherigen Abschnitt behandelt wurde) die grundlegenden Mechanismen (CRUD) zum Speichern und Abrufen von Daten aus der Datenbank bereitstellt, sagt sie nichts darüber aus, wie die grafische Benutzeroberfläche aufgebaut sein soll, über die der Benutzer mit diesen Daten interagiert. Hier kommt die Settings API (Einstellungs-API) ins Spiel.

Eingeführt mit WordPress 2.7 ist die Settings API eine Abstraktionsschicht, die auf der Options API aufbaut. Ihr Hauptzweck besteht darin, die Erstellung von Einstellungsseiten im Administrationsbereich zu standardisieren und dabei die mühsamsten und kritischsten Aufgaben zu automatisieren: das Rendern von Formularen, die Datenvalidierung und die Sicherheit.

Vergleich: Options API vs. Settings API

Um ihren Wert zu verstehen, ist es wichtig zu begreifen, wo die eine aufhört und die andere anfängt.

Visuelle Architektur der Settings API

Die API organisiert die Informationen visuell in einer strengen hierarchischen Struktur. Jedes mit dieser API erstellte Einstellungsformular besteht aus drei Ebenen:

TEXT
Copiar
[ Einstellungsseite ] (z. B. Lese-Einstellungen oder deine eigene Seite)
 │
 ├── [ Bereich / Sektion ] (Logische Gruppierung, z. B. „Darstellungs-Einstellungen“)
 │    │
 │    ├── [ Feld ] (HTML-Input: Primärfarbe) ---> Mit einer Option verknüpft
 │    └── [ Feld ] (HTML-Input: Dark Mode aktivieren) ---> Mit einer Option verknüpft
 │
 └── [ Bereich / Sektion ] (Logische Gruppierung, z. B. „API-Einstellungen“)
      │
      └── [ Feld ] (HTML-Input: API-Schlüssel) ---> Mit einer Option verknüpft

1. Einstellungsseite (Options Page): Der Hauptcontainer (das <form>-Tag). Es kann eine bestehende WordPress-Seite sein (wie Einstellungen > Allgemein) oder eine neue, von deinem Plugin erstellte Seite.
2. Bereiche / Sektionen (Settings Sections): Thematische Blöcke innerhalb der Seite. Sie ermöglichen es, verwandte Felder unter einer gemeinsamen Zwischenüberschrift zu gruppieren, was dem Benutzer das Lesen erleichtert.
3. Felder (Settings Fields): Die einzelnen interaktiven Elemente (Textfelder, Dropdown-Menüs, Checkboxen). Jedes Feld ist direkt mit einem Eintrag in der Datenbank (einer Option) verknüpft.

Vorteile des „Whitelisting“-Verfahrens (Erlaubnisliste)

Der größte Beitrag der Settings API zur Sicherheit eines Plugins ist ihr „Whitelisting“-System.

Wenn du ein standardmäßiges HTML-Formular erstellst und absendest, musst du Code schreiben, um diesen Absendevorgang abzufangen, zu prüfen, welche Felder übermittelt wurden, deren Gültigkeit zu validieren und dann für jedes Feld einzeln update_option() aufzurufen.

Mit der Settings API verwendest du die Funktion register_setting(), um WordPress mitzuteilen: „Ich werde eine Option namens miplugin_opciones verwenden. Bitte kümmere dich darum.“

Ab diesem Moment setzt WordPress deine Option auf eine Erlaubnisliste (Whitelist). Wenn das Formular an die interne WordPress-Datei options.php gesendet wird, prüft der Core, ob die eingehenden Daten zu einer registrierten Option gehören. Wenn ja, überprüft er die Sicherheits-Nonces, wendet die von dir definierten Bereinigungsfunktionen an und speichert die Daten automatisch in der Datenbank, woraufhin der Benutzer mit der Meldung „Einstellungen gespeichert“ zurückgeleitet wird.

Diese Delegation von Aufgaben macht die Settings API zum unbestrittenen Standard für die Entwicklung von Konfigurationsoberflächen in WordPress. So kannst du dich auf deine Geschäftslogik und das Design konzentrieren, anstatt dich um das Abfangen von HTTP-Protokollen und die Sicherheit von Formularen kümmern zu müssen.

6.3 Registrierung von Sektionen und Feldern

Um die im vorherigen Abschnitt besprochene visuelle und sicherheitsrelevante Architektur zu implementieren, stellt WordPress drei Hauptfunktionen bereit. Diese Funktionen müssen immer innerhalb des Hooks admin_init ausgeführt werden, da die Einstellungen nur registriert werden müssen, wenn ein Benutzer auf den Administrationsbereich zugreift oder wenn ein Formular an die options.php gesendet wird.

Die drei Funktionen arbeiten zusammen, um die Verknüpfung zwischen deiner Datenbank und deiner Oberfläche herzustellen:

1. register_setting(): Autorisiert (setzt auf die Whitelist) den Optionsnamen in der Datenbank und definiert, wie er validiert werden soll.
2. add_settings_section(): Erstellt einen visuellen Gruppierungsblock auf der Seite.
3. add_settings_field(): Registriert ein einzelnes Formularfeld und weist es einer bestimmten Sektion zu.

1. Autorisierung der Option: register_setting()

Bevor du etwas auf dem Bildschirm ausgibst, musst du WordPress mitteilen, welche Option du speichern wirst. Wenn du diesen Schritt auslässt, erhältst du beim Absenden des Formulars einen Berechtigungsfehler.

PHP
Copiar
register_setting( 
    string $option_group, 
    string $option_name, 
    array $args = array() 
)

• $option_group: Eine interne Kennung für die Optionsgruppe. Du wirst sie später in der Funktion settings_fields() beim Erstellen des Formulars verwenden (Kapitel 6.4).
• $option_name: Der genaue Name der Option, die in der Tabelle wp_options gespeichert wird (derselbe Name, den du in get_option() verwendest).
• $args: Ein Array mit Argumenten. Das wichtigste Argument hier ist sanitize_callback, an das du den Namen der Funktion übergibst, die die Daten vor dem Speichern bereinigt.

2. Erstellung von Sektionen: add_settings_section()

Die Sektionen fungieren als logische Container für deine Felder. Eine Einstellungsseite kann mehrere Sektionen haben.

PHP
Copiar
add_settings_section( 
    string $id, 
    string $title, 
    callable $callback, 
    string $page 
)

• $id: Die eindeutige Kennung der Sektion (HTML-id).
• $title: Der Titel (HTML-<h2> oder <h3>), der über den Feldern angezeigt wird.
• $callback: Funktion, die einen beschreibenden Text direkt unter dem Titel und vor den Feldern ausgibt. Wenn du keine Beschreibung benötigst, kannst du __return_empty_string übergeben.
• $page: Der Slug der Einstellungsseite, auf der diese Sektion erscheinen soll.

3. Erstellung von Feldern: add_settings_field()

Diese Funktion verknüpft ein Element der Benutzeroberfläche (like ein <input>) mit der entsprechenden Sektion und Seite.

PHP
Copiar
add_settings_field( 
    string $id, 
    string $title, 
    callable $callback, 
    string $page, 
    string $section = 'default', 
    array $args = array() 
)

• $id: Das id-Attribut des Felds.
• $title: Das Label (HTML-<label>), das links vom Feld erscheint.
• $callback: Die Funktion, die für die Ausgabe (per echo) des HTML-Codes des Formularfelds (das <input>, <select>, etc.) zuständig ist.
• $page: Der Slug der Seite (muss mit dem Slug der Sektion übereinstimmen).
• $section: Die ID der Sektion ($id aus add_settings_section), zu der dieses Feld gehört.
• $args: Zusätzliche Argumente, die an die $callback-Funktion übergeben werden. Ideal, um das HTML-Attribut name oder benutzerdefinierte CSS-Klassen zu übergeben.

Der Verbindungsfluss (Der Kleber)

Die größte Herausforderung beim Erlernen der Settings API besteht darin, zu verstehen, wie diese Funktionen über Strings (Identifikatoren) miteinander verknüpft sind. Betrachte dieses Beziehungsdiagramm:

TEXT
Copiar
[ Datenbank ]                       [ Oberfläche / Rendering ]
      |                                        |
register_setting( 'grupo_A', 'opcion_X' )      |
                                               |
                           add_settings_section( 'seccion_1', ..., 'mi_pagina' )
                                                       ^                ^
                                                       |                |
                           add_settings_field( ..., 'mi_pagina', 'seccion_1' )

Der campo sucht die Sektion (seccion_1) und die Seite (mi_pagina), um zu wissen, wo es sich zeichnen soll. Später verwendet das gesamte Formular die Gruppe grupo_A, um zu wissen, an welche Option opcion_X die Daten gesendet werden sollen.

Beispiel einer vollständigen Implementierung

Im Folgenden führen wir alles innerhalb des Hooks admin_init zusammen:

PHP
Copiar
/**
 * Initialisiert und registriert alle Einstellungen unseres Plugins
 */
function miplugin_registrar_ajustes() {
    
    // 1. Die Option registrieren (Erlaubnisliste / Whitelist)
    register_setting(
        'miplugin_opciones_grupo',      // Optionsgruppe
        'miplugin_configuracion',       // Name in wp_options
        array(
            'sanitize_callback' => 'miplugin_sanitizar_datos',
            'default'           => array( 'api_key' => '' )
        )
    );

    // 2. Den Bereich (Sektion) registrieren
    add_settings_section(
        'miplugin_seccion_api',         // ID der Sektion
        'API-Verbindungseinstellungen',  // Sichtbarer Titel
        'miplugin_seccion_api_cb',      // Callback für die Beschreibung
        'miplugin_pagina_ajustes'       // Slug der Einstellungsseite
    );

    // 3. Das Feld registrieren
    add_settings_field(
        'miplugin_campo_apikey',        // ID des Felds
        'API-Schlüssel',                 // Feld-Label (<label>)
        'miplugin_renderizar_apikey',   // Callback, der das <input> ausgibt
        'miplugin_pagina_ajustes',      // Slug der Einstellungsseite
        'miplugin_seccion_api'          // ID der Sektion, zu der es gehört
    );
}
add_action( 'admin_init', 'miplugin_registrar_ajustes' );

/**
 * Render-Callbacks (Die „Views“)
 */

// Beschreibung der Sektion
function miplugin_seccion_api_cb() {
    echo '<p>Gib deine Zugangsdaten ein, um dich mit dem externen Dienst zu verbinden.</p>';
}

// Rendern des Inputs
function miplugin_renderizar_apikey() {
    // Wir rufen die aktuellen Werte aus der Datenbank ab
    $opciones = get_option( 'miplugin_configuracion' );
    $api_key  = isset( $opciones['api_key'] ) ? esc_attr( $opciones['api_key'] ) : '';
    
    // Beachte, dass das 'name'-Attribut exakt lauten muss: options_name[array_key]
    echo '<input type="text" id="miplugin_campo_apikey" name="miplugin_configuracion[api_key]" value="' . $api_key . '" class="regular-text" />';
}

/**
 * Bereinigungsfunktion (Sicherheit)
 */
function miplugin_sanitizar_datos( $input ) {
    $sanitizado = array();
    
    if ( isset( $input['api_key'] ) ) {
        $sanitizado['api_key'] = sanitize_text_field( $input['api_key'] );
    }
    
    return $sanitizado;
}

Es ist wichtig zu beachten, wie das name-Attribut in der Render-Funktion aufgebaut ist: name="miplugin_configuracion[api_key]". Da wir unsere Einstellungen in einem Array unter einer einzigen Option speichern (eine in 6.1 beschriebene Best Practice), muss das HTML-name-Attribut diese Array-Struktur widerspiegeln, damit WordPress es bei der Verarbeitung der Anfrage korrekt serialisiert.

6.4 Rendern von Formularen

Sobald wir unsere Option, Sektionen und Felder im Backend über den Hook admin_init definiert haben (wie wir in Abschnitt 6.3 gesehen haben), besteht der letzte Schritt darin, die grafische Benutzeroberfläche aufzubauen. Wir müssen das HTML-Formular auf der Administrationsseite unseres Plugins ausgeben.

Das Schöne an der Settings API ist, dass sie das Rendern eines komplexen Formulars auf wenige Zeilen Code reduziert und die Schleifen sowie die Implementierung von Sicherheitsmaßnahmen intern verwaltet.

Die Anatomie des Views

Die Callback-Funktion, die für die Anzeige deiner Einstellungsseite verantwortlich ist (diejenige, die du bei der Verwendung von Funktionen wie add_menu_page o add_options_page definiert hast, welche wir in Kapitel 7 behandeln werden), muss eine ganz bestimmte HTML-Struktur aufweisen, damit die Settings API korrekt funktioniert.

Der grundlegende Ablauf erfordert vier wesentliche Elemente:

1. Der globale Container: Die Standard-WordPress-Klasse <div class="wrap">.
2. Das Formular-Tag: Es muss zwingend auf die interne Datei options.php verweisen.
3. Sicherheit und Referenzen: Die Funktion settings_fields().
4. Rendern von Sektionen: Die Funktion do_settings_sections().
5. Der Senden-Button: Die Funktion submit_button().

Implementierung des Formulars

Im Folgenden wird gezeigt, wie der View der Seite aufgebaut wird, unter der Annahme, dass wir dieselben Identifikatoren verwenden, die im Beispiel des vorherigen Abschnitts registriert wurden:

PHP
Copiar
/**
 * Rendert die Konfigurationsseite des Plugins im Administrationsbereich.
 */
function miplugin_renderizar_pagina_ajustes() {
    
    // Grundlegende Sicherheitsüberprüfung (optional, aber empfohlen)
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }

    // WordPress verwaltet Erfolgs-/Fehlermeldungen hier automatisch
    settings_errors( 'miplugin_mensajes' );
    ?>
    
    <div class="wrap">
        <h1><?php echo esc_html( get_admin_page_title() ); ?></h1>
        
        <form action="options.php" method="post">
            
            <?php
            // 1. Gibt die versteckten Sicherheitsfelder (Nonces) und die Referenz zur Gruppe aus
            // Muss EXAKT mit dem $option_group-Parameter aus register_setting() übereinstimmen
            settings_fields( 'miplugin_opciones_grupo' );
            
            // 2. Gibt alle für diese Seite registrierten Sektionen und Felder aus
            // Muss EXAKT mit dem $page-Parameter aus add_settings_section/field() übereinstimmen
            do_settings_sections( 'miplugin_pagina_ajustes' );
            
            // 3. Gibt den Button „Änderungen speichern“ aus
            submit_button( 'Einstellungen speichern' );
            ?>
            
        </form>
    </div>
    
    <?php
}

Die Render-Funktionen verstehen

• settings_errors(): Wenn das Formular an options.php gesendet wird, verarbeitet WordPress die Daten, aktualisiert die Datenbank und leitet den Benutzer zurück zu deiner Seite. Bei dieser Weiterleitung werden Variablen an die URL angehängt, die Erfolg oder Misserfolg anzeigen. Diese Funktion fängt diese Variablen ab und gibt die nativen WordPress-Benachrichtigungen aus (die klassischen grünen oder roten Boxen im oberen Bereich).

• <form action="options.php">: Dies ist der Motor des gesamten Prozesses. options.php ist die Core-Datei von WordPress, die ausschließlich dafür konzipiert wurde, POST-Anfragen der Settings API entgegenzunehmen. Wenn du das Action-Attribut auf einen anderen Pfad änderst, verlierst du die gesamte Automatisierung und Sicherheit.

• settings_fields( $grupo ): Diese Funktion gibt keine sichtbaren Daten aus. Sie schleust jedoch mehrere entscheidende <input type="hidden">-Felder ein:

  • option_page: Teilt der options.php mit, welche Optionsgruppe du zu speichern versuchst.
  • action: Definiert die interne Aktion (update).
  • _wpnonce: Schleust das dynamisch generierte CSRF-Sicherheits-Token ein, um das Formular zu schützen.

• do_settings_sections( $pagina ): Hier passiert die visuelle Magie. WordPress sucht im Arbeitsspeicher nach allen für den Slug $pagina registrierten Sektionen. Für jede Sektion gibt es den Titel aus, führt den Beschreibungs-Callback aus, öffnet eine HTML-Tabelle (<table class="form-table">) und durchläuft alle dieser Sektion zugewiesenen Felder, wobei die individuellen Callbacks ausgeführt werden, die wir für das Rendern der <input>-Felder erstellt haben.

Mit dieser Struktur haben wir den Kreislauf geschlossen. Die Daten fließen vom View des Benutzers (dem gerenderten Formular) zum nativen Prozessor (options.php), durchlaufen den Sicherheits- und Bereinigungsfilter (register_setting) und werden schließlich sicher in der Datenbank gespeichert, wo sie über get_option() abgerufen werden können.

Kapitelzusammenfassung

In diesem Kapitel haben wir die Verwaltung globaler Daten und die Erstellung von Konfigurationsoberflächen eingehend untersucht — eine grundlegende Säule in der Architektur jedes robusten Plugins:

1. Die Datenbank und die Options API: Wir haben die Rolle der Tabelle wp_options verstanden und gelernt, wie Funktionen wie update_option() und get_option() das Speichern und Abrufen von Daten unabhängig vom Inhalt ermöglichen. Wir haben die Bedeutung des autoload-Feldes für die Gesamt-Performance der Website hervorgehoben und die Best Practice aufgezeigt, Einstellungen in einem einzigen serialisierten Array zu gruppieren.
2. Übergang zur Settings API: Wir haben gesehen, wie die Einstellungs-API eine Abstraktionsschicht über die Datenbankoperationen legt und die Verantwortung für das Rendern des Formulars, die Verwaltung des POST-Ablaufs, die Validierung von Nonces und das Weiterleiten von Fehlern über ein sicheres Whitelisting-System übernimmt.
3. Visuelle Datenarchitektur: Wir haben den dreistufigen Prozess über den Hook admin_init gelernt: Validieren der Eingabe mit register_setting(), visuelles Strukturieren mit add_settings_section() und Verknüpfen interaktiver Elemente mit add_settings_field().
4. Integration der Benutzeroberfläche: Schließlich haben wir unseren Registrierungscode mit der visuellen Oberfläche verknüpft, indem wir die Formularverarbeitung an options.php delegiert und die Komponenten standardisiert mithilfe von settings_fields() und do_settings_sections() gerendert haben. Dies stellt sicher, dass die Administrations-Panels deines Plugins die visuelle Konsistenz und die vom WordPress-Ökosystem geforderten Sicherheitsstandards wahren.