Jak wyłączyć WP-Cron i użyć systemowego crona w WordPress

Czym jest wp-cron i dlaczego systemowy cron go zastępuje

WP-Cron to wbudowany w WordPress harmonogram zadań, który uruchamia się wyłącznie w momencie wywołania strony przez użytkownika. Żaden proces wewnątrz WordPressa nie inicjuje się samodzielnie. Przy każdym żądaniu, które nie jest obsługiwane z pamięci podręcznej, WordPress odczytuje listę zaplanowanych zadań. Jeśli nadszedł czas wykonania któregoś z nich, wysyła ono drugie żądanie HTTP do samego siebie pod adres /wp-cron.php, aby wykonać pracę. Przeniesienie tego zadania do systemowego crona zapewnia przewidywalne uruchomienie zgodnie ze stałym harmonogramem, niezależnie od tego, czy w danej minucie witrynę odwiedziło tysiąc osób, czy nikt.

Dwie linie wykonują właściwą pracę: stała w wp-config.php oraz wpis w crontab. Wszystko inne w tym przewodniku stanowi uzupełnienie, o którym te dwie linie nie informują. Określają one, jako który użytkownik musi działać zadanie, jak zweryfikować, czy zaplanowane zdarzenia faktycznie zostały wywołane, oraz wskazują trzy sposoby, w jakie konfiguracja może zawieść bez wyświetlenia jakiegokolwiek komunikatu na stronie.

Przykłady wykorzystują /srv/www/example.com jako katalog WordPressa oraz www-data jako użytkownika serwera WWW. W każdym miejscu należy podstawić własne ścieżki oraz nazwę użytkownika.

Który użytkownik generuje koszty cron na obciążonej witrynie

Każde żądanie nieobsłużone przez pamięć podręczną opłaca koszt sprawdzenia zadań. WordPress wczytuje opcję cron, porównuje znaczniki czasu, a gdy nadejdzie czas wykonania, wywołuje spawn_cron(). Funkcja ta wysyła nieblokujące żądanie zwrotne (loopback) do /wp-cron.php. Użytkownik nie czeka na wynik, ale proces PHP już tak. Na małym serwerze VPS z PHP-FPM i pm.max_children = 5, jedno wolne zadanie harmonogramu zajmuje jedną piątą dostępnych zasobów PHP na czas swojego trwania. Najprawdopodobniej zostanie ono wywołane w najbardziej obciążonej minucie, ponieważ wtedy występuje największa liczba odsłon.

WordPress ogranicza duplikaty. Zakłada blokadę, której czas życia wynosi WP_CRON_LOCK_TIMEOUT (domyślnie 60 sekund), dzięki czemu równocześni użytkownicy nie uruchamiają wielokrotnie tego samego procesu. Blokada ogranicza duplikację, ale nie przenosi pracy poza ścieżkę żądania.

Przed podjęciem decyzji o optymalizacji, należy sprawdzić częstotliwość wywołań na własnym serwerze. Każde żądanie zwrotne pojawia się w logu dostępu serwera WWW:

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

Apache zapisuje te informacje w /var/log/apache2/access.log. Liczba tysięcy wywołań dziennie stanowi realny koszt. Jest to wartość, którą należy zmierzyć na własnej maszynie, zamiast polegać na danych z artykułów, podobnie jak w przypadku testowania wydajności VPS przed i po wprowadzeniu zmian.

Pamięć podręczna zmienia sytuację. Jeśli cache stron obsługuje większość żądań jako statyczny kod HTML, PHP nie jest uruchamiane dla tych zapytań, więc sprawdzenie crona nigdy nie następuje. Mocno zoptymalizowana pod kątem cache witryna zaczyna zachowywać się jak serwis o niskim natężeniu ruchu opisany poniżej.

Dlaczego brak odwiedzających powoduje przestoje w działaniu cron na mało uczęszczanych witrynach

Brak odwiedzających oznacza brak aktywności cron. Witryna, która odnotowuje zaledwie kilka wizyt dziennie, uruchamia zaplanowane zadania tylko kilka razy na dobę, w przypadkowych momentach, w których pojawia się użytkownik.

Objawy zawsze wyglądają tak samo. Wpis zaplanowany na godzinę 09:00 pozostaje na liście wpisów oznaczony jako Missed schedule, dopóki ktoś nie załaduje strony. Wtyczki do tworzenia kopii zapasowych pomijają nocne harmonogramy. Sprawdzanie aktualizacji opóźnia się, przez co panel administracyjny nie wyświetla informacji o dostępnych poprawkach, mimo że wydanie bezpieczeństwa jest już dostępne. E-maile z potwierdzeniami zamówień, powiadomienia o odnowieniach i ostrzeżenia o wygaśnięciu usług są wysyłane z opóźnieniem.

Żaden z tych przypadków nie generuje błędu w logach. Z punktu widzenia WordPress zadanie nigdy nie było spóźnione, ponieważ po prostu nie zostało uruchomione.

Krok 1: wyłączenie wyzwalacza odwiedzin w wp-config.php

Otwórz /srv/www/example.com/wp-config.php i dodaj stałą:

define( 'DISABLE_WP_CRON', true );

Umieść ją powyżej linii zawierającej /* That's all, stop editing! Happy publishing. */, ponieważ linia znajdująca się bezpośrednio pod tym komentarzem wymaga wp-settings.php, a wp-settings.php to miejsce, w którym WordPress podłącza sprawdzanie crona do init. Stała zdefiniowana po tym require jest ustawiana zbyt późno, aby wywołać jakikolwiek efekt, przez co plik wygląda poprawnie, podczas gdy wyzwalacz nadal działa.

Potwierdź, że linia znajduje się w oczekiwanym miejscu:

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

Stała ta nie zatrzymuje planowania zdarzeń. Wtyczki nadal dodają zadania do kolejki, dokładnie tak jak wcześniej. Powoduje ona jedynie, że ładowanie stron przestaje przetwarzać tę kolejkę, co oznacza, że kolejka nie zostanie uruchomiona, dopóki nie wykonasz kroku 3.

Nie blokuje to również bezpośrednich żądań do /wp-cron.php. Każdy nadal może wywołać ten adres URL, co zazwyczaj jest nieszkodliwe, ponieważ plik wykonuje tylko zadania, których termin nadszedł. Blokowanie go w konfiguracji serwera WWW jest opcjonalne. Jeśli jednak go zablokujesz, mechanizm awaryjny curl opisany pod koniec tego przewodnika również przestanie działać.

Krok 2: instalacja WP-CLI

WP-CLI to oficjalne narzędzie wiersza poleceń dla WordPress. Wymaga ono binarnego pliku PHP dla wiersza poleceń, który jest pakietem odrębnym od modułu PHP serwera WWW.

php -v
sudo apt install -y php-cli

Zainstaluj WP-CLI z kompilacji phar, zgodnie z zaleceniami oficjalnego przewodnika instalacji:

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 wyświetla ścieżkę do pliku binarnego PHP, wersję PHP oraz wersję WP-CLI. Jeśli wyświetlone zostaną wszystkie trzy elementy, plik phar działa poprawnie. Według stanu na sierpień 2026 przewodnik instalacji określa PHP 7.2.24 jako wersję minimalną, a Ubuntu 24.04 dostarcza PHP 8.3, więc aktualny serwer spełnia te wymagania z dużym zapasem. Aktualizację przeprowadź później za pomocą sudo wp cli update.

Uruchamiaj WP-CLI jako użytkownik witryny, nigdy jako root:

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

Jako root, WP-CLI odmawia uruchomienia:

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

Narzędzie sugeruje użycie --allow-root. Nie należy tego tutaj stosować. Przyczyna wyjaśniona jest w pierwszym poniższym trybie awarii.

Zwróć również uwagę, że sudo -u www-data -i nie działa, ponieważ powłoką logowania tego konta jest /usr/sbin/nologin, co skutkuje błędem This account is currently not available.. Przekazanie polecenia bezpośrednio do sudo -u pomija powłokę logowania, dzięki czemu działa ono poprawnie.

Teraz potwierdź, że sam WordPress widzi stałą z kroku 1:

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

Polecenie to wyświetla bool(true). Błąd krytyczny dotyczący niezdefiniowanej stałej oznacza, że linia define() nie jest osiągana, co zazwyczaj oznacza, że została umieszczona poniżej instrukcji require.

Krok 3: dodanie wpisu cron dla odpowiedniego użytkownika

Właściwym użytkownikiem jest ten, który posiada pliki zapisywane przez PHP. Należy sprawdzić oba końce:

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

W domyślnej instalacji Ubuntu obie odpowiedzi wskazują na www-data. Jeśli witryna posiada własną pulę PHP-FPM z dedykowanym użytkownikiem, co jest standardem w konfiguracji dla pojedynczej witryny w ramach stosu LAMP na Ubuntu 24.04, należy użyć tego użytkownika we wszystkich poniższych krokach.

Utwórz katalog logów, do którego użytkownik ma uprawnienia zapisu:

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

Edytuj crontab tego użytkownika:

sudo crontab -u www-data -e

Dodaj jeden wiersz:

*/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

Analiza poszczególnych elementów: */5 uruchamia zadanie co pięć minut. flock -n korzysta z pliku blokady i przerywa działanie, jeśli poprzedni proces nadal go przetrzymuje. /usr/local/bin/wp to ścieżka bezwzględna, wymagana przez cron. --path pozwala na uruchomienie polecenia z dowolnego katalogu roboczego. --due-now uruchamia tylko te zdarzenia, których czas nadszedł, zamiast przetwarzać całą kolejkę. Przekierowanie wysyła standardowe wyjście oraz błędy do jednego pliku, który można odczytać.

W praktyce to przekierowanie nie jest opcjonalne. Cron wysyła wyjście zadania na adres e-mail użytkownika, większość obrazów VPS nie posiada zainstalowanego agenta transferu poczty (MTA), przez co cron rejestruje (CRON) info (No MTA installed, discarding output) i odrzuca wyjście. Plik pozwala zachować historię działań.

Sprawdź, czy plik został zapisany:

sudo crontab -u www-data -l

W przypadku wielu witryn należy użyć osobnego wiersza dla każdej z nich, stosując przesunięcie czasowe w minutach, aby nie uruchamiały się jednocześnie:

*/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

Log będzie stale rósł, jeśli nie zostanie poddany rotacji. Utwórz /etc/logrotate.d/wp-cron:

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

Sprawdź poprawność składni bez wprowadzania zmian: sudo logrotate --debug /etc/logrotate.d/wp-cron.

Krok 4: potwierdzenie wykonania zaplanowanych zdarzeń

Poprawny zapis w crontab nie gwarantuje działania zadania. Należy przejść od najprostszej weryfikacji do sprawdzenia ostatecznego rezultatu.

Najpierw należy sprawdzić, czy cron uruchomił polecenie. Cron zapisuje logi w journal pod własną jednostką:

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

Poprawny wpis wygląda następująco (po usunięciu znacznika czasu i nazwy hosta):

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)

Taka linia oznacza, że cron uruchomił polecenie jako użytkownik www-data. Nie informuje ona jednak o tym, czy polecenie zakończyło się powodzeniem.

Następnie należy sprawdzić, czy WordPress wykonał jakiekolwiek operacje. Należy odczytać plik dziennika:

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

WP-CLI generuje jedną linię na zdarzenie oraz podsumowanie:

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

Błędy trafiają do tego samego pliku, co jest głównym celem użycia 2>&1. W większości przypadków, gdy nie ma zaplanowanych zadań, plik pozostanie niemal pusty, dlatego należy go sprawdzić po czasie, w którym wiadomo, że zadania powinny zostać wykonane.

Na koniec należy przeprowadzić weryfikację end-to-end. Należy zaplanować zdarzenie testowe i sprawdzić, czy zniknie z kolejki:

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

Po upływie jednego interwału należy ponownie uruchomić polecenie wyświetlające listę. Jeśli zdarzenie zniknęło, oznacza to, że zostało przetworzone, ponieważ zdarzenia jednorazowe są usuwane z kolejki po wykonaniu. Ponieważ żadna wtyczka nie rejestruje callbacku dla tej nazwy hooka, jego uruchomienie nie wpłynie na działanie witryny. Jeśli po dwóch interwałach hook nadal znajduje się na liście, oznacza to, że kolejka nie jest przetwarzana. Pierwsze dwa kroki weryfikacji pozwolą ustalić, czy problem leży po stronie crona, czy WP-CLI.

Do tego celu nie należy używać wp cron test. Polecenie to sprawdza, czy mechanizm wyzwalania zadań przez odwiedzających działa poprawnie, a w przypadku ustawienia DISABLE_WP_CRON na true zwraca błąd. Na poprawnie skonfigurowanym serwerze błąd ten jest oczekiwanym wynikiem, a nie usterką.

Alternatywa w postaci systemd timer

Jeśli pozostałe zadania harmonogramu na serwerze są już realizowane jako systemd services and timers, należy przenieść tam również WordPress. Każde uruchomienie będzie wtedy widoczne w systemctl list-timers, a dane wyjściowe trafią do dziennika zamiast do pliku wymagającego rotacji.

Utwórz /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

Następnie /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 nie uruchomi dwóch kopii tej samej usługi jednocześnie, więc ta wersja nie wymaga flock. Opcja Persistent=true pozwala na nadrobienie uruchomienia pominiętego w czasie, gdy maszyna była wyłączona, czego nie potrafi wpis w crontab.

Należy wybrać albo crontab, albo timer. Uruchamianie obu dla tej samej witryny oznacza, że kolejka jest przetwarzana dwukrotnie, a zduplikowane wykonania zadań, takich jak wysyłka wiadomości e-mail czy obsługa zamówień, będą widoczne dla klientów.

Dlaczego zadanie cron nie powinno być uruchamiane jako root

Jest to pierwszy z trzech sposobów, w jaki konfiguracja może zawieść. Umieszczenie zadania w crontabie użytkownika root powoduje, że WP-CLI zatrzymuje się przed wykonaniem jakiejkolwiek operacji:

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

Kolejka nigdy nie jest przetwarzana, a w przypadku braku przekierowania wyjścia komunikat pozostaje niewidoczny. Niebezpiecznym rozwiązaniem jest dodanie --allow-root, ponieważ wówczas każdy plik utworzony przez wtyczkę podczas tego uruchomienia staje się własnością użytkownika root. Kolejne żądanie HTTP jest obsługiwane przez www-data, który nie ma uprawnień do zapisu w tych katalogach, co skutkuje błędami typu:

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

Należy naprawić uprawnienia do plików, a następnie przenieść zadanie:

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

Crontab użytkownika root oraz crontab użytkownika www-data to oddzielne pliki, więc usunięcie wpisu z jednego nie wpływa na drugi. Należy sprawdzić oba:

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

Dlaczego cron zgłasza wp: not found

To druga awaria. Cron nadaje zadaniom użytkownika bardzo krótki PATH, /usr/bin:/bin. WP-CLI instaluje się w /usr/local/bin, co nie znajduje się na tej liście. Zadanie uruchamia się, kończy niepowodzeniem w ułamku sekundy, a dziennik zawiera jedną linię:

/bin/sh: 1: wp: not found

Zamiast zgadywać, sprawdź samodzielnie środowisko crona. Dodaj tymczasową linię:

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

Odczytaj /tmp/cron-env.txt po jednym interwale, a następnie usuń tę linię. Wartość PATH= w tym pliku jest dokładnie tym, co otrzymuje zadanie.

Istnieją dwie poprawki. Użyj ścieżki bezwzględnej /usr/local/bin/wp, tak jak w kroku 3. Możesz też ustawić PATH jednorazowo na początku crontab, powyżej każdej linii zadania:

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

Ta sama pułapka znajduje się poziom niżej. Plik phar wp zaczyna się od #!/usr/bin/env php, więc powłoka musi być w stanie znaleźć również php. Jeśli PHP znajduje się poza /usr/bin, co zdarza się w przypadku kompilacji niestandardowych oraz wersji z paneli sterowania, otrzymasz:

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

W takim przypadku wywołaj interpreter jawnie, na przykład /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now.

Dlaczego interwał jednominutowy odtwarza pierwotny problem

To trzecia awaria. * * * * * wydaje się bezpieczniejszy niż pięć minut, jednak w przypadku obciążonej witryny przywraca stan wyjściowy. Jeśli pojedyncze uruchomienie trwa dłużej niż interwał, kolejna instancja rozpoczyna się, gdy poprzednia nadal działa. Dziesięć minut później w systemie znajduje się dziesięć procesów PHP, z których każdy zajmuje własną pamięć i utrzymuje własne połączenie z bazą danych.

Należy bezpośrednio monitorować zjawisko nawarstwiania się procesów:

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

etimes oznacza wiek procesu w sekundach. Pojedynczy wiersz oznacza stan prawidłowy. Kilka wierszy z wartościami wieku znacznie przekraczającymi interwał oznacza, że uruchomienia nakładają się na siebie. Na małym serwerze VPS kończy się to błędem Too many connections w MySQL lub zabiciem procesu PHP przez jądro systemu w celu odzyskania pamięci, co można potwierdzić za pomocą sudo dmesg -T | grep -i 'killed process'.

WP-CLI wykonuje wywołania zwrotne zdarzeń bezpośrednio, zamiast wysyłać żądania do wp-cron.php, więc blokada 60-sekundowa, której WordPress używa przeciwko duplikowaniu procesów, tutaj nie ma zastosowania. flock -n w punkcie 3 zapobiega obecnie nakładaniu się zadań. Pominięte uruchomienie kończy się natychmiast i bez komunikatów, zgodnie z założeniem. Nakładanie się procesów to problem, który należy rozwiązać w crontab, a nie taki, który jądro systemu rozwiąże za administratora: nawet mechanizm rozmieszczania zadań z uwzględnieniem pamięci podręcznej dodany w jądrze Linux 7.2 decyduje jedynie o tym, na którym rdzeniu proces zostanie uruchomiony, a nie o tym, ile instancji zostało zainicjowanych.

Należy wybrać interwał na podstawie najkrótszego harmonogramu, od którego faktycznie zależy działanie systemu, oraz najpierw zmierzyć czas trwania uruchomienia:

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

Pięć minut to rozsądna wartość domyślna: wpis zaplanowany na 09:00 zostanie opublikowany do 09:05. Piętnaście minut jest wystarczające dla witryny, w której nie ma zadań krytycznych czasowo. Interwał jednominutowy jest przeznaczony dla sklepów i wtyczek opartych na kolejkach, które rzeczywiście tego wymagają, i tylko wtedy, gdy wiadomo, że uruchomienie kończy się w ciągu kilku sekund.

Jeśli nie można zainstalować WP-CLI

Niektórzy dostawcy hostingu blokują narzędzia powłoki. Zwykłe żądanie HTTP do wp-cron.php uruchamia tę samą kolejkę, przechodząc przez cały stos webowy:

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

Oto co tracisz:

• Czas wykonania jest ograniczony przez limity czasu żądań serwera WWW i PHP-FPM, więc długie zadanie może zostać przerwane w trakcie.
• Certyfikat musi być ważny, w przeciwnym razie curl zatrzyma się z błędem SSL certificate problem, dlatego należy dbać o odnawianie certyfikatów zgodnie z Certbot na nginx.
• Mechanizm buforowania stron nie może obejmować wp-cron.php, w przeciwnym razie żądania cron otrzymają zbuforowaną odpowiedź i żadne zadanie nie zostanie wykonane.
• Brak danych wyjściowych dla poszczególnych zdarzeń, więc jedynym dowodem wykonania zadania jest jego efekt.

-sS wycisza curl w przypadku powodzenia, wyświetlając jedynie błędy, co jest pożądanym zachowaniem w zadaniach cron.

Co jeszcze powinno znaleźć się w harmonogramie zadań serwera

Gdy systemowy cron przejmie obsługę kolejki WordPress, pozostałe rutynowe zadania serwera należy umieścić w tym samym miejscu, aby zachować ich przejrzystość. Aktualizacje bezpieczeństwa systemu operacyjnego powinny być obsługiwane przez unattended upgrades, a nie przez ręcznie zarządzane wpisy w crontab. Aktualizacje wtyczek i motywów WordPress to odrębna kwestia: wp plugin update --all w pliku crontab może spowodować awarię działającej witryny o godzinie 3 nad ranem bez nadzoru, dlatego proces ten należy uruchamiać świadomie lub po przeprowadzeniu testów na środowisku stagingowym i wykonaniu kopii zapasowej.

FAQ

Czy wyłączenie WP-Cron uniemożliwia publikację zaplanowanych wpisów?

Nie, o ile kolejka jest wyzwalana w inny sposób. DISABLE_WP_CRON jedynie blokuje wyzwalanie kolejki podczas ładowania stron. Zdarzenia są nadal planowane w standardowy sposób. Wpis ustawiony na godzinę 09:00 zostanie opublikowany podczas pierwszego uruchomienia crona po godzinie 09:00, więc przy interwale pięciominutowym publikacja nastąpi najpóźniej o 09:05. Jeśli stała zostanie ustawiona, a wpis w cronie nie zostanie dodany, wpis pozostanie na liście z oznaczeniem Missed schedule do momentu uruchomienia kolejki.

Który użytkownik powinien uruchamiać zadanie cron dla WordPressa?

Użytkownik, który jest właścicielem plików zapisywanych przez PHP; w domyślnej instalacji Ubuntu jest to www-data. Należy to sprawdzić za pomocą stat -c '%U %G' /srv/www/example.com/wp-content/uploads i porównać z linią user = w konfiguracji puli PHP-FPM. Uruchomienie zadania jako root spowoduje zatrzymanie WP-CLI z błędem YIKES, a wymuszenie go za pomocą --allow-root spowoduje powstanie plików należących do roota wewnątrz wp-content, których serwer WWW nie będzie mógł później nadpisać.

Jak często systemowy cron powinien uruchamiać crona WordPressa?

Dla większości witryn odpowiedni jest interwał pięciominutowy. Należy dopasować interwał do najkrótszego harmonogramu, z którego faktycznie korzystasz, i zachować bezpieczny margines powyżej czasu trwania pojedynczego uruchomienia. Czas ten można zmierzyć, dodając time przed poleceniem WP-CLI. Interwały jednominutowe powodują nakładanie się zadań na obciążonych witrynach, chyba że przed ich uruchomieniem chroni flock.

Dlaczego wp cron test kończy się niepowodzeniem po wyłączeniu WP-Cron?

Ponieważ to polecenie testuje wyzwalanie zadań przez odwiedzających i zgłasza błąd, gdy DISABLE_WP_CRON jest ustawione na true. Jest to prawidłowy wynik na serwerze skonfigurowanym w ten sposób. Zamiast tego należy sprawdzić ścieżkę systemowego crona: odczytać /var/log/wp-cron/example.log lub zaplanować zdarzenie znacznikowe za pomocą wp cron event schedule i potwierdzić, że zniknęło ono z wp cron event list po kolejnym uruchomieniu.

Czy potrzebuję WP-CLI, czy wystarczy curl do wp-cron.php?

Curl działa i jest właściwym rozwiązaniem, gdy nie można zainstalować WP-CLI. Jest on wolniejszy, ponieważ ładuje WordPressa przez serwer WWW i jest ograniczony czasem oczekiwania na żądanie (timeout). WP-CLI uruchamia zdarzenia w procesie PHP linii poleceń bez limitu czasu serwera WWW i wypisuje jedną linię na zdarzenie wraz z jego czasem trwania, dzięki czemu dziennik dokładnie informuje, co zostało uruchomione i jak długo to trwało.