Czym jest WP-Cron?

WordPress ma swój własny wbudowany harmonogram zadań o nazwie WP-Cron. Obsługuje on wszystko, co musi się dziać według harmonogramu: publikowanie wpisów o ustalonej godzinie, sprawdzanie aktualizacji, wysyłanie powiadomień e-mail, czyszczenie nadmiaru bazy danych, uruchamianie zadań tła wtyczek. Brzmi rozsądnie — dopóki nie zorientujesz się, jak to faktycznie działa. W przeciwieństwie do prawdziwego systemu cron, który działa według stałego timera, WP-Cron jest wyzwalany tylko wtedy, gdy ktoś odwiedza Twoją witrynę. Brak odwiedzających — brak crona. I ta decyzja projektowa prowadzi do całej serii problemów.

Jak wyzwalany jest WP-Cron

Za każdym razem, gdy ładowana jest strona na Twojej witrynie WordPress, WordPress sprawdza listę zaplanowanych zdarzeń. Jeśli któreś jest opóźnione, zostaje wystrzelone podczas tego ładowania strony. Odwiedzający, który wyzwolił sprawdzenie, nie widzi niczego innego — zadania crona uruchamiają się (mniej więcej) w tle. Ale ważne, by zrozumieć: nie ma niezależnego procesu, który tyka. Cały system harmonogramowania jeździ na gapę z przychodzącym ruchem HTTP.

Był to pragmatyczny wybór. WordPress został zaprojektowany do działania na taniej hostingu współdzielonym, gdzie nie można instalować usług systemowych ani mieć dostępu do crontab. Podejście oparte na ruchu zapewniało, że zaplanowane zadania działały od ręki, na każdym hostingu, bez konfiguracji serwera.

Gdzie to się psuje

Projekt zależny od ruchu ma oczywiste problemy, które stają się bardziej bolesne, gdy Twoja witryna rośnie — lub, paradoksalnie, gdy nie rośnie wystarczająco:

• Witryny o niskim ruchu nie trafiają w harmonogram. Jeśli Twoja witryna ma 10 wizyt dziennie, zaplanowane wpisy mogą być publikowane z wielogodzinnym opóźnieniem. Wpis zaplanowany na 8:00 ukaże się dopiero, gdy ktoś odwiedzi witrynę po 8:00 — co może być po południu, jeśli Twoja publiczność jest w innej strefie czasowej. Przetwarzanie zamówień WooCommerce, harmonogramy kopii zapasowych i digesty e-mail spotyka ten sam los.
• Witryny o wysokim ruchu marnują zasoby. Na ruchliwej witrynie WP-Cron jest wyzwalany praktycznie przy każdym ładowaniu strony. WordPress sprawdza listę zdarzeń, ocenia znaczniki czasu i — zazwyczaj — nie znajduje nic do zrobienia. To zmarnowane cykle obliczeniowe przy każdym żądaniu. Co gorsza: wielu jednoczesnych odwiedzających może wyzwolić tę samą kontrolę crona w tym samym czasie, co prowadzi do race conditions, w których to samo zadanie uruchamia się dwukrotnie.
• Długo działające zadania spowalniają ładowanie stron. Gdy WP-Cron wystrzeli, zadania uruchamiają się jako część żądania strony. WordPress próbuje uruchomić osobne żądanie tła dla faktycznej pracy crona, ale w niektórych konfiguracjach serwera nie udaje się to po cichu i zadania uruchamiają się inline. Wtyczka kopii zapasowych generująca 500 MB zrzutu bazy danych może zablokować ładowanie strony dla odwiedzającego, jeśli połączenie loopback nie działa prawidłowo.
• Dryft crona się kumuluje. Ponieważ zdarzenia uruchamiają się tylko wtedy, gdy wyzwala je ruch, czasy są w najlepszym razie przybliżone. Zadanie zaplanowane na każdą godzinę może uruchomić się o 1:00, 2:17, 3:02, 4:45 — kiedykolwiek nadejdzie następna wizyta po zaplanowanym czasie.

Czym faktycznie zarządza WP-Cron

Możesz być zaskoczony, ile rzeczy zależy od tego systemu:

• Publikowanie zaplanowanych wpisów i stron w ustalonej dacie i godzinie
• Sprawdzanie aktualizacji rdzenia WordPress, wtyczek i motywów
• Przetwarzanie zadań tła WooCommerce (zmiany statusu zamówień, zaplanowane wyprzedaże, zarządzanie zapasami)
• Uruchamianie automatycznych wtyczek kopii zapasowych (UpdraftPlus, BackWPup, BlogVault)
• Wysyłanie zaplanowanych kampanii e-mail lub digestów
• Czyszczenie wygasłych transientów, wpisów w koszu i historii rewizji
• Przetwarzanie kolejek zadań z wtyczek formularzy, członkostwa i LMS
• Odnawianie certyfikatów SSL Let's Encrypt (na hostingach, które obsługują to przez WordPress)

Jeśli WP-Cron jest niewiarygodny, wszystkie te rzeczy stają się niewiarygodne.

Rozwiązanie: zastąp WP-Cron prawdziwym systemowym cronem

Standardową rekomendacją dla każdej witryny, która traktuje harmonogramowanie poważnie, jest wyłączenie wyzwalacza opartego na ruchu i zastąpienie go prawdziwym systemowym zadaniem cron. Jest to proces dwuetapowy:

Krok 1: Dodaj tę linię do swojego wp-config.php, aby zapobiec wyzwalaniu crona przez WordPress przy każdym ładowaniu strony:

define('DISABLE_WP_CRON', true);

Krok 2: Skonfiguruj systemowe zadanie cron, aby wywoływało wp-cron.php w stałym interwale. Większość paneli kontrolnych hostingu (cPanel, Plesk) ma menedżera zadań cron, albo możesz użyć crontab -e na serwerze, którym zarządzasz:

# Wywołuj WP-Cron co 5 minut przez wget
*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

# Alternatywa z curl
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

# Alternatywa z WP-CLI (zalecana dla lokalnych wywołań, unika narzutu HTTP)
*/5 * * * * cd /var/www/html && wp cron event run --due-now >/dev/null 2>&1

Podejście WP-CLI jest najczystsze, ponieważ nie wymaga żadnego żądania HTTP. Uruchamia zdarzenia crona bezpośrednio przez PHP, co unika problemów z połączeniami loopback, timeoutami HTTP i uwierzytelnianiem (np. HTTP basic auth na witrynach staging).

Hosting zarządzany a WP-Cron

Wiele zarządzanych hostingów WordPress (Kinsta, WP Engine, Cloudways, SiteGround) wyłącza domyślne zachowanie WP-Cron i automatycznie zastępuje je serwerowym cronem. Jeśli używasz zarządzanego hostingu, sprawdź ich dokumentację — możesz nie musieć nic robić. Zweryfikuj jednak, że to faktycznie działa, ponieważ niektóre hostingi ustawiają bardzo długi interwał (co 30 minut lub nawet godzinę), który może być zbyt rzadki jak na Twoje potrzeby.

Bezpieczeństwo: endpoint wp-cron.php

Plik wp-cron.php jest domyślnie publicznie dostępny. Odwiedzenie go w przeglądarce ręcznie wyzwala kontrolę crona. Choć nie ujawnia to wrażliwych danych, może być wykorzystane: atakujący zalewający endpoint żądaniami może wielokrotnie uruchamiać zasobochłonne zadania crona, powodując stan denial-of-service.

Jeśli przeszedłeś na systemowy cron, nie ma powodu, aby wp-cron.php był publicznie dostępny. Możesz zablokować dostęp zewnętrzny przez konfigurację serwera webowego, jednocześnie pozwalając systemowemu cronowi nadal wywoływać go lokalnie.

Rozwiązywanie problemów z WP-Cron

Jeśli zaplanowane zadania nie działają zgodnie z oczekiwaniami, wtyczka WP Crontrol jest nieoceniona. Dodaje stronę do panelu administracyjnego WordPress, która pokazuje wszystkie zarejestrowane zdarzenia crona, ich następny zaplanowany czas uruchomienia i częstotliwość. Możesz ręcznie wyzwolić dowolne zdarzenie, usuwać zacięte zdarzenia lub dodawać nowe niestandardowe harmonogramy. To pierwsze narzędzie, które należy zainstalować przy diagnozowaniu problemów z cronem.

Jak InspectWP pomaga

InspectWP sprawdza, czy Twój plik wp-cron.php jest publicznie dostępny. Jeśli przeszedłeś na systemowy cron i wyłączyłeś wbudowany WP-Cron, endpoint nie powinien być osiągalny z zewnątrz. Raport pomaga potwierdzić, że Twoja konfiguracja crona jest prawidłowo skonfigurowana i że nie ujawniasz niepotrzebnego endpointu.