WP-Cron läuft nicht nach einem festen Zeitplan. Es wird beim Laden einer Seite ausgeführt, weshalb Ihr geplanter Beitrag seinen Termin verpasst hat und Ihre Verlängerungs-E-Mail drei Stunden zu spät eingetroffen ist.
Jeder wird Ihnen raten, es durch einen echten Server-Cron zu ersetzen. Das ist oft richtig, aber nicht immer – daher geht dieser Beitrag von Ihrem Problem aus und nicht vom Tool.
Wichtigste Erkenntnisse
- WP-Cron wird durch das Laden von Seiten ausgelöst, nicht durch die Systemuhr. Daher werden bei einer Website mit geringem Traffic die geplanten Aufgaben nicht ausgeführt, während eine Website mit hohem Traffic dieselbe Überprüfung tausende Male pro Stunde durchführt.
- Die übliche Lösung lautet
define( 'DISABLE_WP_CRON', true );inwp-konfig.phpsowie einen echten Server-Cron-Aufrufwp-cron.phpin festgelegten Abständen. - Legen Sie die Konstante fest, und schon werden der Server-Cron sowie alle geplanten Aufgaben auf Ihrer Website automatisch beendet. Die Konstante deaktiviert den Trigger, ersetzt ihn jedoch nicht.
- Der Action Scheduler ist eine Warteschlange, keine Uhr. In den eigenen FAQ heißt es, dass er standardmäßig von WP-Cron ausgelöst wird und dass überfällige Aktionen normal sind; er sorgt also für einen gleichmäßigen Durchsatz, nicht für Pünktlichkeit.
- Externe Cron-Dienste benötigen keinen Serverzugriff und bieten zusätzliche Überwachungsfunktionen, haben jedoch den Nachteil, dass ein einzelner Ausfallpunkt außerhalb Ihrer Website entsteht.
- Der standardmäßige WP-Cron ist für die meisten kleinen Blogs wirklich völlig ausreichend. WordPress beschreibt sein Warteschlangen- und Wiederholungsverhalten als Funktion, und genau das ist es auch.
Warum WP-Cron seinen Zeitplan nicht einhält
WP-Cron wird nur ausgelöst, wenn jemand eine Seite lädt. WordPress überprüft bei jedem Seitenaufruf die Liste der fälligen Aufgaben und führt alle überfälligen Aufgaben aus. Wenn also zwischen 14:00 Uhr und 17:00 Uhr niemand Ihre Website besucht, wird die für 14:00 Uhr geplante Aufgabe erst um 17:00 Uhr ausgeführt.
Das ist nicht meine Interpretation, sondern das, was in der WordPress-Dokumentation steht. Im Kapitel zum Thema „cron“ im Plugin-Handbuch wird es ganz klar formuliert: “WP-Cron läuft nicht ständig wie der System-Cron; es wird nur beim Laden einer Seite ausgelöst.”, und darin wird fast genau dieses Beispiel mit 14:00 Uhr genannt.
Das Problem ist also der Name. Es heißt „cron“ und funktioniert wie eine To-do-Liste, die jedes Mal abgehakt wird, wenn jemand daran vorbeigeht.
Der Fehler tritt in beide Richtungen auf – und genau diesen Aspekt lassen die meisten Anleitungen außer Acht. Eine wenig frequentierte Website hält ihre Zeitpläne nicht ein, während eine stark frequentierte Website bei jeder einzelnen Anfrage dieselbe Überprüfung durchführt, was Die Dokumentation von WP Engine heißt es: “Dies führt dazu, dass der Server stärker ausgelastet wird, als eigentlich nötig wäre, und kann zu Verzögerungen, Timeouts und anderen Leistungsproblemen führen.”
Gehen Sie von Ihrem Symptom aus, nicht vom Werkzeug
Unterschiedliche Symptome erfordern unterschiedliche Lösungen, und wenn man zuerst das Werkzeug auswählt, kommt es oft dazu, dass ein externer Cron-Dienst eine Website anpingt, deren eigentliches Problem eine überladene „actions“-Tabelle war. Suchen Sie Ihr Symptom in dieser Tabelle und lesen Sie dann den Abschnitt, auf den es verweist.
| Was Sie hier sehen | Was ist eigentlich los? | Was hilft dagegen? |
|---|---|---|
| Ein geplanter Beitrag wird angezeigt “Terminversäumnis” | Zum Zeitpunkt der geplanten Veröffentlichung des Beitrags hat niemand eine Seite geladen. | Ein echter Server-Cron, sodass der Auslöser je nach Besucherzahl stoppt |
| E-Mails und Verlängerungsbenachrichtigungen von WooCommerce kommen verspätet an | Dasselbe Trigger-Problem, allerdings bei einer Warteschlange, die wichtiger ist | Server-Cron und Überprüfung des Action Schedulers auf festgefahrene Aufträge |
Tausende Zeilen in wp_actionscheduler_actions | Ein Durchsatzproblem, kein Timing-Problem | Optimierung und Bereinigung des Aktionsplaners, kein neuer Auslöser |
| Ihre Website verzeichnet nur sehr wenige Besucher | Der Abzug löst zu selten aus, als dass man sich darauf verlassen könnte | Server-Cron oder ein externer Cron-Dienst |
| Hohes Datenaufkommen und eine langsame TTFB unter Last | Die Cron-Prüfung wird bei jeder Anfrage ausgeführt | DISABLE_WP_CRON sowie ein Server-Cron-Job in festen Zeitabständen |
| Es ist eigentlich nichts kaputt | Nichts | Lass es einfach sein. Wirklich. |
Beachten Sie, wie wenige dieser Einträge den Hinweis “WP-Cron ersetzen” enthalten. Das ist beabsichtigt, und genau hier weiche ich von den Empfehlungen ab, die Sie ganz oben in den Suchergebnissen finden.
Server-Cron, Action Scheduler und externe Dienste im Vergleich
Diese drei sind keine Konkurrenten, und sie als Auswahlliste zu betrachten, ist der erste Fehler. Ein Server-Cron ersetzt den Trigger, der Action Scheduler verwaltet eine Warteschlange von Aufträgen, und ein externer Dienst ersetzt den Trigger von außerhalb Ihres Servers.
| Echter Server-Cron | Aktionsplaner | Externer Cron-Dienst | |
|---|---|---|---|
| Was es tatsächlich bewirkt | Anrufe wp-cron.php auf der Systemuhr | Warteschlangen, Stapel, Wiederholungsversuche und Protokolle von Hintergrundjobs | Anrufe wp-cron.php von einem anderen Server |
| Verbessert das die Pünktlichkeit? | Ja | Nein. Es übernimmt standardmäßig den Auslöser von WP-Cron. | Ja |
| Verbessert den Durchsatz? | Nein | Ja, das ist genau seine Aufgabe. | Nein |
| Ist ein Serverzugriff erforderlich? | Ja, crontab oder ein Hosting-Panel | Nein, es wird über WooCommerce und andere Plattformen versendet. | Nein |
| Hauptrisiko | Man legt die Konstante fest und muss sich dann nicht mehr um den Cron kümmern | Dies fälschlicherweise für eine Lösung des Terminierungsproblems halten | Ein einzelner Fehlerpunkt, über den Sie keine Kontrolle haben |
| Am besten geeignet für | Feste Veröffentlichungszeiten, Verlängerungen, Websites mit geringem Besucheraufkommen | Speicher mit Tausenden von Aufträgen in der Warteschlange | Managed Hosting ohne Cron-Zugriff |
Um zu überprüfen, was auf Ihrer Website tatsächlich geplant ist, ist WP Crontrol das Standard-Plugin, und WP-CLI liefert Ihnen dieselbe Liste mit Liste der WP-Cron-Ereignisse. Schau erst einmal nach, bevor du etwas änderst.
So stellen Sie WP-Cron auf einen echten Server-Cron um
Es sind zwei Schritte: Deaktivieren Sie den Auslöser „Seitenladen“ und lassen Sie anschließend die Systemuhr die gleiche Datei nach einem Zeitplan aufrufen. Führen Sie den zweiten Schritt durch, sonst stellt Ihre Website stillschweigend die Ausführung aller geplanten Aufgaben ein.
Schritt 1. Füge dies hinzu zu wp-konfig.php, oberhalb der Zeile mit dem Text “Das war’s, Bearbeitung beenden”:
define( 'DISABLE_WP_CRON', true );Schritt 2. Richten Sie einen echten Cron-Job auf dem Server ein, entweder über das Control Panel Ihres Hosting-Anbieters oder in der crontab. Alle fünf Minuten ist eine sinnvolle Standardeinstellung:
*/5 * * * * wget -q -O - https://yoursite.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1Nun zum wichtigen Teil – und zwar zu dem Fehlerfall, vor dem dich niemand warnt. DISABLE_WP_CRON deaktiviert nicht die Zeitplanung, sondern deaktiviert die Auslöser.
Ihre Ereignisse befinden sich weiterhin in der Datenbank und warten darauf, dass sie an der Reihe sind. Es gibt nichts, was sie ausführt. Daher werden die Beiträge nicht veröffentlicht, die E-Mails nicht versendet, die Backups nicht ausgeführt, und WordPress meldet überhaupt keinen Fehler, da aus seiner Sicht die Warteschlange einfach nicht abgefragt wird.
Noch ein Hinweis, falls Sie Managed Hosting nutzen. In der Dokumentation von WP Engine heißt es dazu unterstützt technisch gesehen keine echten Server-Cron-Jobs und bietet stattdessen einen „Alternate Cron“-Dienst an, der wp-cron.php für dich, wofür dieselbe Konstante erforderlich ist. “Einfach crontab verwenden” ist also auf manchen Hosts nicht einmal im wörtlichen Sinne möglich, und die Anleitungen, die das empfehlen, erwähnen das mit keinem Wort.
Der Action Scheduler ist eine Warteschlange, keine Uhr
Der Action Scheduler sorgt nicht dafür, dass Ihre Aufgaben pünktlich ausgeführt werden, da er nicht über den Auslöser verfügt. Seine eigene FAQ Dort heißt es, dass das Plugin standardmäßig “von WP-Cron ausgelöst wird” und “so konzipiert ist, dass es mit WP-Cron zusammenarbeitet, ohne dessen Verhalten zu verändern”, und es wird darauf hingewiesen, dass überfällige Aktionen normal sind.
Lies das noch einmal, denn es wird regelmäßig als Lösung für verspätete Aufträge angepriesen. Dabei weist es genau das Auslöseproblem auf, das es eigentlich lösen soll.
Ich kann Ihnen das lieber auf unserer eigenen Website zeigen, anstatt darüber zu diskutieren. Der „WordPress Site Health“-Bericht meldet hier, dass ein geplanter Vorgang in Verzug ist, und der dort genannte Vorgang ist action_scheduler_run_queue, das ist das WP-Cron-Ereignis, dessen Aufgabe es ist, die Warteschlange des Action Schedulers auszuführen.
Wozu eignet sich Action Scheduler also? Für große Datenmengen. Es führt Batch-Verarbeitungen durch, wiederholt Vorgänge, protokolliert sie und bietet Ihnen eine Verwaltungsoberfläche – und speichert alles in einer eigenen actionscheduler_ Tabellen, anstatt alles einfach in wp_options.
So sieht das in einem echten Shop aus. Auf unserer Website wurden 1.697 Aktionen erfasst, davon 1.565 abgeschlossen und 123 fehlgeschlagen, und ich hätte nicht gewusst, dass diese Fehler vorliegen, wenn ich diesen Bildschirm nicht geöffnet hätte.
Das ist die ehrliche Zusammenfassung dieses Tools. Es eignet sich hervorragend für die Verwaltung von Tausenden von Aufträgen, ist jedoch die falsche Wahl, wenn Ihr Einwand lautet: “Das hätte um 3:10 Uhr morgens geschehen müssen.”
Was externe Cron-Dienste Ihnen bieten und was sie kosten
Ein externer Cron-Dienst ruft Ihre wp-cron.php von einer anderen Stelle im Internet aus, nach einem festen Zeitplan. Sie benötigen keinerlei Serverzugriff und profitieren in der Regel von Überwachungs- und Benachrichtigungsfunktionen, die Ihnen eine Crontab-Eintragung niemals bieten kann.
Der Haken daran ist, dass das Herzstück Ihrer Website nun außerhalb Ihrer Website liegt. Wenn der Dienst ausfällt, Ihr Konto erlischt oder die Verbindung zu Ihrem Server unterbrochen wird, ist der Trigger weg, und nichts auf Ihrem Server bemerkt dies, da nichts auf Ihrem Server jemals darauf geachtet hat.
Das ist meine Überlegung, kein dokumentierter Fehler, über den irgendjemand berichtet, und ich würde mich dennoch für den Wechsel zu einem verwalteten Host ohne Cron-Zugriff entscheiden. Die Überwachung ist ihren Preis wert, und ein fehlender Trigger, auf den man benachrichtigt wird, ist besser als ein fehlender Trigger, den man erst eine Woche später entdeckt.
Wer muss WP-Cron wirklich nicht ersetzen?
Wenn Ihre Website keine zeitgebundenen Verpflichtungen hat, ist WP-Cron völlig ausreichend, und Sie können hier aufhören zu lesen. Ein Blog, bei dem die Veröffentlichung erst erfolgt, wenn Sie auf „Veröffentlichen“ klicken, und der weder über einen Shop noch über Verlängerungen oder zeitkritische E-Mails verfügt, hat keinerlei Nachteile, wenn eine Bereinigungsaufgabe um 17:00 Uhr statt um 14:00 Uhr ausgeführt wird.
WordPress argumentiert selbst dafür, und genau dieses Zitat zeigt dir die Fraktion, die immer darauf pocht, “es immer zu ersetzen”, niemals. Aus demselben Kapitel des Handbuchs:
Beim System-Scheduler wird ein Task nicht erneut versucht, wenn die Zeit abgelaufen ist und er nicht ausgeführt wurde. Bei WP-Cron werden alle geplanten Tasks in eine Warteschlange gestellt und bei der nächsten Gelegenheit (d. h. beim nächsten Laden der Seite) ausgeführt. Man kann sich also nicht zu 100% sicher sein, wenn Deine Aufgabe wird ausgeführt werden, du kannst dir 100% sicher sein, dass sie ausgeführt wird schließlich.
Das ist, ehrlich gesagt, ein echter Kompromiss beim Design. Ein System-Cron, der ausgelöst wird, während auf Ihrer Website ein Fehler auftritt, lässt diesen Durchlauf einfach aus und fährt fort, während WP-Cron den Auftrag in der Warteschlange hält und ihn bei der nächsten Gelegenheit erneut versucht.
Keines der beiden Modelle ist abstrakt betrachtet besser – sie weisen lediglich unterschiedliche Schwächen auf. Sie haben die Wahl zwischen “Es wird laufen, ich weiß nur nicht genau, wann” und “Es wird um 3:10 Uhr morgens laufen – oder gar nicht”.”
Es lohnt sich auch, darauf zu achten, wer von diesen pauschalen Ratschlägen profitiert. Vor allem Hosting-Anbieter und Anbieter von Cron-Überwachungsdiensten veröffentlichen solche Ratschläge, und die von ihnen beschriebenen Vorgehensweisen sind zwar korrekt. Gegen das Wort “immer” würde ich jedoch Einwände erheben.
Was auf dieser Website tatsächlich läuft und warum
Wir gehören ganz klar zum Lager derjenigen, für die das “richtige Timing entscheidend ist”, daher nutzen wir den serverseitigen Trigger. Dieser Blog veröffentlicht zu festgelegten Zeitpunkten, und diese Woche gingen zwei Beiträge genau zu den geplanten Minuten online – einer um 3:10 Uhr morgens und einer um 15:30 Uhr nach Dhaka-Zeit –, während mein Rechner ausgeschaltet war und ich schlief.
Das funktioniert nur, weil der Auslöser nicht davon abhängt, dass zufällig um 3:10 Uhr morgens ein Besucher auf die Seite gelangt. Zu dieser Uhrzeit surft so gut wie niemand auf einem SEO-Blog – genau das ist der Fall mit geringem Traffic aus der obigen Tabelle.
Unser Gastgeber ist Hostinger, und wie die meisten Hosting-Anbieter bietet auch dieser im Control Panel eine Oberfläche für Cron-Jobs an, sodass die Einrichtung aus den beiden oben genannten Schritten besteht und nicht viel komplizierter ist als das.
Die Geschichte, die uns hierher geführt hat, ist lesenswert, wenn Sie irgendetwas verkaufen: Ich habe genau den Fall beschrieben, in dem E-Mails und Verlängerungsbenachrichtigungen von WooCommerce verspätet eintrafen und Das Problem wurde durch die Einrichtung eines echten Cron-Jobs behoben.. Dieser Artikel ist die allgemeine Version dieser Korrektur.
Eine Unterscheidung, die man dabei im Auge behalten sollte: Eine verspätete E-Mail ist eine Terminplanung Problem, und eine E-Mail, die überhaupt nicht ankommt, ist in der Regel ein Lieferung Problem, das eine ganz andere Lösung erfordert. Wenn Sie sich nicht sicher sind, um welches Problem es sich handelt, überprüfen Sie zunächst, ob Ihre E-Mails das Gebäude überhaupt verlassen, indem Sie SMTP richtig einrichten Erstens.
Und falls Ihr Grund dafür, sich damit zu beschäftigen, eher die Serverauslastung als die Ladezeit ist: Der Overhead beim Laden der Seite ist zwar vorhanden, aber gering, und er ist selten der eigentliche Grund für Verzögerungen. Ich habe darüber geschrieben, was wirklich den Ausschlag gibt, wenn Eine WordPress-Website muss hohen Datenverkehr bewältigen können, und etwa INP und Reaktionsfähigkeit was den Frontend-Bereich betrifft.
Sollten Sie also WP-Cron ersetzen?
Wenn auf Ihrer Website etwas zu einem bestimmten Zeitpunkt geschehen muss, dann ja – und zwar noch heute. Geplante Beiträge, Abonnementverlängerungen, Transaktions-E-Mails und nächtliche Backups verdienen alle einen Auslöser, der nicht davon abhängt, dass ein Fremder Ihre Startseite aufruft.
Wenn nichts auf Ihrer Website eine Frist hat, lassen Sie es einfach so, wie es ist. Sie würden damit einen zusätzlichen Faktor und eine neue Fehlerquelle einführen – und das nur für eine Pünktlichkeit, die Sie ohnehin nie genutzt haben.
Und wenn Sie eine Sache daraus mitnehmen: Wenn Sie diese Konstante festlegen, überprüfen Sie bitte, ob der Server-Cron tatsächlich läuft, bevor Sie das Terminal schließen. Eine Website mit DISABLE_WP_CRON Und kein Cron-Job scheint vollkommen einwandfrei zu laufen – bis zu dem Tag, an dem man feststellt, dass seit einer Woche nichts mehr veröffentlicht wurde.
Werden geplante Aufgaben immer noch verspätet ausgeführt?
Sollten Ihre Beiträge, E-Mails oder Verlängerungen danach immer noch keine Zeitangaben enthalten, kontaktieren Sie uns oder E-Mail und ich werde dir dabei helfen, herauszufinden, welches der drei Probleme bei dir tatsächlich vorliegt.
Möchtest du, dass unsere Beiträge öfter bei Google erscheinen?
Ein Schritt – und Google zeigt diese Seite in Ihren „Top Stories“ an.
