Jak wyłączyć WP-Cron i skonfigurować systemowy cron

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, system wysyła drugie żądanie HTTP do samego siebie na adres /wp-cron.php, aby wykonać pracę. Przeniesienie tego zadania do systemowego crona zapewnia przewidywalne uruchomienie w ustalonym czasie, 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 pliku wp-config.php oraz wpis w crontab. Cała reszta tego przewodnika opisuje aspekty, których te dwie linie nie wyjaśniają. Określają one, jako który użytkownik zadanie musi zostać uruchomione, jak zweryfikować, czy zaplanowane zdarzenia faktycznie zostały wywołane, oraz wskazują trzy sposoby, w jakie konfiguracja może zawieść bez wyświetlenia żadnego komunikatu na stronie.

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

Który użytkownik generuje koszty crona w obciążonej witrynie

Każde żądanie nieobsłużone przez pamięć podręczną wymusza sprawdzenie 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 zadań. 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ć, jak często zadanie jest wywoływane 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 rzędu tysięcy wywołań dziennie oznacza 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 strony obsługuje większość żądań jako statyczny kod HTML, PHP nie jest uruchamiany dla tych zapytań, więc sprawdzenie crona nigdy nie następuje. Mocno zoptymalizowana pod kątem cache witryna zaczyna zachowywać się jak mało obciążona strona opisana poniżej.

Dlaczego brak odwiedzających powoduje przestoje w działaniu cron

Brak odwiedzających oznacza brak uruchomień cron. Witryna, która otrzymuje zaledwie kilka wizyt dziennie, wykonuje zaplanowane zadania tylko kilka razy na dobę, w losowych momentach, w których pojawiają się użytkownicy.

Objawy zawsze wyglądają tak samo. Wpis zaplanowany na godzinę 09:00 pozostaje na liście postó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ę, więc panel administracyjny nie wyświetla żadnych powiadomień, mimo że wydanie poprawki 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ż nigdy nie zostało uruchomione.

Krok 1: wyłączenie wyzwalacza odwiedzin w pliku 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 jest miejscem, 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 uruchamiać tę kolejkę, co oznacza, że kolejka nie będzie przetwarzana, dopóki nie ukończysz 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 minimum, a Ubuntu 24.04 dostarcza PHP 8.3, więc aktualny serwer spełnia te wymagania z dużym zapasem. Aktualizację wykonaj 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 została wyjaśniona w pierwszym poniższym scenariuszu 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 polecenie wykonuje się poprawnie.

Teraz potwierdź, że 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 wskazuje na umieszczenie jej poniżej instrukcji require.

Krok 3: dodanie wpisu cron dla odpowiedniego użytkownika

Właściwym użytkownikiem jest ten, do którego należą pliki zapisywane przez PHP. Sprawdź obie strony:

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 per-site opisanej w stosie LAMP na Ubuntu 24.04, użyj tego użytkownika w 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 jedną linię:

*/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 blokuje. /usr/local/bin/wp to ścieżka bezwzględna, wymagana przez cron. --path umożliwia uruchomienie polecenia z dowolnego katalogu roboczego. --due-now wykonuje 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 jest niezbędne. Cron wysyła wyjście zadania na adres e-mail użytkownika, a większość obrazów VPS nie posiada zainstalowanego agenta transferu poczty (MTA), przez co cron loguje (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

Dla kilku witryn użyj osobnej linii dla każdej z nich, stosując przesunięcie czasowe, 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ń

Zapisanie linii w crontab nie gwarantuje sukcesu. Należy przejść od najprostszej weryfikacji do sprawdzenia ostatecznego.

Po pierwsze, czy cron uruchomił polecenie? Cron zapisuje logi w journalu w ramach własnej jednostki:

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, czy polecenie zakończyło się powodzeniem.

Po drugie, czy WordPress wykonał jakiekolwiek zadanie? Należy sprawdzić plik dziennika:

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

WP-CLI generuje jedną linię na zdarzenie, a następnie 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 zadań do wykonania, plik pozostanie niemal pusty, dlatego należy go sprawdzić po czasie, w którym zaplanowano pracę.

Po trzecie, należy przeprowadzić test end-to-end. Zaplanuj zdarzenie testowe i obserwuj, 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

Odczekaj jeden interwał i ponownie uruchom polecenie wyświetlające listę. Jeśli zdarzenie zniknęło, oznacza to, że zostało usunięte z kolejki po wykonaniu. Ponieważ żadna wtyczka nie rejestruje callbacku dla tej nazwy hooka, jego wywołanie nie wpłynie na działanie witryny. Jeśli po dwóch interwałach hook nadal widnieje na liście, oznacza to, że kolejka nie jest przetwarzana. Pierwsze dwa kroki 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, i zwraca błąd, gdy DISABLE_WP_CRON jest ustawione na true. Na poprawnie skonfigurowanym serwerze błąd ten jest oczekiwanym rezultatem, a nie usterką.

Alternatywa w postaci systemd timer

Jeśli pozostałe zaplanowane zadania na serwerze są już realizowane jako usługi i timery systemd, należy tam również umieścić WordPress. Każde uruchomienie będzie 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 instancji 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ń związanych z pocztą lub zamówieniami 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 crontab 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 o błędzie pozostaje niewidoczny. Niebezpiecznym rozwiązaniem jest dodanie flagi --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ź środowisko crona samodzielnie. 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ą dwa rozwiązania. Użyj ścieżki bezwzględnej /usr/local/bin/wp, tak jak w kroku 3. Możesz też ustawić PATH jednorazowo na początku pliku crontab, powyżej każdej linii z zadaniem:

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

Ta sama pułapka występuje 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 tych 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, ale w przypadku obciążonej witryny przywraca stan wyjściowy. Jeśli jeden cykl trwa dłużej niż interwał, kolejny uruchamia się, gdy poprzedni wciąż trwa. Dziesięć minut później działa 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 to czas działania procesu w sekundach. Pojedynczy wiersz oznacza stan prawidłowy. Wiele wierszy z czasem znacznie przekraczającym interwał oznacza, że cykle nakładają się na siebie, co na małym VPS kończy się 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 uruchamia wywołania zwrotne zdarzeń bezpośrednio, zamiast wysyłać żądania wp-cron.php, więc 60-sekundowa blokada WordPressa zapobiegająca duplikowaniu procesów tutaj nie działa. flock -n w punkcie 3 zapobiega teraz nakładaniu się zadań. Pominięty cykl kończy się natychmiast i bez komunikatów, zgodnie z założeniami projektowymi.

Należy wybrać interwał odpowiadający najkrótszemu harmonogramowi, od którego zależy działanie witryny, oraz najpierw zmierzyć czas trwania pojedynczego cyklu:

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

Pięć minut to rozsądne ustawienie domyślne: wpis zaplanowany na 09:00 zostanie opublikowany do 09:05. Piętnaście minut jest odpowiednie dla witryn, w których nie ma zadań krytycznych czasowo. Interwał jednominutowy jest przeznaczony dla sklepów i wtyczek opartych na kolejkach, które faktycznie tego wymagają, pod warunkiem, że cykl 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 traci się w takim rozwiązaniu:

• Czas wykonania jest ograniczony przez limity czasu żądań serwera WWW oraz PHP-FPM, więc długie zadanie może zostać przerwane w trakcie.
• Certyfikat musi być poprawny, w przeciwnym razie curl zatrzyma się z błędem SSL certificate problem, dlatego należy dbać o działanie odnawiania certyfikatów zgodnie z Certbot on 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 końcowy.

-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 kolejka WordPress jest obsługiwana przez systemowy cron, pozostałe rutynowe zadania serwera należy umieścić w tym samym miejscu, aby zachować przejrzystość konfiguracji. 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 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, pod warunkiem, że kolejka jest obsługiwana w inny sposób. DISABLE_WP_CRON jedynie wyłącza wyzwalanie kolejki podczas ładowania stron. Zdarzenia są nadal planowane w ten sam sposób. Wpis ustawiony na godzinę 09:00 zostanie opublikowany podczas pierwszego uruchomienia crona po godzinie 09:00, więc przy pięciominutowym interwale publikacja nastąpi najpóźniej o 09:05. Jeśli zdefiniujesz stałą, ale nie dodasz wpisu w cronie, wpis pozostanie na liście oznaczony jako Missed schedule, dopóki kolejka nie zostanie uruchomiona.

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

Użytkownik, do którego należą pliki zapisywane przez PHP, czyli www-data w domyślnej instalacji Ubuntu. Sprawdź to za pomocą stat -c '%U %G' /srv/www/example.com/wp-content/uploads i porównaj z linią user = w konfiguracji puli PHP-FPM. Uruchamianie zadania jako root powoduje zatrzymanie WP-CLI z błędem YIKES, a wymuszenie go za pomocą --allow-root pozostawia w wp-content pliki należące do roota, 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. Dostosuj interwał do najkrótszego harmonogramu, z którego faktycznie korzystasz, i utrzymuj go z bezpiecznym zapasem 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 są one zabezpieczone przez 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 sprawdź ścieżkę systemowego crona: odczytaj /var/log/wp-cron/example.log lub zaplanuj zdarzenie znacznikowe za pomocą wp cron event schedule i potwierdź, ż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 limitem czasu żądania. WP-CLI uruchamia zdarzenia w procesie PHP linii poleceń bez limitu czasu WWW i wypisuje jedną linię na zdarzenie wraz z jego czasem trwania, dzięki czemu dziennik dokładnie informuje, co zostało uruchomione i ile czasu to zajęło.