WP-Core-Architektur

Um die Plugin-Entwicklung zu meistern, müssen wir das Terrain verstehen, auf dem sie ausgeführt wird. WordPress ist ein eventgesteuertes Ökosystem mit einem strikten Lebenszyklus. In diesem Kapitel werden wir seine interne Funktionsweise entschlüsseln.

Wir werden den Initialisierungsprozess und die Ladesequenz des Cores untersuchen. Wir werden verstehen, wie die WP_Query-Engine Anfragen verarbeitet und wie die Template-Hierarchie über das visuelle Rendering entscheidet. Schließlich ziehen wir die unverrückbare architektonische Grenze zwischen Themes (Präsentation) und Plugins (Logik). Wenn du diese Grundlagen beherrschst, kannst du deinen Code präzise, skalierbar und professionell einbinden.

1.1 Dateien und Laden des Cores

Um robuste und effiziente Plugins zu entwickeln, ist es unerlässlich zu verstehen, was genau passiert, sobald der Server eine HTTP-Anfrage empfängt, bis dein Code ausgeführt wird. WordPress ist kein statischer Monolith, sondern ein eventgesteuertes (event-driven) System, dessen Lebenszyklus bei jeder Anfrage durch einen Initialisierungsprozess (oder Bootstrap) dynamisch aufgebaut wird.

Der Initialisierungsfluss (Bootstrap)

Das Laden des WordPress-Cores folgt einer strikten Kaskade von Datei-Includes. Bei einer Standardinstallation durchläuft jede Anfrage an das Frontend die folgende Sequenz von Hauptdateien:

TEXT
Copiar
[HTTP-Anfrage]
       |
       v
  index.php
       |-- Definiert WP_USE_THEMES (true)
       v
  wp-blog-header.php
       |-- Koordiniert das Laden der Umgebung und des Templates
       |
       |----> wp-load.php
       |        |-- Sucht und lädt wp-config.php
       |        v
       |      wp-config.php
       |        |-- Definiert Umgebungs- und DB-Konstanten
       |        v
       |      wp-settings.php
       |        |-- FÜHRT DIE CORE-INITIALISIERUNG AUS
       |
       |----> wp() (Konfiguriert WP_Query - siehe 1.2)
       |
       |----> wp-includes/template-loader.php (Hierarchie - siehe 1.3)

Anatomie von wp-settings.php

Die Datei wp-settings.php (im Root-Verzeichnis) ist der eigentliche Anlasser von WordPress. Für dich als Plugin-Entwickler ist dies die kritischste Datei im Ladevorgang, da sie genau bestimmt, zu welchem Zeitpunkt dein Code zum Leben erweckt wird und welche APIs in diesem Moment verfügbar sind.

Die interne Sequenz von wp-settings.php wird in der folgenden Reihenfolge ausgeführt:

1. Frühe Initialisierung: Verzeichnis-Konstanten und Versionskontrolle werden konfiguriert und die Kompatibilitäts-API wird eingebunden.
2. Datenbankverbindung: Die globale Klasse $wpdb wird instanziiert. Ab diesem Moment können Datenbankabfragen durchgeführt werden.
3. Objekt-Cache: WP_Cache wird initialisiert, falls konfiguriert.
4. Laden von Must-Use-Plugins: Die PHP-Dateien im Verzeichnis /wp-content/mu-plugins/ werden gesucht und geladen. Diese Plugins werden vor den regulären Plugins ausgeführt und können im Admin-Bereich nicht deaktiviert werden.
5. Laden aktiver Plugins: Die Tabelle wp_options wird abgefragt, um das serialisierte Array der Option active_plugins zu erhalten. WordPress iteriert über dieses Array und bindet jede Hauptdatei der regulären Plugins per include_once ein.
6. Auslösen des Hooks plugins_loaded: Der erste allgemeine verfügbare Action Hook.
7. Laden überschreibbarer Funktionen (Pluggable Functions): Überschreibbare Core-Funktionen (wie wp_mail oder wp_get_current_user) werden geladen.
8. Theme-Konfiguration: setup_theme wird ausgelöst und die Datei functions.php des aktiven Themes wird eingebunden.
9. Auslösen des Hooks init: Der Core ist nun größtenteils geladen. Authentifizierung, Taxonomien und Custom Post Types sollten hier registriert werden.
10. Auslösen des Hooks wp_loaded: WordPress ist vollständig geladen und geparst, direkt bevor mit der Verarbeitung der Anfrage-URL begonnen wird.

Das Problem der vorzeitigen Abhängigkeit

Ein häufiger Fehler bei der Entwicklung von Plugins is der Versuch, Core-Funktionen zu nutzen, bevor sie deklariert wurden. Da reguläre Plugins im Schritt 5 geladen werden, wird deine Hauptdatei ausgewertet, bevor das Theme geladen wird und bevor Pluggable- oder Benutzerfunktionen verfügbar sind.

Betrachte das folgende Antipattern:

PHP
Copiar
<?php
/* Plugin Name: Mein fehlerhaftes Plugin */

// FEHLER: Dies führt zu einem Fatal Error, da wp_get_current_user() 
// noch nicht definiert ist, wenn diese Datei in Schritt 5 eingebunden wird.
$user = wp_get_current_user();
if ( $user->ID == 1 ) {
    // ...
}

Die richtige architektonische Lösung besteht darin, die Codeausführung auf einen späteren Zeitpunkt im Lebenszyklus zu verschieben, indem du die Hooks-API verwendest (die wir in Kapitel 2 im Detail besprechen werden):

PHP
Copiar
<?php
/* Plugin Name: Mein korrektes Plugin */

// Korrekt: Wir verpacken die Logik in eine Funktion und weisen den Core an,
// sie während des Hooks 'init' (Schritt 9) auszuführen, wenn alles geladen ist.
add_action( 'init', 'mi_plugin_verificar_usuario' );

function mi_plugin_verificar_usuario() {
    $user = wp_get_current_user();
    if ( $user->ID == 1 ) {
        // Sichere Logik
    }
}

Teilladen mit SHORTINIT

In High-Performance-Szenarien, in denen du extrem schnelle Anfragen abfangen musst, indem du das vollständige Laden von Plugins und Themes überspringst (z. B. bei benutzerdefinierten Endpunkten zur Rohdatenerfassung vor der REST-API), bietet WordPress die Konstante SHORTINIT.

Wenn du define('SHORTINIT', true); direkt vor dem Laden von wp-load.php in einem eigenständigen Script definierst, stoppt der Prozess in wp-settings.php auf halbem Weg:

PHP
Copiar
<?php
// custom-endpoint.php im WordPress-Root
define( 'SHORTINIT', true );
require_once( $_SERVER['DOCUMENT_ROOT'] . '/wp-load.php' );

// Zu diesem Zeitpunkt:
// - Ist $wpdb verfügbar.
// - Ist wp_options verfügbar.
// - Wurden Plugins und Themes NICHT geladen.
// - Wurde die REST-/AJAX-API NICHT initialisiert.

global $wpdb;
$resultados = $wpdb->get_results( "SELECT * FROM {$wpdb->prefix}options LIMIT 5" );

// Verarbeiten, JSON zurückgeben und sofort beenden.
wp_send_json_success( $resultados );

Das Verständnis des Core-Ladevorgangs und des Ablaufs in wp-settings.php ermöglicht es dir, deinen Plugin-Code zum algorithmisch perfekten Zeitpunkt einzubinden, wodurch Abhängigkeitskonflikte vermieden und die Serverantwortzeiten optimiert werden.

1.2 Der Anfragefluss (WP Query)

Sobald wp-settings.php das Laden des Cores, der Plugins und des aktiven Themes abgeschlossen hat (wie im vorherigen Abschnitt beschrieben), ist das System bereit, die grundlegende Frage jedes Content-Management-Systems zu beantworten: Was genau fordert der Benutzer an und wie erhalte ich diese Daten?

In WordPress wird der Übergang von einer benutzerfreundlichen URL zu einer Sammlung von Datenbankobjekten durch zwei monumentale Klassen verwaltet: WP (zuständig für Routing und Parsing) und WP_Query (zuständig für die Datenextraktion).

Der Lebenszyklus einer Anfrage

Für einen Plugin-Entwickler ist es wichtig, diesen Ablauf zu verstehen, um Abfragen abzufangen und zu modifizieren, bevor sie sich auf die Datenbank oder die Serverleistung auswirken. Der Prozess folgt diesem logischen Schema:

TEXT
Copiar
https://x.com/masnoticia?lang=en
                           |
                           v
+---------------------------------------------------+
| 1. Klasse WP (Parsing der Anfrage)                 |
|    - Vergleicht die URL mit den Rewrite Rules.     |
|    - Extrahiert die Variablen (Query Vars).       |
|      Bsp: array( 'category_name' => 'news' )      |
+---------------------------------------------------+
                           |
                           |--> Hook: 'request'
                           v
+---------------------------------------------------+
| 2. Klasse WP_Query (Aufbau der Abfrage)            |
|    - Empfängt die Query Vars der Klasse WP.        |
|    - Hook: 'pre_get_posts' <--------------------- | [OPTIMALER EINBINDUNGSPUNKT]
|    - Übersetzt die Query Vars in natives SQL.     |
|    - Führt SQL über $wpdb aus.                    |
|    - Füllt das Array $posts mit den Ergebnissen.  |
+---------------------------------------------------+
                           |
                           v
+---------------------------------------------------+
| 3. Festlegen des globalen Kontextes                |
|    - Konfiguriert Variablen: $wp_query, $post.     |
|    - Definiert Conditional Tags (is_archive,       |
|      is_single, is_category etc.).                |
+---------------------------------------------------+
                           |
                           v
               [Laden der Template-Hierarchie]

Die Parsing-Phase (Klasse WP)

Wenn die Ausführung die Funktion wp() in der Datei wp-blog-header.php erreicht, wird die globale Klasse $wp instanziiert. Ihre Hauptmethode ist main(), welche wiederum parse_request() aufruft.

An diesem Punkt nimmt WordPress die angeforderte URL und gleicht sie mit seinen Umschreibungsregeln (Rewrite Rules, verwaltet von der Klasse WP_Rewrite) ab. Wenn eine Übereinstimmung gefunden wird, verwandelt es die lesbare URL in ein strukturiertes Array von Variablen, die vom Core erkannt werden, bekannt als Query Vars.

Als Plugin-Entwickler kannst du deine eigenen benutzerdefinierten Query Vars registrieren, indem du dich in den Filter query_vars einklinkst. Dadurch versteht der Core Parameter in der URL, die er sonst verwerfen würde.

Die Abfragephase (Klasse WP_Query)

Sobald die Query Vars definiert sind, werden sie an eine globale Instanz von WP_Query übergeben, die in der globalen Variable $wp_query gespeichert ist. Dies ist die Hauptsuchmaschine von WordPress.

WP_Query nimmt dieses harmlose Array von Variablen und erledigt die Schwerstarbeit: Es baut ein komplexes SQL-SELECT-Statement auf (unter Berücksichtigung von Taxonomien, Metadaten, Paginierung und Veröffentlichungsstatus) und führt es auf der Datenbank aus.

Neben dem Abrufen der Posts ist WP_Query auch für das Festlegen des Seitenstatus verantwortlich. Es berechnet die Gesamtzahl der gefundenen Beiträge ($wp_query->found_posts) für die Paginierung und setzt boolesche Flags, die als Conditional Tags bekannt sind (is_front_page(), is_tax(), is_404()).

Der Master-Hook: pre_get_posts

Der häufigste Fehler von Junior-WordPress-Entwicklern ist der Versuch, den Inhalt einer Seite zu verändern, indem sie eine neue sekundäre Abfrage im Template mit veralteten oder destruktiven Funktionen wie query_posts() erstellen oder ein neues WP_Query instanziieren und dabei die Hauptabfrage ignorieren. Dies verdoppelt die Arbeit für die Datenbank (die von WordPress vorbereitete Hauptabfrage wird ausgeführt, verworfen und die neue wird ausgeführt).

Der korrekte und performante Weg, die Suche von WordPress zu modifizieren, besteht darin, die Query Vars abzufangen, bevor sie in SQL übersetzt werden. Dies erreichst du mit dem Action Hook pre_get_posts.

Dieser Hook wird aufgerufen und übergibt das WP_Query-Objekt per Referenz, was eine dynamische Änderung ermöglicht.

PHP
Copiar
/**
 * Modifiziert die Hauptabfrage, um einen Custom Post Type in die Suchergebnisse aufzunehmen, schließt jedoch den Admin-Bereich aus.
 */
add_action( 'pre_get_posts', 'mi_plugin_ampliar_busqueda' );

function mi_plugin_ampliar_busqueda( $query ) {
    // 1. Goldene Regel: Den Admin-Bereich nicht beeinflussen
    if ( is_admin() ) {
        return;
    }

    // 2. Goldene Regel: NUR die Hauptabfrage ändern, keine Menüs oder Widgets
    if ( ! $query->is_main_query() ) {
        return;
    }

    // 3. Gewünschte bedingte Logik anwenden
    if ( $query->is_search() ) {
        // Wir rufen die aktuellen Post-Types ab, nach denen gesucht wird
        $post_types = $query->get( 'post_type' );
        
        if ( empty( $post_types ) ) {
            $post_types = array( 'post', 'page', 'attachment' );
        } elseif ( ! is_array( $post_types ) ) {
            $post_types = array( $post_types );
        }

        // Wir fügen unseren Custom Post Type 'portfolio' hinzu
        $post_types[] = 'portfolio';
        
        // Wir weisen den Query Vars den neuen Wert zu
        $query->set( 'post_type', $post_types );
    }
}

Durch die Verwendung von pre_get_posts manipulierst du die native Anfrage auf der richtigen Abstraktionsebene. Wenn WP_Query schließlich das SQL kompiliert, wird dein Post-Type portfolio nativ einbezogen, was exakt dieselben Datenbankressourcen verbraucht wie die ursprüngliche Anfrage.

The Loop (Die Schleife) und der globale Zustand

Sobald WP_Query seine Ausführung beendet, geht die Anwendung in die Rendering-Phase über. Der berühmte „Loop“ von WordPress (while ( have_posts() ) : the_post();) ist nichts anderes als eine Iteration über die Ergebnisse der globalen Instanz $wp_query.

Die Funktion the_post() extrahiert den aktuellen Beitrag aus dem Ergebnis-Array und weist ihn der globalen Variable $post zu, wodurch er für alle Theme-Funktionen (die Template Tags wie the_title() oder the_content()) verfügbar wird. Dies schließt den Kreis von der Eingangs-URL bis zum Ausgabe-HTML.

1.3 Template-Hierarchie

Wenn WP_Query das Gehirn ist, das bestimmt, welche Daten der Benutzer angefordert hat, dann ist die Template-Hierarchie die Rendering-Engine, die entscheidet, wie diese Daten präsentiert werden. Sobald die Datenbankabfrage abgeschlossen und die globalen Variablen ($wp_query, $post) befüllt sind, erreicht die Ausführung die Datei wp-includes/template-loader.php.

Für einen Plugin-Entwickler ist das Verständnis dieser Hierarchie nicht nur eine Frage des visuellen Designs. Es ist grundlegend, um zu wissen, wie man benutzerdefinierte Ansichten einbindet, Standard-Templates für Custom Post Types (CPTs) bereitstellt oder den Rendering-Prozess komplett kapert, wenn die Logik des Plugins dies erfordert.

Der Entscheidungsbaum (Die Kaskade)

WordPress verwendet die während der Abfrage generierten Conditional Tags, um nach der passenden .php-Datei im Verzeichnis des aktiven Themes (und gegebenenfalls des Parent-Themes) zu suchen. Die Suche geht immer vom spezifischsten zum allgemeinsten Dokument über und landet unweigerlich bei der index.php, wenn keine vorherigen Übereinstimmungen gefunden werden.

Dies ist der vereinfachte Entscheidungsbaum für die Anfrage eines Custom Post Types namens portfolio:

TEXT
Copiar
[URL: /portfolio/mein-projekt/]
                    |
                    v
1. Ist es ein einzelner Beitrag? (is_single)
   |
   |-- Sucht: single-portfolio-mein-projekt.php (nach Slug)
   |-- Falls nicht vorhanden, sucht: single-portfolio.php (nach Post-Type)
   |-- Falls nicht vorhanden, sucht: single.php (jeder einzelne Beitrag)
   |-- Falls nicht vorhanden, sucht: singular.php (jeder Beitrag oder jede Seite)
   |-- Falls nicht vorhanden, nutzt: index.php (die absolute Rettungsleine)

Die Core-Funktion, die dafür zuständig ist, diesen Baum zu durchlaufen und die Existenz der physischen Dateien zu prüfen, lautet locate_template().

Abfangen über ein Plugin: Der Filter template_include

Das WordPress-Ökosystem schreibt eine klare Aufteilung der Verantwortlichkeiten vor: Plugins verwalten Logik und Daten, während Themes für die Präsentation zuständig sind. Wenn du jedoch ein Plugin entwickelst, das neue Datenstrukturen einführt (wie ein Ticketsystem, un Forum oder einen Produktkatalog), verfügt das aktive Theme oft nicht über die spezifischen Templates (z. B. single-ticket.php), um diese korrekt darzustellen.

Um dies zu lösen, können Plugins ihre eigenen Templates über den Filter template_include einschleusen. Dieser Filter wird direkt vor dem include der im Theme gefundenen Datei durch WordPress ausgelöst. Er erhält den absoluten Pfad dieser Datei als Argument und erwartet, dass du einen absoluten Pfad zurückgibst (entweder denselben oder einen anderen).

PHP
Copiar
/**
 * Überschreibt das Theme-Template mit einem vom Plugin bereitgestellten Template für den Custom Post Type 'portfolio'.
 */
add_filter( 'template_include', 'mi_plugin_cargar_plantilla_portfolio' );

function mi_plugin_cargar_plantilla_portfolio( $template ) {
    // 1. Wir prüfen, ob wir uns in der Einzelansicht unseres CPTs befinden
    if ( is_singular( 'portfolio' ) ) {
        
        // 2. Wir definieren den Pfad des Templates im Verzeichnis unseres Plugins
        $plugin_template = plugin_dir_path( __FILE__ ) . 'templates/single-portfolio.php';
        
        // 3. (Best Practice) Wir erlauben dem Theme, unser Template zu überschreiben, falls der Theme-Entwickler eine Datei 'single-portfolio.php' erstellt hat
        $theme_template = locate_template( array( 'single-portfolio.php' ) );
        
        if ( $theme_template ) {
            return $theme_template; // Theme gewinnt
        } elseif ( file_exists( $plugin_template ) ) {
            return $plugin_template; // Plugin gewinnt
        }
    }
    
    // 4. Falls es nicht unser CPT ist oder wir keine Dateien finden, geben wir das originale Template zurück
    return $template;
}

Dieses Entwurfsmuster (zuerst im Theme suchen und dann ein Fallback auf das Plugin machen) entspricht exakt der Architektur, die große Plugins wie WooCommerce verwenden, um ihre Ansichten zu integrieren, ohne die native Hierarchie zu stören.

template_redirect vs. template_include

Es ist wichtig, diese beiden Hooks nicht zu verwechseln, da sie zu unterschiedlichen Zeiten ausgeführt werden und unterschiedliche Zwecke erfüllen:

• template_redirect (Action): Wird ausgelöst, bevor WordPress mit der Suche nach der zu ladenden Datei beginnt. Dies ist der ideale Ort, um HTTP-Weiterleitungen einzurichten, Zugriffsberechtigungen für eine Seite zu prüfen und diese gegebenenfalls zu sperren oder Formularübermittlungen zu verarbeiten. Er wird nicht zum Laden von Interface-Dateien verwendet.
• template_include (Filter): Wird ausgelöst, nachdem WordPress entschieden hat, welche Datei verwendet werden soll, aber kurz vor dem Laden dieser Datei. Sein einziger Zweck besteht darin, den Pfad der zu verarbeitenden .php-Datei zu ändern, um das HTML zu generieren.

Content-Injektion vs. Template-Injektion

Wenn du Daten deines Plugins im Frontend anzeigen musst, hast du zwei architektonische Hauptoptionen. Die richtige Wahl hängt vom gewünschten Kontrollniveau ab:

1. Filter the_content: Du fügst dein HTML am Ende oder am Anfang des Beitragsinhalts hinzu.

• Vorteil: 100 % Kompatibilität mit jedem Theme. Das Theme kontrolliert weiterhin den Header, den Footer, die Sidebars und den Hauptcontainer.
• Nachteil: Du hast wenig Kontrolle über das Gesamtdesign der gesamten Seite.

2. Filter template_include: Du lädst eine komplette .php-Datei aus deinem Plugin.

• Vorteil: Absolute Kontrolle über das HTML. Du kannst Sidebars weglassen, einen modifizierten get_header()-Aufruf tätigen oder Fullscreen-Layouts erstellen.
• Nachteil: Risiko, das visuelle Design der Website zu zerstören, wenn dein Template nicht die CSS-Wrapper enthält, die das aktive Theme erwartet, was erfordert, dass der Benutzer sein CSS anpasst.

1.4 Unterschiede zwischen Plugins und Themes

In der WordPress-Entwicklung gibt es ein architektonisches Prinzip, das als Separation of Concerns (Trennung der Belange) bekannt ist. Obwohl die PHP-Engine von WordPress es technisch erlaubt, fast jeden Code sowohl über ein Theme als auch über ein Plugin auszuführen, führt die Verletzung dieser Trennung zu instabilen Ökosystemen, schwer wartbarem Code und Benutzern, die in mangelhaften Architekturen gefangen sind.

Die goldene Regel ist einfach, aber strikt: Themes steuern die Präsentation; Plugins steuern die Funktionalität und die Daten.

Das Antipattern von functions.php

Die Datei functions.php eines Themes verhält sich technisch gesehen genauso wie ein Plugin. Sie wird während des Initialisierungsprozesses geladen (Schritt 8, siehe Abschnitt 1.1) und hat Zugriff auf die allermeisten WordPress-Hooks. Diese Ähnlichkeit ist der Ursprung des häufigsten Fehlers unter Theme-Entwicklern: die Aufnahme von Geschäftslogik in das Theme.

Wenn du einen Custom Post Type (CPT) für „Portfolio“ oder „Testimonials“ in der functions.php registrierst, erzeugst du ein schwerwiegendes Portabilitätsproblem namens Vendor Lock-in (Anbieter-Lock-in). Wenn der Benutzer in Zukunft das Theme wechselt, um das visuelle Design seiner Website zu erneuern, verliert er sofort den Zugriff auf alle Daten seines Portfolios. Die Daten verbleiben zwar in der Datenbank, aber das WordPress-Admin-Interface weiß nicht, wie sie angezeigt oder verwaltet werden sollen, weil der Code zur Registrierung des CPTs mit dem alten Theme verschwunden ist.

Jedes Feature, das Daten generiert oder verwaltet, die einen Wechsel des visuellen Designs überdauern sollen, muss in ein Plugin ausgelagert werden.

Vergleichstabelle der Verantwortlichkeiten

Um die Grenzen zu verdeutlichen, zeigt die folgende Tabelle im Detail, welche Elemente strikt zu den einzelnen Komponenten des Ökosystems gehören:

Technische Unterschiede bei der Ausführung

Abgesehen von der Design-Philosophie gibt es grundlegende technische Unterschiede darin, wie WordPress beide Elemente während ihres Lebenszyklus behandelt:

1. Lade-Reihenfolge: Plugins werden immer vor dem Theme geladen. Das bedeutet, dass ein Plugin Daten vorbereiten, globale Variablen registrieren oder Konfigurationen festlegen kann, die das Theme später für sein Rendering konsumiert. Ein Theme kann keine Funktionalitäten initialisieren unter der Annahme, dass das Plugin sich anpasst, da das Plugin bereits ausgeführt wurde.
2. Vielzahl: Du kannst Dutzende von Plugins gleichzeitig aktiv haben, die über Hooks miteinander interagieren. Es kann jedoch immer nur ein Theme gleichzeitig aktiv sein (oder maximal zwei bei einer Child/Parent-Theme-Beziehung).
3. Deaktivierung vs. Deinstallation: Plugins verfügen über komplexe Lebenszyklus-Routinen (Aktivierung, Deaktivierung und Deinstallation), mit denen sich beim Aktivieren die Datenbank ändern oder benutzerdefinierte Tabellen erstellen lassen, die bei der Deinstallation wieder bereinigt werden. Themes fehlt dieser formale native Lebenszyklus; sie werden einfach durch ein anderes Theme ersetzt.

Die Rolle des Plugins im View-Layer

Obwohl der Schwerpunkt von Plugins auf der Logik liegt, müssen sie oft visuelle Elemente integrieren (z. B. ein Kontaktformular oder einen Payment-Button). Als Plugin-Entwickler sollte deine Verantwortung im View-Layer minimal und flexibel sein.

Wenn ein Plugin HTML generieren muss, sollte es dies auf neutrale Weise tun. Vermeide es, übermäßig spezifische CSS-Styles (!important) oder starre Layout-Strukturen zu erzwingen. Stelle stattdessen semantische CSS-Klassen bereit und überlasse dem Theme-Entwickler die endgültige Kontrolle über das Design. Wenn dein Plugin komplexe Ansichten erfordert, nutze das System zur Template-Überschreibung (wie in Abschnitt 1.3 erläutert). Dies ermöglicht es dem Benutzer, deine .php-Dateien in einen Ordner innerhalb seines Themes zu kopieren und sie dort sicher und frei zu modifizieren.

Zusammenfassung des Kapitels

In diesem ersten Kapitel haben wir die architektonischen Grundlagen geschaffen, die für eine professionelle Entwicklung im WordPress-Ökosystem erforderlich sind.

• Lade-Reihenfolge: Wir haben gelernt, dass WordPress ein reaktives und strukturiertes System ist. Über wp-settings.php werden der Core, die Plugins und das Theme in einer strikt vorhersehbaren Reihenfolge geladen. Dies unterstreicht, wie wichtig es ist, die Hooks-API zu nutzen, um Code zum algorithmisch richtigen Zeitpunkt auszuführen und Fehler durch vorzeitige Abhängigkeiten zu vermeiden.
• Die Daten-Engine: Wir haben die Funktionsweise von WP_Query und der Klasse WP analysiert. Wir haben gesehen, wie URLs in Abfragevariablen umgewandelt werden und warum der Hook pre_get_posts das einzige optimale und effiziente Werkzeug ist, um Datenbankabfragen vor ihrer Ausführung zu ändern.
• Die Rendering-Engine: Wir haben die Template-Hierarchie und den Entscheidungsbaum untersucht, mit dem WordPress die passende .php-Datei zur Darstellung der Daten auswählt. Außerdem haben wir gelernt, wie wir über ein Plugin eigene Ansichten einbinden können, indem wir den Prozess mit dem Filter template_include abfangen.
• Trennung der Belange: Schließlich haben wir die Grenzen zwischen Themes und Plugins abgesteckt. Wir haben definiert, dass das Theme ausschließlich für das Design und die visuelle Präsentation verantwortlich ist, während Plugins die gesamte Geschäftslogik, Datenmanipulation und die Erstellung von Strukturen (wie CPTs) kapseln müssen, um so die Portabilität und Skalierbarkeit der Website zu gewährleisten.