W wielu sklepach PrestaShop część zadań powinna działać w tle, bez klikania w panelu. Dotyczy to wysyłki maili, generowania feedów do porównywarek, synchronizacji stanów magazynowych, a także prac porządkowych, które odciążają sklep w ciągu dnia. Gdy te zadania odpalają się przypadkowo, na przykład dopiero po wejściu klienta na stronę, efekty bywają słabe: opóźnione maile, nieaktualne stany i skoki obciążenia.
Cron rozwiązuje ten problem, bo uruchamia skrypt o określonej godzinie lub co kilka minut. Dzięki temu sklep nie musi czekać na ruch, a zadania działają regularnie i przewidywalnie. To jest szczególnie ważne w integracjach, gdzie opóźnienie kilkunastu minut potrafi oznaczać sprzedaż produktu, którego już nie ma, albo brak zamówień, bo feed nie odświeżył się na czas.
W PrestaShop cron występuje w kilku wariantach. Czasem to moduł daje adres URL, który trzeba wywołać cyklicznie. Czasem jest to komenda uruchamiana z poziomu serwera, czyli klasyczny cron w systemie Linux. Zdarza się też, że hosting oferuje panel do ustawiania zadań, ale z ograniczeniami, które trzeba znać, aby nie doprowadzić do przeciążenia.
W tym artykule pokażę Ci prostą ścieżkę: jak rozpoznać, co dokładnie masz uruchamiać, jak ustawić harmonogram pod realne potrzeby sklepu i jak sprawdzić, czy zadania działają. Dostaniesz też listę błędów, które najczęściej psują cron w PrestaShop, oraz sposoby naprawy bez zgadywania.
Jeśli przy okazji widzisz, że sklep zwalnia w momentach synchronizacji lub generowania feedów, może to być kwestia zasobów hostingu. Wtedy przyda się kontekst z artykułu PrestaShop: hosting współdzielony vs hosting VPS oraz tekst o limitach hostingu, bo zadania w tle potrafią szybko ujawnić ograniczenia CPU i I/O.
Co w PrestaShop powinno działać przez cron i dlaczego
Cron ma sens tam, gdzie zadanie powinno wykonać się regularnie, niezależnie od tego, czy sklep ma aktualnie ruch. Typowy przykład to synchronizacja z hurtownią lub ERP, bo stany magazynowe i ceny muszą być aktualne nawet wtedy, gdy nikt nie wchodzi na stronę. Podobnie jest z feedami do porównywarek, które mają swoje okna aktualizacji i nie będą czekać na Twojego klienta.
Drugą grupą zadań są wysyłki i komunikacja. Część modułów do mailingu lub powiadomień działa na kolejce, którą trzeba cyklicznie opróżniać. Jeśli tego nie zrobisz, maile mogą zbierać się godzinami, a potem wyskoczyć naraz, co bywa problemem dla reputacji domeny i dla serwera pocztowego. W takich sytuacjach przydaje się świadomość, jak działa poczta na hostingu i co ją blokuje, dlatego warto mieć pod ręką artykuł Poczta na hostingu: SPF, DKIM, DMARC – jak poprawić dostarczalność maili z domeny.
Trzecia grupa to zadania porządkowe i techniczne, które poprawiają stabilność. Mogą to być czyszczenia tymczasowych plików, odbudowy cache modułów, archiwizacja logów lub generowanie plików, które później są tylko serwowane klientom. Dzięki temu przenosisz cięższą pracę poza moment, gdy użytkownik ogląda produkt i składa zamówienie.
Na końcu są zadania, które robią się niebezpieczne, jeśli uruchamiasz je zbyt często. Przykładem jest pełna regeneracja feedu dla dużego katalogu albo masowa synchronizacja, która skanuje bazę i wykonuje setki zapytań. Tu cron nadal jest dobry, ale wymaga rozsądnego harmonogramu i kontroli czasu wykonania, bo inaczej sklep będzie dostawał zadyszki.
Rodzaje cronów w sklepach: URL z modułu vs cron systemowy
W PrestaShop spotkasz dwa podejścia. Pierwsze to cron przez adres URL. Moduł pokazuje link, który trzeba wywołać, a po jego odpaleniu zadanie wykonuje się po stronie sklepu. To jest proste do ustawienia w większości hostingów, bo panel często ma miejsce, gdzie wpisujesz adres i częstotliwość.
Drugie podejście to cron systemowy, czyli komenda uruchamiana na serwerze. To rozwiązanie jest zwykle stabilniejsze, bo nie zależy od HTTP i łatwiej kontrolować środowisko wykonania. W praktyce częściej spotkasz je na VPS, gdzie masz dostęp do crontaba i możesz precyzyjnie ustawić, co i jak ma się uruchamiać.
Jest jeszcze wariant pośredni, czyli narzędzia typu pseudo-cron uruchamiany przez ruch na stronie. To mechanizm awaryjny, który może działać w małych sklepach, ale w większych jest ryzykowny, bo zadanie odpali się w losowym momencie, na przykład wtedy, gdy klient wchodzi na kartę produktu. W efekcie wąskie gardło pojawia się tam, gdzie najbardziej nie chcesz go mieć.
Jeżeli rozważasz przejście z hostingu współdzielonego na VPS głównie po to, aby mieć pełną kontrolę nad cronem i integracjami, wróć do tekstu PrestaShop: hosting współdzielony vs hosting VPS. W praktyce cron jest jedną z rzeczy, które na VPS po prostu łatwiej utrzymać w ryzach.
Jak ustawić cron w panelu hostingu krok po kroku
W panelach hostingowych nazwy mogą się różnić, ale schemat jest podobny. Szukasz sekcji typu Cron, Zaplanowane zadania albo Zadania cykliczne. Najpierw decydujesz, czy uruchamiasz adres URL, czy komendę. Na hostingu współdzielonym najczęściej wybierasz adres URL, bo to jest dostępne bez dodatkowych uprawnień.
Jeśli moduł podaje URL, wklejasz go w pole zadania i ustawiasz częstotliwość. Wiele paneli pozwala wybrać co 5 minut, co 15 minut, raz na godzinę albo raz dziennie. W sklepach integracyjnych najczęściej zaczyna się od 15 minut, a potem dostosowuje do tego, jak szybko muszą aktualizować się stany i ceny.
Kolejny krok to zabezpieczenie URL. W dobrych modułach link zawiera token, czyli losowy ciąg znaków, który utrudnia przypadkowe uruchomienie zadania. Jeśli moduł pozwala ustawić token, ustaw go i nie używaj prostych wartości. W praktyce traktuj to jak klucz do uruchamiania procesu, który może obciążać sklep.
Na koniec testujesz zadanie ręcznie. Większość paneli pozwala uruchomić cron od razu lub daje przycisk testowy. Jeżeli takiej opcji nie ma, wchodzisz w URL w przeglądarce, ale tylko wtedy, gdy jest to bezpieczne i nie uruchamia ciężkich procesów na produkcji w złym momencie.
Jeżeli w trakcie zmian musisz przenosić sklep na inny hosting, warto trzymać się uporządkowanej ścieżki z poradnika Migracja strony między hostingami krok po kroku, bo cron i integracje to często ten element, który psuje się po migracji jako pierwszy.
Harmonogramy w praktyce: jak dobrać częstotliwość do zadania
Najważniejsza zasada jest prosta: zadanie ma być uruchamiane tak często, jak wymaga tego biznes, ale nie częściej. Jeśli hurtownia wysyła stany raz na godzinę, odpalanie synchronizacji co 5 minut nie da Ci lepszej aktualności, a jedynie zwiększy obciążenie i ryzyko konfliktów.
Dla stanów magazynowych i cen typowe wartości to 15–60 minut, zależnie od branży i tempa rotacji. Sklepy, które sprzedają szybkorotujące produkty, schodzą niżej, ale tylko wtedy, gdy integracja jest szybka i dobrze zaprojektowana. Jeżeli jedno odpalenie synchronizacji trwa 10 minut, a ustawisz ją co 5 minut, zrobisz kolejkę, która nigdy się nie kończy.
Dla feedów produktowych rozsądne jest uruchamianie rzadziej, na przykład 1–2 razy dziennie, chyba że porównywarka wymaga częstszych aktualizacji. Feedy bywają ciężkie, bo generują duże pliki i potrafią mielić bazę. W praktyce lepiej wygenerować feed w spokojnym oknie, a potem serwować gotowy plik, zamiast generować go przy każdym wywołaniu.
Dla zadań wysyłkowych i kolejek mailowych częstotliwość bywa wyższa, na przykład co 5–15 minut, bo tu liczy się płynność. Ważne jest jednak, aby kolejka była przetwarzana w paczkach, a nie jako jedna długa operacja, która może zawiesić PHP. Jeśli widzisz, że wysyłki robią skoki i trwają długo, to znak, że ustawienia wymagają korekty.
Wysyłki i maile: kolejka, opóźnienia i typowe pułapki
W PrestaShop maile transakcyjne zwykle idą od razu, ale moduły marketingowe, powiadomienia o porzuconych koszykach czy newslettery często korzystają z kolejki. Kolejka jest po to, aby nie wysyłać tysięcy maili w jednym momencie i nie blokować serwera podczas normalnej pracy sklepu. Cron uruchamia przetwarzanie tej kolejki w tle.
Jeśli maile przychodzą z opóźnieniem, zacznij od sprawdzenia, czy cron działa regularnie. Często problemem nie jest konfiguracja poczty, tylko to, że kolejka uruchamia się raz dziennie zamiast co 10 minut. Dopiero gdy cron jest poprawny, ma sens analizowanie ustawień SMTP i dostarczalności, do czego przyda się artykuł o SPF, DKIM i DMARC: Poczta na hostingu: SPF, DKIM, DMARC – jak poprawić dostarczalność maili z domeny.
Typowa pułapka to zbyt duża paczka wysyłek na jedno uruchomienie. Jeśli moduł próbuje wysłać kilkaset maili naraz, może dojść do limitów po stronie hostingu lub do timeoutów PHP. W praktyce lepiej wysyłać mniejszymi porcjami, ale częściej, bo wtedy obciążenie jest równomierne i łatwiej utrzymać stabilność.
Druga pułapka to nieaktualna godzina na serwerze albo inna strefa czasowa niż w panelu sklepu. Wtedy cron działa, ale nie wtedy, kiedy myślisz. To brzmi banalnie, ale bywa realnym problemem, gdy zadania mają trafić w konkretne okno, na przykład tuż po aktualizacji hurtowni.
Feedy produktowe: generowanie, cache i bezpieczne okna czasowe
Feed produktowy potrafi być jednym z cięższych zadań w sklepie, zwłaszcza przy dużym katalogu. Sklep musi pobrać dane z bazy, często przeliczyć ceny, uwzględnić stany, a na końcu zapisać duży plik. Jeśli robisz to w złej porze, obciążenie może odczuć klient.
Dobrym podejściem jest generowanie feedu do pliku i udostępnianie gotowego adresu. Wtedy porównywarka pobiera plik statyczny, a sklep nie wykonuje ciężkiej pracy przy każdym pobraniu. W praktyce różnica jest ogromna, bo unikasz sytuacji, w której kilka robotów pobiera feed równocześnie.
Częstotliwość feedu dobierasz do tego, jak często realnie zmienia się oferta. Jeśli ceny i stany zmieniają się kilka razy dziennie, feed raz dziennie może być za mało. Jeśli zmiany są sporadyczne, generowanie co godzinę jest stratą zasobów. Tu warto myśleć o tym jak o koszcie, który płacisz na hostingu, dlatego kontekst o ograniczeniach zasobów bywa przydatny: limitach hostingu.
Jeśli feed jest bardzo duży, planuj jego generowanie poza szczytem. Dobrą praktyką jest też dodanie prostego monitoringu, na przykład sprawdzania daty modyfikacji pliku, aby szybko zauważyć, że feed przestał się odświeżać.
Aktualizacje stanów i cen: jak nie zrobić sobie bałaganu w magazynie
Synchronizacja stanów i cen często wygląda niewinnie, dopóki nie pojawią się konflikty. Konflikt to sytuacja, w której jedno uruchomienie synchronizacji jeszcze trwa, a drugie już startuje. Wtedy możesz dostać mieszaninę danych, częściowo z nowej paczki, częściowo ze starej, co w skrajnym przypadku kończy się sprzedażą niedostępnych produktów.
Dlatego pierwsza rzecz to kontrola czasu wykonania. Sprawdź w logach, ile trwa jedno uruchomienie. Jeśli trwa 12 minut, harmonogram co 10 minut jest proszeniem się o kłopoty. Lepiej ustawić co 30 minut i zoptymalizować integrację, niż upierać się przy bardzo częstym odpalaniu.
Druga rzecz to kolejność i zależności. Czasem aktualizacje cen powinny iść po aktualizacjach stanów, a czasem odwrotnie, zależnie od integracji. Jeśli masz osobne zadania dla różnych integracji, ustaw je tak, aby nie startowały w tym samym czasie. W panelu hostingu często da się to zrobić przesuwając minutę startu, a na VPS jest to jeszcze prostsze.
Trzecia rzecz to bezpieczeństwo danych. Jeśli integracja robi masowe zmiany, chcesz mieć możliwość szybkiego powrotu. Dlatego przy dużych integracjach i zmianach warto pamiętać o backupach, a w razie potrzeby wrócić do tekstu Kopie zapasowe w hostingu. Jak wybrać backup, który działa?.
Monitoring i logi: jak sprawdzić, że cron działa?
Najgorsze w cronach jest to, że mogą przestać działać cicho. Sklep wygląda normalnie, klienci kupują, ale stany nie są aktualne albo feed ma datę sprzed trzech dni. Dlatego potrzebujesz prostych sygnałów, że zadania wykonują się regularnie.
Pierwszy poziom to logi modułu lub sklepu. Wiele modułów zapisuje informację o ostatnim uruchomieniu i o wyniku. Jeśli masz taki ekran w panelu modułu, traktuj go jako podstawową kontrolkę. Gdy nie ma logów, możesz dodać własny prosty zapis do pliku, ale tylko wtedy, gdy wiesz, co robisz i nie tworzysz dodatkowego obciążenia.
Drugi poziom to monitoring zewnętrzny. W przypadku URL możesz monitorować, czy adres odpowiada i jaki jest kod odpowiedzi. Dla generowania feedu możesz monitorować datę modyfikacji pliku albo jego rozmiar, bo nagła zmiana rozmiaru bywa sygnałem, że feed wygenerował się niepoprawnie.
Trzeci poziom to obserwacja zasobów. Jeżeli cron powoduje skoki obciążenia i w tych momentach sklep zwalnia, to znak, że zadanie jest zbyt ciężkie albo ustawione zbyt często. Wtedy wracasz do harmonogramu i do tematu zasobów, a jeśli trzeba, rozważasz zmianę hostingu lub typ usługi zgodnie z wpisem PrestaShop: hosting współdzielony vs hosting VPS.
Bezpieczne wdrożenie na produkcji: plan zmian bez przestojów
Zacznij od spisania zadań, które mają działać cyklicznie. Dla każdego zadania dopisz: co robi, jak długo trwa i jaki ma sensowny cel czasowy, na przykład aktualizacja stanów co 30 minut. Dzięki temu nie ustawiasz wszystkiego na oko.
Następnie ustaw jedno zadanie i testuj je na spokojnie. Jeśli masz kilka integracji, nie uruchamiaj ich wszystkich naraz, bo w razie problemów nie będziesz wiedzieć, które zadanie wywołało kłopot. Po pierwszym poprawnym uruchomieniu sprawdź logi i realny efekt, na przykład czy stany się zmieniły albo czy feed ma nową datę.
Potem dodaj monitoring. Nie musi to być rozbudowane narzędzie, ale powinno dać Ci sygnał, że coś się zatrzymało. Najprościej jest kontrolować, czy zadanie wykonało się w ostatnich 24 godzinach, bo to wyłapuje większość awarii.
Na końcu zaplanuj kopię zapasową i sposób cofnięcia zmian. Jeśli cron uruchamia masowe aktualizacje, chcesz mieć możliwość szybkiego przywrócenia danych. W tym kontekście dobrze mieć uporządkowane podejście opisane we wpisie Kopie zapasowe w hostingu. Jak wybrać backup, który działa?.
FAQ – Najczęściej zadawane pytania
Duży ruch czasem maskuje brak crona, bo zadania uruchamiają się przy wejściach na stronę. To nadal jest ryzykowne, bo odpalenie zadania może trafić w moment, gdy klient składa zamówienie. Cron daje przewidywalność i pozwala przesunąć cięższe prace poza krytyczne momenty.
Najprostszy sygnał to sytuacja, w której kolejne uruchomienie startuje zanim poprzednie się skończy. Zobaczysz to w logach jako nakładające się czasy lub jako powtarzające się błędy. Drugi sygnał to skoki obciążenia i spowolnienia sklepu o stałych porach.
URL jest prostszy na hostingu współdzielonym, bo nie wymaga dostępu do systemu. Cron systemowy daje większą kontrolę i zwykle lepszą stabilność, dlatego jest popularny na VPS. Wybór zależy od tego, co oferuje hosting i jak krytyczne są integracje.
Najpierw sprawdź logi modułu lub sklepu, bo czasem zadanie kończy się błędem w środku. Potem sprawdź, czy zadanie działa na właściwym środowisku i czy nie jest blokowane przez timeouty. W integracjach warto też upewnić się, że źródło danych, na przykład hurtownia, udostępnia aktualne pliki.
Tak, jeśli zadania są ciężkie i uruchamiasz je w złym momencie lub zbyt często. Wtedy klienci odczują spowolnienie. Rozwiązaniem jest zmiana harmonogramu, rozbicie zadań na mniejsze porcje albo dostosowanie hostingu do obciążenia.
Bardzo często tak, bo zmienia się domena, ścieżki, a czasem tokeny w modułach. Po migracji sprawdź wszystkie zadania, uruchom testowo i upewnij się, że logi pokazują poprawne wykonanie. Pomaga podejście krok po kroku z poradnika migracyjnego.
Najlepiej przetwarzać kolejkę częściej, ale w mniejszych paczkach. Jeśli moduł ma ustawienia limitu maili na jedno uruchomienie, zacznij od niższych wartości i obserwuj, czy kolejka się opróżnia. To stabilniejsze niż rzadkie, ale masowe wysyłki.
30-letnia pasjonatka informatyki, która świat serwerów i hostingów zna od podszewki. Wierzy, że technologia powinna ułatwiać życie, a nie je komplikować. Żyje w ciągłym ruchu – jeśli akurat nie konfiguruje nowej usługi, prawdopodobnie pakuje plecak na kolejną wyprawę w nieznane.
Dodaj komentarz