Aktualizacja PrestaShop 1.7 do 8 lub 9 - plan, zgodność i testy

Aktualizacja PrestaShop 1.7 do 8 lub 9 zaczyna się od dokładnej wersji sklepu, PHP, motywu i modułów. Samo „mam 1.7” nie wystarcza do wybrania pliku aktualizacji ani kolejności zmiany środowiska. Poniżej znajdziesz plan dla właściciela sklepu i osoby technicznej: jakie dane zebrać, co sprawdzić na kopii i jakie dowody muszą poprzedzić zgodę na przełączenie.

Potrzebujesz wykonania prac? Zakres zakupowy i sposób wyceny znajdziesz na stronie aktualizacji PrestaShop 8/9. Ten poradnik służy przygotowaniu decyzji i testów.

PrestaShop 8 czy 9: najpierw zgodność, potem wersja docelowa

Nie wybieraj starszej gałęzi wyłącznie dlatego, że wydaje się bardziej przewidywalna, ani nowszej tylko z powodu numeru. Porównaj aktualny status wsparcia, wymagania środowiska oraz potwierdzenia autorów krytycznych dodatków. Wersję docelową zapisz z numerem poprawki, a nie jako samo „9”.

Źródła zakresów: archiwalne wymagania PrestaShop 1.7, wymagania PrestaShop 8 oraz wymagania PrestaShop 9. Zestaw je z cyklem wsparcia PHP; techniczna możliwość uruchomienia nie oznacza dostępności poprawek bezpieczeństwa.

Status poprawek trzeba czytać dla konkretnego wydania i podatności. Nieprawdziwe jest kategoryczne założenie, że dla wszystkich sklepów 1.7 nie istnieją żadne oficjalne działania naprawcze. Komunikat PrestaShop z kwietnia 2026 r. o wydaniu 8.2.6 opisuje także rozwiązanie awaryjne dla starszych instalacji. Doraźne ograniczenie podatności nie zastępuje planu modernizacji całego sklepu.

Sprawdź komunikat bezpieczeństwa PrestaShop 8.2.6 i nowsze komunikaty producenta przed wyznaczeniem terminu prac.

Czy można przejść bezpośrednio z PrestaShop 1.7 do 9?

Nie ma jednej odpowiedzi dla całej rodziny 1.7. Wybór zależy od wersji źródłowej, zgodnej wersji Update Assistant, dostępnego środowiska PHP i stanu dodatków. Nie zakładaj automatycznie ani obowiązkowego etapu przez 8, ani możliwości jednego skoku dla każdego sklepu. Najpierw sprawdź wymagania narzędzia i planowanej wersji, potem odtwórz dokładną ścieżkę na izolowanej kopii.

Oficjalna dokumentacja PrestaShop 9 opisuje aktualizację przez Update Assistant w panelu lub CLI. Repozytorium modułu zawiera kontrole wymagań i modułów, tworzenie kopii oraz odtwarzanie. Wynik kontroli narzędzia jest jednym z dowodów technicznych; nie obejmuje całego procesu sprzedaży ani wszystkich modyfikacji wykonanych przez poprzednią agencję.

Dokumentacja: aktualizacja PrestaShop 9 i oficjalny Update Assistant. Używaj wydania przeznaczonego do takiego zastosowania, nie przypadkowego archiwum gałęzi rozwojowej.

Zakres starej procedury wskazuje dokumentacja aktualizacji PrestaShop 1.7.

Krok 1. Inwentaryzacja sklepu i odpowiedzialności

• Zapisz wersje PrestaShop, PHP w procesie WWW i CLI, serwera bazy oraz Update Assistant. Sprawdź też dostępne miejsce, uprawnienia procesu i limity hostingu dla wybranej procedury; nie kopiuj uniwersalnych wartości z innego serwera.
• Wyeksportuj listę modułów z wersjami, autorem, licencją i rolą w sprzedaży. Osobno oznacz płatności, dostawy, checkout, faktury, podatki, consent, feedy oraz połączenia ERP/Allegro.
• Zidentyfikuj motyw, motyw potomny, override i zmiany core. Dostęp do panelu nie mówi, czy kod różni się od oficjalnego wydania.
• Zapisz właściciela decyzji biznesowej, wykonawcę technicznego i osobę zatwierdzającą odbiór. Określ, kto może zatrzymać przełączenie oraz kto uzgodni zamówienia przy awarii.

Wypełniony przykład macierzy kompatybilności

Poniższy sklep DEMO nie jest wdrożeniem klienta ani wykonanym audytem. To syntetyczny brief pokazujący, dlaczego zgodność samego silnika nie wystarcza do zgody na start. Wpisy są przykładowymi danymi i decyzjami, nie potwierdzeniem testów. W rzeczywistym protokole dodaj datę, dokładny numer poprawki, źródło deklaracji i link do logu próby.

Krok 2. Backup i staging bez skutków w prawdziwym sklepie

Kopia musi obejmować spójny zestaw bazy, plików, konfiguracji i danych potrzebnych do odtworzenia. Przechowuj ją poza katalogiem publicznym z ograniczonym dostępem. Sprawdzenie rozmiaru archiwum nie jest próbą odtworzenia: uruchom kopię w osobnym środowisku i zapisz, czy działa panel, katalog oraz odczyt zamówień.

• Zabezpiecz staging kontrolą dostępu, np. uwierzytelnianiem na serwerze lub ograniczeniem IP. Noindex jest dodatkową dyrektywą dla wyszukiwarki, nie ochroną danych ani panelu.
• Oddziel bazę, magazyn plików, kolejki, zadania cron i klucze integracji od produkcji. Zablokuj prawdziwe e-maile oraz automatyczne zamówienia u dostawców.
• Użyj środowisk testowych operatorów, gdy są dostępne; ogranicz i odpowiednio zabezpiecz dane klientów w kopii. Ustal dostęp oraz termin usunięcia danych testowych.
• Odnotuj konfigurację środowiska i przebieg odtwarzania. Po próbie nie zostawiaj publicznych archiwów, instalatorów ani plików diagnostycznych.

Krok 3. Próba aktualizacji i rejestr zmian

Na kopii wykonaj uzgodnioną ścieżkę narzędziem zgodnym z wersją źródłową. Zapisz jego wersję, wybraną wersję docelową, kolejność zmian PHP, wynik kontroli wstępnej i log wykonania. Każdy naprawiony moduł lub override musi wrócić do listy zmian, żeby produkcja nie była odtwarzana z pamięci.

Nie mieszaj w jednym niekontrolowanym podejściu aktualizacji core, przebudowy motywu, zmiany domeny i nowego ERP. Jeśli projekt wymaga kilku zmian, przygotuj dla nich osobne kryteria odbioru i możliwość wskazania, która zmiana spowodowała regresję. Przenoszenie gotowych plików stagingu nie rozwiązuje aktualizacji bazy ani nowych zamówień przyjętych w czasie prac.

Krok 4. Testy odbioru: liczba produktów nie wystarczy

Porównaj rekordy i reprezentatywne pola: wariant, podatek, walutę, cenę, rabat, metodę dostawy, sumę zamówienia i powiązania klienta. Po pozytywnym teście panelu wykonaj ścieżkę kupującego na desktopie i telefonie. Samo dotarcie do bramki płatności nie potwierdza obsługi płatności ani powiadomienia operatora.

Do wyniku rzeczywistego testu dopisz datę, wersje, osobę wykonującą oraz PASS albo FAIL z opisem. Nie zamieniaj „producent deklaruje zgodność” na PASS. Jeśli nie wykonano próby, status to „nie przetestowano”, a krytyczny brak blokuje zgodę na wdrożenie.

Krok 5. Przełączenie produkcji i granica rollbacku

• Ustal okno prac na podstawie próby, nie arbitralnej liczby godzin. Zapisz punkt wstrzymania zapisów i sposób obsługi zamówień, płatności oraz zmian stanów, które docierają z zewnętrznych systemów.
• Przygotuj świeżą, spójną kopię tuż przed uzgodnionym przełączeniem. Wykonaj odtworzoną wcześniej procedurę i kontrolę różnic danych.
• Wyłącz testowe ustawienia płatności, ale nie uruchamiaj wszystkich kolejek naraz bez uzgodnienia. Zweryfikuj domeny callbacków, adresy API, e-maile i harmonogramy.
• Sprawdź pełną ścieżkę zamówienia w sposób uzgodniony z właścicielem i operatorem płatności. Rzeczywista transakcja produkcyjna wymaga zgody oraz prawidłowego rozliczenia.
• Jeżeli po wznowieniu sprzedaży potrzebny jest rollback, najpierw zabezpiecz nowe dane. Odtworzenie starej bazy bez uzgodnienia delty może usunąć nowe zamówienia lub rozjechać stany.

Zgodę GO wydaj dopiero po zamknięciu krytycznych błędów i akceptacji pozostałych ryzyk przez właściciela. Plan STOP powinien wskazywać objawy uruchamiające wycofanie, osobę decyzyjną, punkt odtworzenia i obsługę nowych transakcji. Backup to narzędzie odtwarzania, nie kompletna procedura biznesowa.

SEO i analityka po aktualizacji: co naprawdę porównać

Aktualizacja silnika nie gwarantuje wzrostu pozycji ani konwersji. Najpierw sprawdź, czy wdrożenie nie zepsuło istniejących adresów, treści i pomiaru. Porównaj statusy HTTP, canonical, robots/noindex, linki wewnętrzne, sitemapę i dane strukturalne na reprezentatywnych produktach, kategoriach i stronach treści.

• Zapisz datę wdrożenia w raporcie. W GSC porównuj te same URL-e i klastry zapytań z uwzględnieniem sezonu, urządzenia i opóźnienia danych; krótkie wahanie nie dowodzi wpływu aktualizacji.
• Zweryfikuj zdarzenia e-commerce i identyfikator transakcji bez duplikacji. Porównaj zamówienia z bazą sklepu; raport analityczny nie zastępuje księgi zamówień.
• Mierz wydajność w porównywalnych warunkach. Rozdziel test laboratoryjny od danych rzeczywistych użytkowników; nie obiecuj poprawy INP na podstawie samego pojedynczego testu ładowania.

Szczegółowe kryteria rozwijamy w poradnikach SEO PrestaShop i optymalizacji wydajności PrestaShop.

Od czego zależą koszt i termin aktualizacji?

Do porównania ofert przekaż ten sam brief: dokładne wersje, listę dodatków i zmian własnych, wielkość danych, integracje, liczbę sklepów i języków, wymagane scenariusze testowe oraz warunki przełączenia. Oddziel koszt licencji, dostosowania kodu, środowiska, testów i opieki po starcie. Brak wyceny pozycji nie oznacza kosztu zero.

Nie da się rzetelnie przypisać liczby dni na podstawie samej liczby modułów. Jeden własny checkout lub nietypowa integracja może wymagać większej pracy niż wiele prostych dodatków. W harmonogramie zaznacz zależności od producentów i decyzji właściciela oraz moment, w którym po próbie można potwierdzić okno produkcyjne.

Sprawdź zakres usługi aktualizacji PrestaShop. Jeśli projekt obejmuje przenoszenie danych z innego systemu, domeny albo przebudowę struktury, oddziel go od samej aktualizacji i opisz w zakresie migracji PrestaShop.