WP Cron w WordPress: jak kontrolować harmonogram zadań

Jeśli korzystasz z WordPressa trochę dłużej, to na pewno liznąłeś temat „zapycha się cron”, „nie działa wordpress zaplanowany post”. W tym tekście chcę pokazać ci, jak ogarnąć harmonogram wordpress tak, żebyś miał nad nim pełną kontrolę – od domyślnego WP‑Cron, przez wtyczkę, aż po WP‑CLI.

Co to jest WP‑Cron?

WordPress nie ma klasycznego crona systemowego, tylko własną namiastkę – WP‑Cron. To kawałek mechanizmu, który odpala zaplanowane zadania przy okazji zwykłych requestów HTTP. Ktoś wejdzie na stronę, WordPress sprawdza listę zadań i jeśli coś „jest na termin”, odpala hooki.

To oznacza dwie rzeczy. Po pierwsze, wordpress cron działa tylko wtedy, kiedy jest jakiś ruch na stronie. Inaczej – gdy nie ma ruchu, to się nie odpali. Po drugie, nie masz gwarancji co do dokładnej minuty wykonania. Dla zadań typu „raz na godzinę sprawdź API” to zwykle wystarcza. Dla rzeczy wrażliwych czasowo – no już niekoniecznie.

Jak WordPress planuje zadania w tle

Kiedy jakaś wtyczka albo twój kod chce coś robić w tle, rejestruje swoje zadania za pomocą funkcji harmonogramu. Najczęściej zobaczysz:

• wp_schedule_event() – zadanie cykliczne, np. co godzinę, raz dziennie.
• wp_schedule_single_event() – jednorazowy strzał w konkretnym czasie.

Do tego dochodzą predefiniowane interwały, takie jak hourly, twicedaily, daily, czasem weekly. Możesz też dorzucić własne interwały, jeśli potrzebujesz czegoś bardziej częstszego, np. co pięć minut. To jest ten moment, w którym wordpress harmonogram zaczyna przypominać normalnego crona, tylko że żyje wewnątrz bazy danych i odpala się przy ruchu.

Jeśli kiedyś miałeś sytuację, że wordpress zaplanowany post nie chciał się opublikować o czasie, to zwykle zawinił właśnie WP‑Cron. Albo nie było ruchu, albo coś przycięło wywołanie wp-cron.php.

Podstawowa diagnoza problemów z harmonogramem

Zobacz, czy zwykłe zaplanowane wpisy faktycznie publikują się o czasie. Jeżeli nie, wejdź na stronę z poziomu incognito, odśwież kilka podstron i zobacz, czy zadanie „zaskoczyło”. W wielu przypadkach to wystarczy, bo samo wejście odwiedzającego uruchamia wordpress cron.

Drugi krok to zacznij od rzeczy, które dadzą ci twarde dane, a nie tylko przeczucia. Najprostszy i bardzo skuteczny sposób to sprawdzenie, czy WordPress w ogóle odpala wp-cron. Wejdź w logi dostępu do strony np. access.log w panelu hostingowym i przefiltruj wpisy po frazie wp-cron.php albo doing_wp_cron. Jeśli log jest zupełnie pusty, a masz włączony domyślny mechanizm, to znaczy, że harmonogram w ogóle się nie uruchamia. Jeśli wpisy są, popatrz na statusy HTTP – interesuje cię głównie kod 200. Gdy widzisz 500, 403 albo inne błędy, wiesz, że coś po drodze blokuje lub wywala wykonanie i wtedy od razu zaglądasz w error.log, żeby złapać konkretne wyjątki.

WP‑Cron a prawdziwy cron na serwerze

Niestety w pewnym momencie dojdziesz do sufitu z WP‑Cron. Widzę to często przy sklepach WooCommerce albo portalach z dużym ruchem. Core WordPressa radzi sobie jeszcze jakoś, ale wtyczki dorzucają własne zadania i nagle masz kilkadziesiąt eventów, które próbują odpalić się przy jednym requeście użytkownika.

Rozwiązanie jest proste: wyłączasz automatyczne wywoływanie wp-cron.php przez WordPressa i przejmujesz inicjatywę na poziomie crona systemowego. Ustawiasz na serwerze zadanie, które co minutę lub co pięć minut wywoła cron ręcznie. Dzięki temu masz wordpress cron, który zachowuje się jak normalne zadanie systemowe – bez zależności od ruchu i bez niespodzianek.

Jeżeli chcesz gotową instrukcję krok po kroku, jak to zrobić konkretnie na hostingu, zajrzyj do naszego poradnika: Jak wyłączyć wp-cron i poprawić wydajność w WordPress? | Jak to zrobić na hostingu? – znajdziesz tu cały proces rozpisany ze screenami i przykładami ustawień. 

Wtyczka WordPress do zarządzania harmonogramem

Sam mechanizm WP‑Cron działa w tle, więc bez narzędzi pomocniczych widzisz głównie skutki, a nie przyczynę. Jeśli zaczynasz grzebać w harmonogramie, zainstaluj lekką wtyczkę do podglądu i zarządzania zadaniami. Dzięki niej zauważysz, ile hooków jest tak naprawdę zaplanowanych, zobaczysz najbliższe terminy wykonania i szybko wyłapiesz powtarzające się błędy.

Podgląd listy zadań to świetny reality check. Nagle okazuje się, że jakaś niepozorna wtyczka marketingowa odpala cron co minutę, a plugin do SEO uruchamia kosztowne analizy kilka razy dziennie. Z poziomu panelu możesz te zadania zmodyfikować, przesunąć im interwał, a w razie potrzeby całkiem wyłączyć. Dla mnie to absolutny must-have na środowiskach produkcyjnych, gdzie wordpress harmonogram robi się naprawdę rozbudowany.

WP‑CLI – gdy jednak wolisz terminal

Jeżeli lubisz terminal, to wordpress cron dużo wygodniej ogarniesz z poziomu WP‑CLI. Nie musisz klikać po panelu, tylko jednym poleceniem sprawdzasz, co siedzi w kolejce, a drugim odpalasz wszystkie zadania, które są „due now”. To świetne narzędzie, gdy pracujesz na VPS‑ie albo masz kilka instancji WordPressa do ogarnięcia naraz.

Jeśli dopiero zaczynasz z WP‑CLI, to zamiast wchodzić od razu w zaawansowane skrypty, zerknij do poradnika dla początkujących: Kurs WP-CLI – polecenia i przykłady. | Jak to zrobić na hostingu?. Tam rozpisaliśmy, jak zainstalować WP‑CLI, jak się nim posługiwać na hostingu HitMe i jak wykonywać podstawowe operacje na WordPressie z linii komend. 

Przykładowo, żeby szybko zobaczyć listę zaplanowanych zadań wraz z najbliższym terminem wykonania, wystarczy w katalogu WordPressa odpalić:

wp cron event list

A jeśli już o litespeed mowa…

Typowe use case’y z życia

To weźmy już jako pierwszy LiteSpeed Cache. Masz wszystko ładnie pocache’owane, strona śmiga, ale nagle zaczyna się cyrk z opóźnionymi zadaniami w tle. Crawler, automatyczne purge’y, odświeżanie cache’u po czasie – to wszystko potrafi polegać na WP‑Cron. Jeśli cron nie działa przewidywalnie, zaczynasz widzieć np. przeterminowane treści albo brak odświeżania niektórych podstron. LiteSpeed sam w dokumentacji sugeruje, żeby przy mocno cache’owanych stronach przejąć kontrolę nad WP‑Cron i odpalać go z poziomu crona systemowego, bo przy pełnym cache’u PHP po prostu „nie budzi się” wystarczająco często.

Druga sytuacja to klasyk czyli zaplanowany post wordpress. Na zwykłym blogu wkurza, na serwisie z większym ruchem psuje cały plan publikacji. Jeżeli widzisz, że zaplanowane wpisy nagminnie publikują się z opóźnieniem, to pierwszy kandydat do sprawdzenia jest właśnie harmonogram – od logów z wp-cron.php, przez kolejkę zadań, aż po to, czy jakiś plugin cache’ujący nie utrudnia WordPressowi wywoływania crona.

Trzeci use case to sklepy i aplikacje biznesowe, gdzie w tle lata masa akcji: wygaszanie kuponów, generowanie raportów, synchronizacje z systemami zewnętrznymi. Tutaj dobrze ustawiony harmonogram wordpress to nie tyle „ładna technologia”, co po prostu ciągłość procesów biznesowych. Kiedy cron siada, nie dochodzą maile, nie aktualizują się statusy zamówień, a raporty dnia przychodzą puste albo z opóźnieniem.

Na koniec środowiska dev i staging. Tam wordpress cron traktujesz bardziej jak sandbox – chcesz mieć możliwość ręcznego odpalenia konkretnych hooków, sprawdzenia logów i powtórzenia testu kilka razy pod rząd. WP‑CLI robi tu robotę, bo jednym poleceniem wyświetlasz listę eventów, drugim je odpalasz, a w logach widzisz dokładnie, co się zadziało. Dzięki temu każde nowe zadanie w harmonogramie możesz „przeklikać” w kontrolowanych warunkach, zanim wyleci na produkcję.