Jak bezpiecznie zaktualizować PrestaShop 8 do PrestaShop 9

Aktualizacja z PrestaShop 8 do PrestaShop 9 nie jest zwykłą czynnością konserwacyjną. To przejście na nową główną wersję, które zmienia techniczną podstawę sklepu, w tym generację Symfony, zgodność z PHP, działanie interfejsu sklepu, wymagania modułów i kilka wewnętrznych API.

Dobrą wiadomością jest to, że PrestaShop udostępnia dziś znacznie bardziej rozbudowany Update Assistant niż dawny proces aktualizacji jednym kliknięciem. Obsługuje panel administracyjny i wiersz poleceń, sprawdza wymagania, zapewnia dokładniejsze logi oraz funkcje tworzenia i odtwarzania kopii zapasowych.

Najważniejszy nadal pozostaje Twój proces.

Sklepu e-commerce w produkcji nigdy nie należy aktualizować, najpierw klikając przycisk, a dopiero później sprawdzając zgodność. Najbezpieczniejszy proces to:

inwentaryzacja → kopia zapasowa → środowisko testowe → audyt zgodności → próba → testy regresji → przełączenie produkcji → monitorowanie

Ten przewodnik szczegółowo wyjaśnia ten proces.

Uwaga dotycząca wersji: Ten artykuł zweryfikowano 22 września 2026 r. PrestaShop 9.1.5 jest najnowszym stabilnym wydaniem 9.1 i ostatnią planowaną wersją 9.1.x przed PrestaShop 9.2. W chwili pisania PrestaShop 9.2 nadal przechodzi testy Release Candidate, więc nie należy jeszcze traktować go jako stabilnej wersji docelowej do produkcji.

Aktualizować czy migrować?

Zanim wybierzesz narzędzie, ustal, jaki projekt naprawdę realizujesz.

Dokumentacja PrestaShop rozróżnia aktualizację i migrację.

Aktualizacja zachowuje istniejący sklep i stosuje nową wersję rdzenia, utrzymując dotychczasowe dane, moduły i motyw w zakresie, na jaki pozwala proces aktualizacji.

Migracja oznacza utworzenie świeżej instalacji docelowej wersji PrestaShop i przeniesienie do niej potrzebnych danych biznesowych.

W przypadku stosunkowo uporządkowanych sklepów PrestaShop 8 aktualizacja za pomocą Update Assistant może być sprawną drogą.

Migracja może być lepszym wyborem, gdy obecny sklep zawiera lata długu technicznego, na przykład:

• bezpośrednie modyfikacje plików rdzenia;
• porzucone moduły;
• mocno zmodyfikowany starszy motyw;
• wiele nadpisań;
• nieudokumentowane zmiany schematu bazy danych;
• przestarzałe biblioteki zewnętrzne;
• stare integracje, których nikt w pełni nie rozumie;
• duże ilości nieaktualnej konfiguracji lub danych;
• powracające błędy obecne jeszcze przed aktualizacją.

Aktualna dokumentacja PrestaShop wyraźnie wskazuje, że przy zmianie głównej wersji migracja może być lepsza, ponieważ główne wydania mogą wprowadzać istotne zmiany rdzenia i niezgodności.

Najważniejsze jest, aby nie narzucać każdemu sklepowi tego samego procesu.

1. Wybierz dokładną wersję docelową PrestaShop 9

Nie twórz projektu nazwanego po prostu „aktualizacja do PrestaShop 9”.

Wybierz dokładną wersję docelową.

Na dzień 22 września 2026 r. PrestaShop 9.1.5 jest najnowszym stabilnym wydaniem 9.1. PrestaShop zapowiedział je jako ostatnie planowane wydanie gałęzi 9.1.x przed 9.2.

Dzięki temu cel jest bardziej jednoznaczny.

Jednocześnie zdecyduj o docelowej wersji PHP.

Zgodnie z oficjalnymi wymaganiami PrestaShop 9:

Jeśli zamierzasz uruchamiać PrestaShop 9.1 na PHP 8.5, środowisko testowe powinno sprawdzać dokładnie tę kombinację.

Nie aktualizuj PrestaShop na jednej wersji PHP, aby później zmienić PHP i założyć, że ta druga zmiana jest nieszkodliwa.

2. Zinwentaryzuj obecny sklep PrestaShop 8

Zanim cokolwiek zmienisz, udokumentuj posiadany sklep.

Zapisz:

• dokładną wersję PrestaShop;
• dokładną wersję PHP;
• wersję MySQL lub MariaDB;
• aktywny motyw;
• wszystkie zainstalowane moduły;
• wyłączone moduły nadal obecne na dysku;
• nadpisania;
• własne kontrolery;
• własne usługi Symfony;
• własne tabele bazy danych;
• bezpośrednie modyfikacje rdzenia;
• zadania cron;
• polecenia CLI;
• adresy URL webowych zadań cron;
• importy dostawców;
• połączenia ERP;
• połączenia PIM;
• połączenia CRM;
• integracje z marketplace;
• integracje wysyłkowe;
• bramki płatnicze;
• własne API;
• webhooki;
• konfigurację CDN;
• Redis lub inne usługi pamięci podręcznej;
• zewnętrzne silniki wyszukiwania;
• zależności od systemu plików lub magazynu obiektowego.

Następnie sklasyfikuj każdy komponent.

Przydatna klasyfikacja to:

Krytyczne — składanie zamówień, płatności, stany magazynowe, zamówienia, księgowość, ERP, wysyłka.

Ważne — import produktów, wyszukiwanie, feedy, SEO, analityka, automatyzacja e-maili.

Opcjonalne — ozdobne widżety, nieużywane integracje, eksperymenty, stare narzędzia.

Otrzymujesz w ten sposób listę priorytetów migracji.

3. Zidentyfikuj bezpośrednie zmiany rdzenia

Bezpośrednie zmiany plików rdzenia PrestaShop są szczególnie niebezpieczne podczas dużej aktualizacji.

Jeśli programista zmienił pliki w katalogach takich jak:

/classes/
/controllers/
/src/
/admin/
/themes/

bez przygotowania tych zmian jako modułu, nadpisania, modyfikacji motywu lub udokumentowanej poprawki, aktualizacja może je zastąpić.

Użyj kontroli wersji albo porównaj instalację z dokładnie odpowiadającym jej oficjalnym wydaniem PrestaShop.

Każdą różnicę należy sklasyfikować jako:

• oczekiwaną konfigurację;
• wygenerowaną zawartość lub cache;
• plik modułu lub motywu;
• celową własną poprawkę;
• nieznaną modyfikację.

Nieznane modyfikacje należy zbadać przed aktualizacją.

Nie czekaj do wdrożenia, aby odkryć, że zniknęła modyfikacja kluczowa dla biznesu.

4. Przejrzyj wszystkie nadpisania

Nadpisania zasługują na osobny audyt.

Nadpisanie PrestaShop może zastąpić zachowanie klasy lub kontrolera rdzenia. Daje to duże możliwości, ale mocno wiąże modyfikację z implementacją rdzenia.

Dla każdego nadpisania:

1. ustal, dlaczego istnieje;
2. znajdź osobę odpowiedzialną za modyfikację;
3. porównaj je z wersją klasy w PrestaShop 9;
4. sprawdź, czy pierwotny problem nie został już rozwiązany w rdzeniu;
5. usuń niepotrzebne nadpisania;
6. zaimplementuj wymagane działanie ponownie z użyciem hooków lub usług, jeśli istnieje już bezpieczniejszy punkt rozszerzenia.

Nadpisanie utworzone przed laty dla PrestaShop 1.7 może nadal być kopiowane między wydaniami, choć nikt już nie pamięta, dlaczego istnieje.

Aktualizacja głównej wersji to odpowiedni moment, aby przestać przenosić niepotrzebny kod.

5. Przeprowadź audyt zgodności modułów

Moduły są jednym z największych źródeł ryzyka przy zmianie głównej wersji.

Dla każdego kluczowego modułu sprawdź, czy dostawca wyraźnie obsługuje Twoją dokładną wersję docelową PrestaShop 9.

Nie polegaj na deklaracjach takich jak:

Zgodny z PrestaShop 1.7+

Mówi to bardzo niewiele o Symfony 6.4, nowszych wersjach PHP, nowych stronach panelu administracyjnego czy zmienionych strukturach danych.

Dla każdego modułu przetestuj:

• instalację;
• aktualizację z aktualnie zainstalowanej wersji modułu;
• stronę konfiguracji;
• trasy panelu administracyjnego;
• hooki interfejsu sklepu;
• hooki produktów;
• hooki zamówień;
• punkty końcowe Ajax;
• punkty końcowe cron;
• polecenia CLI;
• migracje bazy danych;
• działanie multistore;
• działanie dezinstalacji.

Moduły płatności wymagają dokładniejszych testów

W modułach płatności przetestuj więcej niż udaną płatność kartą.

Przetestuj:

• udaną płatność;
• odrzuconą płatność;
• anulowaną płatność;
• opóźnione powiadomienie zwrotne;
• zduplikowane powiadomienie zwrotne;
• zwrot pieniędzy;
• częściowy zwrot pieniędzy;
• synchronizację statusu płatności;
• tworzenie zamówień;
• obsługę walut;
• zakupy jako gość;
• zakupy zarejestrowanego klienta.

Moduł płatności może poprawnie ładować się w panelu administracyjnym, a mimo to zawodzić przy asynchronicznych powiadomieniach zwrotnych.

6. Usuń moduły, których już nie potrzebujesz

Aktualizacja głównej wersji jest łatwiejsza, jeśli najpierw ograniczysz niepotrzebne zależności.

Jeśli moduł jest wyłączony i nieużywany od dwóch lat, zastanów się, czy nadal powinien istnieć na serwerze produkcyjnym.

Stare moduły mogą powodować:

• problemy ze zgodnością PHP;
• zagrożenia bezpieczeństwa;
• konflikty autoloadingu;
• bałagan w bazie danych;
• mylące hooki;
• niepotrzebne ostrzeżenia aktualizacji.

Usuwaj porzucone komponenty dopiero po potwierdzeniu, że żadne zadanie zaplanowane, eksport danych, proces zamówień ani potrzeba raportowania historycznego od nich nie zależy.

7. Przeprowadź audyt motywu

Motyw to kolejny istotny obszar zgodności.

PrestaShop 9 wprowadził duże zmiany interfejsu sklepu, a PrestaShop 9.1 ustanowił Hummingbird 2 domyślnym motywem nowych instalacji.

Nie oznacza to, że istniejący sklep musi natychmiast wymienić motyw.

Oznacza to, że obecny motyw trzeba przetestować.

Sprawdź:

• stronę główną;
• strony kategorii;
• strony produktów;
• wyniki wyszukiwania;
• strony producentów;
• strony dostawców;
• koszyk;
• proces składania zamówienia;
• logowanie klienta;
• rejestrację;
• strony konta;
• historię zamówień;
• strony kontaktowe;
• strony CMS;
• dane strukturalne;
• kanoniczne adresy URL;
• paginację;
• responsywność;
• komponenty JavaScript;
• typy obrazów.

Zwróć szczególną uwagę na własne szablony zależne od tablic presenterów lub wewnętrznych struktur danych.

Motyw może wyglądać poprawnie, a jednocześnie bez widocznego ostrzeżenia generować uszkodzone dane strukturalne lub nieprawidłowe ceny.

8. Utwórz pełną kopię zapasową

Przed pierwszą próbą aktualizacji utwórz pełną kopię zapasową.

Uwzględnij co najmniej:

Bazę danych

Utwórz pełny zrzut bazy danych.

Sprawdź, czy zawiera:

• strukturę;
• dane;
• wyzwalacze, jeśli ich używasz;
• poprawne kodowanie znaków.

Pliki

Wykonaj kopię:

• rdzenia PrestaShop;
• modułów;
• motywów;
• obrazów;
• katalogów przesyłania i pobierania;
• tłumaczeń;
• własnych skryptów;
• konfiguracji;
• .htaccess;
• plików specyficznych dla środowiska.

Konfiguracja infrastruktury

Udokumentuj:

• konfigurację PHP;
• pule PHP-FPM;
• konfigurację Apache lub Nginx;
• definicje cron;
• zadania supervisor/systemd;
• konfigurację Redis;
• konfigurację CDN;
• zmienne środowiskowe.

Baza danych i plik ZIP nie stanowią kompletnego planu odtwarzania po awarii, jeśli nikt nie wie, jak skonfigurowano serwer.

9. Przetestuj kopię zapasową przez jej odtworzenie

Ten krok jest często pomijany.

Nie poprzestawaj na utworzeniu kopii.

Odtwórz ją.

Pomyślne odtworzenie dowodzi, że:

• archiwum nie jest uszkodzone;
• wszystkie pliki są obecne;
• zrzut bazy danych importuje się poprawnie;
• dane uwierzytelniające są dostępne;
• ścieżki są udokumentowane;
• aplikacja może się uruchomić;
• potrzebne usługi zewnętrzne są znane.

Najgorszy możliwy moment na odkrycie wadliwej kopii to wycofywanie zmian w produkcji.

10. Zbuduj realistyczne środowisko testowe

Utwórz kopię testową przypominającą produkcję.

Środowisko powinno wykorzystywać:

• docelową wersję PHP;
• podobną konfigurację serwera;
• niedawną kopię produkcyjnej bazy danych;
• reprezentatywne obrazy produktów;
• ten sam motyw;
• te same kluczowe moduły;
• te same polecenia cron.

Następnie je odizoluj.

Nie dopuść, aby środowisko testowe:

• wysyłało prawdziwe e-maile do klientów;
• obciążało rzeczywiste metody płatności;
• wysyłało zamówienia do produkcyjnego ERP;
• modyfikowało systemy dostawców;
• pojawiało się w Google;
• wysyłało rzeczywiste zdarzenia marketingowe.

Środowisko testowe powinno być realistyczne, ale nie stawać się drugim systemem produkcyjnym.

11. Sprawdź wymagania systemowe PrestaShop 9

Przed aktualizacją sprawdź, czy serwer spełnia aktualne wymagania PrestaShop.

Oficjalne wymagania PrestaShop 9 obejmują obecnie:

• Apache 2.4 lub nowszy albo zgodną konfigurację Nginx;
• co najmniej MySQL 5.7 lub co najmniej MariaDB 10.2;
• zalecany limit pamięci PHP wynoszący co najmniej 512 MB na skrypt;
• rozszerzenia PHP wymagane przez platformę.

Nie interpretuj „minimum” jako „zalecane dla dużego sklepu”.

Duże katalogi, generowanie obrazów, masowe importy i operacje panelu administracyjnego mogą wymagać znacznie większej mocy CPU, pamięci i wydajności wejścia/wyjścia.

12. Zainstaluj lub zaktualizuj Update Assistant

Nowoczesny Update Assistant zastąpił wcześniejsze podejście „1-Click Upgrade”.

Update Assistant 7 wprowadził przeprojektowany proces aktualizacji obejmujący:

• interfejs panelu administracyjnego;
• interfejs wiersza poleceń;
• sprawdzanie wymagań;
• funkcje tworzenia i odtwarzania kopii zapasowych;
• ulepszone logowanie;
• lepsze raportowanie błędów;
• większą niezawodność dla dużych sklepów.

PrestaShop 9 można aktualizować przez panel administracyjny albo CLI Update Assistant.

Ścieżka przez panel administracyjny

Interfejs panelu jest wygodny dla zwykłych sklepów i aktualizacji z prowadzeniem krok po kroku.

Ścieżka CLI

CLI jest szczególnie przydatne dla:

• dużych sklepów;
• programistów;
• automatyzacji;
• CI/CD;
• środowisk z ograniczeniami czasu wykonywania żądań webowych;
• aktualizacji, podczas których przydają się szczegółowe logi w terminalu.

Oficjalna dokumentacja wskazuje, że CLI może ominąć typowe ograniczenia PHP-FPM lub serwera WWW, takie jak czas wykonywania żądania.

13. Sprawdź wymagania przed rozpoczęciem

Nie ignoruj ostrzeżeń.

Użyj kontroli Update Assistant, aby potwierdzić:

• dostępność wersji docelowej;
• wymagania serwera;
• zgodność PHP;
• uprawnienia systemu plików;
• zgodność modułów;
• miejsce na dysku.

Ostrzeżenie wyglądające niegroźnie przed aktualizacją może być przyczyną awarii sklepu w połowie procesu.

Najpierw rozwiąż znane problemy.

14. Zatrzymaj zadania w tle zmieniające dane

Przed właściwym przełączeniem produkcji wstrzymaj zadania, które mogą zmieniać ważne dane.

Przykłady:

• importy produktów dostawców;
• synchronizacja stanów magazynowych;
• synchronizacja cen;
• eksporty zamówień;
• aktualizacje ERP;
• importy marketplace;
• generowanie obrazów;
• tworzenie feedów;
• automatyczna synchronizacja kategorii.

W przeciwnym razie aktualizacja może zmieniać struktury bazy, podczas gdy inny proces zapisuje dane zgodnie z założeniami starej wersji.

W sklepach o dużym wolumenie ustal krótkie, kontrolowane okno zamrożenia zmian.

15. Pierwszą aktualizację wykonaj tylko w środowisku testowym

Pierwsza pełna aktualizacja nigdy nie powinna odbywać się w produkcji.

Uruchom ją w środowisku testowym i zachowaj wszystkie logi.

Zapisz:

• czas rozpoczęcia;
• czas zakończenia;
• wersję PHP;
• wersję Update Assistant;
• docelową wersję PrestaShop;
• ostrzeżenia;
• błędy SQL;
• błędy modułów;
• błędy systemu plików;
• poprawki po aktualizacji.

Nie uznawaj próby za udaną tylko dlatego, że końcowy ekran informuje o zakończeniu aktualizacji.

Aktualizacja jest udana dopiero po testach regresji procesów biznesowych.

16. Ostrożnie wyczyść i odbuduj pamięć podręczną

Po dużej aktualizacji wiele warstw cache może zawierać nieaktualną zawartość.

W zależności od infrastruktury sprawdź:

• cache PrestaShop;
• cache Symfony;
• OPcache;
• Redis;
• cache odwrotnego proxy;
• cache CDN;
• zasoby przeglądarki lub zasoby wersjonowane.

Podczas diagnozowania nie czyść losowo wszystkiego wiele razy.

Wiedz, która warstwa cache odpowiada za daną zawartość.

Strona może wyglądać na „zepsutą po aktualizacji” tylko dlatego, że CDN nadal podaje stare pliki CSS lub JavaScript.

17. Przeprowadź pełne testy regresji

Przygotuj pisemną listę kontrolną regresji.

Interfejs sklepu

Przetestuj:

• stronę główną;
• menu;
• kategorie;
• filtry;
• wyszukiwanie;
• strony produktów;
• kombinacje;
• obrazy produktów;
• ceny;
• rabaty;
• dostępność magazynową;
• koszyk;
• proces składania zamówienia.

Klienci

Przetestuj:

• rejestrację;
• logowanie;
• resetowanie hasła;
• adresy;
• historię zamówień;
• zamówienia gości.

Zamówienia

Przetestuj:

• nowe zamówienie;
• płatność;
• fakturę;
• dokument dostawy;
• zmianę statusu zamówienia;
• zwrot pieniędzy;
• częściowy zwrot pieniędzy;
• powiadomienia e-mail.

Katalog

Przetestuj:

• tworzenie produktu;
• edycję produktu;
• tworzenie kombinacji;
• aktualizację stanów magazynowych;
• zmianę kategorii;
• przesyłanie obrazów;
• regenerację typów obrazów;
• działania masowe.

Automatyzacja

Uruchom:

• zadania cron;
• polecenia CLI;
• importy dostawców;
• eksporty;
• synchronizację ERP;
• synchronizację marketplace;
• feedy.

Multistore

Jeśli korzystasz z multistore, powtórz kluczowe kontrole w kontekście każdego sklepu.

To niezbędne, ponieważ konfiguracja i powiązania mogą działać inaczej w poszczególnych sklepach.

18. Sprawdź integralność bazy danych i logi

Po aktualizacji przejrzyj:

• logi błędów PHP;
• logi PrestaShop;
• logi serwera WWW;
• logi Update Assistant;
• błędy bazy danych;
• wolne zapytania;
• logi cron.

Szukaj problemów, których użytkownicy mogą od razu nie zauważyć.

Przykłady obejmują:

• ostrzeżenia o przestarzałych funkcjach zalewające logi;
• ciągle nieudane zadania;
• brakujące kolumny bazy danych oczekiwane przez moduł;
• zapytania SQL skanujące miliony wierszy;
• powiadomienia zwrotne integracji zwracające HTTP 500.

19. Porównaj wydajność przed aktualizacją i po niej

Przed aktualizacją wykonaj pomiary bazowe.

Przydatne metryki to:

• TTFB strony głównej;
• TTFB kategorii;
• TTFB produktu;
• czas odpowiedzi procesu składania zamówienia;
• czas ładowania strony produktu w panelu administracyjnym;
• wolne zapytania SQL;
• zużycie pamięci PHP;
• czas trwania importu;
• czas generowania obrazów.

Powtórz te same testy po aktualizacji.

PrestaShop 9 zawiera usprawnienia architektury i wydajności, ale końcowa wydajność zależy też od modułów, motywu, zapytań do bazy danych i konfiguracji hostingu.

Bez punktu odniesienia trudno zdiagnozować „wydaje się wolniejszy”.

20. Przeskanuj sklep w poszukiwaniu problemów SEO

Duża aktualizacja może wpłynąć na techniczne SEO, nawet gdy sklep wygląda poprawnie.

Uruchom crawler przed wdrożeniem i po nim.

Sprawdź:

• kody statusu HTTP;
• adresy URL produktów;
• adresy URL kategorii;
• przekierowania;
• znaczniki kanoniczne;
• hreflang;
• znaczniki title;
• opisy meta;
• dyrektywy robots;
• mapę witryny;
• paginację;
• dane strukturalne.

PrestaShop 9 zawiera usprawnienia URL i SEO, ale zmiana już zaindeksowanych adresów bez strategii przekierowań nadal może zaszkodzić ruchowi organicznemu.

21. Określ warunek wycofania przed produkcją

Nie decyduj o wycofaniu zmian dopiero wtedy, gdy klienci nie mogą już płacić.

Ustal obiektywne warunki wycofania.

Przykłady:

• proces składania zamówienia pozostaje niedostępny po określonym czasie;
• powiadomienia zwrotne płatności zawodzą;
• synchronizacja ERP uszkadza stany magazynowe;
• kluczowe zamówienia nie są tworzone;
• błędów migracji bazy danych nie można bezpiecznie rozwiązać;
• odsetek błędów sklepu przekracza uzgodniony próg.

Następnie udokumentuj procedurę wycofania.

Wycofanie zwykle wymaga odtworzenia zarówno plików, jak i bazy danych z tego samego momentu.

Przywrócenie starych plików aplikacji z częściowo zaktualizowaną bazą może pogorszyć sytuację.

22. Zaplanuj przełączenie produkcji

Gdy środowisko testowe przejdzie kontrole, przygotuj listę produkcyjną.

Typowa kolejność to:

1. ogłoś okno konserwacji;
2. sprawdź najnowszą kopię zapasową;
3. zatrzymaj zadania cron zmieniające dane;
4. w razie potrzeby włącz tryb konserwacji;
5. utwórz końcowy zrzut bazy danych;
6. zapisz znacznik czasu wdrożenia;
7. uruchom aktualizację;
8. wyczyść wymagane cache;
9. wykonaj podstawowe testy działania;
10. przetestuj składanie zamówień;
11. przetestuj powiadomienie zwrotne płatności;
12. przetestuj panel administracyjny;
13. wznów integracje;
14. monitoruj logi i metryki;
15. ponownie otwórz sklep.

Przypisz odpowiedzialność za każdy krok.

Podczas dużej aktualizacji niejasności kosztują czas.

23. Uważnie monitoruj sklep po uruchomieniu

Pierwsze udane zamówienie nie kończy projektu.

Monitoruj sklep przynajmniej przez kilka kolejnych cykli biznesowych.

Obserwuj:

• błędy HTTP 500;
• nieudane płatności;
• błędy powiadomień zwrotnych;
• zablokowane kolejki;
• awarie cron;
• synchronizację stanów magazynowych;
• porzucone koszyki;
• nietypowe porzucenia procesu zamówienia;
• błędy pamięci PHP;
• wolne zapytania;
• wzrost zajętości dysku;
• zgłoszenia do obsługi klienta.

Niektóre błędy pojawiają się tylko przy rzadkich produktach, nietypowych kombinacjach, mało popularnych walutach lub określonych grupach klientów.

24. Tymczasowo zachowaj stare środowisko

Nie niszcz starego środowiska natychmiast po migracji.

Zachowaj zabezpieczoną kopię przez rozsądny krótki okres.

Może pomóc porównać:

• wartości konfiguracji;
• dane produktów;
• działanie modułów;
• działanie adresów URL;
• przetwarzanie zamówień;
• wygenerowane pliki.

Nie pozostawiaj starej, niezałatanej kopii publicznie dostępnej.

Typowe błędy aktualizacji z PrestaShop 8 do 9

Aktualizowanie najpierw produkcji

Zamienia to testowanie zgodności w rzeczywisty incydent.

Jednoczesna zmiana PrestaShop, PHP, serwera i motywu

Zbyt wiele zmiennych utrudnia odizolowanie przyczyn awarii.

Zaufanie deklaracji „zgodny” bez testów

Moduł może technicznie dać się zainstalować, choć ważny proces nie działa.

Ignorowanie zadań cron

Zadania zaplanowane mogą używać innego pliku wykonywalnego PHP lub ładować kod inaczej niż żądania webowe.

Zapominanie o powiadomieniach zwrotnych

Powiadomienia płatności i marketplace mogą zawodzić, nawet gdy ręczne testy w przeglądarce przechodzą.

Brak testów multistore

Problemy kontekstu sklepu często pojawiają się tylko poza sklepem domyślnym.

Brak planu wycofania zmian

Kopia zapasowa bez udokumentowanej procedury odtworzenia nie wystarczy.

Aktualizacja a świeża migracja: praktyczna zasada

Rozważ aktualizację istniejącej instalacji przez Update Assistant, gdy:

• obecny sklep PrestaShop 8 jest w dobrym stanie;
• moduły są aktywnie utrzymywane;
• motyw jest zgodny lub można go dostosować;
• modyfikacje są udokumentowane;
• testy w środowisku testowym kończą się powodzeniem.

Rozważ migrację do świeżej instalacji, gdy:

• obecna instalacja ma znaczny dług techniczny;
• wiele plików rdzenia jest zmodyfikowanych;
• stare nadpisania dominują w architekturze;
• motyw i tak wymaga całkowitej przebudowy;
• zestaw modułów jest wymieniany;
• obecna baza zawiera lata przestarzałych własnych struktur;
• odtwarzalność jest słaba.

Bardziej uporządkowana opcja bywa tańsza, nawet jeśli początkowo wygląda na bardziej pracochłonną.

Lista kontrolna przed aktualizacją z PrestaShop 8 do 9

• Dokładna wersja źródłowa PrestaShop udokumentowana
• Dokładna wersja docelowa PrestaShop 9 wybrana
• Docelowa wersja PHP wybrana
• Wersja bazy danych sprawdzona
• Zgodność motywu przetestowana
• Zgodność kluczowych modułów przetestowana
• Moduły płatności przetestowane
• Moduły wysyłkowe przetestowane
• Nadpisania sprawdzone
• Modyfikacje rdzenia zidentyfikowane
• Zadania cron udokumentowane
• Integracje zewnętrzne udokumentowane
• Pełna kopia zapasowa plików utworzona
• Pełna kopia zapasowa bazy danych utworzona
• Odtworzenie kopii zapasowej przetestowane
• Środowisko testowe przygotowane
• Indeksowanie przez wyszukiwarki zablokowane w środowisku testowym
• Rzeczywiste pobieranie płatności wyłączone w środowisku testowym
• Update Assistant zaktualizowany
• Sprawdzenie wymagań zakończone powodzeniem
• Miejsce na dysku zweryfikowane
• Procedura wycofania zmian spisana

Lista kontrolna po aktualizacji

• Interfejs sklepu się otwiera
• Panel administracyjny się otwiera
• Strony produktów działają
• Kategorie działają
• Wyszukiwanie działa
• Kombinacje działają
• Koszyk działa
• Zakupy jako gość działają
• Zakupy zarejestrowanego klienta działają
• Każda metoda płatności przetestowana
• Powiadomienia zwrotne płatności przetestowane
• Zamówienia tworzone poprawnie
• Faktury generowane
• Zwrot pieniędzy przetestowany
• Aktualizacje stanów magazynowych działają
• Tworzenie produktów działa
• Edycja produktów działa
• Przesyłanie obrazów działa
• Zadania cron działają
• Polecenia CLI działają
• Integracje ERP/PIM/CRM działają
• Multistore przetestowany
• Logi błędów przejrzane
• Wolne zapytania przejrzane
• Skanowanie SEO zakończone
• Mapa witryny sprawdzona
• Wydajność porównana z punktem odniesienia

Najczęściej zadawane pytania

Czy mogę aktualizować bezpośrednio z PrestaShop 8 do PrestaShop 9?

PrestaShop udostępnia Update Assistant dla obsługiwanych ścieżek aktualizacji, w tym przejścia do głównej wersji PrestaShop 9. Zawsze sprawdź aktualne wymagania Update Assistant dla dokładnej wersji źródłowej i docelowej przed rozpoczęciem. W przypadku mocno zmodyfikowanych sklepów dokumentacja PrestaShop zaleca też rozważenie świeżej migracji przy zmianie głównych wersji.

Czy używać Update Assistant w panelu administracyjnym, czy przez CLI?

Panel administracyjny jest wygodny przy zwykłych aktualizacjach z prowadzeniem krok po kroku. CLI przydaje się szczególnie w dużych sklepach, automatyzacji, CI/CD i środowiskach, w których limity wykonywania żądań webowych mogą przerwać długie operacje.

Jakiej wersji PHP użyć?

Dla PrestaShop 9.0 zalecane jest obecnie PHP 8.4. Dla PrestaShop 9.1 zalecane jest PHP 8.5. Przetestuj każdy kluczowy moduł z docelową wersją PHP przed zmianą produkcji.

Czy PrestaShop 9.2 jest już stabilny?

Na dzień 22 września 2026 r. PrestaShop 9.2 przechodzi testy Release Candidate. W produkcji używaj aktualnego stabilnego wydania 9.x, chyba że świadomie uczestniczysz w testach przedpremierowych.

Ile trwa aktualizacja z PrestaShop 8 do 9?

Samo polecenie aktualizacji może działać stosunkowo szybko, ale profesjonalny projekt obejmuje inwentaryzację, poprawki zgodności, środowisko testowe, testy regresji, testy wydajności i planowanie wycofania. Złożoność zależy bardziej od modyfikacji niż wyłącznie od liczby produktów.

Czy mój motyw nadal będzie działał w PrestaShop 9?

Możliwe, ale trzeba go przetestować. Własne motywy mogą zależeć od starych danych szablonów, działania JavaScript lub struktur interfejsu sklepu. Nie zakładaj zgodności wyłącznie na podstawie wyglądu.

Czy moje moduły nadal będą działać?

Niektóre tak, inne mogą wymagać aktualizacji, a porzucone moduły mogą potrzebować zastąpienia. Kluczowe moduły biznesowe testuj indywidualnie.

Czy muszę przejść na Hummingbird 2?

Nie. Hummingbird 2 jest domyślnym motywem nowych instalacji PrestaShop 9.1, ale istniejący sklep może nadal używać innego zgodnego motywu.

Czy wyłączyć zadania cron podczas aktualizacji?

Zatrzymaj zadania, które mogą modyfikować produkty, stany magazynowe, ceny, zamówienia lub inne dane podczas przełączenia produkcji. Wznów je dopiero po pomyślnych podstawowych testach działania zaktualizowanego sklepu.

Jaki jest najważniejszy środek bezpieczeństwa aktualizacji?

Realistyczna próba w środowisku testowym oraz przetestowane wycofanie zmian. Te dwa kroki zamieniają niepewną aktualizację w kontrolowane wdrożenie.

Powiązane przewodniki i zasoby PrestaShop 9

• sprawdź wymagania systemowe PrestaShop 9
• przejrzyj przewodnik optymalizacji wydajności
• Crash Snapshot Lite
• dokumentacja PrestaSuite

Chroń stare adresy URL podczas aktualizacji

Jeśli aktualizacja lub migracja zmienia adresy produktów, kategorii lub stron CMS, przygotuj przekierowania przed przełączeniem. Zobacz proces przekierowań 301/302 przy migracji PrestaShop i zarządzaj dokładnymi regułami za pomocą URL Redirect Migration Helper Lite.