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

> Od czego zależy przejście z PrestaShop 1.7 do 8 lub 9? Pokazujemy aktualne różnice PHP, wybór ścieżki Update Assistant, demonstracyjną macierz zgodności oraz odbiór zamówień, płatności i SEO przed przełączeniem sklepu.

Autor: Rafał Kędracki (WebAlpha). Opublikowano: 2026-06-08. Zaktualizowano: 2026-09-03. Kanoniczny adres: https://webalpha.pl/blog/aktualizacja-prestashop-1-7-do-9

Około 11 min czytania (szacunek; bez czasu wykonania instrukcji).

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.

> **To plan przygotowania i odbioru, nie uniwersalna komenda aktualizacji:** Nie uruchamiaj procedury z tego artykułu bezpośrednio na działającym sklepie. Zmiana wersji oprogramowania nie zawsze oznacza przenoszenie sklepu na nową domenę lub platformę. Jeśli projekt obejmuje również taką migrację, potrzebuje osobnego planu danych i adresów. Żaden ogólny poradnik nie potwierdza zgodności Twoich modułów.

Potrzebujesz wykonania prac? Zakres zakupowy i sposób wyceny znajdziesz na stronie [aktualizacji PrestaShop 8/9](https://webalpha.pl/sklep/aktualizacja-prestashop-8-9). Ten poradnik służy przygotowaniu decyzji i testów.

<a id="sekcja-prestashop-8-czy-9-najpierw-zgodnosc-potem-wersja-docelowa"></a>

## 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”.

**Zakresy zgodności PHP w dokumentacji odczytanej 3 września 2026 r. To zgodność techniczna, nie rekomendacja używania niewspieranego PHP.**

| Gałąź sklepu | PHP wskazane jako zgodne | Wniosek do planu |
| --- | --- | --- |
| PrestaShop 1.7.8 | PHP 7.1–7.4 | Dokumentacja archiwalna: nie przełączaj działającego 1.7.8 na PHP 8 przed ustaleniem ścieżki. |
| PrestaShop 8.0–8.2 | PHP 7.2–8.1; dla 7.2 minimum 7.2.5 | „PHP 8.1 lub nowsze” jest niepoprawnym uproszczeniem; PHP 8.2 nie mieści się w tej macierzy. |
| PrestaShop 9.0 | PHP 8.1–8.4 | Sprawdź dodatkowo wymagania konkretnego wydania i modułów. |
| PrestaShop 9.1 | PHP 8.1–8.5 | Zgodność core nie potwierdza zgodności motywu, płatności ani własnego kodu. |

Źródła zakresów: [archiwalne wymagania PrestaShop 1.7](https://devdocs.prestashop-project.org/1.7/basics/installation/system-requirements/), [wymagania PrestaShop 8](https://devdocs.prestashop-project.org/8/basics/installation/system-requirements/) oraz [wymagania PrestaShop 9](https://devdocs.prestashop-project.org/9/basics/installation/system-requirements/). Zestaw je z [cyklem wsparcia PHP](https://www.php.net/supported-versions.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](https://build.prestashop-project.org/news/2026/prestashop-8-2-6-security-release/) i nowsze komunikaty producenta przed wyznaczeniem terminu prac.

<a id="sekcja-czy-mozna-przejsc-bezposrednio-z-prestashop-1-7-do-9"></a>

## 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](https://devdocs.prestashop-project.org/9/basics/keeping-up-to-date/update/) i [oficjalny Update Assistant](https://github.com/PrestaShop/autoupgrade). Używaj wydania przeznaczonego do takiego zastosowania, nie przypadkowego archiwum gałęzi rozwojowej.

> **Nie przenoś starej instrukcji ręcznej na aktualizację do 9:** Ręczna procedura w dokumentacji 1.7 jest opisana dla aktualizacji 1.7.0 → 1.7.8. Nie jest uniwersalną instrukcją przejścia do 8 lub 9. Podmiana plików core i uruchomienie znalezionego w internecie skryptu aktualizacji może pozostawić niespójne pliki, moduły i bazę.

Zakres starej procedury wskazuje [dokumentacja aktualizacji PrestaShop 1.7](https://devdocs.prestashop-project.org/1.7/basics/keeping-up-to-date/update/).

<a id="sekcja-krok-1-inwentaryzacja-sklepu-i-odpowiedzialnosci"></a>

## 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.

<a id="sekcja-wypelniony-przyklad-macierzy-kompatybilnosci"></a>

### 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.

**DEMO: sklep źródłowy 1.7.8.11, rozważana gałąź 9.1; demonstracja oceny dokumentacji, nie certyfikat zgodności.**

| Element i dane przykładu | Ocena | Decyzja przed wdrożeniem |
| --- | --- | --- |
| Core: 1.7.8.11 / PHP 7.4 → gałąź 9.1 / PHP 8.4 | PHP 8.4 mieści się w macierzy 9.1; ścieżka aktualizacji tego sklepu nie została sprawdzona. | Nie uruchamiać produkcji: wybrać wydanie docelowe i powtórzyć procedurę na kopii. |
| Motyw autorski: brak potwierdzenia autora dla 9.1 | Zgodność nieznana; widok produktu nie potwierdza checkoutu. | STOP do oceny kodu i próby koszyka, formularzy oraz widoków mobile. |
| Płatności: dostępna paczka opisana przez dostawcę jako zgodna; brak próby callbacku | Deklaracja producenta, nie wynik transakcji. | STOP do testu sukcesu, odmowy i powtórzonego powiadomienia. |
| ERP: w briefie harmonogram wskazuje dotychczasową domenę | Ryzyko uruchomienia zapisu ze stagingu do produkcji. | Odseparować endpoint i kolejkę; ustalić właściciela stanów i zamówień. |
| Backup: jest archiwum bazy i plików, nie ma odtworzenia | Nie potwierdzono możliwości uruchomienia kopii. | STOP do odtworzenia w odizolowanym środowisku. |
| Adresy: briefing nie przewiduje zmiany domeny ani ścieżek | Brak planowanej migracji URL; wynik powdrożeniowy nieznany. | Porównać crawl przed/po; nie tworzyć przekierowań dla niezmienionych adresów. |

<a id="sekcja-krok-2-backup-i-staging-bez-skutkow-w-prawdziwym-sklepie"></a>

## 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.

<a id="sekcja-krok-3-proba-aktualizacji-i-rejestr-zmian"></a>

## 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.

<a id="sekcja-krok-4-testy-odbioru-liczba-produktow-nie-wystarczy"></a>

## 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.

**DEMO: wypełniona specyfikacja odbioru na syntetycznych danych. Oczekiwane wyniki nie są wynikami wykonanych testów.**

| Próba i dane wejściowe | Oczekiwany wynik | Dowód wymagany do odbioru |
| --- | --- | --- |
| Katalog: produkt DEMO-BUT, wariant rozmiar 42, stan 3 szt. | Wariant zachowuje przypisanie; koszyk zawiera właściwy rozmiar i ilość. | Porównanie identyfikatorów i pól przed/po oraz zapis próby koszyka. |
| Koszyk: 2 × 100 PLN brutto, rabat 20 PLN na produkty, dostawa 15 PLN; bez innych reguł | Suma brutto 195 PLN; podatki i dokument zgodne z konfiguracją testu. | Zamówienie testowe, rozbicie kwot i dokument bez danych rzeczywistego klienta. |
| Płatność testowa: sukces, a potem ponowne powiadomienie dla tej samej transakcji | Jedna płatność i jedno zamówienie; brak podwójnego księgowania skutku. | Identyfikatory testowe i zanonimizowany log obsługi powiadomień. |
| Integracja: przerwane połączenie po zapisie zamówienia DEMO-01 | Po ponowieniu nadal jedno zamówienie i jeden uzgodniony ruch magazynowy. | Log przed/po ponowieniu i porównanie stanu źródła nadrzędnego. |
| SEO: istniejący URL produktu zachowany bez zmiany treści adresu | Odpowiedź 200, właściwy canonical, brak przypadkowego noindex i adresu stagingu. | Porównanie crawl oraz źródła HTML przed/po. |
| Rollback: nowe zamówienie DEMO-02 powstaje po kopii bazowej | Plan obejmuje odzyskanie tego zamówienia i uzgodnienie jego płatności; nie znika przy odtworzeniu. | Próba odtworzenia wraz z udokumentowaną obsługą delty danych. |

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.

<a id="sekcja-krok-5-przelaczenie-produkcji-i-granica-rollbacku"></a>

## 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.

<a id="sekcja-seo-i-analityka-po-aktualizacji-co-naprawde-porownac"></a>

## 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](https://webalpha.pl/blog/seo-prestashop-poradnik) i [optymalizacji wydajności PrestaShop](https://webalpha.pl/blog/optymalizacja-prestashop-jak-przyspieszyc-sklep).

<a id="sekcja-od-czego-zaleza-koszt-i-termin-aktualizacji"></a>

## 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](https://webalpha.pl/sklep/aktualizacja-prestashop-8-9). Jeśli projekt obejmuje przenoszenie danych z innego systemu, domeny albo przebudowę struktury, oddziel go od samej aktualizacji i opisz w zakresie [migracji PrestaShop](https://webalpha.pl/sklepy-internetowe/migracja-prestashop).

## Masz listę wersji, ale niepewną ścieżkę aktualizacji?

Przekaż dokładną wersję PrestaShop i PHP, listę modułów, informacje o motywie oraz integracjach. Na tej podstawie możemy określić zakres sprawdzenia zgodności i wycenić aktualizację. Haseł ani kluczy API nie umieszczaj w formularzu.

[Aktualizacja PrestaShop - zakres i wycena](https://webalpha.pl/sklep/aktualizacja-prestashop-8-9)

## Najczęstsze pytania (FAQ)

### Czy każdy PrestaShop 1.7 można automatycznie zaktualizować do 9?

Nie należy tak zakładać. Trzeba sprawdzić dokładną wersję źródłową, wymagania Update Assistant, PHP oraz zgodność modułów i motywu. Ścieżkę i odtwarzanie należy przećwiczyć na odizolowanej kopii.

### Czy muszę przejść najpierw przez PrestaShop 8?

Nie ma uniwersalnego wymogu dla każdej instalacji 1.7. Etap pośredni wynika z ograniczeń konkretnego środowiska, narzędzia i dodatków, a nie z samej numeracji wersji. Ustal ścieżkę na podstawie dokumentacji i próby.

### Czy PrestaShop 8 działa na PHP 8.2?

Macierz dokumentacji odczytana 3 września 2026 r. nie wskazuje PHP 8.2 jako zgodnego z PrestaShop 8.0–8.2. Przed zmianą sprawdź wymagania dokładnej gałęzi i modułów oraz aktualne wsparcie bezpieczeństwa PHP.

### Czy wystarczy backup wykonany przez hosting?

Tylko jeśli jego zakres i punkt w czasie odpowiadają procedurze oraz potwierdzono możliwość odtworzenia. Trzeba sprawdzić spójność bazy z plikami i osobno zaplanować odzyskanie zamówień powstałych po kopii.

### Czy aktualizacja PrestaShop poprawi SEO?

Nie ma takiej gwarancji. Wdrożenie trzeba odebrać pod kątem adresów, indeksowalności, treści, danych strukturalnych i pomiaru. Zmiany widoczności ocenia się w danych GSC, uwzględniając inne zmiany i sezonowość.

### Jak przygotować sklep do wyceny aktualizacji?

Zbierz dokładną wersję PrestaShop i PHP, listę modułów z wersjami, informacje o motywie, zmianach własnych, integracjach i wymaganym oknie prac. Nie przesyłaj haseł ani kluczy API w zwykłym formularzu.