Konfiguracja zadań CRON w PrestaShop – najlepsze praktyki

Aktualizacja stanów magazynowych, wymiana danych z ERP, generowanie plików produktowych, wysyłka newsletterów, pobieranie statusów przesyłek… W takich zadaniach przydaje się CRON, czyli mechanizm uruchamiający określone polecenia według ustalonego harmonogramu.

Nieprawidłowo skonfigurowany CRON może jednak uruchamiać ten sam proces kilka razy, blokować kolejne zadania, przeciążać bazę danych albo przez wiele dni nie realizować ważnej synchronizacji. W tym poradniku zobaczysz, jak dobrać metodę uruchamiania zadań w PrestaShop, ustawić bezpieczny harmonogram, rejestrować błędy i kontrolować, czy automatyzacja rzeczywiście działa.

Przykłady możesz dostosować zarówno do zadań dostarczonych przez moduły, jak i własnych integracji. Pamiętaj tylko, że dokładna komenda, adres URL oraz zalecana częstotliwość powinny pochodzić z dokumentacji używanego modułu.

Czym jest CRON i za co odpowiada w PrestaShop?

CRON jest usługą systemową, która uruchamia polecenia automatycznie o wybranej porze lub w określonych odstępach czasu. Sam PrestaShop nie potrzebuje jednego uniwersalnego zadania CRON do wyświetlania produktów i przyjmowania zamówień. Harmonogramu wymagają przede wszystkim konkretne moduły, integracje i procesy administracyjne.

W sklepie internetowym CRON może odpowiadać między innymi za:

• synchronizację produktów, cen i stanów magazynowych z systemem ERP lub hurtownią,
• eksport ofert do porównywarek cenowych i marketplace’ów,
• import zamówień i aktualizację ich statusów,
• przekazywanie danych do systemów księgowych, kurierskich lub marketing automation,
• generowanie plików XML, CSV i raportów,
• obsługę kolejek wiadomości oraz opóźnionych operacji,
• czyszczenie danych tymczasowych lub starych logów,
• przebudowę indeksu wyszukiwarki sklepu, jeśli dany moduł udostępnia taką funkcję,
• wykonywanie czynności konserwacyjnych wskazanych przez twórcę modułu.

CRON jest szczególnie ważny przy integracjach. Gdy zadanie przestaje działać, panel administracyjny PrestaShop może nadal wyglądać poprawnie, ale w tle narastają zaległości. Produkty pozostają ze starymi cenami, zamówienia nie trafiają do ERP, a klienci otrzymują nieaktualne informacje o dostępności. Więcej możliwych przyczyn takich problemów znajdziesz w poradniku jak naprawić synchronizację zamówień w PrestaShop.

Warto wiedzieć. Harmonogram CRON informuje serwer, kiedy ma uruchomić proces. Nie gwarantuje, że sam skrypt zakończy się powodzeniem. Dlatego obok konfiguracji czasu potrzebujesz logów, kodów zakończenia, blokady równoległych uruchomień i kontroli wyniku.

Uruchamianie przez CLI czy adres URL?

Moduły PrestaShop mogą udostępniać zadania w kilku formach. Najczęściej spotkasz komendę uruchamianą w terminalu, bezpośredni skrypt PHP albo zabezpieczony adres URL. Wybór metody wpływa na bezpieczeństwo, stabilność i możliwość diagnozowania błędów.

Komenda CLI

Jeżeli moduł udostępnia polecenie konsolowe, zazwyczaj warto wybrać właśnie ten wariant. Zadanie działa wtedy bez pośrednictwa serwera HTTP, nie jest narażone na limit czasu przeglądarki, łatwiej przechwycić jego kod zakończenia i nie trzeba publikować technicznego endpointu w internecie.

PrestaShop korzysta z komponentu Symfony Console. Dostępne polecenia możesz wyświetlić z katalogu głównego sklepu:

cd /pelna/sciezka/do/prestashop
/usr/local/bin/php bin/console list

Pomoc dla konkretnej komendy sprawdzisz przez:

/usr/local/bin/php bin/console nazwa:komendy --help

Oficjalna dokumentacja konsoli PrestaShop wskazuje zadania CRON jako jedno z typowych zastosowań komend CLI. Moduły mogą również rejestrować własne polecenia, dlatego ich dokładne nazwy zależą od zainstalowanych rozszerzeń.

Przykładowy wpis uruchamiający komendę modułu co 15 minut może wyglądać tak:

7,22,37,52 * * * * cd /home/uzytkownik/domains/sklep.pl/public_html && /usr/local/bin/php bin/console vendor:module:sync --env=prod >> var/log/cron-sync.log 2>&1

Minuty są celowo przesunięte względem pełnego kwadransa. Dzięki temu proces nie startuje dokładnie o 00, 15, 30 i 45 minucie, kiedy wiele innych sklepów i usług może rozpoczynać własne zadania.

Bezpośredni skrypt PHP

Starsze moduły mogą wymagać wywołania konkretnego pliku PHP. Użyj wówczas pełnej ścieżki do interpretera PHP oraz pełnej ścieżki do skryptu:

13 * * * * /usr/local/bin/php /home/uzytkownik/domains/sklep.pl/public_html/modules/nazwamodulu/cron.php >> /home/uzytkownik/logs/nazwamodulu-cron.log 2>&1

Nie zakładaj, że polecenie php uruchomi tę samą wersję, z której korzysta sklep. W środowisku WWW i w terminalu mogą być aktywne inne interpretery oraz inne pliki php.ini. Przed dodaniem zadania sprawdź:

/usr/local/bin/php -v
/usr/local/bin/php --ini

Wywołanie przez URL

Niektóre moduły podają jedynie adres URL, na przykład z indywidualnym tokenem. Zadanie można wtedy wywołać za pomocą curl:

19,34,49,4 * * * * /usr/bin/curl --fail --silent --show-error --max-time 300 "https://sklep.pl/module/nazwamodulu/cron?token=DLUGI_LOSOWY_TOKEN" >> /home/uzytkownik/logs/nazwamodulu-url.log 2>&1

Parametr --fail sprawia, że odpowiedzi HTTP wskazujące błąd nie zostaną potraktowane jak poprawne wykonanie. --show-error zachowuje komunikat błędu, a --max-time ogranicza maksymalny czas połączenia.

Uwaga. Token w adresie URL jest sekretem. Nie umieszczaj go w publicznej dokumentacji, zgłoszeniu z pełnym zrzutem ekranu ani repozytorium. Sprawdź również, czy nie trafia do ogólnodostępnych logów analitycznych, historii przeglądarki lub systemu monitoringu.

Jeżeli tworzysz własny moduł, w aktualnych wersjach PrestaShop preferowane są polecenia konsolowe. Oficjalna dokumentacja opisuje zarówno tworzenie komend modułu, jak i użycie kontrolera modułu jako zadania CRON w rozwiązaniach wymagających zgodności ze starszymi wersjami.

Jak ustawić harmonogram bez przeciążania sklepu?

Klasyczny harmonogram CRON składa się z pięciu pól określających minutę, godzinę, dzień miesiąca, miesiąc i dzień tygodnia. Po nich znajduje się komenda:

minuta godzina dzien-miesiaca miesiac dzien-tygodnia polecenie

Najczęściej używane przykłady:

Nie ustawiaj częstotliwości na podstawie zasady „im częściej, tym lepiej”. Najpierw określ, jak szybko dane muszą się zmienić z perspektywy klienta i biznesu.

• Zamówienia i rezerwacje stanów zwykle wymagają krótkiego interwału, na przykład od jednej do kilku minut.
• Ceny i stany magazynowe mogą wymagać synchronizacji co kilka lub kilkanaście minut, zależnie od liczby kanałów sprzedaży.
• Pełne pliki produktowe często wystarczy generować co godzinę lub kilka razy dziennie.
• Raporty, czyszczenie logów i ciężkie operacje konserwacyjne najlepiej uruchamiać nocą.

Sprawdź też czas trwania procesu. Jeżeli synchronizacja uruchamia się co pięć minut, ale czasami działa osiem minut, kolejne wykonanie może rozpocząć się przed zakończeniem poprzedniego. To częsta przyczyna duplikatów, blokad bazy i nieprzewidywalnych wyników.

Dobra praktyka. Rozłóż zadania na różne minuty. Zamiast uruchamiać pięć procesów o pełnej godzinie, ustaw je na przykład na 03, 11, 19, 27 i 41 minutę. Takie przesunięcie zmniejsza chwilowe zużycie procesora, pamięci, dysku i połączeń z bazą danych. Podobne zalecenia dotyczące rozdzielania czasu wykonania znajdziesz w instrukcji konfiguracji zadań CRON w panelu cyber_Folks.

Uwzględnij strefę czasową serwera. Godzina widoczna w panelu hostingu nie zawsze musi odpowiadać strefie ustawionej w PrestaShop, module lub zewnętrznym ERP. Przy operacjach zależnych od konkretnej pory wykonaj test i zapisz w logu zarówno datę rozpoczęcia, jak i używaną strefę czasową.

Jak zbudować bezpieczną komendę CRON?

Poprawna komenda powinna być jednoznaczna, odporna na równoległe uruchomienie i pozostawiać ślad diagnostyczny. Samo wpisanie ścieżki do pliku PHP zazwyczaj nie wystarcza.

Używaj pełnych ścieżek

Środowisko CRON ma ograniczone zmienne systemowe i może nie znać katalogów dostępnych w Twojej sesji SSH. Dlatego podawaj pełne ścieżki do PHP, katalogu sklepu, skryptu oraz pliku logu.

cd /home/uzytkownik/domains/sklep.pl/public_html && /usr/local/bin/php bin/console vendor:module:sync

Operator && jest istotny. Drugie polecenie uruchomi się tylko wtedy, gdy zmiana katalogu zakończy się powodzeniem. Bez tego komenda mogłaby wystartować w niewłaściwym miejscu.

Blokuj równoległe uruchomienia

Jeżeli aplikacja sama nie stosuje blokady, możesz wykorzystać systemowe narzędzie flock, o ile jest dostępne na serwerze:

*/5 * * * * /usr/bin/flock -n /tmp/prestashop-orders.lock -c 'cd /home/uzytkownik/domains/sklep.pl/public_html && /usr/local/bin/php bin/console vendor:orders:sync --env=prod' >> /home/uzytkownik/logs/orders-cron.log 2>&1

Opcja -n oznacza, że nowe wykonanie nie będzie czekało na zwolnienie blokady. Gdy poprzedni proces nadal działa, kolejne uruchomienie zostanie pominięte. To bezpieczniejsze niż jednoczesne przetwarzanie tych samych rekordów, ale pominięcia również powinny być monitorowane.

Najlepszym rozwiązaniem jest blokada zaimplementowana w samym module. Może ona rozpoznawać martwy proces, zapisywać identyfikator wykonania, kontrolować czas blokady i bezpiecznie wznawiać pracę po awarii.

Ustaw rozsądny limit czasu

Zawieszony proces może zajmować zasoby przez wiele godzin. Jeżeli serwer udostępnia polecenie timeout, ogranicz maksymalny czas wykonania:

*/10 * * * * /usr/bin/timeout 8m /usr/bin/flock -n /tmp/prestashop-stock.lock -c 'cd /home/uzytkownik/domains/sklep.pl/public_html && /usr/local/bin/php bin/console vendor:stock:sync --env=prod' >> /home/uzytkownik/logs/stock-cron.log 2>&1

Limit musi uwzględniać normalny czas działania oraz okresowe wzrosty liczby danych. Zbyt krótki będzie przerywał poprawne synchronizacje, a zbyt długi opóźni wykrycie awarii.

Nie wyłączaj logów za wcześnie

Popularne przekierowanie >/dev/null 2>&1 usuwa zarówno zwykły wynik, jak i błędy. Ogranicza liczbę wiadomości, ale w razie awarii pozbawia Cię najważniejszych informacji. Na etapie wdrożenia zapisuj pełne dane do pliku:

>> /home/uzytkownik/logs/prestashop-cron.log 2>&1

Po ustabilizowaniu procesu możesz ograniczyć szczegółowość, ale nadal zapisuj co najmniej godzinę rozpoczęcia, wynik, czas wykonania, liczbę przetworzonych elementów oraz komunikat błędu. Zadbaj również o rotację logów, żeby pliki nie rosły bez końca.

Jak przetestować i monitorować zadania?

Zanim włączysz automatyczne wykonanie, uruchom polecenie ręcznie przez SSH. Dzięki temu od razu zobaczysz błędy składni, brak dostępu do plików, niewłaściwą wersję PHP lub problem z konfiguracją modułu.

Praktyczna procedura testowa wygląda następująco:

1. Wykonaj kopię zapasową plików i bazy danych, szczególnie przed pierwszym uruchomieniem importu lub masowej aktualizacji.
2. Uruchom dokładnie tę samą komendę, która ma trafić do CRON-a.
3. Sprawdź kod zakończenia poleceniem echo $?. Wartość 0 zwykle oznacza sukces, ale ostateczna interpretacja zależy od skryptu.
4. Zweryfikuj dane biznesowe. Sprawdź kilka produktów, zamówień lub rekordów w obu połączonych systemach.
5. Uruchom zadanie ponownie i zobacz, czy nie tworzy duplikatów.
6. Zasymuluj bezpieczny błąd, na przykład na środowisku testowym, aby upewnić się, że log i alert rzeczywiście go rejestrują.
7. Dopiero po udanym teście dodaj harmonogram produkcyjny.

Po wdrożeniu nie ograniczaj monitoringu do pytania, czy proces został uruchomiony. Kontroluj trzy osobne warstwy:

• Uruchomienie – czy CRON wystartował o zaplanowanej porze?
• Wykonanie techniczne – czy proces zakończył się bez błędu i w akceptowalnym czasie?
• Rezultat biznesowy – czy rzeczywiście przesłano zamówienia, zaktualizowano produkty albo wygenerowano prawidłowy plik?

Proces może zwrócić odpowiedź HTTP 200 lub kod zakończenia 0, mimo że nie przetworzył żadnych danych z powodu błędnej konfiguracji. Dlatego dobry log powinien zawierać liczbę pobranych, zmienionych, pominiętych i błędnych rekordów.

Ważne zadania warto objąć mechanizmem typu heartbeat. Po udanym wykonaniu skrypt wysyła sygnał do systemu monitorującego. Brak sygnału w ustalonym czasie wywołuje alarm. Takie rozwiązanie wykrywa także sytuację, w której CRON został przypadkowo usunięty i nie powstał żaden nowy log błędu.

Jeżeli sklep działa na starszej wersji platformy, przed większymi zmianami sprawdź możliwości aktualizacji i zgodność modułów. W artykule o PrestaShop 9.1 znajdziesz omówienie zmian związanych między innymi z wydajnością, stabilnością i pracą z komendami CLI.

Najczęstsze błędy w konfiguracji CRON-a

Gdy zadanie nie działa, zacznij od prostych elementów. W praktyce wiele awarii wynika nie z samego PrestaShop, lecz z nieaktualnej ścieżki, błędnego tokenu albo różnicy między środowiskiem WWW i CLI.

Inna wersja PHP niż w sklepie

Sklep może działać na PHP skonfigurowanym dla domeny, podczas gdy polecenie php w CRON-ie wskazuje domyślną wersję systemową. Objawem bywają błędy składni, brak rozszerzeń, problemy z IonCube albo inne limity pamięci. Wpisz pełną, zweryfikowaną ścieżkę do interpretera.

Nieaktualna ścieżka lub domena

Po migracji sklepu, zmianie domeny, przeniesieniu katalogu albo utworzeniu nowego środowiska dotychczasowy CRON może nadal odwoływać się do starej lokalizacji. Sprawdź każdy wpis po migracji i usuń zadania prowadzące do poprzedniego serwera lub środowiska testowego.

Nieprawidłowy lub ujawniony token

Aktualizacja albo ponowna konfiguracja modułu może wygenerować nowy token. Stary URL przestaje wówczas działać. Jeśli token został ujawniony, zmień go i zaktualizuj harmonogram. Nie rozwiązuj problemu przez usunięcie zabezpieczenia endpointu.

Brak uprawnień do plików i katalogów

Użytkownik uruchamiający CRON musi mieć dostęp do skryptu, katalogu sklepu, plików cache oraz miejsca zapisu logów. Nie nadawaj jednak globalnych praw zapisu w rodzaju 777. Popraw właściciela, grupę i minimalne wymagane uprawnienia.

Zbyt częsty harmonogram

Proces uruchamiany co minutę może być zbędny, szczególnie gdy za każdym razem skanuje cały katalog produktów lub wykonuje ciężkie zapytania. Zmierz czas wykonania i liczbę przetwarzanych rekordów, a potem ustaw częstotliwość odpowiadającą realnej potrzebie.

Duplikaty zadań

Ten sam proces może być zapisany w panelu hostingu, systemowym crontabie i zewnętrznym planerze jednocześnie. Przejrzyj wszystkie źródła automatyzacji. Dwa niezależne wywołania tej samej synchronizacji mogą prowadzić do podwójnej wysyłki, konfliktów blokad lub wielokrotnej zmiany statusu.

Brak kopii przed zmianami

Importy i masowe synchronizacje mogą zmodyfikować tysiące rekordów w kilka minut. Przed wdrożeniem nowego zadania, zmianą parametrów albo pierwszym pełnym wykonaniem utwórz kopię plików i bazy. Praktyczne zasady znajdziesz w artykule o samodzielnym wykonywaniu kopii bezpieczeństwa.

Stabilny CRON to kontrolowany proces

Dobra konfiguracja CRON-a w PrestaShop nie kończy się na wskazaniu godziny. Zacznij od metody zalecanej przez autora modułu, wybierz CLI, gdy rozszerzenie je udostępnia, zastosuj pełne ścieżki i uruchamiaj proces z właściwą wersją PHP. Następnie rozłóż zadania w czasie, zabezpiecz je przed równoległym wykonaniem i zapisuj przydatne logi.

Najważniejsza jest weryfikacja rezultatu. Automatyzacja ma nie tylko wystartować, lecz także poprawnie przesłać zamówienia, zaktualizować stany albo wygenerować kompletny plik. Połącz logi techniczne z alertem o braku wykonania oraz kontrolą danych biznesowych. Wtedy błąd wykryjesz po kilku minutach, a nie po zgłoszeniu niezadowolonego klienta.

Jeżeli Twój sklep obsługuje wiele integracji, duży katalog i częste synchronizacje, zadbaj o wydajny hosting. Dobre środowisko serwerowe daje zadaniom odpowiednie zaplecze, a przemyślany harmonogram pozwala wykorzystać jego zasoby bez niepotrzebnych skoków obciążenia.