Aktualizacja PrestaShop 1.7 do wersji 8 lub 9 — poradnik krok po kroku 2026
Sklep na PrestaShop 1.7 to dziś realne ryzyko bezpieczeństwa i utraty sprzedaży. Ten poradnik prowadzi Cię krok po kroku przez audyt, backup, staging, wybór wersji 8 lub 9, testy i wdrożenie — z zachowaniem SEO i integracji.
Jeśli Twój sklep nadal działa na PrestaShop 1.7, pytanie brzmi nie „czy aktualizować”, tylko „jak zrobić to tak, żeby nie stracić zamówień, pozycji w Google ani integracji z Allegro, kurierami czy ERP”. W 2026 roku sensowne cele to PrestaShop 8.2.x (dojrzała gałąź z szerokim wsparciem modułów) albo PrestaShop 9.x (nowsza architektura — wymaga dokładniejszego audytu kompatybilności). Ten poradnik prowadzi Cię przez cały proces: od audytu po wdrożenie na produkcję.
Dla kogo jest ten poradnik
Ten artykuł jest dla właścicieli sklepów PrestaShop 1.7, managerów e-commerce i osób technicznych, które muszą zaplanować migrację. Zakładamy, że masz dostęp do panelu hostingowego, FTP/SFTP i bazy danych (phpMyAdmin lub CLI). Jeśli sklep ma dziesiątki modułów, customowy szablon lub integracje z WMS/ERP — na końcu artykułu opisujemy, kiedy warto zlecić migrację specjalistom zamiast robić to samodzielnie.
Jeśli wolisz od razu przekazać migrację zespołowi — sprawdź naszą usługę migracji PrestaShop lub audytu sklepu przed podjęciem decyzji.
Dlaczego PrestaShop 1.7 trzeba zaktualizować w 2026 roku
Gałąź 1.7 nie otrzymuje już oficjalnych poprawek bezpieczeństwa — luki w starym core i modułach pozostają otwarte.
Nowe moduły płatności (BLIK, raty), kurierów (InPost, DPD) i marketplace (Allegro, Erli) są rozwijane pod PrestaShop 8 i 9.
Hostingi podnoszą minimalną wersję PHP — stary sklep blokuje modernizację serwera i spowalnia całą infrastrukturę.
Wolniejszy sklep obniża konwersję; gorsze Core Web Vitals (LCP, INP) wpływają na pozycje w Google — szczegóły w naszym poradniku o optymalizacji PrestaShop.
Brak zgodności z wymogami prawnymi (np. Omnibus, cookies) w nowych wersjach modułów wymusza upgrade ekosystemu.
PrestaShop 8 czy 9 — jak wybrać wersję docelową
Decyzja nie powinna opierać się na „najnowsza = najlepsza”, tylko na kompatybilności Twojego sklepu. Poniżej praktyczne kryteria wyboru.
Kiedy wybrać PrestaShop 8.2.x
Masz wiele modułów od polskich dostawców (PrestaShow, MyPresta, Zento) — większość ma pełne wsparcie dla PS 8.
Szablon pochodzi z 2019–2022 i autor oferuje aktualizację pod PS 8, ale nie pod PS 9.
Chcesz minimalizować ryzyko — PS 8 ma dłuższą historię wdrożeń produkcyjnych w Polsce.
Integracje (Allegro, BaseLinker, Subiekt) mają potwierdzoną wersję dla PS 8.
Kiedy wybrać PrestaShop 9.x
Budujesz sklep od zera lub i tak planujesz wymianę szablonu i modułów.
Wszyscy dostawcy modułów potwierdzili wsparcie dla PS 9 (sprawdź to na piśmie, nie z opisu na sklepie z modułami).
Zależy Ci na nowszej architekturze i dłuższym horyzoncie wsparcia platformy.
Masz zespół developerski, który poradzi sobie z ewentualnymi breaking changes w hookach i szablonie.
Przygotowanie do migracji — plan krok po kroku
Krok 1Inwentaryzacja sklepu — co masz dziś
Zanim dotkniesz aktualizacji, musisz wiedzieć, z czego składa się Twój sklep. Otwórz panel administracyjny PrestaShop 1.7 i przygotuj arkusz (Excel lub Google Sheets) z czterema sekcjami.
Moduły: Moduły → Menedżer modułów — zapisz nazwę, wersję, autora i czy moduł jest aktywny. Osobno oznacz moduły krytyczne: płatności, dostawa, koszyk, SEO, integracje.
Szablon: Wygląd → Szablon — nazwa motywu, wersja, czy są nadpisania plików (child theme / overrides w /themes/).
Nadpisania core: sprawdź katalog /override/ — każdy plik tutaj wymaga ręcznej weryfikacji po migracji.
Integracje zewnętrzne: Allegro, BaseLinker, ERP, hurtownie XML, Google Merchant, Facebook Catalog — zapisz wersję modułu i częstotliwość synchronizacji.
Multistore i języki: jeśli masz wiele sklepów w jednej instalacji lub wiele języków — zanotuj konfigurację, bo to najczęstsze źródło błędów URL po migracji.
Cron i zadania: importy XML, czyszczenie cache, synchronizacje — gdzie są skonfigurowane (crontab serwera, moduł, zewnętrzny serwis).
Krok 2Pełny backup plików i bazy danych
Backup to Twoja polisa ubezpieczeniowa. Bez działającego backupu nie wolno zaczynać migracji na produkcji.
Pliki: pobierz cały katalog sklepu przez SFTP (szczególnie /img/, /upload/, /themes/, /modules/, /override/, .htaccess).
Baza danych: eksport przez phpMyAdmin (Eksport → Szybka → SQL) lub mysqldump z CLI. Zapisz plik z datą w nazwie, np. sklep_backup_2026-06-08.sql.
Przechowuj backup poza serwerem produkcyjnym (lokalny dysk, S3, inny hosting). Backup na tym samym serwerze nie chroni przed awarią dysku.
Zweryfikuj backup: rozpakuj pliki i sprawdź rozmiar; opcjonalnie zaimportuj bazę na lokalnym środowisku, żeby potwierdzić, że dump jest kompletny.
Zapisz też kopię pliku parameters.php (lub app/config/parameters.php w starszych instalacjach) — zawiera dane do bazy.
Krok 3Utworzenie środowiska staging (kopia testowa)
Migrację wykonujesz najpierw na stagingu — kopii sklepu niedostępnej dla klientów. Dopiero po przejściu wszystkich testów wdrażasz zmiany na produkcję.
Utwórz subdomenę, np. staging.twojsklep.pl, lub osobną instancję na hostingu.
Skopiuj pliki sklepu na staging (FTP/SFTP lub narzędzie hostingu).
Zaimportuj kopię bazy danych na staging.
Zaktualizuj dane połączenia z bazą w pliku konfiguracyjnym stagingu.
Ustaw tryb konserwacji na stagingu lub zabezpiecz HTTP Basic Auth, żeby Google i klienci nie indeksowali kopii.
W panelu PrestaShop na stagingu zmień URL sklepu (Ustawienia sklepu → URL) na adres stagingu.
Wyłącz na stagingu: wysyłkę maili transakcyjnych, płatności produkcyjne (przełącz bramki na tryb testowy), synchronizacje z Allegro/ERP — żeby test nie wysłał fałszywych zamówień.
Nowa wersja PrestaShop wymaga nowszego PHP i wyższych limitów. Sprawdź to na stagingu przed migracją — nie na produkcji.
PHP: sprawdź oficjalną dokumentację dla wybranej wersji (8.2.x lub 9.0.x). Typowo potrzebujesz PHP 8.1+ dla PS 8 i nowszego dla PS 9.
memory_limit: minimum 256M, zalecane 512M przy większych sklepach i migracji.
max_execution_time: minimum 300 sekund na czas upgrade (moduł aktualizacji potrzebuje czasu).
Rozszerzenia PHP: intl, mbstring, curl, gd, zip, json, openssl — brak któregoś kończy się białym ekranem.
Uprawnienia katalogów: /var/, /cache/, /img/, /log/, /download/, /upload/ muszą być zapisywalne przez serwer WWW.
Sprawdź wersję MySQL/MariaDB — zbyt stara baza może blokować migrację schematu.
Krok 5Weryfikacja kompatybilności modułów i szablonu
To najważniejszy krok techniczny. Moduł bez wersji pod PS 8/9 może zepsuć koszyk, płatności lub SEO.
Dla każdego modułu z listy (krok 1) sprawdź u autora: czy jest wersja dla PS 8 lub 9, jaki jest koszt upgrade, czy moduł jest nadal rozwijany.
Moduły porzucone: zaplanuj zamiennik (np. inny moduł SEO, inna integracja Allegro) przed migracją — nie po.
Szablon: skontaktuj się z autorem motywu lub sprawdź changelog. Brak aktualizacji szablonu = budżet na dostosowanie frontu przez developera.
Nadpisania w /override/: porównaj z dokumentacją nowej wersji — hooki i klasy mogły się zmienić.
Przygotuj plan B: które moduły tymczasowo wyłączysz na stagingu, jeśli blokują upgrade.
Jeśli lista modułów jest długa i nie wiesz, co jest krytyczne — zamów audyt sklepu PrestaShop. Audyt zwraca raport z priorytetami: co aktualizować, co wymienić, co usunąć.
Migracja na stagingu — dwie metody
Metoda A: Update Assistant (moduł oficjalny)
Update Assistant (dawniej 1-Click Upgrade) to oficjalny moduł PrestaShop do aktualizacji. Sprawdza się przy mniejszych skokach w obrębie tej samej gałęzi, ale przy 1.7 → 8/9 często wymaga wcześniejszego przejścia pośredniego lub ręcznej migracji. Jeśli jednak Twój dostawca migracji wskazuje tę metodę — postępuj tak:
Krok 6Aktualizacja przez Update Assistant na stagingu
Wykonuj wyłącznie na kopii testowej. Produkcji nie dotykaj, dopóki staging nie przejdzie pełnych testów z kroku 9.
Zainstaluj lub zaktualizuj moduł „Update Assistant” w panelu: Moduły → Menedżer modułów → wyszukaj „Update Assistant”.
W module wybierz wersję docelową i uruchom kreator. Moduł pobierze paczkę i rozpocznie proces.
Nie przerywaj procesu — zamknij inne karty panelu, nie restartuj serwera w trakcie.
Po zakończeniu wyczyść cache: Zaawansowane → Wydajność → Wyczyść cache.
Sprawdź wersję w stopce panelu admina lub w Ustawienia → Informacje o sklepie.
Jeśli moduł zgłosi błąd: zapisz log z /var/logs/ lub komunikat modułu — to podstawa do diagnozy lub zlecenia migracji.
Metoda B: Migracja ręczna / profesjonalna (zalecana przy 1.7 → 8/9)
Przy skoku z 1.7 na 8 lub 9 większość agencji i software house’ów stosuje migrację ręczną: świeże pliki core nowej wersji, migracja bazy według skryptów upgrade, dostosowanie szablonu i modułów. To standard przy sklepach z integracjami.
Krok 7Ręczna migracja — przebieg pracy
Poniżej uproszczony scenariusz, który wykonujemy w projektach komercyjnych. Szczegóły zależą od instalacji — przy customowych override’ach każdy krok wymaga weryfikacji.
Pobierz oficjalną paczkę PrestaShop 8 lub 9 z prestashop.com (nie z nieoficjalnych źródeł).
Podmień pliki core (admin, app, classes, controllers, src itd.) zgodnie z procedurą opisaną w oficjalnej dokumentacji migracji.
Uruchom skrypt aktualizacji bazy (install/upgrade w zależności od wersji) — baza zmienia strukturę tabel.
Zaktualizuj moduły jeden po drugim, zaczynając od płatności i dostawy.
Dostosuj szablon: porównaj pliki motywu z domyślnym motywem nowej wersji (classic/hummingbird) i uzupełnij brakujące szablony Twig.
Usuń lub przepisz nadpisania w /override/, które powodują konflikty.
Włącz tryb debugowania tylko na stagingu (define _PS_MODE_DEV_ w config) — nigdy na produkcji.
Migracja ręczna wymaga doświadczenia w PrestaShop. Jeśli nie masz developera w zespole — migracja PrestaShop przez WebAlpha obejmuje staging, upgrade, testy i wdrożenie z planem rollback.
Testy po migracji na stagingu — checklist
Krok 8Testy funkcjonalne sklepu
Nie wdrażaj na produkcję, dopóki nie przejdziesz poniższej listy. Każdy punkt to realny problem, który widzieliśmy po nieudanych migracjach klientów.
Strona główna i kategorie: czy ładują się bez błędów PHP, czy obrazy produktów się wyświetlają.
Karta produktu: warianty, ceny brutto/netto, stany magazynowe, opinie, powiązane produkty.
Koszyk: dodawanie, usuwanie, kody rabatowe, minimalna wartość zamówienia.
Checkout: pełna ścieżka jako gość i jako zalogowany klient.
Płatności: każda bramka w trybie testowym (Przelewy24, PayU, Stripe, pobranie, przelew).
Dostawy: ceny i metody dla różnych wag i regionów, punkty odbioru (InPost Paczkomaty itd.).
Maile transakcyjne: potwierdzenie zamówienia, zmiana statusu — czy szablony maili renderują się poprawnie.
Panel admina: edycja produktu, import CSV, zamówienia, faktury, zwroty.
Moduły integracji: test synchronizacji jednego produktu z Allegro / BaseLinker (na koncie testowym).
Cron: ręczne uruchomienie importu XML i sprawdzenie logów.
Wielojęzyczność i multistore: poprawne URL i ceny w każdym sklepie/języku.
Krok 9Testy SEO i wydajności po migracji
Migracja bez testów SEO to jeden z głównych powodów utraty ruchu organicznego. Wykonaj je na stagingu, a po wdrożeniu powtórz wybrane punkty na produkcji.
URL produktów i kategorii: czy struktura się nie zmieniła. Jeśli się zmieniła — przygotuj mapę przekierowań 301 (stary URL → nowy URL).
Meta title i description: czy moduł SEO zachował dane (np. po migracji z starym modułem SEO).
Sitemap XML: czy generuje się poprawnie i zawiera wszystkie ważne URL-e.
robots.txt: czy nie blokuje sklepu przypadkowym Disallow.
Canonical: sprawdź kilka stron produktowych i kategorii w źródle HTML.
Hreflang: jeśli masz wiele języków — weryfikacja w Google Search Console po wdrożeniu.
PageSpeed / Core Web Vitals: LCP, INP, CLS — porównaj ze starą wersją. Regresja wydajności to sygnał do optymalizacji cache i modułów.
Google Search Console: po wdrożeniu wyślij zaktualizowaną sitemapę i monitoruj raport Indeksowanie → Strony.
Wdrożenie najlepiej zaplanować na godziny najmniejszego ruchu (np. noc, wczesny poranek). Przygotuj komunikat w trybie konserwacji dla klientów.
Włącz tryb konserwacji na produkcji (Ustawienia sklepu → Utrzymanie sklepu) lub krótką stronę maintenance.
Wykonaj świeży backup produkcji tuż przed wdrożeniem (pliki + baza).
Wgraj zaktualizowane pliki ze stagingu lub powtórz migrację na produkcji tą samą metodą co na stagingu.
Uruchom skrypt upgrade bazy na produkcji, jeśli migracja tego wymaga.
Wyczyść cache PrestaShop i cache serwera (LiteSpeed, Varnish, Cloudflare).
Wyłącz tryb debugowania na produkcji (_PS_MODE_DEV_ = false).
Wykonaj szybki test: dodaj produkt do koszyka i przejdź do checkoutu (możesz przerwać przed płatnością).
Wyłącz tryb konserwacji.
Włącz synchronizacje Allegro/ERP i sprawdź pierwszy cykl cron.
Monitoruj logi błędów przez 48–72 godziny po wdrożeniu.
Co najczęściej psuje się po aktualizacji i jak to naprawić
Biały ekran / HTTP 500: zwykle brak rozszerzenia PHP, złe uprawnienia lub konflikt w /override/. Sprawdź logi serwera i /var/logs/.
Koszyk się nie aktualizuje: konflikt modułu dostawy lub cache — wyłącz moduły po kolei na stagingu, wyczyść cache.
Płatność odrzucona: nieaktualny moduł bramki — zaktualizuj moduł płatności do wersji pod nowe PS.
Złe ceny lub stany: błąd po migracji reguł cenowych lub multistore — porównaj konfigurację sklepów w panelu.
Import XML przestaje działać: timeout PHP lub zmiana ścieżki cron — zwiększ max_execution_time, zaktualizuj URL w crontab.
Utrata pozycji w Google: brak przekierowań 301 po zmianie URL — wdroż mapę redirectów w .htaccess lub module SEO.
Podwójne meta tagi: dwa moduły SEO aktywne jednocześnie — zostaw jeden.
Kiedy zlecić aktualizację firmie zewnętrznej
Samodzielna migracja ma sens przy prostym sklepie: standardowy szablon, kilka modułów, brak integracji z ERP. Zlecenie migracji specjalistom jest rozsądne, gdy:
Masz więcej niż 15–20 modułów, w tym customowe lub porzucone.
Działa integracja z ERP, WMS, hurtownią XML lub marketplace (Allegro, Amazon).
Szablon jest customowy i autor nie oferuje aktualizacji.
Sklep generuje istotny przychód — każda godzina przestoju kosztuje więcej niż usługa migracji.
Nie masz stagingu ani osoby, która odczyta logi PHP i naprawi override.
Po nieudanym samodzielnym upgrade stagingu nie wiesz, od czego zacząć rollback.
Zaplanuj optymalizację wydajności — nowa wersja to dobry moment na cache, WebP i audyt modułów.
Zaktualizuj moduły prawne (Omnibus, cookies) do wersji zgodnych z PS 8/9.
Sprawdź integrację z Allegro — po migracji wymaga reautoryzacji API w wielu przypadkach.
Ustaw cykliczne backupy i monitoring uptime.
Rozważ umowę opieki technicznej — prewencyjna aktualizacja minor jest tańsza niż gaszenie pożaru po kolejnej luce.
aktualizacja prestashop
prestashop 1.7
prestashop 8
prestashop 9
migracja sklepu
update assistant
FAQ
Najczęściej zadawane pytania
Przy skoku między głównymi wersjami rzadko. Update Assistant pomaga, ale większość sklepów produkcyjnych wymaga stagingu, weryfikacji modułów, dostosowania szablonu i testów checkoutu. Jedno kliknięcie bez przygotowania często kończy się błędem 500 lub niedziałającym koszykiem.
Sprawdź oficjalne wymagania dla konkretnej wersji minor przed migracją. PrestaShop 8 wymaga zwykle PHP 8.1 lub nowszego; PrestaShop 9 — nowszego PHP. Podnieś wersję PHP najpierw na stagingu i przetestuj sklep przed migracją core.
Nie musisz — jeśli zachowasz URL-e lub wdrożysz poprawne przekierowania 301, zaktualizujesz sitemapę i nie usuniesz treści produktów. Utrata pozycji wynika zwykle z błędów technicznych (zmiana URL bez 301, brak canonical, indeksacja stagingu), nie z samej aktualizacji platformy.
Prosty sklep (standardowy motyw, do 10 modułów): 3–5 dni roboczych z testami. Sklep z integracjami Allegro/ERP, customowym szablonem i 20+ modułami: zwykle 2–4 tygodnie, zależnie od dostępności aktualizacji modułów i zakresu nadpisań.
Tak — to często bezpieczniejsza ścieżka. Najpierw stabilizujesz sklep na PS 8, potem planujesz skok na PS 9 z osobnym audytem kompatybilności. Dwa mniejsze kroki bywają tańsze w utrzymaniu niż jeden duży skok z 1.7 od razu na 9.
Masz trzy opcje: znaleźć zamiennik od innego autora, zamówić aktualizację u autora modułu (jeśli oferuje custom dev) lub tymczasowo wyłączyć moduł i zastąpić funkcję innym rozwiązaniem. Nie wdrażaj na produkcję z niekompatybilnym modułem płatności lub dostawy.
Tak. Po migracji moduł Allegro wymaga zwykle aktualizacji do nowej wersji i ponownej autoryzacji połączenia API. Przetestuj synchronizację ofert i zamówień na stagingu przed go-live. Więcej w naszym artykule o integracji PrestaShop z Allegro.
Zależy od liczby modułów, integracji i customizacji szablonu. Prosta migracja zaczyna się od kilku tysięcy złotych; złożone sklepy z ERP i customem — znacznie więcej. Dokładny koszt po audycie — sprawdź cennik lub poproś o wycenę po liście modułów.
Bezpłatna konsultacja
Porozmawiajmy o Twoim projekcie
Opisz, czego potrzebujesz — zaproponujemy zakres, technologię i realny harmonogram. Bez zobowiązań.
24–48 hCzas odpowiedzi
100%Wycena indywidualna
0 złBez zobowiązań
kontakt
Masz projekt lub pytanie? Napisz do nas
Opisz, czego potrzebujesz — strony, sklepu, integracji czy wsparcia technicznego. Odpowiemy z konkretnymi propozycjami i orientacyjną wyceną, zwykle w ciągu jednego dnia roboczego.
