wordpress-plugins

WP-Cron und Hintergrundaufgaben

Automatisiere wiederkehrende Prozesse auf dem Server. Plane Events, beherrsche das Pseudo-Cron-System von WordPress und lerne, Hintergrundaufgaben optimiert und sicher auszuführen.

Bei der Entwicklung von Plugins verbrauchen rechenintensive Aufgaben wie der E-Mail-Versand oder die Datenbereinigung zu viel Zeit, um während des Ladevorgangs einer Seite ausgeführt zu werden. Den Besucher zu blockieren, während diese abgeschlossen werden, führt zu einer schlechten Benutzererfahrung. Um dies zu lösen, integriert WordPress seinen eigenen Planer: WP-Cron. In diesem Kapitel werden wir seine auf HTTP-Anfragen basierende Architektur entdecken, du wirst lernen, wie du einmalige und wiederkehrende Events sicher programmierst, und du wirst die notwendigen Debugging-Techniken beherrschen, um asynchrone Prozesse und Hintergrundprozesse effizient und ohne Beeinträchtigung der Serverleistung zu verwalten.

14.1 Wie WP-Cron funktioniert

In Unix-basierten Betriebssystemen ist der Befehl cron ein Aufgabenplaner, der von der Systemuhr gesteuert wird. Er ermöglicht es, Skripte oder Befehle zu genauen Zeiten oder in regelmäßigen Intervallen auszuführen (z. B. „jeden Mitternacht“ oder „alle 5 Minuten“). WordPress wurde jedoch so konzipiert, dass es in möglichst vielen Umgebungen funktioniert, einschließlich Shared-Hosting-Servern, auf denen Benutzer in der Regel keinen Zugriff haben, um Aufgaben auf Betriebssystemebene zu konfigurieren.

Um dieses Problem zu lösen, implementiert WordPress sein eigenes System zur Aufgabenplanung, bekannt als WP-Cron. Im Gegensatz zum System-Cron ist WP-Cron ein Pseudo-Cron. Es wird nicht von der Serveruhr gesteuert, sondern vom Web-Traffic. Das bedeutet, dass WP-Cron auf HTTP-Anfragen (Besuche von Benutzern, Suchmaschinen-Crawler etc.) angewiesen ist, um aktiviert zu werden.

Der Ausführungsfluss von WP-Cron

Der interne Mechanismus von WP-Cron wird bei fast jedem Laden einer WordPress-Seite ausgewertet, ist jedoch so konzipiert, dass er so wenig wie möglich stört. Der Prozess folgt diesem Ablauf:

TEXT
[Benutzer oder Bot] ───> Führt eine HTTP-Anfrage auf eine beliebige Seite aus
                                 |
                                 v
               [WordPress startet den Ladevorgang] (Kapitel 1)
                                 |
                                 v
              Gibt es abgelaufene geplante Aufgaben?
               (Abfrage in der Tabelle wp_options)
                                 |
                   +-------------+-------------+
                   | (Ja)                      | (Nein)
                   v                           v
         Aufruf von spawn_cron()        Das Laden der Seite
                   |                    wird normal fortgesetzt
                   v
    Asynchrone HTTP-Anfrage an `wp-cron.php`
    (Non-blocking loopback request)
                   |
                   v
         Ausführung der den
         Aufgaben zugeordneten Hooks

Wenn ein Benutzer die Website besucht, überprüft WordPress eine Option in der Datenbank (genauer gesagt die Zeile mit option_name = 'cron' in der Tabelle wp_options). Diese Option enthält ein serialisiertes Array mit allen geplanten Aufgaben und deren Ausführungs-Zeitstempeln (Timestamps).

Wenn WordPress feststellt, dass der aktuelle Zeitstempel größer oder gleich dem einer geplanten Aufgabe ist, ruft es die Funktion spawn_cron() auf.

Um zu verhindern, dass der Benutzer, der den Besuch generiert hat, auf die Ausführung schwerer Aufgaben (wie den Versand von Newslettern oder die Bildoptimierung) warten muss, WordPress führt eine HTTP-Anfrage an sich selbst durch, die an die Datei wp-cron.php gerichtet ist. Diese Anfrage wird über die native HTTP-API (mit wp_remote_post()) gesendet und mit einem extrem kurzen Timeout konfiguriert, der in der Regel bei 0,01 Sekunden liegt.

Dadurch startet WordPress den Hintergrundprozess asynchron („fire and forget“) und liefert die Seite für den Besucher fast augenblicklich weiter aus.

Einschränkungen des trafficbasierten Ansatzes

Das Design des Pseudo-Crons bringt je nach Traffic-Volumen der Website zwei grundlegende Probleme mit sich:

Websites mit geringem Traffic: Wenn ein Event für 03:00 Uhr morgens geplant ist, aber bis 08:30 Uhr niemand die Website besucht, wird die Aufgabe erst um 08:30 Uhr ausgeführt. WP-Cron ist nicht in der Lage, Events zu einer exakten Zeit auszuführen, wenn keine Anfrage den Trigger auslöst.
Websites mit hohem Traffic: Obwohl die Anfrage an wp-cron.php asynchron ist und standardmäßig ein Sperrlimit (Lock) von 10 Minuten hat, um gleichzeitige Ausführungen zu verhindern, kann die ständige Überprüfung auf ausstehende Aufgaben und die Generierung wiederkehrender Loopback-Anfragen auf Websites mit Tausenden von Besuchen pro Minute einen unnötigen Ressourcenverbrauch (CPU und Speicher) auf dem Webserver verursachen.

Entkopplung von WP-Cron: Systemmodus

Für Produktionsumgebungen oder Plugins, die auf strikte Präzision angewiesen sind (z. B. kritische Synchronisationen mit externen APIs über die in Kapitel 13 behandelte REST-API oder Zahlungsgateways), ist es Branchenstandard, das native trafficgesteuerte Verhalten zu deaktivieren und den Trigger an den echten System-Cron des Servers zu delegieren.

Dies wird durch die Definition einer Konstante in der Datei wp-config.php erreicht:

PHP
define( 'DISABLE_WP_CRON', true );

Durch das Setzen von DISABLE_WP_CRON auf true sendet WordPress bei Benutzerbesuchen keine asynchrone Anfrage mehr an wp-cron.php. Das System zur Aufgabenwarteschlange funktioniert jedoch weiterhin unverändert; die Aufgaben werden weiterhin in der Datenbank registriert.

Damit die Aufgaben ausgeführt werden, muss der Serveradministrator einen echten Cronjob im Betriebssystem (z. B. über crontab unter Linux) einrichten, der die Datei wp-cron.php in regelmäßigen Intervallen (normalerweise jede Minute oder alle 5 Minuten) anpingt:

Bash
# Beispiel für einen crontab-Eintrag, der WP-Cron alle 5 Minuten aufruft
*/5 * * * * wget -q -O - https://deinedomaene.de/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Als Plugin-Entwickler musst du standardmäßig davon ausgehen, dass sich WP-Cron nativ (trafficabhängig) verhält. Das bedeutet, dass der Code deiner Hintergrundaufgaben tolerant gegenüber Verzögerungen bei der Ausführung sein muss und niemals von einer sekundengenauen Präzision abhängen darf.

14.2 Planung einmaliger Events

Bei der Entwicklung von Plugins kommt es häufig vor, dass eine rechenintensive oder sekundäre Aufgabe nicht sofort ausgeführt werden muss, sondern auf einen bestimmten zukünftigen Zeitpunkt verschoben werden soll. Einmalige Events ermöglichen es, die Ausführung einer Funktion an einen bestimmten Zeitstempel zu delegieren. Dadurch wird der aktuelle Prozess entlastet, sodass der Benutzer eine schnelle Antwort erhält.

Typische Anwendungsfälle sind:

Senden einer Follow-up-E-Mail 24 Stunden nach der Registrierung eines Benutzers.
Verarbeiten oder Ändern der Größe eines großen Stapels hochgeladener Bilder, ohne die Benutzeroberfläche zu blockieren.
Löschen temporärer Daten oder Testdaten nach einer Schonfrist.

Die Funktion wp_schedule_single_event()

Die Hauptfunktion des Cores, um ein einmaliges Event in die Warteschlange einzureihen, ist wp_schedule_single_event(). Diese Funktion führt den Code nicht direkt aus, sondern registriert einen Action-Hook (wie in Kapitel 2 behandelt) im WP-Cron-System, damit dieser in der Zukunft ausgelöst wird.

Ihre Signatur sieht wie folgt aus:

PHP
wp_schedule_single_event( int $timestamp, string $hook, array $args = array(), bool $wp_error = false )

$timestamp: Ein UNIX-Zeitstempel, der angibt, wann das Event stattfinden soll. Dies muss die aktuelle Zeit o eine Zeit in der Zukunft sein. Um Berechnungen zu erleichtern, WordPress bietet mathematische Zeitkonstanten wie MINUTE_IN_SECONDS, HOUR_IN_SECONDS, DAY_IN_SECONDS etc.
$hook: Der Name des benutzerdefinierten Action-Hooks, der ausgelöst wird, wenn der Zeitstempel erreicht ist.
$args (Optional): Ein indiziertes Array von Argumenten, die an die Callback-Funktion übergeben werden, wenn der Hook ausgeführt wird.
$wp_error (Optional): Wenn auf true gesetzt, wird im Fehlerfall un WP_Error-Objekt anstelle von false zurückgegeben.

Lebenszyklus eines einmaligen Events

Die Implementierung eines einmaligen Events erfordert immer zwei separate Codeteile:

Der Enqueue-Prozess: Der Code, der bewertet, wann die Aktion stattfinden soll, und das Event plant.
Der Handler (Callback): Die an den benutzerdefinierten Hook angehängte Funktion, welche die tatsächliche Logik ausführt, wenn das Event von WP-Cron ausgelöst wird.

TEXT
Ausführungsfluss eines einmaligen Events:

[Auslösendes Event] (z. B. user_register)
          |
          v
1. wp_schedule_single_event() ───> Registriert den Hook und den Zeitstempel in der DB
          |
     (Sofortige Rückgabe an den Benutzer)
          |
    ... Zeit vergeht ...
          |
2. WP-Cron erkennt Ablauf ───> Löst den benutzerdefinierten Action-Hook aus
          |
          v
3. add_action( 'dein_hook', 'dein_callback' ) ───> Führt die Aufgabe im Hintergrund aus

Duplikatsvermeidung bei Events

Eine der goldenen Regeln bei der Arbeit mit der WP-Cron-API is es, die Überlastung der Aufgabenwarteschlange zu vermeiden. Wenn das auslösende Event mehrmals auftritt, bevor die geplante Aufgabe ausgeführt wird, könntest du dasselbe Event mehrfach registrieren, was unnötige Ressourcen verbraucht.

Um dies zu verhindern, solltest du mit wp_next_scheduled() immer prüfen, ob die Aufgabe bereits geplant ist.

Praktisches Beispiel: Zeitverzögerter E-Mail-Versand

Angenommen, du möchtest einem Benutzer genau 1 Stunde nach Erstellung seines Kontos eine Willkommens-E-Mail senden. Anstatt den Registrierungsprozess anzuhalten, um den Versand abzuwickeln, delegieren wir dies an WP-Cron.

PHP
// 1. Auslösender Hook: Tritt auf, wenn sich ein Benutzer registriert
add_action( 'user_register', 'mi_plugin_programar_email_bienvenida', 10, 1 );

function mi_plugin_programar_email_bienvenida( $user_id ) {
    // Wir berechnen die Zeit: 1 Stunde ab jetzt
    $timestamp = time() + HOUR_IN_SECONDS;
    
    // Wir definieren den Namen unseres benutzerdefinierten Action-Hooks
    $hook = 'mi_plugin_evento_email_bienvenida';
    
    // Die Argumente MÜSSEN ein Array sein, selbst bei einem einzelnen Wert
    $args = array( $user_id );

    // Wir überprüfen, ob exakt dieses Event mit denselben Argumenten nicht bereits geplant ist
    if ( ! wp_next_scheduled( $hook, $args ) ) {
        wp_schedule_single_event( $timestamp, $hook, $args );
    }
}

// 2. Wir lauschen auf unseren benutzerdefinierten Hook
add_action( 'mi_plugin_evento_email_bienvenida', 'mi_plugin_procesar_email_bienvenida', 10, 1 );

function mi_plugin_procesar_email_bienvenida( $user_id ) {
    // Wir holen die Benutzerdaten
    $user = get_userdata( $user_id );
    
    if ( ! $user ) {
        return; // Vorzeitiger Abbruch, wenn der Benutzer vor Ablauf der Stunde gelöscht wurde
    }

    $to      = $user->user_email;
    $subject = 'Willkommen auf unserer Plattform!';
    $message = 'Hallo ' . $user->display_name . ', danke für deine Registrierung. Entdecke die neuen Funktionen.';

    // Wir versenden die E-Mail
    wp_mail( $to, $subject, $message );
}

Stornierung eines einmaligen Events

Wenn ein geplantes Event aufgrund einer Änderung des Systemstatus nicht mehr erforderlich ist (z. B. hast du das Löschen eines Kontos geplant, das noch auf die Aktivierung wartet, nach 3 Tagen, aber der Benutzer hat es am zweiten Tag aktiviert), musst du die Warteschlange mit wp_clear_scheduled_hook() leeren.

PHP
function mi_plugin_cancelar_borrado_cuenta( $user_id ) {
    $hook = 'mi_plugin_borrar_cuenta_inactiva';
    $args = array( $user_id );

    // Löscht jedes geplante Event für diesen Hook und diese spezifischen Argumente
    wp_clear_scheduled_hook( $hook, $args );
}

Es ist entscheidend zu beachten, dass sowohl wp_next_scheduled() als auch wp_clear_scheduled_hook() erfordern, dass du genau dasselbe Array von $args übergibst, das du in wp_schedule_single_event() verwendet hast. WP-Cron generiert eine Hash-Signatur basierend auf dem Hook-Namen und den Argumenten, um Events eindeutig zu identifizieren. Wenn die Argumente nicht übereinstimmen, schlägt die Überprüfung oder Stornierung fehl.

14.3 Erstellung wiederkehrender Events

Im Gegensatz zu einmaligen Events, die nur einmal ausgeführt und aus der Warteschlange gelöscht werden, ermöglichen wiederkehrende Events die periodische Ausführung von Bereinigungs-, Synchronisations- oder Wartungsaufgaben (z. B. stündlich, täglich oder wöchentlich).

Um ein wiederkehrendes Event in WordPress zu implementieren, muss man zwei wesentliche Komponenten beherrschen: die Definition des Zeitintervalls (Cron-Schedule) und die Planung des Events selbst.

Definition benutzerdefinierter Intervalle

WordPress enthält standardmäßig einen begrenzten Satz von Zeitintervallen: hourly (stündlich), twicedaily (zweimal täglich) und daily (täglich). Wenn dein Plugin eine andere Periodizität benötigt (z. B. alle 5 Minuten oder alle 15 Tage), musst du dieses neue Intervall mithilfe des Filters cron_schedules registrieren.

Der mit diesem Filter verknüpfte Callback empfängt ein Array mit den vorhandenen Intervallen und muss das modifizierte Array zurückgeben, indem das neue Intervall mit seiner entsprechenden Struktur hinzugefügt wird:

PHP
// 1. Ein benutzerdefiniertes Intervall von alle 5 Minuten registrieren
add_filter( 'cron_schedules', 'mi_plugin_añadir_intervalo_cinco_minutos' );

function mi_plugin_añadir_intervalo_cinco_minutos( $schedules ) {
    // Der Array-Schlüssel ('five_minutes') wird der technische Bezeichner des Intervalls sein
    $schedules['five_minutes'] = array(
        'interval' => 5 * MINUTE_IN_SECONDS, // Wert in Sekunden (300 Sekunden)
        'display'  => __( 'Alle 5 Minuten', 'mi-plugin-textdomain' ) // Text für den Adminbereich
    );
    return $schedules;
}

Die Funktion wp_schedule_event()

Sobald das Intervall existiert (entweder nativ oder benutzerdefiniert), wird die Funktion wp_schedule_event() verwendet, um die Wiederholung zu initialisieren.

PHP
wp_schedule_event( int $timestamp, string $recurrence, string $hook, array $args = array(), bool $wp_error = false )

$timestamp: Der UNIX-Zeitstempel der ersten Ausführung. Wenn du time() angibst, erfolgt die erste Ausführung sofort beim nächsten Auslösen von WP-Cron, und ab diesem Zeitpunkt wird sie gemäß dem Intervall wiederholt.
$recurrence: Der Bezeichner des Intervalls (hourly, daily, five_minutes etc.).
$hook: Der Name des benutzerdefinierten Action-Hooks, der die Logik ausführt.

Die Gefahr der Überprogrammierung

Im Gegensatz zu normale Hooks von WordPress, die bei jedem Laden einer Seite registriert werden, schreibt wp_schedule_event() direkt und dauerhaft in die Datenbank. Wenn du diese Funktion bei jedem Seitenaufruf ausführst, ohne zu prüfen, ob das Event bereits existiert, duplizierst du das Event Tausende von Malen, was die Tabelle wp_options überlastet und den Server verlangsamt.

Daher sollte die Planung wiederkehrender Events idealerweise an die Aktivierungsroutinen des Plugins (behandelt in Kapitel 2) gebunden sein oder andernfalls streng in eine Überprüfung mit wp_next_scheduled() gehüllt werden.

Praktisches Beispiel: Periodische Bereinigung von Debug-Protokollen

Nachfolgend wird die vollständige und sichere Implementierung einer wiederkehrenden Aufgabe gezeigt, die täglich alte Protokolle aus der Datenbank löscht, wobei die Aktivierung und Deaktivierung korrekt verwaltet wird.

PHP
// Registrierung der Aktivierungsroutine des Plugins (Kapitel 2)
register_activation_hook( __FILE__, 'mi_plugin_activar_cron_limpieza' );

function mi_plugin_activar_cron_limpieza() {
    $hook = 'mi_plugin_cron_diario_limpieza';
    
    // Sicherheitsüberprüfung, falls es bereits geplant sein sollte
    if ( ! wp_next_scheduled( $hook ) ) {
        // Wir planen den Start für morgen um Mitternacht
        $primera_ejecucion = strtotime( 'tomorrow midnight' );
        
        wp_schedule_event( $primera_ejecucion, 'daily', $hook );
    }
}

// 2. Die Logik mit dem Action-Hook verknüpfen, der periodisch ausgeführt wird
add_action( 'mi_plugin_cron_diario_limpieza', 'mi_plugin_ejecutar_limpieza_registros' );

function mi_plugin_ejecutar_limpieza_registros() {
    global $wpdb;
    $tabla = $wpdb->prefix . 'mi_plugin_logs';

    // Logs, die älter als 30 Tage sind, sicher löschen (Kapitel 5)
    $limite_tiempo = date( 'Y-m-d H:i:s', strtotime( '-30 days' ) );
    
    $wpdb->query(
        $wpdb->prepare(
            "DELETE FROM $tabla WHERE fecha_registro < %s",
            $limite_tiempo
        )
    );
}

Zwingende Bereinigung bei der Deaktivierung

Ein Plugin mit einem guten Codestandard sollte niemals Müll im System hinterlassen, wenn es nicht mehr verwendet wird. Wenn du ein wiederkehrendes Event planst, ist es zwingend erforderlich, dieses während der Deaktivierungsroutine des Plugins über wp_clear_scheduled_hook() aus dem WP-Cron-System zu entfernen.

PHP
// Registrierung der Deaktivierungsroutine des Plugins (Kapitel 2)
register_deactivation_hook( __FILE__, 'mi_plugin_desactivar_cron_limpieza' );

function mi_plugin_desactivar_cron_limpieza() {
    // Entfernt das wiederkehrende Event dauerhaft aus der Datenbank
    wp_clear_scheduled_hook( 'mi_plugin_cron_diario_limpieza' );
}

Wenn du diese Bereinigung nicht durchführst, versucht WordPress weiterhin jeden Tag unendlich lange, den Hook mi_plugin_cron_diario_limpieza auszulösen. Da die Plugin-Dateien inaktiv sind, sucht es nach einem nicht mehr existierenden Callback, was zu stillen Fehlern in den Server-Protokollen führt.

14.4 Debugging von geplanten Aufgaben

Das Debugging von geplanten Aufgaben in WordPress stellt eine einzigartige Herausforderung dar. Da WP-Cron im Hintergrund, asynchron und entkoppelt von der Sitzung des aktuellen Benutzers arbeitet, kannst du keine traditionellen Methoden des visuellen Debuggings wie var_dump(), print_r() oder echo verwenden. Jede Bildschirmausgabe, die während einer Cron-Ausführung generiert wird, geht bei der HTTP-Loopback-Anfrage verloren.

Um Probleme bei deinen Hintergrundaufgaben zu diagnostizieren und zu beheben, musst du einen Ansatz wählen, der auf Protokollierung (Logging), Befehlszeilenwerkzeugen und der Verwendung spezifischer Hilfsprogramme des Ökosystems basiert.

1. Das Fehlerprotokoll (Error Logging)

Die zuverlässigste Technik zum Debuggen von Code, der innerhalb eines WP-Cron-Callbacks ausgeführt wird, besteht darin, direkt in die Datei debug.log des Servers zu schreiben.

Damit dies funktioniert, musst du sicherstellen, dass der Debugging-Modus in deiner Datei wp-config.php korrekt konfiguriert ist:

PHP
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // Verhindert die Anzeige von Fehlern im Frontend

Verwende innerhalb der mit deinem Event verknüpften Funktion die native PHP-Funktion error_log(), um wichtige Meilensteine, den Status von Variablen oder abgefangene Ausnahmen zu protokollieren.

PHP
add_action( 'mi_plugin_tarea_compleja', 'mi_plugin_ejecutar_tarea_compleja' );

function mi_plugin_ejecutar_tarea_compleja( $args ) {
    error_log( '[Mi Plugin] Starte komplexe Aufgabe.' );
    
    $resultado = realizar_operacion_pesada( $args );
    
    if ( is_wp_error( $resultado ) ) {
        error_log( '[Mi Plugin] Fehler in der Aufgabe: ' . $resultado->get_error_message() );
        return;
    }

    error_log( '[Mi Plugin] Aufgabe erfolgreich beendet. Betroffene Zeilen: ' . $resultado );
}

2. Inspektion des Cron-Arrays

Intern speichert WordPress alle geplanten Aufgaben in einem mehrdimensionalen Array in der Tabelle wp_options (unter dem Schlüssel cron). Um genau zu überprüfen, welche Events in der Warteschlange stehen und wann sie ausgeführt werden, kannst du die private Funktion _get_cron_array() verwenden.

TEXT
Vereinfachte Struktur des WP-Cron-Arrays:

Array
(
    [1698750000] => Array  <-- Ausführungs-Zeitstempel
        (
            [mi_plugin_cron_diario] => Array <-- Hook-Name
                (
                    [40cd750bba9870...] => Array <-- Hash (Eindeutige Signatur)
                        (
                            [schedule] => daily
                            [args] => Array()
                            [interval] => 86400
                        )
                )
        )
)

*Nota: Aunque _get_cron_array() es útil para depuración temporal, al ser una función privada (comienza con guion bajo), no debe usarse en código de producción.*

3. Debugging mit WP-CLI

WP-CLI (die Befehlszeilenschnittstelle von WordPress) ist das leistungsstärkste Werkzeug für jeden Plugin-Entwickler, der mit geplanten Aufgaben arbeitet. Sie ermöglicht es dir, die Abhängigkeit vom Web-Traffic zum Testen deiner Events zu vermeiden, was dir absolute manuelle Kontrolle gibt.

Unerlässliche Befehle für das Debugging:

Alle geplanten Events auflisten: Ermöglicht es, die aktuelle Warteschlange, die nächsten Ausführungszeiten und die zugehörigen Hooks einzusehen.

Bash
wp cron event list

Ein bestimmtes Event sofort ausführen: Ignoriert die Wartezeit und erzwingt die Ausführung des Hooks genau in diesem Moment. Dies ist entscheidend, um den Callback zu testen, ohne die Systemzeit ändern zu müssen.

Bash
wp cron event run mi_plugin_tarea_compleja

Das allgemeine WP-Cron-System testen: Führt alle Aufgaben aus, die bereits fällig sind.

Bash
wp cron test

4. Häufige Verbindungsprobleme (Loopback)

Wenn deine Aufgaben korrekt registriert werden (sie erscheinen in WP-CLI), aber niemals automatisch auf dem Server ausgeführt werden, liegt das Problem meist daran, dass der Server die HTTP-Loopback-Anfrage an wp-cron.php blockiert.

Die häufigsten Ursachen sind:

Der Server erfordert eine Standard-Authentifizierung (htpasswd), die automatisierte Anfragen blockiert.
Fehlerhafte DNS-Auflösung der eigenen Domain in der hosts-Datei des Servers.
Sicherheits-Plugins, welche interne Anfragen der servereigenen IP blockieren.
Selbstsignierte oder abgelaufene SSL-Zertifikate in lokalen Entwicklungsumgebungen, die dazu führen, dass die cURL-Anfrage geräuschlos fehlschlägt.

Du kannst den Status von Loopback-Anfragen überprüfen, indem du im Administrationsbereich auf Werkzeuge > Website-Zustand (Site Health) gehst. Wenn WordPress nicht mit sich selbst kommunizieren kann, wird dort ein kritischer Fehler angezeigt.

Zusammenfassung des Kapitels

In diesem Kapitel haben wir das native Pseudo-Cron-System von WordPress untersucht – eine raffinierte, durch Web-Traffic gesteuerte Lösung, die es ermöglicht, die Einschränkungen von Shared-Hosting-Umgebungen zu umgehen. Wir haben gelernt, einmalige Events (wp_schedule_single_event) für verzögerte Aufgaben zu planen und wiederkehrende Routinen (wp_schedule_event) durch die Erstellung benutzerdefinierter Intervalle einzurichten. Darüber hinaus haben wir uns mit der Wichtigkeit der Datenbankbereinigung bei der Deaktivierung des Plugins befasst und solide Debugging-Methoden unter Verwendung von WP-CLI sowie asynchronen Fehlerprotokollen etabliert, um sicherzustellen, dass unsere Hintergrundprozesse zuverlässig und geräuschlos ausgeführt werden.

Diese Seite bearbeiten