WordPress: wp-cron deaktivieren und system cron nutzen

Was wp-cron ist und warum system cron es 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 an system cron übertragen, wird sie unabhängig davon einmal nach einem festen Zeitplan ausgeführt, ob die Website in dieser Minute tausend Besucher oder keine hatte.

Zwei Zeilen führen die Aufgabe tatsächlich aus: eine Konstante in wp-config.php und ein crontab-Eintrag. Alles andere in dieser Anleitung behandelt Punkte, die diese beiden Zeilen nicht festlegen. Dazu gehören der Benutzer, unter dem die Aufgabe 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 diese Pfade und den Benutzer überall durch Ihre eigenen Werte.

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

Jede nicht aus dem Cache bediente Anfrage bezahlt die Prüfung. WordPress lädt die Option cron, vergleicht die Zeitstempel und ruft, sobald etwas fällig ist, spawn_cron() auf. Dieses sendet eine nicht blockierende Loopback-Anfrage an /wp-cron.php. 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. Wahrscheinlich wird er in Ihrer arbeitsreichsten Minute ausgelöst, weil dann die meisten Seitenaufrufe stattfinden.

WordPress begrenzt doppelte Ausführungen. Es setzt eine Sperre mit einer Laufzeit 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.

Messen Sie auf Ihrem eigenen Server, wie oft dies ausgelöst wird, bevor Sie entscheiden, ob es relevant ist. 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 Ausführungen pro Tag verursachen einen realen Aufwand. Eine solche Zahl sollten Sie auf Ihrem eigenen System messen, statt sie in einem Artikel nachzulesen. Das gilt ebenso, 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 nie ausgeführt. Daher findet auch keine Cron-Prüfung statt. Eine stark gecachte, stark ausgelastete Website beginnt sich wie die unten beschriebene ruhige Website zu verhalten.

Welche Besucher verzögerten Cron-Aufgaben auf einer wenig besuchten Website

Ohne Besucher gibt es keine Cron-Ausführung. Eine Website mit wenigen Besuchen pro Tag führt ihre geplanten Aufgaben ebenfalls nur wenige Male pro Tag aus. Der Ausführungszeitpunkt hängt davon ab, wann diese Besuche zufällig eintreffen.

Die Symptome sehen immer ähnlich aus. Ein für 09:00 geplanter Beitrag bleibt in der Beitragsliste mit dem Status Missed schedule, 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 die Aufgabe nie verspätet, weil sie nie gestartet wurde.

Schritt 1: Visitor-Trigger in wp-config.php deaktivieren

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

define( 'DISABLE_WP_CRON', true );

Fügen Sie sie oberhalb der Zeile ein, die /* That's all, stop editing! Happy publishing. */ enthält, da die direkt unter diesem Kommentar stehende Zeile wp-settings.php benötigt und wp-settings.php dort die Cron-Prüfung an init bindet. Wird die Konstante erst nach diesem require definiert, ist es zu spät, um etwas zu ändern. 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 nicht mehr ausgeführt, bis Sie Schritt 3 abgeschlossen haben.

Direkte Anfragen an /wp-cron.php werden dadurch ebenfalls nicht blockiert. Jeder kann diese URL weiterhin anfordern. Das ist normalerweise unbedenklich, weil die Datei nur fällige Aufgaben ausführt. Sie können die URL optional in der Konfiguration Ihres Webservers blockieren. Wenn Sie sie blockieren, funktioniert jedoch 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 nicht zum PHP-Modul des Webservers.

php -v
sudo apt install -y php-cli

Installieren Sie WP-CLI aus dem Phar-Build. Das 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-Archiv. Seit August 2026 nennt die Installationsanleitung PHP 7.2.24 als Mindestversion. Ubuntu 24.04 liefert PHP 8.3 aus. Ein aktueller Server liegt damit deutlich über dieser Grenze. Aktualisieren Sie 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 Fehlerfall weiter unten erläutert.

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

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 );'

Dadurch wird bool(true) ausgegeben. Ein schwerwiegender Fehler wegen einer nicht definierten Konstante bedeutet, dass die Zeile define() nicht erreicht wird. In der Regel steht sie dann unterhalb von require.

Schritt 3: Den Cron-Eintrag für den 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 standardmäßigen Ubuntu-Installation liefern beide Abfragen www-data. Wenn Sie dem Webauftritt einen eigenen PHP-FPM-Pool mit einem eigenen Benutzer zugewiesen haben, wie es bei einem webbasierten Setup unter einem LAMP-Stack unter Ubuntu 24.04 normalerweise der Fall ist, verwenden Sie für alle folgenden Schritte diesen Benutzer.

Legen Sie ein Protokollverzeichnis an, 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 sich sofort, wenn ein vorheriger Lauf die Sperre noch hält. /usr/local/bin/wp ist der absolute Pfad, den cron benötigt. --path sorgt dafür, dass der Befehl aus jedem Arbeitsverzeichnis ausgeführt werden kann. --due-now verarbeitet nur die Ereignisse, deren Ausführungszeit erreicht ist, statt jedes Ereignis in der Warteschlange. Die Umleitung schreibt 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 per E-Mail. 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 diese Informationen auf.

Prüfen Sie, ob die Datei gespeichert wurde:

sudo crontab -u www-data -l

Verwenden Sie bei mehreren Webauftritten jeweils eine Zeile mit versetzten Minuten, damit sie 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 die Datei ohne Änderungen verarbeitet werden kann: sudo logrotate --debug /etc/logrotate.d/wp-cron.

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

Eine erfolgreich gespeicherte Crontab-Zeile beweist nichts. Arbeiten Sie sich von der einfachsten Prüfung bis zu der Prüfung vor, die den Sachverhalt tatsächlich klärt.

Startete cron den Befehl? cron schreibt unter seiner eigenen Unit in das Journal:

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

Ein korrekter Eintrag sieht wie folgt 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.

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 das ist der Zweck von 2>&1. Bei den meisten Durchläufen ist kein Ereignis fällig, daher wird nur sehr wenig geschrieben. Lesen Sie die Datei deshalb nach einem Durchlauf, bei dem nachweislich Arbeit ausstand.

Belegen Sie die Ausführung durchgehend. 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 anschließend 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 hat daher keine weiteren Auswirkungen auf die Site. Wenn der Hook nach zwei Intervallen weiterhin aufgeführt wird, wird die Warteschlange nicht verarbeitet. Die ersten beiden Prüfungen zeigen, ob das Problem bei cron oder bei WP-CLI liegt.

Verwenden Sie hierfür nicht wp cron test. Dieser Befehl prüft, ob das Starten durch einen Besucher funktioniert, und gibt einen Fehler aus, wenn DISABLE_WP_CRON zutrifft. Auf einem korrekt konfigurierten Server ist dieser Fehler die erwartete Ausgabe und kein Problem.

Die systemd-Timer-Alternative

Wenn die geplanten Aufgaben des Systems bereits über systemd-Dienste und -Timer ausgeführt werden, sollten Sie WordPress ebenfalls dort einbinden. Jeder Lauf erscheint dann in systemctl list-timers, und die Ausgabe wird ins Journal geschrieben. Sie müssen keine Datei rotieren.

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 Dienstes aus. Diese Variante benötigt daher kein flock. Persistent=true sorgt dafür, dass ein Lauf nachgeholt wird, der während eines ausgeschalteten Systems verpasst wurde. Ein Crontab-Eintrag kann das nicht.

Verwenden Sie entweder die Crontab oder den Timer. Wenn beide denselben Standort 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, durch die die Einrichtung fehlschlägt. 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 wird als www-data ausgeführt, 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 Besitz 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 der einen 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 Benutzerjobs einen sehr kurzen PATH bereit: /usr/bin:/bin. WP-CLI wird in /usr/local/bin installiert. Dieses Verzeichnis ist nicht in der Liste enthalten. Der Job startet, schlägt innerhalb eines Sekundenbruchteils fehl und hinterlässt eine einzige Zeile im Log:

/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. Der Wert PATH= in dieser Datei entspricht genau dem Wert, den Ihr Job 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 Jobzeilen:

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

Dieselbe 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 benutzerdefinierten 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. Auf einer ausgelasteten Website bringt es Sie jedoch 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. Jeder hält eigenen Speicher und eine eigene Datenbankverbindung.

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 aufstauen. 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. Daher gilt die von WordPress verwendete Sperre von 60 Sekunden gegen doppelte Starts hier nicht. flock -n im Eintrag aus Schritt 3 verhindert die Überschneidung jetzt. Ein übersprungener Lauf wird absichtlich sofort und ohne Meldung beendet.

Wählen Sie das Intervall anhand des kürzesten Zeitplans, auf den Sie tatsächlich angewiesen sind, und messen Sie zuerst 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 spätestens um 09:05 veröffentlicht. Fünfzehn Minuten sind für eine Website ohne zeitkritische Inhalte ausreichend. Eine Minute ist für Shops und warteschlangenbasierte Plugins vorgesehen, die sie tatsächlich benötigen, und erst dann sinnvoll, wenn ein Lauf innerhalb weniger Sekunden abgeschlossen wird.

Wenn Sie WP-CLI nicht installieren können

Einige Hosts blockieren Shell-Tools. Eine einfache HTTP-Anfrage an wp-cron.php verarbeitet dieselbe Warteschlange, jedoch über 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 Überblick:

• Die Ausführung ist durch die Timeouts des Webservers und von PHP-FPM begrenzt. Ein langer Auftrag kann daher vorzeitig abgebrochen werden.
• Das Zertifikat muss gültig sein. Andernfalls bricht curl mit SSL certificate problem ab. Halten Sie daher die Erneuerung mit Certbot unter nginx funktionsfähig.
• Der Seiten-Cache darf wp-cron.php nicht zwischenspeichern. Andernfalls erhalten Cron-Anfragen eine gecachte Antwort und führen nichts aus.
• Sie erhalten keine Ausgabe für einzelne Ereignisse. Der einzige Nachweis für die Ausführung eines Auftrags ist daher die von ihm verursachte Änderung.

-sS unterdrückt bei Erfolg die Ausgabe von curl, gibt Fehler aber weiterhin aus. Das ist für einen Cron-Auftrag erforderlich.

Was gehört noch in den Zeitplan des Servers

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

FAQ

Verhindert das Deaktivieren von WP-Cron die Veröffentlichung geplanter Beiträge?

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 das also bis 09:05. Wenn Sie die Konstante setzen, aber keinen Cron-Eintrag anlegen, bleibt der Beitrag mit dem Status Missed schedule in der Liste, bis ein Prozess die Warteschlange ausführt.

Welcher Benutzer sollte den WordPress-Cron-Job ausführen?

Der Benutzer, dem die Dateien gehören, in die PHP schreibt. Bei einer standardmäßigen Ubuntu-Installation 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 user =-Zeile in der PHP-FPM-Pool-Konfiguration. Wenn Sie den Job als root ausführen, beendet sich WP-CLI mit einem YIKES-Fehler. Wenn Sie ihn mit --allow-root erzwingen, entstehen root gehörende Dateien in wp-content, in die der Webserver anschließend nicht schreiben kann.

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

Für die meisten Websites sind fünf Minuten ausreichend. Richten Sie das Intervall nach dem kürzesten Zeitplan, auf den Sie tatsächlich angewiesen sind. Das Intervall 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 ausgelasteten Website können Läufe im Abstand von einer Minute einander überlagern, sofern flock sie nicht schützt.

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

Weil dieser Befehl das durch Besucher ausgelöste Starten prüft und einen Fehler meldet, wenn DISABLE_WP_CRON auf true gesetzt ist. Das ist auf einem entsprechend konfigurierten Server das erwartete Ergebnis. Prüfen Sie stattdessen den Pfad des 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, und unterliegt dem Request-Timeout. WP-CLI führt die Ereignisse in einem PHP-Prozess auf der Kommandozeile ohne Web-Timeout aus. Außerdem gibt es pro Ereignis eine Zeile mit der Laufzeit aus. Dadurch zeigt das Log genau, was ausgeführt wurde und wie lange es gedauert hat.