Jak skonfigurować zadania cron dla WordPressa i sprawdzić, czy działają

WP-Cron sprawdza zaplanowane zdarzenia przy wczytaniu strony, a cron serwerowy uruchamia polecenie według harmonogramu systemu. Dokumentacja WordPressa opisuje WP-Cron jako mechanizm wyzwalany przy żądaniach do witryny; nie wymaga on zalogowania do kokpitu ani dostępu do administracji. Dokumentację sprawdziliśmy w październiku 2026 roku.

Cron serwerowy zwykle wywołuje `wp-cron.php` albo uruchamia komendy WP-CLI, czyli narzędzia do obsługi WordPressa z wiersza poleceń. Samo uruchomienie zadania systemowego nie potwierdza, że kod wtyczki wykonał się poprawnie. Tabela porównuje mechanizmy i warunki ich użycia.

Tabela pokazuje, że WP-Cron nie wymaga dostępu do kokpitu, a cron serwerowy wymaga konfiguracji po stronie hostingu lub serwera.

WP-Cron wymaga mniej konfiguracji, a cron serwerowy daje kontrolę nad porą wywołania. Dla strony firmowej, na której niewielkie opóźnienie publikacji nie wpływa na obsługę klienta, mechanizm domyślny może wystarczyć.

Cron serwerowy warto skonfigurować, gdy opóźnienie zadania powoduje problem operacyjny albo witryna nie ma ruchu wystarczającego do regularnego wyzwalania WP-Cron. Dotyczy to importów, synchronizacji stanów, wysyłek i procesów WooCommerce, jeśli ich termin ma znaczenie dla obsługi zamówień.

Sygnały do sprawdzenia:
- Zaplanowany wpis lub wiadomość nie pojawia się w oczekiwanym czasie.
- Synchronizacja zaczyna się dopiero po wejściu użytkownika na stronę.
- W kolejce WooCommerce przybywa oczekujących lub nieudanych działań.
- Import trwa dłużej niż odstęp między uruchomieniami i może się nakładać.

Z naszych wdrożeń: gdy sklep miał zaległe akcje, a ręczne wywołanie `wp-cron.php` nie zmieniało ich statusu, diagnozę zaczynaliśmy od komunikatu błędu w zaplanowanym działaniu i logu wtyczki, zanim zmieniliśmy harmonogram. Sam fakt posiadania sklepu nie przesądza o potrzebie zmiany mechanizmu.

Jeśli przygotowujesz nową witrynę, wymagania dla zadań cyklicznych ustal na etapie wdrożenia. Strony internetowe na WordPressie możemy przygotować z uwzględnieniem konfiguracji środowiska i harmonogramu.

Działanie zadania potwierdza połączenie trzech dowodów: zdarzenie jest zaplanowane, wykonanie pozostawia ślad w logu, a oczekiwany skutek pojawia się w systemie. WP-CLI rozdziela test mechanizmu `wp cron test` od listy zdarzeń `wp cron event list`; lista pokazuje harmonogram, ale nie dowodzi wykonania kodu. Dokumentację WP-CLI sprawdziliśmy w październiku 2026 roku.

W WooCommerce przejdź do `WooCommerce > Status > Zaplanowane działania`. Sprawdź status działania, datę następnego uruchomienia oraz komunikat błędu. Dokumentacja WooCommerce opisuje to miejsce jako widok planowanych działań; lokalizację i opis sprawdziliśmy w październiku 2026 roku.

Weryfikację przeprowadź w kolejności:
1. Zapisz nazwę hooka, czyli zdarzenia wywołującego kod, oraz planowany czas wykonania.
2. Użyj `wp cron event list`, aby potwierdzić, że zdarzenie znajduje się w harmonogramie.
3. Użyj `wp cron test`, aby sprawdzić mechanizm uruchamiania WP-Cron.
4. Sprawdź log PHP, log hostingu lub log wtyczki, szukając czasu wykonania i komunikatu błędu.
5. Na kopii albo w uzgodnionym oknie serwisowym uruchom bezpieczne zdarzenie przez `wp cron event run nazwa_hooka` i potwierdź jego skutek.

Przykładowym skutkiem jest zmiana statusu konkretnej akcji, pojawienie się pliku importu albo aktualizacja danych w systemie docelowym. Nie uruchamiaj ręcznie zadania, które wysyła wiadomości lub tworzy dokumenty, jeśli ponowne wykonanie może zdublować operację. Więcej poleceń opisujemy w artykule WP-CLI i zarządzanie WordPressem z terminala.

Zadanie w panelu hostingu skonfigurujesz, podając harmonogram, polecenie i ścieżkę do instalacji WordPressa. Poszukaj sekcji o nazwie "Cron", "Harmonogram zadań" albo "Zadania cykliczne"; nazwy pól zależą od dostawcy.

Przygotuj kolejno:
1. Pełną ścieżkę do katalogu, w którym znajduje się `wp-cron.php`.
2. Ścieżkę do PHP CLI podaną przez hosting lub administratora.
3. Interwał dopuszczony przez plan hostingowy.
4. Lokalizację logu poza publicznym katalogiem witryny.
5. Polecenie oraz sposób sprawdzenia jego wykonania po pierwszym terminie.

Przykładowa komenda PHP wymaga podmiany ścieżek na właściwe dla serwera:

/usr/bin/php /sciezka/do/wordpress/wp-cron.php

Jeśli panel pozwala tylko na wywołanie URL, oficjalna instrukcja WordPressa podaje `wget` jako jeden ze sposobów uruchomienia `wp-cron.php`. Sprawdź, czy żądanie nie jest blokowane przez zaporę ani uwierzytelnianie HTTP, a odpowiedź nie zapisuje się w katalogu publicznym. Instrukcję sprawdziliśmy w październiku 2026 roku.

Tabela pokazuje, jakie dane zweryfikować przed zapisaniem polecenia.

Tabela pozwala sprawdzić ścieżki, ograniczenia i lokalizację logu przed aktywacją zadania.

Przed aktywacją sprawdź, czy konto wykonujące zadanie może odczytać pliki WordPressa i zapisać log.

Przez SSH zadanie ustawisz poleceniem `crontab -e`, jeśli hosting udostępnia crontab dla używanego konta. Wpis harmonogramu zawiera pola minuty, godziny, dnia miesiąca, miesiąca i dnia tygodnia, po których następuje komenda; dokumentację WordPressa sprawdziliśmy w październiku 2026 roku.

Przykład uruchomienia `wp-cron.php` co 15 minut z logiem poza katalogiem publicznym:

*/15 * * * * /usr/bin/php /sciezka/do/wordpress/wp-cron.php >> /sciezka/do/logow/wp-cron.log 2>&1

Wariant z WP-CLI:

*/15 * * * * cd /sciezka/do/wordpress && /usr/local/bin/wp cron event run --due-now --quiet >> /sciezka/do/logow/wp-cron.log 2>&1

Ścieżkę do WP-CLI sprawdzisz poleceniem `command -v wp`, a do PHP poleceniem `command -v php`. Uruchom test ręczny jako to samo konto, które będzie właścicielem zadania cron. W wielu instalacjach WP-CLI wymaga wskazania właściwego katalogu przez `--path`.

Nie testuj na produkcji polecenia, które może wysłać powiadomienie, wygenerować dokument lub ponownie zaimportować te same dane. Najpierw potwierdź, czy aplikacja zabezpiecza takie operacje przed duplikacją.

WP-Cron wyłącz dopiero po sprawdzeniu crona serwerowego i potwierdzeniu skutku zadania w WordPressie. Stała `DISABLE_WP_CRON` powinna być zdefiniowana w `wp-config.php` przed załadowaniem WordPressa, najlepiej przed `require_once ABSPATH . 'wp-settings.php';`; jeśli plik ma wiersz kończący edycję PHP, dodaj ją przed tym wierszem. Dokumentacja WordPressa zaleca tę stałą do wyłączenia uruchamiania WP-Cron przy odsłonach.

Bezpieczna kolejność przełączenia:
1. Skonfiguruj cron serwerowy, który wywołuje `wp-cron.php` albo WP-CLI.
2. Uruchom test mechanizmu i niekrytyczne zdarzenie.
3. Potwierdź zapis w logu oraz oczekiwany skutek w witrynie.
4. Obserwuj kilka uruchomień i sprawdź, czy liczba zaległych działań nie rośnie.
5. Dopiero wtedy ustaw `define( 'DISABLE_WP_CRON', true );`.

Tabela pomaga wybrać metodę na podstawie dostępu do hostingu.

Tabela pokazuje wymagany dostęp i dowód poprawnego działania każdej metody.

Jeśli po przełączeniu nie powstaje log lub nie zmienia się stan zadania, przywróć poprzednią konfigurację i sprawdź polecenie systemowe. Zasady ochrony plików opisujemy w poradniku bezpieczeństwa WordPressa.

Interwał crona dobierz do dopuszczalnego opóźnienia zadania, jego czasu wykonania oraz limitu hostingu. Przykład `*/15` w dokumentacji WordPressa pokazuje składnię harmonogramu, a nie uniwersalne zalecenie dla każdej witryny.

Zapisuj czas startu, czas końca, polecenie, kod zakończenia i komunikat błędu. Przechowuj log poza katalogiem publicznym, ustaw rotację plików i nie zapisuj w nim haseł, tokenów ani danych klientów.

Dwa uruchomienia mogą się nałożyć, gdy pierwsze zadanie trwa dłużej niż odstęp harmonogramu. W logu szukaj kolejnego znacznika startu przed zakończeniem poprzedniego albo powtarzających się procesów widocznych w monitoringu hostingu. Dla długiego importu zastosuj blokadę, która pomija kolejny start do czasu zakończenia poprzedniego.

Problemy z cronem diagnozuj od ścieżki polecenia i uprawnień, a następnie sprawdź blokady sieciowe, harmonogram i logi aplikacji. Po każdej zmianie wykonaj jeden test i zapisz jego wynik.

• Błędna ścieżka PHP: sprawdź `command -v php` przez SSH albo poproś hosting o ścieżkę PHP CLI.
• Błędny katalog WordPressa: sprawdź, czy wskazany katalog zawiera `wp-cron.php`.
• Brak uprawnień: uruchom polecenie jako konto harmonogramu i sprawdź możliwość zapisu logu.
• Blokada HTTP: sprawdź zaporę, uwierzytelnianie i możliwość połączeń do własnej witryny.
• Niezgodny czas: porównaj czas serwera z `Ustawienia > Ogólne` w WordPressie.
• Zaległe działania WooCommerce: odczytaj komunikat przy akcji i sprawdź log powiązanej wtyczki.
• Nakładające się procesy: porównaj znaczniki startu i końca z odstępem harmonogramu.

Poprawne działanie potwierdza oczekiwany skutek, zapis w logu i brak powtarzającego się błędu. Odpowiedź HTTP 200 potwierdza odpowiedź serwera, ale sama nie dowodzi poprawnego wykonania zdarzenia WordPressa. Jeśli potrzebujesz wykonawcy konfiguracji strony i jej procesów, wdrożenie witryny opartej na WordPressie może objąć także harmonogram zadań.

• Serwer pod WordPress: jak dobrać parametry i przygotować środowisko
• WP Cerber Security w WordPressie: konfiguracja, testy i diagnostyka
• Przejęcie strony WordPress: jak sprawdzić dostęp, kopię i działanie serwisu
• Jak stworzyć bloga na WordPress: konfiguracja, publikacja i rozwój