Aktualizacja PrestaShop to jedna z tych rzeczy, które właściciele sklepów odkładają latami — aż do momentu, w którym moduł płatności przestaje działać albo hosting wymusza nowszą wersję PHP. Wtedy aktualizacja przestaje być planowym zadaniem i staje się awarią.
Poniżej opisuję, jak przeprowadzić ją tak, żeby nie stracić danych i nie zatrzymać sprzedaży. Jeśli wolisz to zlecić, zajmujemy się aktualizacjami PrestaShop wraz z weryfikacją modułów i motywu.
Najpierw ustal, co właściwie masz zrobić
To nie jest jedna operacja, a trzy różne — o zupełnie różnym poziomie trudności. Sprawdź numer swojej wersji w panelu (Konfiguracja → Informacje) i dopasuj scenariusz.
Scenariusz A: Aktualizacja w ramach tej samej linii
ProstyPrzejście między wersjami różniącymi się ostatnim numerem to zwykle poprawki bezpieczeństwa i błędów. Zmiany w strukturze bazy są niewielkie, moduły zazwyczaj działają dalej. Najprostszy wariant — ale nadal wymaga kopii zapasowej.
Scenariusz B: Aktualizacja do nowszej wersji głównej
ŚredniTo realna aktualizacja silnika: zmienia się struktura bazy danych, część funkcji zostaje usunięta, a moduły i motyw muszą być zgodne z nową wersją. Wymaga środowiska testowego i przeglądu wszystkich modułów. Tu najczęściej pojawiają się problemy, ale jest to proces przewidywalny.
Scenariusz C: Wyjście z PrestaShop 1.6
ZłożonyJeśli wciąż masz 1.6, nie czeka Cię aktualizacja, a migracja. Architektura szablonów zmieniła się przy wejściu linii 1.7 na tyle, że motyw trzeba zbudować od nowa, a wiele starych modułów nie ma odpowiedników. Dane produktów, klientów i zamówień przenosi się bez problemu — kodu i wyglądu nie. Opisujemy to osobno jako migrację PrestaShop.
Co ważne, drogi na skróty tu nie ma. Przejście z 1.6 wprost na aktualną wersję 9 wykonuje się etapami, przez wersje pośrednie 1.7 i 8 — inaczej nie da się kontrolować, który element przestał działać. Jak to wygląda w praktyce, opisujemy niżej na przykładzie sklepu Enduro7.
Zanim cokolwiek zaczniesz, sprawdź na stronie PrestaShopa, która wersja jest aktualnie wspierana i jakiej wersji PHP wymaga. To się zmienia, a aktualizacja do wersji bez wsparcia nie ma sensu.
Czego nie robić
Trzy błędy, które widzimy najczęściej, każdy kończy się tak samo:
-
Aktualizacja bezpośrednio na sklepie produkcyjnym w godzinach pracy
Jeśli coś pójdzie nie tak, sklep stoi, a Ty naprawiasz go pod presją zamówień.
-
Kopia zapasowa „na tym samym serwerze"
Przy awarii serwera tracisz sklep i kopię jednocześnie.
-
Aktualizacja silnika i modułów w tym samym kroku
Gdy coś przestanie działać, nie wiesz, co było przyczyną.
-
Krok 1: Pełna kopia zapasowa
Kopia to nie formalność, a Twój plan wyjścia. Musi zawierać:
- pliki — cały katalog sklepu,
- bazę danych — pełny zrzut SQL,
- informacje o środowisku — wersja PHP, limity, konfiguracja serwera.
Kopię pobierz na dysk lokalny albo do zewnętrznego magazynu. I rzecz najważniejsza, a prawie zawsze pomijana: sprawdź, czy kopię da się odtworzyć. Niesprawdzona kopia zapasowa to tylko nadzieja — uszkodzony zrzut bazy poznasz dopiero wtedy, gdy będzie za późno.
-
Krok 2: Środowisko testowe
Utwórz kopię sklepu na subdomenie albo w osobnym katalogu, z własną bazą danych. Zablokuj jej indeksowanie przez
robots.txti hasło na poziomie serwera — kopia sklepu widoczna w Google to duplikat treści i poważny problem SEO.Na tej kopii przeprowadzasz całą aktualizację. Dopiero gdy wszystko działa, powtarzasz operację na sklepie produkcyjnym. Ten jeden krok eliminuje większość ryzyka.
-
Krok 3: Inwentaryzacja modułów i motywu
To etap, który decyduje o powodzeniu, i jednocześnie najbardziej pracochłonny.
Wypisz wszystkie zainstalowane moduły i dla każdego sprawdź trzy rzeczy: czy autor wydał wersję zgodną z docelową wersją PrestaShop, czy nadal jest rozwijany i czy jest Ci faktycznie potrzebny.
Przy tej okazji zwykle okazuje się, że sklep ma kilka modułów, których nikt nie używa od dwóch lat. Każdy z nich to kolejne ryzyko i kolejny element do aktualizowania — usunięcie ich jest najtańszą częścią całej operacji.
Osobno sprawdź moduły krytyczne, bez których sklep nie sprzedaje: płatności, dostawy, integracja z ERP lub Baselinkerem, faktury. Jeśli którykolwiek z nich nie ma wersji zgodnej z nową wersją PrestaShop, musisz znaleźć zamiennik przed aktualizacją, a nie po niej.
Motyw traktuj tak samo. Jeśli korzystasz z motywu kupionego kilka lat temu i nieaktualizowanego, przygotuj się na to, że przy większym skoku wersji trzeba będzie go dostosować albo zbudować nowy.
-
Krok 4: Sprawdź wersję PHP
Każda wersja PrestaShop obsługuje określony zakres wersji PHP i to bywa źródłem najbardziej zagadkowych awarii. Zbyt stare PHP nie uruchomi nowego PrestaShopa, a zbyt nowe potrafi wywrócić stary motyw lub moduł.
Kolejność ma znaczenie: najpierw ustal wersję PHP wymaganą przez docelową wersję PrestaShop, potem sprawdź, czy Twój hosting ją udostępnia, i dopiero wtedy planuj termin. Zmianę wersji PHP wykonuj na środowisku testowym w tym samym kroku co aktualizację — inaczej nie będziesz wiedział, co spowodowało ewentualny błąd.
Jeśli hosting nie nadąża za wymaganiami, to sygnał, że czas na zmianę serwera. Przy sklepach PrestaShop ma to zresztą dodatkowy sens wydajnościowy — więcej o tym na stronie hostingu PrestaShop.
-
Krok 5: Aktualizacja
PrestaShop udostępnia oficjalny moduł aktualizacji (w zależności od wersji znany jako 1-Click Upgrade lub Upgrade Assistant), który przeprowadza proces automatycznie: tworzy kopię, pobiera nową wersję, podmienia pliki i migruje strukturę bazy.
Przed uruchomieniem:
- włącz tryb konserwacji,
- wyłącz cache,
- upewnij się, że masz świeżą kopię zapasową,
- zaplanuj operację na godziny o najmniejszym ruchu.
Przy większych skokach wersji albo mocno zmodyfikowanym sklepie aktualizacja ręczna bywa pewniejsza od automatu — daje kontrolę nad każdym etapem i pozwala zatrzymać się w momencie pierwszego problemu zamiast dowiedzieć się o nim na końcu.
-
Krok 6: Testy po aktualizacji
Sklep, który się otwiera, to nie sklep, który działa. Sprawdź po kolei:
- pełną ścieżkę zakupową — od karty produktu, przez koszyk, po potwierdzenie zamówienia,
- każdą metodę płatności w trybie testowym,
- metody dostawy i reguły kosztów wysyłki,
- e-maile transakcyjne — czy wychodzą i czy mają poprawną treść,
- integracje z ERP, hurtownią i Allegro,
- panel administracyjny — dodawanie produktu, edycja zamówienia, generowanie faktury,
- wersję mobilną i widok na telefonie,
- adresy URL i przekierowania, żeby nie stracić pozycji w Google,
- szybkość ładowania — po aktualizacji trzeba zwykle ponownie skonfigurować cache i optymalizację.
Testy wykonaj najpierw na środowisku testowym, a po wdrożeniu produkcyjnym powtórz najważniejsze z nich — szczególnie płatności.
Przykład z praktyki: Enduro7, z PrestaShop 1.6 do 9.1.4
Enduro7
Części do enduro i motocrossu
- Czas trwania
- ok. 6 miesięcy
- Ścieżka
- 3 etapy: 1.7 → 8 → 9.1.4
- Nasza rola
- Development dla PAQ Studio
Najlepiej pokazać to na konkretnym sklepie. Enduro7 sprzedaje części do enduro i motocrossu i działał na PrestaShop 1.6 z PHP 7.2 — wersji dawno pozbawionej wsparcia. Celem było PrestaShop 9.1.4 na PHP 8.2.
Część developerską tej aktualizacji realizowaliśmy jako podwykonawca agencji PAQ Studio, która prowadziła projekt od strony strategicznej i SEO. Cały przebieg prac opisali w publicznym case study, więc nie musisz wierzyć nam na słowo.
Decyzja, która przesądziła o powodzeniu
Zapadła na samym początku i brzmiała: żadnego skoku wprost z 1.6 do 9. Taki przeskok oznacza jednoczesną zmianę struktury bazy, architektury szablonu i sposobu działania modułów — przy problemie nie da się ustalić, który z tych elementów zawinił.
Zamiast tego rozpisaliśmy ścieżkę etapową:
- 1.6 start
- 1.7 etap 1
- 8 etap 2
- 9.1.4 cel
Każdy etap wykonywany na osobnym środowisku testowym, z weryfikacją danych i modułów po drodze. Dzięki temu po każdym kroku wiadomo było dokładnie, co się zmieniło i co przestało działać.
Jak to wyglądało w czasie
-
Marzec
Audyt starej wersji, inwentaryzacja modułów, motywu i rozwiązań własnych, rozpisanie ryzyk i ustalenie, które dane oraz funkcje muszą przetrwać.
-
Kwiecień
Budowa środowiska testowego i deweloperskiego oraz przygotowanie scenariuszy testowych dla produktów, kategorii, zamówień i kont klientów.
-
Maj
Pierwszy etap: 1.6 → 1.7, czyli ten najtrudniejszy, bo zmieniający architekturę szablonu.
-
Czerwiec
Drugi etap: 1.7 → 8, z ponowną kontrolą danych i modułów.
-
Sierpień
Dostosowanie modułów, motywu i kodu własnego do nowej architektury.
-
Wrzesień
Migracja produkcyjna do 9.1.4 i przeniesienie produktów, kategorii, zamówień oraz kont klientów.
Co trzeba było wymienić
Część modułów nie miała wersji zgodnej z nowszym PrestaShopem i nie dało się ich po prostu zaktualizować — trzeba je było zastąpić innymi rozwiązaniami. Motyw i kod własny wymagały dostosowania do zmienionej architektury.
Najciekawsza technicznie okazała się przebudowa zapytań AJAX. W starym sklepie odwoływały się bezpośrednio do plików PHP — w nowszych wersjach PrestaShopa taka konstrukcja nie jest już obsługiwana, więc przepisaliśmy je na kontrolery platformy. To typowy przykład rzeczy, której nie widać w żadnej instrukcji aktualizacji, a która potrafi zatrzymać projekt na kilka dni.
Po wdrożeniu
Zaraz po migracji uruchomiony został monitoring Search Console i logów serwerowych, żeby wyłapać ewentualne błędy, zanim odbiją się na widoczności w Google. Przy skoku o kilka wersji głównych zmienia się struktura adresów i sposób generowania stron, więc pierwsze dni po wdrożeniu decydują o tym, czy sklep utrzyma pozycje.
Ile to trwa i od czego zależy
Czas zależy przede wszystkim od liczby wersji do przeskoczenia, liczby modułów i stopnia modyfikacji motywu — a nie od wielkości katalogu produktów.
To nie znaczy, że przez sześć miesięcy sklep stoi — przez większość tego czasu działa normalnie, a prace toczą się na środowisku testowym. Oznacza to natomiast, że takiej aktualizacji nie da się sensownie zrobić „na już”, pod presją wymuszonej zmiany PHP przez hosting. Im dłużej czekasz, tym więcej wersji masz do nadrobienia.
Najczęstsze pytania
Czy przy aktualizacji stracę produkty, klientów i zamówienia?
Przy prawidłowo przeprowadzonej aktualizacji nie. Dane pozostają w bazie, a moduł aktualizacyjny migruje jej strukturę. Ryzyko dotyczy wyglądu i funkcji modułów, nie danych — pod warunkiem, że masz sprawdzoną kopię zapasową.
Czy sklep będzie niedostępny?
Na czas wdrożenia produkcyjnego włącza się tryb konserwacji, zwykle na kilkadziesiąt minut. Jeśli całość została wcześniej przetestowana na kopii, przestój jest krótki i przewidywalny.
Czy mogę zostać na starej wersji?
Możesz, ale rośnie Ci dług techniczny. Wersje bez wsparcia nie dostają poprawek bezpieczeństwa, a przy pierwszym wymuszonym podniesieniu PHP przez hosting sklep przestanie działać. Im dłużej czekasz, tym większy skok wersji do wykonania — a im większy skok, tym droższa operacja.
Co, jeśli aktualizacja się nie uda?
Dlatego robi się ją na kopii. Przy wdrożeniu produkcyjnym planem wyjścia jest przywrócenie kopii zapasowej — zwykle kwestia kilkunastu minut, jeśli kopia została wcześniej przetestowana.
Czy po aktualizacji sklep będzie szybszy?
Nowsze wersje są zwykle wydajniejsze, ale sama aktualizacja nie zastąpi optymalizacji. Po jej zakończeniu trzeba na nowo skonfigurować cache i sprawdzić wagę zdjęć.
Zleć aktualizację zamiast odkładać ją kolejny rok
Przeprowadzamy aktualizacje PrestaShop z weryfikacją modułów i motywu, na środowisku testowym, z planem wyjścia. Podaj obecną wersję sklepu i listę krytycznych modułów, a oszacujemy zakres pracy.
