Przejdź do treści
WWW i WordPress

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

WP-Cron zależy od ruchu i bywa zawodny. Zobacz różnice WP-Cron vs cron systemowy, jak wyłączyć WP-Cron i ustawić prawdziwego crona przez wp-config.php i crontab.

CZCzarek ZawolskiAktualizacja: 6 min czytania
Harmonogram zadań na serwerze WordPress w porównaniu z wewnętrznym mechanizmem WP-Cron

W skrócie

  • WP-Cron to mechanizm WordPressa uruchamiany przy wejściach na stronę, a nie o konkretnej godzinie — bez ruchu zadania się opóźniają, przy dużym ruchu uruchamiają się za często.
  • Rozwiązanie: wyłącz WP-Cron w wp-config.php (DISABLE_WP_CRON) i wywołuj wp-cron.php prawdziwym cronem systemowym co 5–15 minut.
  • Do wywołania crona użyj WP-CLI (wp cron event run --due-now) albo zapytania HTTP przez curl/wget — WP-CLI jest pewniejsze i nie obciąża serwera WWW.
  • Nie ustawiaj crona systemowego częściej niż realnie potrzebujesz; co minutę ma sens tylko dla sklepów i zadań czasu rzeczywistego.
  • Zadania przeglądasz i debugujesz wtyczką WP Crontrol, a na współdzielonym hostingu crona dodajesz w panelu (cPanel, DirectAdmin).
Spis treści

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

CechaWP-CronCron systemowy
Co wyzwala zadanieWejście użytkownika na stronęUsługa serwera o zaplanowanej porze
Dokładność czasuZależna od ruchu, nieprzewidywalnaCo do minuty
Działa bez ruchu na stronieNieTak
KonfiguracjaBrak, działa od razuWymaga dostępu do crontab lub panelu
Wpływ na wydajnośćObciąża przy każdej odsłonieKontrolowany, poza serwerem WWW
Typowe zastosowanieMałe strony, środowiska testoweProdukcja, sklepy, strony z dużym ruchem

Różnice między WP-Cron a cronem systemowym w WordPressie

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.

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.

Najczęściej zadawane pytania

Czym różni się WP-Cron od crona systemowego?

WP-Cron to kod PHP WordPressa wyzwalany przez odwiedziny strony, więc nie ma gwarancji, że zadanie wykona się o danej godzinie. Cron systemowy to usługa serwera uruchamiająca polecenia dokładnie o zaplanowanym czasie, niezależnie od ruchu.

Czy wyłączenie WP-Cron jest bezpieczne?

Tak, pod warunkiem że zamiast niego ustawisz cron systemowy lub zewnętrzny, który regularnie wywołuje wp-cron.php. Samo wyłączenie bez zamiennika spowoduje, że zaplanowane zadania (aktualizacje, publikacje, kopie) przestaną się wykonywać.

Jak często uruchamiać crona dla WordPressa?

Dla większości stron wystarczy co 5–15 minut. Sklepy WooCommerce i strony z zadaniami wrażliwymi na czas mogą potrzebować co minutę lub co 5 minut. Zbyt częste wywołania niepotrzebnie obciążają serwer.

Dlaczego zaplanowany wpis nie został opublikowany (missed schedule)?

Najczęstsza przyczyna to brak ruchu na stronie w zaplanowanym czasie przy domyślnym WP-Cron albo zablokowane wewnętrzne zapytanie HTTP. Rozwiązaniem jest przejście na cron systemowy i sprawdzenie zadań wtyczką WP Crontrol.

Czy WP-Cron działa na hostingu współdzielonym?

Tak, domyślnie działa wszędzie. Na hostingu współdzielonym możesz też zwykle dodać prawdziwego crona w panelu (np. cPanel → Cron Jobs) i wyłączyć WP-Cron, co daje stabilniejsze i wydajniejsze działanie zadań.

CZ

Autor

Czarek Zawolski

Założyciel i redaktor XAD.pl. Pisze o sieciach, bezpieczeństwie IT, administracji systemami Windows i Linux oraz o sprzęcie, który sprawia ludziom problemy na co dzień.