Action Scheduler w WooCommerce. Co to jest, dlaczego rośnie i jak nad nim zapanować

Krótka odpowiedź, zanim wejdę w szczegóły

Action Scheduler to kolejka zadań w tle dla WordPressa. Autorzy opisują go jako „skalowalną, śledzalną kolejkę zadań do przetwarzania w tle dużych kolejek zadań” (actionscheduler.org). Sklep na WooCommerce korzysta z niego cały czas, tylko po cichu: przy webhookach, mailach, raportach i aktualizacjach bazy po update.

Rośnie z prostego powodu. Każde zaplanowane zadanie to wiersz w tabeli wp_actionscheduler_actions, a każdy krok jego życia to wiersz w wp_actionscheduler_logs. Gdy wtyczki dorzucają zadania szybciej, niż wbudowane sprzątanie je usuwa, tabele rosną bez końca, a panel zamówień zaczyna zwalniać.

Panujesz nad tym na trzy sposoby: krótszy okres przechowywania (filtr action_scheduler_retention_period), regularne uruchamianie kolejki (cron systemowy zamiast WP-Cron) i zaglądanie co jakiś czas do WooCommerce, Status, Zaplanowane działania. Czego nie robić: czyścić tych tabel przez TRUNCATE. Niżej wyjaśniam dlaczego, bo to częsta „rada z internetu”, która potrafi zatrzymać sklep bez jednego komunikatu o błędzie.

Wszystkie wersje i wartości domyślne w tym tekście sprawdziłem 22.10.2026: Action Scheduler 4.2.0, WooCommerce 11.2.1. WooCommerce dołącza własną kopię biblioteki, w 11.2.1 jest to 4.1.0; działa najnowsza z zainstalowanych.

Czym właściwie jest Action Scheduler

To biblioteka dołączana do wtyczek, a nie osobny produkt do kupienia. Pozwala uruchomić hak w przyszłości albo asynchronicznie, czyli poza żądaniem użytkownika. Sam WordPress też umie zaplanować hak przez WP-Cron, ale Action Scheduler dokłada do tego prawdziwą kolejkę: rezerwację paczek zadań, statusy, logi i ekran w panelu.

Zamiast liczyć coś ciężkiego w chwili, gdy klient klika „Kupuję”, wtyczka zapisuje zadanie i od razu wraca do klienta. Zadanie wykona się chwilę później, w tle. Klient nie czeka.

Skala jest spora. Według strony projektu Action Scheduler co miesiąc przetwarza miliony płatności dla WooCommerce Subscriptions, a na działających sklepach obsługiwał kolejki powyżej 50 000 zadań, w 10 równoległych kolejkach, z prędkością ponad 10 000 akcji na godzinę.

Nie myl go z HPOS. HPOS to sposób zapisu zamówień w osobnych tabelach i opisuję go w tekście czym jest HPOS i jak go włączyć. Action Scheduler to kolejka zadań, która działa niezależnie od tego, gdzie leżą zamówienia.

Jak to działa pod spodem

Domyślnie kolejkę budzi WP-Cron. Action Scheduler rejestruje w WP-Cron zdarzenie action_scheduler_run_queue w harmonogramie co minutę (harmonogram zmienisz filtrem action_scheduler_run_schedule). Dodatkowo raz na minutę sprawdza kolejkę przy zakończeniu żądań w panelu admina. Gdy są zadania, runner rezerwuje paczkę 25 akcji i przetwarza je, dopóki nie zużyje 90 procent dostępnej pamięci albo dopóki kolejne 3 akcje nie przekroczyłyby 30 sekund pracy. Domyślnie działa jedna paczka naraz (actionscheduler.org/perf).

Jeśli po tym zostały zadania, Action Scheduler wysyła żądanie sam do siebie (loopback) i pracuje dalej w nowym procesie. Dlatego kolejka potrafi przerobić tysiące zadań, choć pojedyncze żądanie ma tylko 30 sekund.

Te progi zmieniasz filtrami:

Filtr	Co ustawia	Domyślnie
action_scheduler_queue_runner_batch_size	ile akcji rezerwuje jedna paczka	25
action_scheduler_queue_runner_time_limit	ile sekund trwa jedno przetwarzanie	30
action_scheduler_queue_runner_concurrent_batches	ile paczek działa równolegle	1

Dokumentacja nie zaleca podkręcania tych wartości na start. Przy dużej kolejce lepszy jest WP-CLI, bo nie podlega limitom czasu żądania HTTP. Hostingi mają też własne limity czasu żądania, niezależne od ustawień PHP, więc samo podniesienie limitu w PHP często niewiele zmieni.

Action Scheduler a WP-Cron

Obie rzeczy „robią coś w tle”, ale działają zupełnie inaczej. Samo WP-Cron opisałem we wpisie czym jest CRON i do czego służy w WordPressie.

	WP-Cron	Action Scheduler
Kiedy się uruchamia	przy odwiedzinach strony, nie o konkretnej godzinie	przez WP-Cron, WP-CLI albo własny runner
Gdzie trzyma dane	jedna opcja cron w tabeli wp_options	własne tabele w bazie
Kolejka	brak, wszystko w jednej tablicy	kolejka z rezerwacją paczek
Błąd zadania	brak śladu	status failed i wpis w logu, widoczne na liście
Logi	brak	osobna tabela wp_actionscheduler_logs
Podgląd w panelu	brak (potrzebna wtyczka)	wbudowany ekran z filtrami i wyszukiwarką
Brak ruchu na stronie	nic się nie dzieje	to samo, jeśli jedynym runnerem jest WP-Cron

Ostatni wiersz jest ważny. Według FAQ Action Scheduler nie zależy od WP-Cron (actionscheduler.org/faq), ale domyślnie to WP-Cron go budzi. Sklep bez ruchu może mieć zatrzymaną kolejkę, choć sama biblioteka działa bez zarzutu.

Gdzie to zobaczyć w panelu

Ze sklepem: WooCommerce, Status, Zaplanowane działania. Bez WooCommerce, gdy Action Scheduler przyszedł z inną wtyczką: Narzędzia, Zaplanowane działania (actionscheduler.org/admin).

Ekran wygląda jak zwykła lista wpisów: na górze zakładki ze statusami i licznikami, niżej hak, grupa, argumenty i data. Statusy w kodzie nazywają się tak:

Status	Co znaczy	Czy powinien niepokoić
complete	zadanie wykonane, czeka na sprzątanie	Nie. Duża liczba to zdrowy stan
pending	czeka na swoją kolej	Nie, dopóki liczba nie rośnie z dnia na dzień
in-progress	wykonuje się teraz	Tylko gdy wisi tak od godzin. Wtedy proces przerwano w połowie
failed	nie udało się wykonać	Tak. Od tego zaczynasz diagnozę
canceled	anulowane, np. przez wtyczkę	Nie

Jest jeszcze wskaźnik zadań po terminie (past-due). Dokumentacja mówi wprost, że przez sposób działania WP-Cron pewna liczba takich akcji jest normalna. Nie ma progu, od którego liczba jest alarmem. Patrz, czy zadania po terminie przybywają z dnia na dzień, jak bardzo są spóźnione i czego dotyczą. Spóźniona faktura to inna sprawa niż spóźniony raport.

Patrz na trend, nie na liczbę. 40 000 akcji complete w dużym sklepie może być w porządku. 40 000 akcji pending, których wczoraj było 30 000, to problem.

Które wtyczki go używają

Action Scheduler nie jest częścią rdzenia WordPressa. Wtyczki dołączają go jako bibliotekę, więc na stronie może być kilka jego wersji naraz. Radzi sobie z tym sam: po załadowaniu wtyczek (hak plugins_loaded) sprawdza zarejestrowane wersje i uruchamia tylko najnowszą.

Typowe źródła zadań w sklepie:

• WooCommerce, np. webhooki, raporty Analytics i aktualizacje bazy po update.
• Subskrypcje i płatności cykliczne. Każda subskrypcja to powtarzalne zadania.
• Integracje księgowe i fakturowe, które wystawiają dokumenty w tle.
• Mailingi i automatyzacje marketingowe, które kolejkują wysyłki.
• Importy produktów, feedy i synchronizacje magazynu, które idą partiami.

Nie zgaduj, która wtyczka zapełnia kolejkę u Ciebie. Na ekranie zaplanowanych działań masz kolumnę z grupą i nazwę haka. Posortuj listę, znajdź hak, który powtarza się najczęściej, a przedrostek jego nazwy zwykle wskaże wtyczkę.

Dlaczego te tabele puchną

Action Scheduler tworzy cztery tabele (z prefiksem Twojej bazy, domyślnie wp_):

• actionscheduler_actions, czyli zadania,
• actionscheduler_logs, czyli dziennik zdarzeń każdego zadania,
• actionscheduler_claims, czyli rezerwacje paczek przez runnera,
• actionscheduler_groups, czyli słownik grup.

Rosną dwie pierwsze. Jedno zadanie to jeden wiersz w actions i kilka wierszy w logs (utworzenie, start, zakończenie, ewentualny błąd). Prosty rachunek: sklep, który planuje tysiąc zadań dziennie, bez sprzątania miałby po roku 365 000 wierszy w jednej tabeli i kilka razy więcej w drugiej.

Dopóki sprzątanie nadąża, jest spokój. Przestaje nadążać, gdy kolejka nie jest regularnie uruchamiana, bo sprzątaniem też zajmuje się Action Scheduler. Kolejka stoi, sprzątanie stoi, tabele rosną.

Jak sprawdzić rozmiar

Najszybciej zapytaniem SQL w phpMyAdmin albo Adminerze. To zapytanie tylko czyta dane:

SELECT
    TABLE_NAME AS `tabela`,
    TABLE_ROWS AS `wierszy`,
    ROUND( ( DATA_LENGTH + INDEX_LENGTH ) / 1024 / 1024, 2 ) AS `rozmiar_MB`
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME LIKE '%actionscheduler%'
ORDER BY ( DATA_LENGTH + INDEX_LENGTH ) DESC;

W InnoDB kolumna TABLE_ROWS to szacunek, nie dokładna liczba wierszy. Do porównań w czasie wystarczy, a dokładną liczbę da SELECT COUNT(*).

Rozbicie na statusy pokazuje, gdzie leży problem (podmień wp_ na prefiks swojej bazy):

SELECT status, COUNT(*) AS ile
FROM wp_actionscheduler_actions
GROUP BY status
ORDER BY ile DESC;

Przez WP-CLI zrobisz to bez logowania do phpMyAdmina:

wp action-scheduler status

Co jest normą, a co sygnałem ostrzegawczym

Nie ma jednej liczby granicznej. Zależy od liczby zamówień i od tego, ile wtyczek dokłada swoje zadania. Pomagają sygnały jakościowe:

• Norma: przewaga statusu complete, wpisy complete nie starsze niż ok. miesiąc, failed blisko zera, tabela logs kilka razy większa od actions.
• Do sprawdzenia: wpisy complete wyraźnie starsze niż miesiąc (sprzątanie nie działa), rosnąca kolejka pending, in-progress wiszące od wczoraj.
• Alarm: setki tysięcy wierszy przy niewielkiej liczbie zamówień, tabela logs większa niż cała reszta bazy, tysiące wpisów failed.

Pierwszy objaw, który zwykle zauważa właściciel, to wolny panel przy normalnie działającym froncie. Jeśli wolny jest sam front, przyczyny szukaj gdzie indziej, np. w poradniku o tym, jak przyspieszyć stronę na WordPressie.

Sprzątanie, czyli jak to robić dobrze

Jeśli porządkujesz całą bazę, a nie tylko kolejkę, zacznij od wpisu o optymalizacji bazy danych WordPress. Tu skupiam się tylko na Action Schedulerze.

Co Action Scheduler robi sam

Wbudowany mechanizm usuwa akcje starsze niż 31 dni. Tyle wynosi domyślna wartość w kodzie klasy ActionScheduler_QueueCleaner (2678400 sekund). Domyślnie usuwane są statusy complete i canceled.

Wersja 4.0.0 trafiła do katalogu WordPress.org 17 czerwca 2026 i została zapowiedziana jako część WooCommerce 11.0. Wprowadziła trzy zmiany (blog deweloperski WooCommerce):

1. Nieudane akcje też są usuwane, domyślnie po 3 miesiącach. Wcześniej zostawały w bazie bez końca.
2. Sprzątanie działa jako osobne zadanie, raz dziennie o 3 w nocy czasu strony, w paczkach po co najmniej 250 wierszy, aż do nadrobienia zaległości. Wcześniej doklejało się w małych porcjach do każdej paczki kolejki.
3. Zmieniła się reguła unikalności. Gdy wtyczka planuje akcję z flagą „unikalna”, wcześniej porównywano tylko hak i grupę. Od 4.0.0 liczą się też argumenty, więc akcji może powstawać więcej niż przedtem.

Jest jeszcze jeden bezpiecznik z kodu: jeśli akcja cykliczna kilka razy z rzędu kończy się błędem (domyślnie 5), Action Scheduler przestaje planować jej kolejne wystąpienia. Dlatego zakładkę z nieudanymi akcjami warto przeglądać regularnie.

Filtry, którymi to zmienisz

Dodajesz je we wtyczce funkcyjnej albo w functions.php motywu potomnego. Nie w plikach Action Schedulera, bo przy pierwszej aktualizacji zmiana zniknie.

// Krocej trzymamy akcje zakonczone i anulowane: 7 dni zamiast domyslnych 31.
add_filter( 'action_scheduler_retention_period', function () {
	return 7 * DAY_IN_SECONDS;
} );

// Nieudane akcje trzymamy rok zamiast domyslnych 3 miesiecy.
add_filter( 'action_scheduler_retention_period_for_failed', function () {
	return YEAR_IN_SECONDS;
} );

// Albo wcale nie usuwamy nieudanych akcji, czyli zachowanie sprzed 4.0.0.
add_filter( 'action_scheduler_enable_failed_action_cleanup', '__return_false' );

// Wieksze paczki przy codziennym sprzataniu, gdy zaleglosci sa duze.
// Po nadrobieniu wroc do wartosci domyslnej.
add_filter( 'action_scheduler_cleanup_batch_size', function () {
	return 500;
} );

Jest jeszcze filtr action_scheduler_default_cleaner_statuses, który zmienia listę sprzątanych statusów. Nie ruszaj go, jeśli nie wiesz dokładnie, po co to robisz.

Nadrabianie zaległości przez WP-CLI

Przy dużej zaległości klikanie w panelu nie ma sensu. Z SSH, po kopii bazy:

# Ile czego jest
wp action-scheduler status

# Usun zakonczone i anulowane starsze niz 30 dni, paczkami po 200
wp action-scheduler clean --status=canceled,complete --before='30 days ago' --batch-size=200

# Uruchom zalegla kolejke recznie, bez czekania na WP-Cron
wp action-scheduler run --batch-size=50

Domyślne wartości komendy clean to paczka 20 akcji na status i próg 31 dni, a run domyślnie bierze paczki po 100 (dokumentacja WP-CLI Action Schedulera). Pełną listę opcji zobaczysz po wpisaniu wp action-scheduler --help.

Rób to poza godzinami szczytu. Usuwanie setek tysięcy wierszy potrafi na chwilę spowolnić sklep.

Istnieją też wtyczki do czyszczenia bazy (np. WP-Optimize, Advanced Database Cleaner) i wtyczki przeznaczone tylko do Action Schedulera. Zanim którejś użyjesz, sprawdź, czy nie usuwa akcji pending, bo to zatrzyma zadania cykliczne. Żadna z nich nie naprawi też kolejki, która się nie uruchamia. Nie zmieniaj też silnika tych tabel na MyISAM, jak radzą niektóre poradniki. To nie usuwa przyczyny, a MyISAM nie ma transakcji ani blokad na poziomie wiersza, które ma InnoDB.

Dlaczego nie TRUNCATE

Rada „wyczyść tabele Action Schedulera przez TRUNCATE” krąży po forach i grupach. Jest szybka, wygląda niewinnie i potrafi zatrzymać sklep bez jednego komunikatu o błędzie.

Powód jest w działaniu akcji cyklicznych. Zadanie powtarzalne planuje swoje kolejne wystąpienie dopiero w momencie wykonania. W tabeli nie leży sto przyszłych kopii, tylko jedna, następna w kolejce. Czyszcząc tabelę, usuwasz jedyny ślad tego, że zadanie ma się jeszcze wykonać.

Co się dzieje potem:

• Zadania cykliczne nie wracają. Synchronizacje, przypomnienia i raporty po prostu przestają działać.
• Akcje pending znikają razem z resztą. Rzeczy czekające na wykonanie, np. wystawienie dokumentu, nie wykonają się.
• Akcje in-progress znikają w trakcie pracy.
• Nic o tym nie informuje. Panel wygląda zdrowo, sklep przyjmuje zamówienia, a integracje po cichu stoją.

Jak odtworzyć zadania, zależy od wtyczki, która je planowała. Jedynym pewnym ratunkiem jest kopia bazy sprzed czyszczenia.

Ręcznego DELETE w SQL też nie polecam. Usuwając wiersze z actions bezpośrednio w bazie, zostawiasz ich wpisy w logs, a komenda wp action-scheduler clean i wbudowane sprzątanie usuwają akcje przez mechanizm Action Schedulera. Jeśli chcesz najpierw zobaczyć skalę, policz wiersze zapytaniem tylko do odczytu:

SELECT COUNT(*) AS do_usuniecia
FROM wp_actionscheduler_actions
WHERE status = 'complete'
  AND scheduled_date_gmt < DATE_SUB( UTC_TIMESTAMP(), INTERVAL 30 DAY );

Zadania, które się nie wykonują

To drugi częsty problem po rosnących tabelach. Kolejka rośnie, a nic z niej nie schodzi.

Przyczyna	Objaw	Co zrobić
WP-Cron wyłączony bez zastępstwa	wszystko stoi w pending, licznik zadań po terminie rośnie	dodaj zadanie w cronie systemowym (niżej)
Brak ruchu na stronie	kolejka rusza skokami, po wizytach	to samo, cron systemowy
Limit czasu PHP przy ciężkiej akcji	pojedyncze zadania wiszą w in-progress	sprawdź max_execution_time, uruchom kolejkę przez WP-CLI
Za mały limit pamięci	fatal error w logach, kolejka staje w tym samym miejscu	podnieś limit i szukaj winowajcy (następna sekcja)
Blokada ActionScheduler_Lock	licznik stoi, w logach cisza	odczekaj minutę, blokada wygasa sama, potem szukaj dalej
Cache strony obejmuje wp-cron.php	WP-Cron dostaje odpowiedź z cache i nic się nie wykonuje	wyklucz wp-cron.php z cache i optymalizacji
Wtyczka bezpieczeństwa blokuje loopback	pierwsza paczka schodzi, kolejne nie	dopuść żądania serwera do samego siebie
Blokada wp-cron.php na serwerze	to samo, plus błąd 403 w logach serwera	zdejmij regułę albo przejdź w całości na cron systemowy

Słowo o blokadzie. ActionScheduler_Lock chroni przed sytuacją, w której dwa procesy biorą się za tę samą pracę. Domyślnie trzyma 60 sekund i wygasa sama, a jej czas zmienisz filtrem action_scheduler_lock_duration. Blokada nie jest więc przyczyną zatrzymanej kolejki. Jeśli kolejka stoi dłużej, coś przerywa proces, zanim ten skończy pracę.

Przy multisite pamiętaj, że Action Scheduler obsługuje akcje pojedynczej witryny. Według FAQ nie ma specjalnej obsługi kolejek w całej sieci.

Błąd pamięci wskazujący na plik Action Schedulera

Czasem w komunikacie fatal error o wyczerpaniu pamięci pojawia się ścieżka do pliku z katalogu Action Schedulera, np. ActionScheduler_Lock.php. Naturalny odruch to obwinić Action Scheduler. Zwykle to nie jego wina.

Nazwa pliku mówi, gdzie skrypt się zatrzymał, a nie kto zużył pamięć. Rozróżnij dwa przypadki:

Za mały limit pamięci, gdy kolejka jest krótka, a błąd pojawia się od razu po wejściu na ekran zaplanowanych działań albo przy zwykłym żądaniu. Wtedy podnosisz limit, np. w pliku wp-config.php, jeśli hosting na to pozwala.

Zapchana kolejka albo ciężka akcja, gdy limit jest już wysoki, a błąd wraca. Wtedy podnoszenie limitu tylko przesuwa moment awarii. Sprawdź, ile jest akcji pending, która wtyczka je planuje i czy ich liczba rośnie.

Runner ma własny bezpiecznik: kończy paczkę po zużyciu 90 procent pamięci. Jeśli mimo tego dostajesz fatal error, pojedyncza akcja zużywa pamięć skokowo. To już sprawa dla autora wtyczki, która ją planuje.

Kiedy przejść na cron systemowy

WP-Cron nie jest prawdziwym cronem. Nie uruchamia się o wyznaczonej godzinie, tylko przy odwiedzinach strony. Sklep bez ruchu w nocy ma w nocy zatrzymaną kolejkę.

Przejdź na cron systemowy, gdy:

• kolejka regularnie zbiera zaległości,
• sklep ma mały ruch, a zadania mają się wykonywać o stałych porach,
• masz zadania wrażliwe na czas, np. faktury, przypomnienia o płatności, synchronizację magazynu.

Krok pierwszy, w wp-config.php nad linią „That’s all, stop editing”:

// Wylaczamy uruchamianie WP-Cron przy odwiedzinach strony.
define( 'DISABLE_WP_CRON', true );

Krok drugi, wpis w crontabie. Wariant przez WP-CLI, jeśli masz SSH. Nie podlega limitom żądania HTTP:

*/5 * * * * cd /sciezka/do/wordpressa && wp cron event run --due-now >/dev/null 2>&1

Na początek uruchom tę komendę raz ręcznie, bez >/dev/null, żeby zobaczyć ewentualne błędy. Wyciszenie dodaj dopiero, gdy działa.

Wariant przez HTTP, gdy nie masz WP-CLI. Dokumentacja WordPressa podaje wywołanie przez wget z opcją --delete-after, żeby nie zapisywać odpowiedzi na dysku (dokumentacja WordPress):

*/5 * * * * wget -q --delete-after https://twojsklep.pl/wp-cron.php

Dokumentacja pokazuje przykład raz dziennie, ale dla sklepu to za rzadko. Co pięć minut to rozsądny start. Co minutę ma sens tylko przy zadaniach naprawdę wrażliwych na czas.

Częsty błąd: ustawienie DISABLE_WP_CRON bez wpisu w crontabie. Jeśli kolejki nie uruchamia nic innego (WP-CLI, zewnętrzny runner), zadania przestają się wykonywać. Po zmianie odczekaj kwadrans i sprawdź, czy zadania po terminie znikają z listy.

Diagnoza w 15 minut

Kolejność ma znaczenie. Idź od góry.

1. Minuty 1 do 3. Wejdź w WooCommerce, Status, Zaplanowane działania. Zapisz liczby przy statusach oczekujących, nieudanych i w trakcie (w polskim panelu: Oczekujące, Niepowodzenie, W toku). To Twój punkt odniesienia.
2. Minuty 3 do 5. Otwórz zakładkę z nieudanymi akcjami (Niepowodzenie). Zobacz, które haki i grupy powtarzają się najczęściej. Jedna wtyczka odpowiedzialna za większość błędów to gotowa diagnoza.
3. Minuty 5 do 7. Sprawdź akcje w trakcie. Jeśli coś wisi tam dłużej niż godzinę, zostało przerwane. Zapisz hak.
4. Minuty 7 do 9. Uruchom zapytanie SQL o rozmiar tabel. Zapisz liczbę wierszy i rozmiar.
5. Minuty 9 do 11. Sprawdź, czy kolejka w ogóle pracuje. Sam licznik oczekujących niewiele mówi, bo mogą to być zadania zaplanowane na później albo napływ równy wykonaniu. Spisz ID i daty dwóch, trzech zadań po terminie i sprawdź po kilku minutach, czy zmieniły status. Jeśli nadal czekają, porównaj je z resztą kolejki. Gdy inne zadania też stoją i w logach akcji nic nowego się nie pojawia, najbardziej prawdopodobne jest to, że kolejki nic nie uruchamia. Gdy inne zadania się wykonują, a te nie, sprawdź ich priorytet i grupę oraz to, czy nie są zarezerwowane przez przerwany proces (kolumna claim_id w tabeli akcji).
6. Minuty 11 do 13. Sprawdź, czy w wp-config.php jest DISABLE_WP_CRON, a jeśli tak, czy istnieje wpis w crontabie. Przy okazji zobacz limit pamięci w Narzędzia, Stan witryny, Informacje, Serwer.
7. Minuty 13 do 15. Zajrzyj do pliku wp-content/debug.log z ostatniej doby, jeśli logowanie jest włączone. Szukaj powtarzającej się ścieżki do jednej wtyczki. Jak włączyć log, opisałem w poradniku o trybie debugowania WordPressa.

Po tych piętnastu minutach wiesz zwykle jedną z trzech rzeczy: kolejka nie jest uruchamiana, konkretna wtyczka psuje swoje zadania albo tabele nigdy nie były sprzątane. Każdy z tych przypadków ma rozwiązanie opisane wyżej.

Jak my z tym pracujemy

Przegląd bazy danych to u nas stały punkt opieki nad stroną. Najczęściej robimy go z wtyczką Query Monitor i często z własnym kodem, a ekran zaplanowanych działań to jedno z miejsc, które przy tym oglądamy.

Gdy strona zwalnia, a nic się nie wywala, nie zaczynamy od debug logu. Sięgamy po Query Monitor i przechodzimy stronę po stronie, bo winowajcą bywa baza danych albo kod. W sklepie WooCommerce szukamy powolnych zapytań przede wszystkim na stronach koszyka i zamówienia oraz przy dodawaniu produktu do koszyka, bo tam nie działa cache strony.

Na sklepie z ruchem nie wyłączamy wtyczek na produkcji, żeby znaleźć winowajcę. Raczej odtwarzamy problem na kopii sklepu. Po każdej zmianie ręcznie klikamy kluczowe akcje: dodanie do koszyka, koszyk, usunięcie produktu, formularz ze sprawdzeniem, czy dane doszły, i złożenie zamówienia. Każdą jako zalogowany, niezalogowany i w oknie incognito.

Kiedy to nie wystarczy: jeśli wolny jest sam front, a nie panel, porządki w kolejce niewiele zmienią. Wtyczki cache też nie przyspieszą kolejki, bo działają na froncie, a kolejka to baza danych i PHP. Gdy problemem jest serwer albo sposób zbudowania strony, zaczynamy od nich.

Podsumowanie

Action Scheduler to jeden z tych elementów WooCommerce, o których nikt nie myśli, dopóki działają. Zapamiętaj cztery rzeczy:

1. To pełna kolejka zadań z własnymi tabelami, statusami i logami, a nie kolejny WP-Cron.
2. Tabele rosną z definicji, a wbudowane sprzątanie działa tylko wtedy, gdy kolejka jest regularnie uruchamiana.
3. TRUNCATE na tych tabelach to nie sprzątanie, tylko cicha awaria z opóźnieniem.
4. Gdy zadania nie schodzą, zacznij od pytania, czy kolejka w ogóle jest uruchamiana, a dopiero potem podnoś limity.

Krótki rzut oka na ekran zaplanowanych działań przy każdym przeglądzie sklepu wystarczy, żeby trzymać to w ryzach. Jeśli nie chcesz tego pilnować sam, przegląd bazy i kolejki robimy w ramach opieki nad stroną WordPress.

Najczęstsze pytania