WP-Cron vs cron systemowy – jak poprawnie ustawić zadania w WordPressie

WP-Cron to wbudowany w WordPressa mechanizm zadań cyklicznych — publikacji zaplanowanych wpisów, sprawdzania aktualizacji, czyszczenia kosza, wysyłki maili przez wtyczki. Różni się jednak zasadniczo od crona systemowego: nie uruchamia się o konkretnej godzinie, lecz przy okazji wejścia użytkownika na stronę. To źródło dwóch typowych problemów — zadania spóźniają się na stronach o małym ruchu i uruchamiają się zbyt często na stronach o dużym.

Najlepsza praktyka dla większości witryn jest prosta: wyłączyć domyślny WP-Cron i wywoływać go prawdziwym cronem systemowym co kilka–kilkanaście minut. Poniżej wyjaśniam różnice i pokazuję, jak to skonfigurować, także na hostingu współdzielonym.

Jak działa WP-Cron i skąd biorą się problemy

Przy każdym wejściu na stronę WordPress sprawdza, czy są zaległe zadania. Jeśli tak, wysyła do samego siebie nieblokujące zapytanie HTTP do pliku wp-cron.php, który je wykonuje. Dzięki temu mechanizm działa „od ręki” na każdym hostingu, bez konfiguracji.

Ma to jednak wady wynikające wprost z tej konstrukcji:

• Zależność od ruchu. Na blogu z kilkoma wejściami dziennie wpis zaplanowany na 8:00 może pojawić się dopiero, gdy ktoś odwiedzi stronę — np. o 11:30. To klasyczny błąd „missed schedule”.
• Nadmiarowe wywołania. Na popularnej stronie wp-cron.php uruchamia się przy ogromnej liczbie odsłon, zużywając zasoby PHP, mimo że zadania i tak są puste.
• Blokady. Niektóre konfiguracje (cache, firewall, HTTP Basic Auth, brak możliwości połączenia strony z samą sobą) blokują wewnętrzne zapytanie i WP-Cron w ogóle nie rusza.
• Długie zadania spowalniają odwiedziny. Ciężkie zadanie (np. eksport, duża wysyłka maili) potrafi wydłużyć czas ładowania strony temu, kto akurat ją odwiedził.

WP-Cron vs cron systemowy – porównanie

Cron systemowy to część systemu operacyjnego (w Linuksie usługa cron/crond), uruchamiająca polecenia według harmonogramu zapisanego w crontab. Jeśli chcesz zrozumieć sam mechanizm od strony serwera, zajrzyj do artykułu systemctl – do czego służy, bo to przez systemctl zarządza się usługą crona w nowoczesnych dystrybucjach.

Krok 1: wyłącz domyślny WP-Cron

W pliku wp-config.php, powyżej linii /* That's all, stop editing! */, dodaj:

define( 'DISABLE_WP_CRON', true );

To wyłącza automatyczne wywoływanie wp-cron.php przy odsłonach. Zadania nie znikają — po prostu przestają być wyzwalane ruchem i czekają na zewnętrzne wywołanie.

Uwaga: Po wyłączeniu WP-Cron koniecznie skonfiguruj zamiennik (krok 2 lub 3). Bez tego zaplanowane wpisy nie zostaną opublikowane, aktualizacje nie będą sprawdzane, a wtyczki zależne od crona (kopie zapasowe, newslettery, synchronizacje) przestaną działać.

Krok 2: ustaw crona systemowego (dostęp SSH)

Jeśli masz dostęp do SSH i własnego serwera lub VPS, edytuj crontab użytkownika:

crontab -e

Wariant zalecany: WP-CLI

WP-CLI uruchamia zadania bez pośrednictwa serwera WWW, co jest szybsze i stabilniejsze:

*/5 * * * * cd /var/www/twojastrona && wp cron event run --due-now >/dev/null 2>&1

To wywołanie co 5 minut sprawdza i uruchamia wyłącznie zadania, których termin minął. Podmień ścieżkę na katalog swojej instalacji WordPressa. Jeśli WP-CLI nie jest w domyślnej ścieżce, podaj pełną ścieżkę do pliku wp. W sieci WordPress Multisite samo polecenie obsłuży tylko witrynę główną — dla pozostałych uruchom je z parametrem --url, np. w pętli po wyniku wp site list --field=url.

Wariant alternatywny: zapytanie HTTP

Gdy nie masz WP-CLI, wywołaj plik wp-cron.php przez curl lub wget:

*/5 * * * * curl -s "https://twojastrona.pl/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

Parametr doing_wp_cron jest tu ważny, a tryb cichy (-s, >/dev/null) zapobiega wysyłaniu maili z wynikiem przez crona. Pamiętaj, że ten sposób obciąża PHP serwera WWW i nie zadziała, jeśli stronę chroni HTTP Basic Auth.

Składnię pól crontab (minuta godzina dzień miesiąc dzień_tygodnia) i przykłady harmonogramów znajdziesz w poradniku o 20 poleceniach Linuksa, które musisz znać.

Krok 3: cron na hostingu współdzielonym (cPanel, DirectAdmin)

Na hostingu współdzielonym zwykle nie masz crontab przez SSH, ale panel oferuje własny harmonogram zadań.

W cPanelu:

1. Wejdź w sekcję Cron Jobs (Zadania cron).
2. W Common Settings wybierz częstotliwość, np. „Co 5 minut” (*/5 * * * *).
3. W polu Command wpisz wywołanie, najczęściej przez wget lub php:

wget -q -O /dev/null "https://twojastrona.pl/wp-cron.php?doing_wp_cron"

albo, jeśli hosting udostępnia WP-CLI:

cd /home/uzytkownik/public_html && wp cron event run --due-now

W DirectAdmin odpowiednia opcja nazywa się zwykle Cron Jobs w sekcji „Zaawansowane funkcje”. Zasada jest identyczna.

Wielu hostingodawców (np. z obsługą WP-CLI) ma w dokumentacji gotowe polecenie dla WordPressa — warto je sprawdzić, bo bywa dopasowane do ich środowiska.

Krok 4: przeglądaj i debuguj zadania wtyczką WP Crontrol

Zanim coś zmienisz, warto zobaczyć, co w ogóle jest zaplanowane. Darmowa wtyczka WP Crontrol dodaje w Narzędzia → Zdarzenia Cron listę wszystkich zadań: nazwę haka, następny termin, interwał i źródło. Pozwala:

• ręcznie uruchomić zadanie, żeby sprawdzić, czy działa,
• usunąć „osierocone” zadania po odinstalowanych wtyczkach,
• dodać własne zdarzenia i harmonogramy,
• wykryć zadania ustawione na nierealnie częste interwały przez wtyczki.

Jeśli masz problem „Pominięto harmonogram” (missed schedule) przy wpisach, WP Crontrol szybko pokaże, czy zadanie publish_future_post w ogóle się wykonuje.

Do głębszej diagnozy przyda się tryb debugowania WordPressa, który zapisze błędy PHP pojawiające się przy wykonywaniu zadań.

Jak dobrać częstotliwość i uniknąć typowych błędów

Dobór interwału to kompromis między aktualnością zadań a obciążeniem serwera:

• Blog, strona firmowa, portfolio: co 10–15 minut w zupełności wystarcza.
• Sklep WooCommerce, system rezerwacji, strony z subskrypcjami: co 5 minut, a w uzasadnionych przypadkach co minutę (np. ponawianie płatności, zmiany statusów zamówień).
• Zadania ciężkie (eksport, duże wysyłki): rozważ osobny cron o niskiej częstotliwości, poza godzinami szczytu.

Najczęstsze błędy:

1. Wyłączenie WP-Cron bez zamiennika — zadania cichą przestają działać.
2. Dublowanie — włączony WP-Cron i jednocześnie cron systemowy wywołujący wp-cron.php. Zawsze wyłączaj WP-Cron, gdy dodajesz crona zewnętrznego.
3. Zbyt częsty cron — co minutę na małej stronie to niepotrzebne obciążenie, zwłaszcza na współdzielonym hostingu.
4. Brak wyciszenia wyniku — bez >/dev/null 2>&1 cron może zasypywać Cię mailami.
5. Wtyczki ustawiające własne, zbyt częste zadania — sprawdź je w WP Crontrol.

Co wybrać dla swojej strony

Dla środowiska testowego i bardzo małej strony domyślny WP-Cron wystarczy — nie ma sensu komplikować. Dla każdej strony produkcyjnej, a zwłaszcza sklepu, przejdź na cron systemowy: wyłącz WP-Cron w wp-config.php i ustaw wywołanie wp cron event run --due-now co 5–15 minut (przez WP-CLI, jeśli masz je dostępne, albo przez panel hostingu). Zyskasz przewidywalne terminy zadań, koniec z problemem pominiętych publikacji i mniejsze obciążenie przy dużym ruchu — kosztem kilku minut konfiguracji.