PrestaShop AutoUpgrade (w panelu widnieje jako „1-Click Upgrade”, katalog /modules/autoupgrade/) potrafi przeprowadzić sklep przez aktualizację w kilkanaście minut. Potrafi też położyć produkcję w tym samym czasie, jeśli zabraknie kopii, miejsca na dysku albo zgodnej wersji PHP. Poniżej część organizacyjna: checklista przed startem, kolejność kroków i błędy, które najczęściej kończą się sklepem w trybie serwisowym dłużej, niż zakładano. Punktem wyjścia są nasze materiały o PrestaShop: PrestaShop w DropDigital.
W panelu moduł znajdziesz pod nazwą „1-Click Upgrade”, a jego pliki leżą w katalogu /modules/autoupgrade/. Instalujesz go z marketplace PrestaShop — bez ręcznego wgrywania paczek ZIP. Moduł pobiera docelową wersję, podmienia pliki, uruchamia migracje bazy i czyści cache. To wygodne i dokładnie dlatego bywa ryzykowne: jedna operacja dotyka jednocześnie kodu i danych, a przerwanie w połowie zostawia sklep w stanie pośrednim.
Aktualizacje dzielą się na trzy kanały o różnym poziomie ryzyka:
| Kanał | Przykład | Ryzyko | Co zrobić przed startem |
|---|---|---|---|
| Patch / minor | 1.7.8.8 → 1.7.8.11 | Niskie | Kopia plików i bazy, test koszyka i płatności |
| Minor w tej samej gałęzi | 1.7.6 → 1.7.8 | Średnie | Pełny staging, przegląd modułów i szablonu |
| Major | 1.7 → 8.x | Wysokie | Migracja kontrolowana, nie upgrade na produkcji |
Najwięcej awarii nie wynika z błędów modułu, tylko z braku kopii i środowiska, które nie spełnia wymagań docelowej wersji. Zacznij od dwóch niezależnych kopii:
tar -czf sklep.tar.gz /var/www/sklep.mysqldump -u user -p --single-transaction --routines --triggers nazwa_bazy > baza.sql albo eksport przez Adminer.Dalej sprawdź PHP. PrestaShop 1.7.8 wspiera PHP od 7.1.3 wzwyż, PrestaShop 8.x wymaga PHP 7.2.5–8.1. Wartości potwierdź w release notes dla konkretnej wersji i w dokumentacji na php.net — nie zgaduj. Jeśli hosting trzyma PHP 7.0, upgrade padnie w połowie migracji bazy.
Policz miejsce na dysku. AutoUpgrade tworzy archiwa plików i bazy w katalogu administratora, więc potrzebujesz 2–3× rozmiar sklepu wolnego miejsca. Zmierz też realne limity hostingu: max_execution_time, memory_limit, post_max_size, upload_max_filesize. Zapisz je przed startem, żeby po awarii wiedzieć, co zmienić.
Zrób listę modułów pobranych spoza marketplace i takich, których autor nie wydał aktualizacji od 12 miesięcy. To najczęstsze źródło konfliktów. Całość przetestuj w środowisku offline — opisujemy je w materiale o PrestaShop offline i konserwacji.
| Docelowa wersja PrestaShop | Minimalne PHP | Górna granica |
|---|---|---|
| 1.7.8.x | 7.1.3 | sprawdź w release notes |
| 8.x | 7.2.5 | 8.1 |
Ścieżka w panelu: Modules → Module Manager → 1-Click Upgrade → Configure. Zanim cokolwiek wpiszesz, zamknij sklep na czas prac albo przynajmniej ustal okno serwisowe poza godzinami szczytu.
Make a backup. Zaznacz tę opcję ręcznie — w wielu wersjach modułu jest domyślnie odznaczona, a bez niej nie masz rollbacku danych. Backup tworzony przez moduł leży jednak na tym samym serwerze i w tym samym katalogu admina, więc nie zastępuje kopii z checklisty powyżej.
Keep the modules. Zostaw moduły, jeśli pracujesz na mocno dopasowanym szablonie, a moduły pisał pod obecną wersję jeden wykonawca. Odznacz, jeśli moduły pochodzą z marketplace i deklarują zgodność z wersją docelową — wtedy warto je odświeżyć razem z core.
Upgrade the default theme. Przy własnym szablonie odznacz tę opcję. Zaznaczona potrafi nadpisać pliki szablonu i sklep wstanie z połamanym layoutem.
Kolejność bez skrótów: tryb serwisowy → backup → upgrade → czyszczenie cache (Parametry zaawansowane → Wydajność oraz ręczne usunięcie zawartości /var/cache/prod i /var/cache/dev) → testy: logowanie do panelu, dodanie produktu do koszyka, płatność testowa, wysyłka, mail. Tryb serwisowy nie zastępuje kopii — to tylko zasłona.
Po zakończeniu przeczytaj log upgrade'u zanim odświeżysz pulpit. Ostrzeżenia typu brak zgodności modułu albo nieudane nadpisanie override'u oznaczają, że część kodu nie działa. Zapisz log do pliku i dopiero wtedy przejdź do testów. Punktem wyjścia do głębszej pracy jest dokumentacja dla deweloperów PrestaShop.
Gdy panel w przeglądarce kończy pracę błędem 500 albo 504, problemem prawie nigdy nie jest sam upgrade, tylko limit czasu po stronie serwera WWW. Obejściem jest skrypt CLI dołączony do modułu: php admin/autoupgrade/cli-upgrade.php, uruchamiany przez SSH. Zanim go odpalisz, potwierdź ścieżkę — w części wersji moduł leży w /modules/autoupgrade/, a nie w katalogu admin/.
CLI działa tam, gdzie przeglądarka nie ma szans, z trzech powodów:
max_execution_time z konfiguracji PHP-FPM ani timeout reverse proxy — proces może kopiować pliki 40 minut i nikt go nie ubije,post_max_size i upload_max_filesize, które przy wgrywaniu archiwum przez panel potrafią uciąć plik i przerwać procedurę,php -d memory_limit=1024M -d max_execution_time=0 admin/autoupgrade/cli-upgrade.php.Uruchamiaj w screen lub tmux. Sekwencja: screen -S upgrade, w środku pełne polecenie z przekierowaniem wyjścia na dysk, np. | tee /var/log/upgrade.log, wyjście z sesji przez Ctrl+A, D. Zerwane łącze SSH zabija proces w połowie kopiowania plików — to najgorszy możliwy moment na przerwanie. Do sesji wrócisz przez screen -r upgrade.
Przed startem sprawdź, jako kto działa PHP-FPM: ps aux | grep php-fpm. To może być www-data albo użytkownik hostingu, np. sklepftp. Ten użytkownik musi mieć prawo zapisu do app/config/, modules/, themes/ i var/. Test bez zgadywania: sudo -u www-data test -w var/cache && echo OK. Konto bazy potrzebuje też ALTER, CREATE, INDEX i DROP — upgrade zmienia schemat tabel, samo SELECT/INSERT nie wystarczy.
Zasada kolejności: najpierw backup z CLI, potem upgrade z CLI. mysqldump --single-transaction --quick baza | gzip > db.sql.gz i tar --exclude='var/cache' -czf pliki.tar.gz . — oba w tym samym oknie czasowym. Jeśli wolisz najpierw przećwiczyć przebieg na kopii, opisaliśmy organizację środowiska lokalnego do testowania i konserwacji sklepu.
Tabela poniżej jest do trzymania otwartej w trakcie awarii. Najważniejsza reguła: nie zgaduj, tylko zidentyfikuj etap, na którym moduł się zatrzymał — kopiowanie plików, migracja bazy, czy pierwsze wejście sklepu po aktualizacji. Każdy z tych etapów ma inne objawy i inne naprawy.
| Objaw | Prawdziwa przyczyna | Co zrobić |
|---|---|---|
| 500/504 w trakcie kopiowania plików | przekroczony max_execution_time (często 30–60 s) lub timeout proxy przed serwerem | uruchom CLI; u dostawcy hostingu podnieś limit — jeśli nie da się, przenieś sklep na plan z limitem ≥300 s |
| „Unable to unzip” / błąd rozpakowywania archiwum | brak miejsca na dysku albo brak uprawnień do katalogu docelowego | df -h i df -i (wolne i-węzły), sprawdź quota w panelu, popraw chmod/chown na katalogu sklepu |
| Biała strona po aktualizacji | stary .htaccess niedopasowany do nowej struktury albo nieskompilowany cache Smarty | podmień .htaccess na wzorzec z nowej wersji, usuń zawartość var/cache, wygeneruj .htaccess ponownie |
| Komunikat „No upgrade available” | wybrany kanał minor zamiast major (lub odwrotnie) albo brak połączenia z serwerem aktualizacji | przełącz kanał, sprawdź, czy firewall hostingu nie blokuje ruchu wychodzącego do serwera dystrybucyjnego PrestaShop |
| Moduł płatności lub kuriera przestaje działać po major upgrade | zmiana API hooków między gałęziami PrestaShop | zajrzyj w log PHP przy próbie checkoutu, pobierz od producenta moduł w wersji wspierającej nową gałąź |
| Błąd zapisu settings.inc.php / plików w app/config | pliki wniesione z innego środowiska — właściciel root zamiast użytkownika PHP-FPM | chown na użytkownika FPM, chmod 644 dla plików i 755 dla katalogów |
| Upgrade zatrzymuje się na etapie zmian w bazie | konto bazy ma tylko SELECT/INSERT — brak ALTER, CREATE, INDEX | nadaj brakujące uprawnienia i powtórz krok aktualizacji bazy |
Rollback w AutoUpgrade to powrót do kopii, a nie naprawa sklepu po fakcie. Jest dostępny wyłącznie wtedy, gdy aktualizacja szła przez moduł, backup powstał w tym samym przebiegu i nie został nadpisany ani skasowany. Archiwa leżą w katalogu backup modułu — nie usuwaj ich przez co najmniej 48 godzin, czyli po pełnym cyklu zamówień, płatności i wysyłek.
Co rollback przywraca: pliki sklepu z archiwum oraz bazę z tego samego zrzutu, czyli dokładnie stan sprzed aktualizacji. Nic więcej.
Czego nie cofnie:
Przed rollbackiem zrób eksport zamówień złożonych po upgrade — po przywróceniu bazy ich nie odzyskasz. Wystarczy zrzut z tabeli zamówień przefiltrowany po dacie dodania.
Scenariusz awaryjny, gdy rollback nie zadziała (brak archiwum, przerwany proces w połowie): włącz tryb serwisowy, przywróć pliki z archiwum tar, zaimportuj zrzut bazy, wyczyść var/cache, wygeneruj .htaccess, przetestuj koszyk i jedną płatność w trybie testowym. Kolejność jest istotna: serwis → pliki → baza → cache.
Dlatego backup bazy i plików musi powstać w tym samym momencie. Sklep robiący 30 zamówień na godzinę i 20 minut różnicy między zrzutami oznacza kilkanaście zamówień, których po rollbacku nie ma. Jeśli wolisz mieć ten proces poukładany raz na zawsze, zobacz nasze materiały o wdrożeniach i utrzymaniu PrestaShop.
Staging działa 2–4 godziny dłużej niż aktualizacja „na wiarę”, ale wyłapuje błędy, które inaczej zobaczyliby klienci. Poniższa lista to minimalny zestaw przed przełączeniem DNS-a albo zdjęciem trybu serwisowego.
Zestaw kontrolny całego procesu, od kopii po ostatni test, znajdziesz w dziale PrestaShop na naszym blogu.
| Obszar | Co dokładnie sprawdzić | Orientacyjny czas |
|---|---|---|
| Zamówienie | Koszyk → płatność sandbox → mail → faktura, numeracja faktur | 30–45 min |
| Wysyłka | Etykieta InPost/DPD/DHL, punkty odbioru, mapowanie statusów | 30–60 min |
| ERP | Stan magazynowy po zamówieniu, ceny, eksport zamówień, hooki | 30–60 min |
| Technika | Regeneracja .htaccess, cache, miniatury, przekierowania 301 | 45–90 min |
| SEO | Sitemap w GSC, 404, Core Web Vitals (LCP/INP/CLS) | 20–30 min + kontrola po 7–14 dniach |
Aktualizację warto zlecić wtedy, gdy spełniony jest któryś z trzech warunków: producent wydał poprawkę bezpieczeństwa, hosting podnosi wersję PHP i obecna gałąź PrestaShop nie jest z nią zgodna, albo sklep zaczął korzystać z modułu, który wymaga nowszej wersji rdzenia. Odkładanie tego „na po sezonie” zwykle oznacza upgrade w grudniu, w środku szczytu sprzedaży — czyli najgorszym możliwym terminie.
Model wyceny jest prosty: liczba godzin pomnożona przez stawkę. Bez pozycji „cena z sufitu”.
Osobna pozycja to moduły. Jeśli korzystają z API wycofanego w nowej wersji (stare wywołania dyspozytora, bezpośrednie zapytania do tabel, których struktura się zmieniła, albo własne hooki nieistniejące w nowym rdzeniu), trzeba je przepisać pod aktualne hooki i strukturę Symfony. Realistycznie: 4–16 h na moduł. Dokumentację zmian w hookach i API trzyma dokumentacja deweloperska PrestaShop — to pierwsze miejsce, w którym sprawdzamy zgodność przed wyceną.
Do wyceny wchodzi też opieka po wdrożeniu z jasnym SLA: czas reakcji, zakres aktualizacji bezpieczeństwa, monitoring dostępności i kopie. To nie dodatek, tylko element, który decyduje, czy ktoś odbierze telefon, gdy sklep padnie w piątek o 20:00. Pracujemy bezpośrednio z deweloperem, który prowadzi upgrade — bez pośredników i bez przekazywania zadań „do działu”.
Jeśli nie wiesz, czy Twój sklep jest gotowy, zamów audyt aktualizacji. Zakres i czas realizacji wdrożeń opisujemy w sekcji wdrożeń i migracji PrestaShop — napisz, jaką masz wersję i jakie moduły, a odpowiemy konkretną liczbą godzin, nie ogólnikami.
Upgrade bez kopii poza serwerem produkcyjnym. Backup zrobiony przez moduł leży w katalogu admina na tym samym dysku i tej samej bazie, którą właśnie aktualizujesz.
Jak wykryć: Przed startem wpisz w SSH: ls -lh admin/autoupgrade/backup/. Jeśli to jedyne kopie, jakie masz, to nie masz kopii.
Jak naprawić: Zrób zrzut bazy (mysqldump lub eksport w Adminerze) i archiwum całego katalogu sklepu, następnie pobierz oba pliki poza serwer. Dopiero potem uruchamiaj moduł.
Aktualizacja major (np. 1.7 → 8.x) kliknięta bezpośrednio na produkcji, bez żadnego testu na kopii.
Jak wykryć: Sprawdź w release notes, czy zmiana jest minor (1.7.8.8 → 1.7.8.11), czy major. Major zmienia API, theme i zachowanie modułów.
Jak naprawić: Major zawsze na środowisku offline lub stagingu — patrz PrestaShop offline. Na produkcji zostaw tylko minor, i to po teście.
Za mało wolnego miejsca na dysku. Moduł pakuje pliki i bazę do archiwów w katalogu admina, a przy 100% zapełnienia dysku baza potrafi się zablokować.
Jak wykryć: Porównaj du -sh katalogu sklepu z wynikiem df -h przed startem.
Jak naprawić: Zaplanuj 2–3× rozmiar sklepu wolnego miejsca. Jeśli go nie ma, wyłącz backup modułu i zrób własny, zewnętrzny.
Niezgodna wersja PHP. Sklep chodzi na PHP, którego docelowa wersja PrestaShop nie wspiera, a zmiana następuje po aktualizacji, nie przed.
Jak wykryć: Sprawdź php -v na serwerze i zestaw to z wymaganiami w release notes. PS 1.7.8 obsługuje PHP 7.1.3+, PS 8.x wymaga PHP 7.2.5–8.1.
Jak naprawić: Przełącz wersję PHP w panelu hostingu przed aktualizacją. Aktualizuj moduły i theme pod docelową wersję PHP wcześniej, nie po.
Włączenie aktualizacji modułów i theme w tym samym przebiegu, w sklepie z wielokrotnie zmodyfikowanym szablonem i dziesiątkami override'ów.
Jak wykryć: Policz pliki w /override i porównaj /themes z oryginałem. Kilkadziesiąt override'ów lub custom theme to czerwona flaga.
Jak naprawić: Zostaw moduły i theme bez zmian w trakcie upgrade'u core. Zaktualizuj je osobno, po jednym, z testem po każdej zmianie.
Przerwanie procesu (timeout, zamknięta karta, błąd 500/504) i ponowne kliknięcie Upgrade bez zajrzenia w log.
Jak wykryć: Panel nie odpowiada, wraca 500/504, a proces może nadal chodzić w tle. Log upgrade'u znajdziesz w katalogu modułu.
Jak naprawić: Nie klikaj drugi raz. Przeczytaj log, sprawdź stan plików i bazy, a przy kolejnym podejściu użyj wersji CLI opisanej wyżej.
AutoUpgrade jest dobrym narzędziem do aktualizacji minor i do sklepów bez głębokich modyfikacji core. Major, sklep z override'ami, custom theme i integracjami pisanymi pod starą wersję to zadanie dla migracji na staging, nie dla kliknięcia na produkcji. Niezależnie od wybranej drogi: dwie kopie (pliki i baza), jedna z nich poza serwerem, sprawdzona wersja PHP i zapisane limity hostingu. Bez tego moduł nie zawiedzie — zawiedzie organizacja pracy wokół niego.
To natywny moduł aktualizacyjny, widoczny w panelu jako „1-Click Upgrade”, z katalogiem /modules/autoupgrade/. Instaluje się go z marketplace PrestaShop, tak jak inne moduły. Obsługuje trzy kanały: minor (np. 1.7.8.8 → 1.7.8.11), major (1.7 → 8.x) oraz aktualizację samych modułów. Każdy kanał ma inny poziom ryzyka i inne wymagania przed startem.
Ma opcję backupu plików i bazy, ale na dużych sklepach częściej się ją pomija ze względu na czas i miejsce na dysku. Archiwa lądują w katalogu admina, czyli na tym samym serwerze, który aktualizujesz. To wygodne przy małym sklepie i niewystarczające przy produkcji z realnym ruchem. Traktuj backup modułu jako kopię zapasową „drugiej kategorii”, a nie jako jedyną.
Moduł zawiera skrypt CLI w katalogu admina, uruchamiany przez SSH: php admin/autoupgrade/cli-upgrade.php. Linia poleceń nie podlega limitom web serwera ani timeoutowi przeglądarki, a limit pamięci możesz podnieść parametrem -d memory_limit=.... Uruchom go w screenie lub tmux, żeby zerwane połączenie SSH nie przerwało procesu.
Tak, ale tylko wtedy, gdy masz pełne kopie plików i bazy danych sprzed startu. Rollback polega na przywróceniu archiwum plików, wgraniu zrzutu bazy i wyczyszczeniu cache. Jeśli backup leżał wyłącznie w katalogu modułu na tym samym dysku, po nieudanym upgrade'cie możesz nie mieć z czego odtworzyć sklepu.
Gdy core sklepu jest mocno zmodyfikowany, w /override leżą setki plików, theme był wielokrotnie przerabiany, a integracje pisano pod konkretną wersję PrestaShop. W takich przypadkach moduł nadpisze zmiany albo zatrzyma się w połowie. Wtedy właściwą drogą jest migracja na staging z przepisaniem modyfikacji i osobnym testem każdego integracyjnego elementu.
Nie. Tryb serwisowy ukrywa sklep przed klientami, ale nie tworzy kopii, nie cofa zmian i nie zabezpiecza bazy. To element procedury, nie jej zamiennik. Włączasz go po zrobieniu kopii, a wyłączasz po testach i czyszczeniu cache.
Moduł tworzy archiwum plików i zrzut bazy w katalogu admina, więc potrzebujesz 2–3× rozmiar sklepu wolnego miejsca. Przy bazie liczącej kilka GB sam zrzut może zająć tyle, ile cała pozostała przestrzeń na dysku. Sprawdź stan dysku bezpośrednio przed startem i pamiętaj, że brak miejsca w trakcie zapisu bazy to jeden z najgorszych scenariuszy.
Jeśli nie chcesz ryzykować produkcji przy najbliższej aktualizacji, przejdź do naszego huba o PrestaShop: PrestaShop albo opisz nam swój przypadek — powiemy wprost, czy wystarczy AutoUpgrade, czy potrzebne jest środowisko testowe i migracja.