Problemy po aktualizacji PrestaShop to klasyka: sklep działał, po aktualizacji rdzenia albo modułu przestał przyjmować zamówienia, „rozjechał się" motyw albo pojawiły się błędy 500. Najczęstsze przyczyny to niekompatybilne moduły, override'y kolidujące ze zmianami w rdzeniu i stare cache. Dobra wiadomość: aktualizację można bezpiecznie cofnąć, jeśli przed startem powstała kopia i plan rollbacku. Poniżej checklista powrotu do działania i zasady, które czynią aktualizacje bezpiecznymi. Naprawa po nieudanej aktualizacji: 200–600 zł netto, diagnostyka z raportem 500–1 500 zł netto.
Najważniejsze: Po nieudanej aktualizacji PrestaShop działasz według kolejności: 1) nie panikuj i nie aktualizuj „na raz drugi raz", 2) sprawdź logi (
var/logs/, logi PHP) — wskażą winny moduł, 3) wyłącz ostatnio aktualizowany moduł, 4) wyczyść cache (var/cache, cache Smarty, OPcache), 5) jeśli błąd w rdzeniu — przywróć kopię z przed aktualizacji (rollback), 6) aktualizuj ponownie na stagingu, partiami, z testem ścieżki zakupowej. Bezpieczna aktualizacja = kopia + staging + testy + plan powrotu.
- ## Krok 1: Ustal, co dokładnie przestało działać
Zanim zaczniesz naprawiać, zbierz fakty
- - co przestało działać: cały sklep, panel, checkout, pojedyncza strona?
- - kiedy: od razu po aktualizacji czy po kilku godzinach (cache)?
- - co było aktualizowane: rdzeń PrestaShop, moduł, motyw, PHP?
- jaki dokładnie komunikat widzisz (500, biała strona, „Oops! An error occurred")?
Dokładny zakres awarii zawęża krąg podejrzanych. Błąd tylko w checkoutcie po aktualizacji modułu płatności to inny problem niż biały cały sklep po aktualizacji rdzenia.
- ## Krok 2: Logi — pierwszy trop
Logi wskażą sprawcę w większości przypadków
var/logs/prod.logidev.log— błędy PrestaShop i modułów,- logi PHP (
error_log) — brak pamięci, błędy parsowania, - logi serwera — błędy na poziomie hostingu.
Szukaj wpisów z czasu po aktualizacji: Call to undefined method (moduł niekompatybilny z nową wersją), Cannot redeclare (konflikt override'ów), Allowed memory size (nowa wersja potrzebuje więcej pamięci), SQLSTATE (nieprzeprowadzone migracje bazy). Jak czytać logi: logi PrestaShop.
-
## Krok 3: Wyłącz ostatnio aktualizowany moduł
-
Najczęstszy scenariusz: rdzeń zaktualizowany, ale moduły nie. Starszy moduł wywołuje metodę, której nowy rdzeń już nie ma.
- wyłącz moduł wskazany w logach (albo ostatnio aktualizowany),
- gdy panel działa — przez panel; gdy nie — przez bazę:
UPDATE ps_module SET active = 0 WHERE name = 'nazwa';, - sprawdź sklep po każdym wyłączeniu.
Jeśli po wyłączeniu modułu sklep wraca, sprawdź changelog modułu pod kątem wersji zgodnej z Twoim PrestaShop i zaktualizuj go — albo zgłoś problem autorowi. Pełna procedura izolacji: konflikt modułów.
- ## Krok 4: Wyczyść cache — wszystkie warstwy
Stary cache po aktualizacji to druga najczęstsza przyczyna „błędów widmo"
-
- cache PrestaShop: panel → Parametry zaawansowane → Wydajność → Wyczyść cache (albo usuń zawartość
var/cachez zachowaniem struktury), -
- cache Smarty: panel → Wydajność → Szablony → wyczyść kompilację,
-
- OPcache PHP: restart PHP-FPM w hostingu (lub
opcache_reset()), -
cache CDN, jeśli sklep stoi za Cloudflare — purge,
-
- cache przeglądarki: testuj w trybie incognito, żeby nie diagnozować własnego cache.
Po aktualizacji PrestaShop wymaga pełnego czyszczenia wszystkich warstw — samo odświeżenie strony nie wystarczy.
- ## Krok 5: Rollback, gdy błąd jest w rdzeniu
Jeśli logi wskazują na rdzeń albo błąd wraca po wyłączeniu wszystkich modułów — przywróć kopię sprzed aktualizacji
- przywróć pliki z kopii (cały katalog),
- przywróć bazę danych ze zrzutu sprzed aktualizacji (to kluczowe — aktualizacja zmienia schemat),
- wyczyść cache i OPcache,
- sprawdź sklep: stronę główną, produkt, koszyk, checkout, panel,
- dopiero potem planuj ponowną aktualizację — na stagingu.
Uwaga: Rollback bez przywrócenia bazy zostawia sklep w niespójnym stanie: stary kod + nowy schemat bazy. Jeśli nie masz kopii bazy, nie improwizuj z ręcznym cofaniem migracji — to prosta droga do utraty danych.
- ## Krok 6: Zaplanuj bezpieczną aktualizację
Żeby sytuacja się nie powtórzyła
- staging — kopia sklepu na osobnym hostingu/subdomenie z wyłączoną indeksacją,
- kopia — pliki i baza, z testem odtworzenia przed startem,
- changelogi — sprawdź kompatybilność wszystkich modułów z nową wersją rdzenia,
- partiami — najpierw rdzeń, potem moduły po jednym, potem motyw,
- test ścieżki zakupowej — strona główna → produkt → koszyk → checkout → płatność → mail,
- plan rollbacku — dokładna procedura powrotu, przetestowana na stagingu,
- dzień i godzina — nigdy w piątek po południu; aktualizuj w niskim ruchu, z dostępnym czasem na reakcję.
Checklista w formie pliku do wydrukowania przydaje się przy każdej aktualizacji — prowadzę takie procesy w ramach pomocy technicznej PrestaShop.
Co się psuje najczęściej — tabela objawów
| Objaw po aktualizacji | Prawdopodobna przyczyna | Naprawa |
|---|---|---|
| Checkout nie przyjmuje zamówień | Moduł płatności/dostawy niekompatybilny | Wyłącz/zaktualizuj moduł |
| Motyw „rozjechany" | Zmiany struktury szablonów | Child theme, poprawki CSS/TPL |
| Brak tłumaczeń i pól | Nieprzeprowadzone migracje bazy | Uruchom migracje, sprawdź tłumaczenia |
| Błędy 500 na podstronach | Override'y po zmianach rdzenia | Popraw override albo przenieś do hooków |
| Wolniejsze działanie | Stary cache + nowe zapytania | Pełne czyszczenie cache, Redis |
| Panel nie działa | Limit pamięci, cache Symfony | Podnieś memory_limit, wyczyść var/cache |
Kiedy wezwać specjalistę
Rollback i diagnostykę pojedynczego modułu wykonasz sam, mając kopię i logi. Pomoc ma sens, gdy
- nie ma kopii sprzed aktualizacji (odzyskiwanie danych),
- błąd jest w rdzeniu lub bazie danych,
- sklep stoi dłużej niż godzinę — liczy się każda minuta sprzedaży,
- aktualizacja była duża (1.6 → 8/9) i wymaga planu migracji.
Migracje planowane opisuję w wdrożenia PrestaShop.
Najczęściej zadawane pytania
Po aktualizacji PrestaShop przestał działać — jak cofnąć aktualizację?
Przywróć pliki i bazę danych z kopii sprzed aktualizacji (rollback), wyczyść cache i OPcache, sprawdź pełną ścieżkę zakupową. Bez kopii bazy nie cofaj zmian ręcznie — poproś o pomoc, bo niespójność kodu i schematu bazy grozi utratą danych.
Czy mogę zaktualizować PrestaShop bez kopii zapasowej?
Technicznie tak, ale to hazard. Aktualizacja zmienia schemat bazy i pliki rdzenia — bez kopii nie ma drogi powrotu, jeśli coś pójdzie źle. Kopia plików i bazy to warunek startu każdej aktualizacji, nie opcja.
Po aktualizacji modułu zniknęły metody płatności — co robić?
Wyłącz moduł płatności i sprawdź, czy inne metody wracają; następnie włącz go na stagingu z trybem debug i odczytaj błąd. Najczęściej moduł wymaga aktualizacji do wersji zgodnej z nowym rdzeniem — sprawdź changelog u dostawcy.
Jak często aktualizować PrestaShop?
- Rdzeń: przy wydaniach bezpieczeństwa niezwłocznie, przy wydaniach funkcjonalnych w cyklu kwartalnym. Moduły: po sprawdzeniu changelogów, partiami. Każda aktualizacja przez staging. Regularny cykl aktualizacji opisuję w wsparcie PrestaShop.
Źródła i narzędzia
- PrestaShop Build — wydania i aktualizacje
- PrestaShop DevDocs — aktualizacja
- PrestaShop — dokumentacja
👉 Aktualizacja położyła sklep? Pomożemy w rollbacku i bezpiecznym powtórzeniu procesu — formularz kontaktowy lub kontakt@informatix.com.pl. Zobacz też pomoc techniczna PrestaShop.
📖 Zobacz też: konflikt modułów, checkout nie działa i wdrożenia PrestaShop.