WordPress: WP-Cron deaktivieren und System-Cron nutzen

Was WP-Cron ist und warum System-Cron ihn ersetzt

WP-Cron ist der in WordPress integrierte Aufgabenplaner. Er wird nur ausgeführt, wenn jemand eine Seite anfordert. Innerhalb von WordPress wird kein Prozess selbstständig aktiv. Bei jeder Anfrage, die nicht aus einem Cache bedient wird, liest WordPress eine Liste geplanter Aufgaben. Ist eine Aufgabe fällig, sendet WordPress eine zweite HTTP-Anfrage an /wp-cron.php, um sie auszuführen. Wenn Sie diese Aufgabe in den System-Cron verschieben, wird sie unabhängig von der Besucherzahl zu einem festen Zeitpunkt zuverlässig ausgeführt.

Die eigentliche Arbeit erledigen zwei Zeilen: eine Konstante in wp-config.php und ein Crontab-Eintrag. Alles Weitere in dieser Anleitung behandelt Aspekte, die aus diesen beiden Zeilen nicht hervorgehen. Dazu gehören der Benutzer, unter dem der Auftrag ausgeführt werden muss, der Nachweis, dass die geplanten Ereignisse tatsächlich ausgeführt wurden, sowie die drei Möglichkeiten, wie die Konfiguration fehlschlägt, ohne auf der Website eine Meldung auszugeben.

In den Beispielen wird /srv/www/example.com als WordPress-Verzeichnis und www-data als Webserver-Benutzer verwendet. Ersetzen Sie überall die Pfade und den Benutzer durch Ihre eigenen Angaben.

Welche Besucher WordPress-Cron auf einer stark ausgelasteten Website auslösen

Jede nicht aus dem Cache bediente Anfrage verursacht diese Prüfung. WordPress lädt die Option cron, vergleicht die Zeitstempel und ruft, sobald eine Aufgabe fällig ist, spawn_cron() auf. Dadurch wird eine nicht blockierende Loopback-Anfrage an /wp-cron.php gesendet. Der Besucher wartet nicht auf das Ergebnis. Ein PHP-Worker wartet jedoch. Auf einem kleinen VPS mit PHP-FPM und pm.max_children = 5 belegt ein langsamer geplanter Job ein Fünftel Ihrer PHP-Kapazität, solange er läuft. Er wird wahrscheinlich während Ihrer ausgelastetsten Minute ausgelöst, weil dann die meisten Seitenaufrufe stattfinden.

WordPress begrenzt Duplikate. Es setzt eine Sperre mit einer Lebensdauer von WP_CRON_LOCK_TIMEOUT, standardmäßig 60 Sekunden. Dadurch starten gleichzeitige Besucher nicht jeweils einen eigenen Lauf. Die Sperre begrenzt die Duplikation. Sie verlagert die Arbeit jedoch nicht aus dem Anfragepfad.

Ermitteln Sie auf Ihrem eigenen Server, wie oft dieser Vorgang ausgelöst wird, bevor Sie seine Bedeutung bewerten. Jede Loopback-Anfrage erscheint im Access-Log des Webservers:

sudo grep -c 'wp-cron.php' /var/log/nginx/access.log

Apache schreibt stattdessen nach /var/log/apache2/access.log. Mehrere tausend Aufrufe pro Tag verursachen reale Kosten. Eine solche Zahl sollten Sie auf Ihrem eigenen Server messen, statt sie aus einem Artikel zu übernehmen. Das gilt genauso, wie Sie einen VPS vor und nach einer Änderung benchmarken würden.

Caching verändert das Bild. Wenn ein Seiten-Cache die meisten Anfragen als statisches HTML ausliefert, wird PHP für diese Anfragen nicht ausgeführt. Daher findet auch die Cron-Prüfung nicht statt. Eine stark gecachte, ausgelastete Website verhält sich dann eher wie die ruhige Website im folgenden Abschnitt.

Welcher Besucher Cronjobs auf einer wenig besuchten Website auslöste

Keine Besucher bedeutet keine Cronjobs. Eine Website mit wenigen Besuchen pro Tag führt ihre geplanten Aufgaben nur wenige Male täglich aus, und zwar zu den zufälligen Zeitpunkten, an denen diese Besuche eintreffen.

Die Symptome sehen immer gleich aus. Ein für 09:00 geplanter Beitrag bleibt in der Beitragsliste mit Missed schedule markiert, bis jemand eine Seite lädt. Backup-Plugins überspringen die Nacht. Update-Prüfungen verzögern sich. Dadurch zeigt das Dashboard keine verfügbaren Updates an, obwohl bereits ein Sicherheitsrelease veröffentlicht wurde. Bestell-E-Mails, Verlängerungsbenachrichtigungen und Warnungen vor dem Ablauf werden verspätet versendet.

Nichts davon wird als Fehler protokolliert. Aus Sicht von WordPress war der Job nie verspätet, weil er nie gestartet wurde.

Schritt 1: Den Besucher-Trigger in wp-config.php deaktivieren

Öffnen Sie /srv/www/example.com/wp-config.php und fügen Sie die Konstante hinzu:

define( 'DISABLE_WP_CRON', true );

Platzieren Sie sie oberhalb der Zeile mit /* That's all, stop editing! Happy publishing. */. Die direkt unter diesem Kommentar stehende Zeile benötigt wp-settings.php. An wp-settings.php hängt WordPress die Cron-Prüfung in init ein. Eine Konstante, die nach diesem require definiert wird, wird zu spät gesetzt und ändert nichts. Die Datei sieht dann zwar korrekt aus, aber der Trigger läuft weiterhin.

Prüfen Sie, ob sich die Zeile an der erwarteten Stelle befindet:

grep -n "DISABLE_WP_CRON\|stop editing" /srv/www/example.com/wp-config.php

Die Konstante verhindert nicht, dass Ereignisse geplant werden. Plugins fügen weiterhin Jobs zur Warteschlange hinzu, genau wie zuvor. Sie verhindert nur, dass Seitenaufrufe diese Warteschlange ausführen. Dadurch wird die Warteschlange erst wieder ausgeführt, nachdem Sie Schritt 3 abgeschlossen haben.

Direkte Anfragen an /wp-cron.php werden dadurch ebenfalls nicht blockiert. Jeder kann diese URL weiterhin aufrufen. Das ist normalerweise unproblematisch, weil die Datei nur fällige Aufgaben ausführt. Das Blockieren in der Webserver-Konfiguration ist optional. Wenn Sie die URL blockieren, funktioniert auch der curl-Fallback am Ende dieser Anleitung nicht mehr.

Schritt 2: WP-CLI installieren

WP-CLI ist das offizielle Befehlszeilenwerkzeug für WordPress. Es benötigt die PHP-Binärdatei für die Befehlszeile. Diese gehört zu einem separaten Paket und ist nicht Teil des PHP-Moduls des Webservers.

php -v
sudo apt install -y php-cli

Installieren Sie WP-CLI aus dem phar-Build. Dies empfiehlt auch die offizielle Installationsanleitung:

cd /tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

php wp-cli.phar --info gibt den Pfad zur PHP-Binärdatei, die PHP-Version und die WP-CLI-Version aus. Wenn alle drei Werte ausgegeben werden, funktioniert das phar. Stand August 2026 nennt die Installationsanleitung PHP 7.2.24 als Mindestversion. Ubuntu 24.04 enthält PHP 8.3. Ein aktueller Server liegt damit deutlich über dieser Grenze. Aktualisieren Sie WP-CLI später mit sudo wp cli update.

Führen Sie WP-CLI als Benutzer der Website aus, niemals als root:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com core version

Als root verweigert WP-CLI den Start:

Error: YIKES! It looks like you're running this as root.

WP-CLI schlägt --allow-root vor. Verwenden Sie das hier nicht. Der Grund wird im ersten Fehlerszenario weiter unten erklärt.

Beachten Sie außerdem, dass sudo -u www-data -i nicht funktioniert. Die Login-Shell dieses Kontos ist /usr/sbin/nologin, und Sie erhalten This account is currently not available.. Wenn Sie den Befehl direkt an sudo -u übergeben, wird die Login-Shell übersprungen und der Befehl funktioniert.

Prüfen Sie nun, ob WordPress selbst die Konstante aus Schritt 1 erkennt:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com eval 'var_dump( DISABLE_WP_CRON );'

Dies gibt bool(true) aus. Ein fataler Fehler wegen einer nicht definierten Konstante bedeutet, dass die Zeile mit define() nicht erreicht wird. In der Regel steht sie dann unterhalb von require.

Schritt 3: Den Cron-Eintrag mit dem richtigen Benutzer anlegen

Der richtige Benutzer ist derjenige, dem die Dateien gehören, in die PHP schreibt. Prüfen Sie beide Seiten:

stat -c '%U %G' /srv/www/example.com/wp-content/uploads
grep -E '^(user|group) = ' /etc/php/8.3/fpm/pool.d/www.conf

Bei einer Standardinstallation von Ubuntu liefern beide Prüfungen www-data. Wenn Sie dem Standort einen eigenen PHP-FPM-Pool mit eigenem Benutzer zugewiesen haben, verwenden Sie für alle folgenden Schritte diesen Benutzer. Das ist bei einem Setup pro Standort auf einem LAMP-Stack unter Ubuntu 24.04 normalerweise der Fall.

Erstellen Sie ein Protokollverzeichnis, in das dieser Benutzer schreiben kann:

sudo install -d -o www-data -g www-data -m 750 /var/log/wp-cron

Bearbeiten Sie die Crontab dieses Benutzers:

sudo crontab -u www-data -e

Fügen Sie eine Zeile hinzu:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1

Im Einzelnen: */5 führt den Befehl alle fünf Minuten aus. flock -n setzt eine Sperrdatei und beendet den Vorgang sofort, wenn ein vorheriger Lauf die Sperre noch hält. /usr/local/bin/wp ist der absolute Pfad, den cron benötigt. --path ermöglicht die Ausführung des Befehls unabhängig vom aktuellen Arbeitsverzeichnis. --due-now verarbeitet nur die Ereignisse, deren Ausführungszeit erreicht ist, statt jedes Ereignis in der Warteschlange. Die Umleitung schreibt die normale Ausgabe und Fehlermeldungen in eine Datei, die Sie lesen können.

Diese Umleitung ist in der Praxis nicht optional. Cron sendet die Ausgabe eines Jobs an dessen Benutzer. Auf den meisten VPS-Images ist kein Mail-Transfer-Agent installiert. Cron protokolliert dann (CRON) info (No MTA installed, discarding output) und verwirft die Ausgabe. Eine Datei bewahrt die Informationen auf.

Prüfen Sie, ob die Datei gespeichert wurde:

sudo crontab -u www-data -l

Für mehrere Standorte verwenden Sie pro Standort eine Zeile und verteilen Sie die Minuten, damit die Jobs nicht alle gleichzeitig starten:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-one.lock /usr/local/bin/wp --path=/srv/www/one.example.com cron event run --due-now >> /var/log/wp-cron/one.log 2>&1
2-59/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-two.lock /usr/local/bin/wp --path=/srv/www/two.example.com cron event run --due-now >> /var/log/wp-cron/two.log 2>&1

Das Protokoll wächst unbegrenzt, wenn Sie es nicht rotieren. Schreiben Sie /etc/logrotate.d/wp-cron:

/var/log/wp-cron/*.log {
    weekly
    rotate 4
    missingok
    notifempty
    compress
    create 640 www-data www-data
}

Prüfen Sie, ob der Eintrag ohne Ausführung verarbeitet werden kann: sudo logrotate --debug /etc/logrotate.d/wp-cron.

Schritt 4: Bestätigen Sie, dass die geplanten Ereignisse tatsächlich ausgeführt wurden

Eine erfolgreich gespeicherte Crontab-Zeile beweist nichts. Beginnen Sie mit der kostengünstigsten Prüfung und arbeiten Sie sich bis zu der Prüfung vor, die den Sachverhalt eindeutig klärt.

Zuerst: Hat cron den Befehl gestartet? cron schreibt unter seiner eigenen Unit in das Journal:

journalctl -u cron.service --since "15 min ago" | grep wp

Ein korrekter Eintrag sieht so aus, wenn Zeitstempel und Hostname am Anfang entfernt wurden:

CRON[24913]: (www-data) CMD (/usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1)

Diese Zeile bedeutet, dass cron Ihren Befehl als www-data gestartet hat. Sie sagt nichts darüber aus, ob der Befehl erfolgreich war.

Zweitens: Hat WordPress etwas ausgeführt? Lesen Sie die Logdatei:

sudo tail -n 20 /var/log/wp-cron/example.log

WP-CLI gibt eine Zeile pro Ereignis und anschließend eine Gesamtsumme aus:

Executed the cron event 'wp_version_check' in 0.418s.
Success: Executed a total of 2 cron events.

Fehler werden in dieselbe Datei geschrieben. Genau dafür dient 2>&1. Bei den meisten Durchläufen ist nichts fällig, sodass nur wenige Zeilen geschrieben werden. Lesen Sie die Datei daher nach einem Durchlauf, von dem Sie wissen, dass noch Aufgaben ausstanden.

Drittens: Belegen Sie die Ausführung Ende zu Ende. Planen Sie ein Markierungsereignis und beobachten Sie, wie es verschwindet:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event schedule wp_cli_cron_check now
sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event list --fields=hook,next_run_relative --format=csv | grep wp_cli_cron_check

Warten Sie ein Intervall und führen Sie den Listenbefehl erneut aus. Der Hook ist verschwunden, weil ein einmaliges Ereignis beim Ausführen aus der Warteschlange entfernt wird. Kein Plugin registriert einen Callback für diesen Hook-Namen. Seine Ausführung bewirkt daher nichts weiter auf der Website. Wenn der Hook nach zwei Intervallen noch aufgeführt wird, wird die Warteschlange nicht ausgeführt. Die ersten beiden Prüfungen zeigen Ihnen, ob das Problem bei cron oder bei WP-CLI liegt.

Verwenden Sie dafür nicht wp cron test. Dieser Befehl prüft, ob das Auslösen durch einen Besucher funktioniert. Bei DISABLE_WP_CRON wird dabei ein Fehler ausgegeben. Auf einem korrekt konfigurierten Server ist dieser Fehler die erwartete Ausgabe und kein Problem.

Die systemd-Timer-Alternative

Wenn die geplanten Aufgaben des restlichen Systems bereits als systemd-Services und Timer ausgeführt werden, fügen Sie WordPress ebenfalls dort ein. Jeder Lauf erscheint dann in systemctl list-timers, und die Ausgabe wird in das Journal geschrieben statt in eine Datei, die Sie rotieren müssen.

Erstellen Sie /etc/systemd/system/wp-cron-example.service:

[Unit]
Description=Run due WordPress cron events for example.com

[Service]
Type=oneshot
User=www-data
Group=www-data
ExecStart=/usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

Erstellen Sie anschließend /etc/systemd/system/wp-cron-example.timer:

[Unit]
Description=Run WordPress cron for example.com every 5 minutes

[Timer]
OnCalendar=*:0/5
AccuracySec=30s
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now wp-cron-example.timer
systemctl list-timers wp-cron-example.timer
journalctl -u wp-cron-example.service -n 20

systemd führt nicht gleichzeitig zwei Instanzen desselben Service aus. Diese Variante benötigt daher kein flock. Persistent=true holt einen Lauf nach, der während des ausgeschalteten Systems verpasst wurde. Ein crontab-Eintrag kann das nicht.

Verwenden Sie entweder die crontab oder den Timer. Wenn beide dieselbe Site ausführen, wird die Warteschlange doppelt abgearbeitet. Doppelte Ausführungen eines E-Mail- oder Auftragsjobs sind für Ihre Kunden sichtbar.

Warum der Cronjob nicht als root ausgeführt werden darf

Dies ist die erste von drei Ursachen für das Fehlschlagen der Einrichtung. Wenn Sie den Job in die Crontab von root eintragen, beendet sich WP-CLI, bevor es etwas ausführt:

Error: YIKES! It looks like you're running this as root.

Die Warteschlange wird nie verarbeitet. Wenn Sie die Ausgabe nicht umgeleitet haben, sehen Sie die Meldung nicht. Die gefährliche Lösung besteht darin, --allow-root hinzuzufügen. Dann gehört jede Datei, die ein Plugin während dieses Laufs schreibt, root. Die nächste Webanfrage läuft als www-data, kann nicht in diese Verzeichnisse schreiben, und die Website meldet beispielsweise:

Unable to create directory wp-content/uploads/2026/08. Is its parent directory writable by the server?

Korrigieren Sie den Eigentümer und verschieben Sie anschließend den Job:

sudo chown -R www-data:www-data /srv/www/example.com/wp-content

Die Crontab von root und die Crontab von www-data sind separate Dateien. Wenn Sie die Zeile aus einer Datei löschen, wird die andere nicht geändert. Prüfen Sie beide:

sudo crontab -u root -l
sudo crontab -u www-data -l

Warum cron wp: not found meldet

Dies ist der zweite Fehler. cron stellt Benutzeraufträgen einen sehr kurzen PATH bereit: /usr/bin:/bin. WP-CLI wird in /usr/local/bin installiert, das nicht in dieser Liste enthalten ist. Der Auftrag startet, schlägt innerhalb eines Sekundenbruchteils fehl, und im Log steht eine einzige Zeile:

/bin/sh: 1: wp: not found

Prüfen Sie die Umgebung von cron selbst, statt zu raten. Fügen Sie vorübergehend folgende Zeile hinzu:

*/5 * * * * env > /tmp/cron-env.txt 2>&1

Lesen Sie /tmp/cron-env.txt nach einem Intervall aus und löschen Sie die Zeile anschließend wieder. Der Wert PATH= in dieser Datei entspricht genau der Umgebung, die Ihr Auftrag erhält.

Es gibt zwei Lösungen. Verwenden Sie den absoluten Pfad /usr/local/bin/wp, wie in Schritt 3. Oder setzen Sie PATH einmal am Anfang der Crontab, oberhalb aller Auftragszeilen:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Die gleiche Falle tritt eine Ebene tiefer auf. Das wp-Phar beginnt mit #!/usr/bin/env php. Daher muss die Shell auch php finden können. Wenn PHP außerhalb von /usr/bin liegt, was bei eigenen Builds und Builds von Control Panels vorkommt, erhalten Sie:

/usr/bin/env: 'php': No such file or directory

Rufen Sie den Interpreter in diesem Fall explizit auf, zum Beispiel /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now.

Warum ein Intervall von einer Minute das ursprüngliche Problem erneut verursacht

Dies ist der dritte Fehler. * * * * * wirkt sicherer als fünf Minuten, bringt Sie auf einer ausgelasteten Website aber wieder zum Ausgangspunkt. Wenn ein Lauf länger als das Intervall dauert, startet der nächste Lauf, während der erste noch läuft. Zehn Minuten später gibt es zehn PHP-Prozesse, die jeweils ihren eigenen Speicher und ihre eigene Datenbankverbindung belegen.

Prüfen Sie direkt, ob sich Läufe aufstauen:

ps -eo etimes,user,args | grep '[c]ron event run'

etimes ist das Prozessalter in Sekunden. Eine Zeile ist unproblematisch. Mehrere Zeilen mit einem Alter deutlich über Ihrem Intervall bedeuten, dass sich Läufe stapeln. Auf einem kleinen VPS endet das mit einem MySQL-Fehler Too many connections oder damit, dass der Kernel PHP beendet, um Speicher freizugeben. Das können Sie mit sudo dmesg -T | grep -i 'killed process' bestätigen.

WP-CLI führt die Event-Callbacks direkt aus, statt wp-cron.php anzufordern. Die 60-Sekunden-Sperre, die WordPress gegen das doppelte Starten verwendet, gilt hier daher nicht. flock -n im Eintrag aus Schritt 3 verhindert jetzt die parallele Ausführung. Ein übersprungener Lauf wird absichtlich sofort und ohne Meldung beendet. Überschneidungen müssen Sie im Crontab verhindern, statt darauf zu vertrauen, dass der Host-Kernel dies für Sie übernimmt: Selbst die cachebewusste Platzierung von Aufgaben, die im Linux-Kernel 7.2 hinzugefügt wurde, entscheidet nur, auf welchem Kern ein Prozess ausgeführt wird, nicht, wie viele Prozesse Sie gestartet haben.

Wählen Sie das Intervall anhand des kürzesten Zeitplans, auf den Sie tatsächlich angewiesen sind, und messen Sie zunächst die Dauer eines Laufs:

time sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

Fünf Minuten sind ein sinnvoller Standard: Ein für 09:00 geplanter Beitrag wird bis 09:05 veröffentlicht. Für eine Website ohne zeitkritische Inhalte sind 15 Minuten ausreichend. Ein Intervall von einer Minute ist für Shops und warteschlangengesteuerte Plugins gedacht, die es tatsächlich benötigen, und sollte erst verwendet werden, wenn Sie wissen, dass ein Lauf innerhalb weniger Sekunden abgeschlossen ist.

Wenn Sie WP-CLI nicht installieren können

Einige Hosts blockieren Shell-Tools. Eine einfache HTTP-Anfrage an wp-cron.php startet dieselbe Warteschlange, durchläuft dabei jedoch den gesamten Web-Stack:

*/5 * * * * /usr/bin/curl -sS --max-time 120 "https://example.com/wp-cron.php?doing_wp_cron" > /dev/null

Die Einschränkungen im Einzelnen:

• Der Lauf ist durch die Timeouts des Webservers und von PHP-FPM begrenzt. Ein langer Job kann daher mittendrin abgebrochen werden.
• Das Zertifikat muss gültig sein. Andernfalls bricht curl mit SSL certificate problem ab. Sorgen Sie daher dafür, dass Erneuerungen mit Certbot unter nginx funktionieren.
• Das Seiten-Caching darf wp-cron.php nicht cachen. Andernfalls erhalten Cron-Anfragen eine gecachte Antwort und es wird nichts ausgeführt.
• Sie erhalten keine Ausgabe für einzelne Ereignisse. Der einzige Nachweis, dass ein Job ausgeführt wurde, ist daher seine Wirkung.

-sS unterdrückt bei Erfolg die Ausgabe von curl, gibt Fehler jedoch weiterhin aus. Das ist für einen Cron-Job die gewünschte Einstellung.

Was gehört außerdem auf den Zeitplan des Servers

Sobald system cron die WordPress-Warteschlange übernimmt, sollten Sie auch die übrigen regelmäßigen Aufgaben des Systems an derselben Stelle verwalten, damit Sie sie zentral einsehen können. Sicherheitsupdates des Betriebssystems gehören zu automatischen Updates und nicht in eine Cron-Zeile, die Sie manuell pflegen. Updates von WordPress-Plugins und -Themes sind eine andere Entscheidung: wp plugin update --all in einer Crontab kann eine produktive Website problemlos um 3 Uhr morgens beschädigen, ohne dass jemand den Vorgang überwacht. Führen Sie solche Updates daher bewusst aus oder erst nach einem Staging-Schritt und einem Backup.

FAQ

Verhindert das Deaktivieren von WP-Cron, dass geplante Beiträge veröffentlicht werden?

Nein, sofern ein anderer Prozess die Warteschlange ausführt. DISABLE_WP_CRON verhindert lediglich, dass Seitenaufrufe die Warteschlange auslösen. Die Ereignisse bleiben unverändert geplant. Ein für 09:00 geplanter Beitrag wird beim ersten Cron-Lauf nach 09:00 veröffentlicht. Bei einem Intervall von fünf Minuten geschieht dies also bis 09:05. Wenn Sie die Konstante setzen, aber keinen Cron-Eintrag hinzufügen, bleibt der Beitrag mit dem Status Missed schedule in der Liste, bis ein Prozess die Warteschlange ausführt.

Welcher Benutzer sollte den WordPress-Cronjob ausführen?

Es sollte der Benutzer sein, dem die Dateien gehören, in die PHP schreibt. Bei einer Standardinstallation von Ubuntu ist das www-data. Prüfen Sie dies mit stat -c '%U %G' /srv/www/example.com/wp-content/uploads und vergleichen Sie den Wert mit der Zeile user = in Ihrer PHP-FPM-Pool-Konfiguration. Wenn Sie den Job als root ausführen, beendet sich WP-CLI mit einem YIKES-Fehler. Wenn Sie die Ausführung mit --allow-root erzwingen, entstehen von root angelegte Dateien in wp-content, in die der Webserver anschließend nicht schreiben kann.

Wie oft sollte system cron den WordPress-Cron ausführen?

Alle fünf Minuten eignen sich für die meisten Websites. Richten Sie das Intervall nach dem kürzesten Zeitplan, auf den Sie tatsächlich angewiesen sind. Es sollte deutlich länger sein als die Dauer eines einzelnen Laufs. Diese Dauer können Sie messen, indem Sie time vor den WP-CLI-Befehl setzen. Bei einer stark ausgelasteten Website können sich Läufe bei einem Intervall von einer Minute überschneiden, sofern flock dies nicht verhindert.

Warum schlägt wp cron test fehl, nachdem ich WP-Cron deaktiviert habe?

Dieser Befehl prüft, ob Besucher das Starten der Cron-Verarbeitung auslösen können. Er meldet einen Fehler, wenn DISABLE_WP_CRON auf true gesetzt ist. Das ist auf einem entsprechend konfigurierten Server das erwartete Ergebnis. Prüfen Sie stattdessen den Pfad für system cron: Lesen Sie /var/log/wp-cron/example.log aus oder planen Sie mit wp cron event schedule ein Markierungsereignis. Bestätigen Sie anschließend, dass es nach dem nächsten Lauf aus wp cron event list verschwunden ist.

Benötige ich WP-CLI, oder reicht curl auf wp-cron.php aus?

curl funktioniert und ist die richtige Lösung, wenn Sie WP-CLI nicht installieren können. Es ist langsamer, weil WordPress über den Webserver geladen wird. Außerdem ist die Ausführung durch das Request-Timeout begrenzt. WP-CLI führt die Ereignisse in einem PHP-Prozess auf der Kommandozeile ohne Web-Timeout aus. Für jedes Ereignis wird eine Zeile mit der Ausführungsdauer ausgegeben. Dadurch zeigt das Log genau, was ausgeführt wurde und wie lange es gedauert hat.