# Migracja z PrestaShop 8 do PrestaShop 9: audyt modułów

> O aktualizacji do nowej wersji głównej nie decyduje rdzeń PrestaShop, tylko wasze moduły. Inwentaryzacja przed wyceną, cztery kategorie postępowania, częste awarie techniczne i plan testów oparty na ścieżkach klienta.

- Strona: <https://www.datafirefly.com/pl/2026/09/05/migracja-prestashop-8-do-9-audyt-modulow/>
- Język: pl
- Opublikowano: 2026-09-05
- Zaktualizowano: 2026-09-05
- Inne języki: [fr](https://www.datafirefly.com/2026/09/05/migration-prestashop-8-vers-9-audit-modules/index.md), [en](https://www.datafirefly.com/en/2026/09/05/prestashop-8-to-9-migration-module-audit/index.md), [es](https://www.datafirefly.com/es/2026/09/05/migrar-prestashop-8-a-9-auditoria-modulos/index.md), [de](https://www.datafirefly.com/de/2026/09/05/prestashop-8-auf-9-migration-modul-audit/index.md), [it](https://www.datafirefly.com/it/2026/09/05/migrare-prestashop-8-a-9-audit-moduli/index.md), [nl](https://www.datafirefly.com/nl/2026/09/05/migratie-prestashop-8-naar-9-moduleaudit/index.md), [pt](https://www.datafirefly.com/pt/2026/09/05/migracao-prestashop-8-para-9-auditoria-modulos/index.md)
- Indeks: <https://www.datafirefly.com/pl/2026/llms.txt>

O migracji do nowej wersji głównej rzadko decyduje rdzeń PrestaShop, który w większości przypadków aktualizuje się poprawnie. Decydują o niej wasze moduły. W sklepie, który ma ich czterdzieści, wystarczy jeden dotykający procesu zamówienia i niezgodny z nową wersją, żeby zablokować całą migrację.

Audyt modułów musi więc wyprzedzić wszystko inne, łącznie z wyceną.

## Co się naprawdę zmienia

PrestaShop 9 opiera się na nowszych wersjach PHP i Symfony, co powoduje trzy rodziny awarii.

**Awarie związane z PHP.** Ostrzejsze typowanie, wycofane właściwości dynamiczne, usunięte funkcje. Moduł napisany pięć lat temu i nigdy nie poprawiany generuje błędy krytyczne, a nie ostrzeżenia.

**Awarie związane z frameworkiem.** Moduły rozszerzające kontrolery Symfony albo deklarujące serwisy muszą nadążyć za nową wersją. Dotyczy to modułów nowych i dobrze zbudowanych, paradoksalnie bardziej narażonych niż te czysto legacy.

**Awarie właściwe dla PrestaShop.** Metody usunięte z historycznych klas, wycofane lub przemianowane hooki, zmiany w szablonach motywu domyślnego.

## Inwentaryzacja, pierwszy efekt pracy

Zanim cokolwiek ruszycie, przygotujcie tabelę z jednym wierszem na moduł i sześcioma kolumnami.

1. **Nazwa techniczna i zainstalowana wersja.**
2. **Dostawca** i to, czy nadal istnieje. Dostawca, który zniknął, oznacza moduł bez przyszłości.
3. **Data ostatniej dostępnej aktualizacji.** Powyżej osiemnastu miesięcy bez publikacji traktujcie moduł jako porzucony, dopóki nie zostanie udowodnione inaczej.
4. **Deklarowana zgodność** z wersją docelową, z rozróżnieniem na to, co pisze strona produktu, i na to, co faktycznie przetestowano.
5. **Krytyczność**: czy moduł dotyka płatności, procesu zamówienia, katalogu, czy tylko drugorzędnego elementu wyświetlania?
6. **Obecność nadpisań**, widoczna w katalogu override. To najlepszy wskaźnik kruchości.

Tabelę wypełnia się w pół dnia i to ona wyznacza całą resztę projektu.

## Cztery kategorie

Każdy moduł trafia do jednej z nich, a postępowanie jest inne.

**Zgodny i utrzymywany.** Aktualizujecie i testujecie. Przypadek najprostszy i rzadko stanowiący większość.

**Zgodność zadeklarowana, ale niesprawdzona.** Wzmianka na stronie produktu nie zastępuje odbioru. Te moduły trzeba testować w pierwszej kolejności, bo niezgodność wykryta późno kosztuje przesunięcie terminu.

**Porzucony.** Dwa wyjścia: znaleźć zamiennik albo zlecić przejęcie kodu. Przejęcie ma sens tylko wtedy, gdy funkcja jest specyficzna dla waszej działalności.

**Zastępowalny funkcją rdzenia.** Kategoria systematycznie niedoceniana. Każda wersja główna wchłania funkcje, które wcześniej wymagały modułu. Migracja to dobry moment, żeby odinstalować to, co przestało być potrzebne.

W rzeczywistych audytach ten ostatni przegląd usuwa z listy zwykle od pięciu do dziesięciu modułów, co odpowiednio odchudza projekt.

## Najczęstsze pułapki techniczne

Dla programistów i agencji cztery awarie wracają stale na modułach wymagających poprawek.

Metoda tłumaczenia dostępna bezpośrednio na kontrolerach zniknęła: trzeba przejść przez instancję modułu. Nadpisania metod, których sygnatura się zmieniła, generują błędy zgodności, zwłaszcza na metodach renderowania używanych do odpowiedzi asynchronicznych. Wywołania asynchroniczne do historycznych kontrolerów administracyjnych zmieniły postać i wymagają innego przekazywania parametrów. A moduły, które pisały bezpośrednio do tabel rdzenia, zderzają się ze zmianami schematu.

Żadna z tych poprawek nie jest sama w sobie złożona. Koszt bierze się z liczby.

## Środowisko testowe

Nie podlega negocjacji, a mimo to regularnie się je pomija.

Musi opierać się na świeżej kopii bazy produkcyjnej, nie na zestawie demonstracyjnym. Większość niezgodności ujawnia się na prawdziwych danych: produkty ze stoma kombinacjami, klienci z niekompletnymi adresami, zamówienia w zapomnianych statusach.

Dwie ostrożności: zanonimizujcie dane klientów przed skopiowaniem i wyłączcie wszelką wysyłkę maili z tego środowiska. Test migracji, który wysyła dwa tysiące maili o zmianie statusu do prawdziwych klientów, to historia prawdziwa i częsta.

## Plan testów

Testujcie ścieżki, nie strony. Sześć ścieżek pokrywa to, co istotne.

Pełne zamówienie jako niezalogowany odwiedzający, z realną płatnością w trybie testowym. Zamówienie z istniejącym kontem i zapisanym adresem. Dodanie do koszyka ze strony kategorii z aktywnymi filtrami. Wyszukiwanie wewnętrzne zakończone zakupem. Zwrot albo zgłoszenie posprzedażowe. A po stronie administracji: utworzenie produktu z kombinacjami i zatwierdzenie zamówienia.

Każdą ścieżkę trzeba przejść na komputerze i na telefonie. Liczcie jeden dzień na całość, do powtórzenia po każdej istotnej poprawce.

## Przełączenie i to, co po nim

Zaplanujcie migrację poza okresami handlowymi, z określonym i przetestowanym oknem powrotu. Kopia zapasowa, której nigdy nie przywrócono, się nie liczy.

W kolejnych dniach liczą się trzy kontrole. Dzienniki błędów serwera, które ujawniają niezgodności nienapotkane na testach. Zepsute linki i brakujące obrazy, bo zmiana wersji może wpłynąć na ścieżki obrazów i przepisane adresy URL. Oraz napływ zamówień w porównaniu ze zwykłym poziomem: nagły spadek sygnalizuje blokadę w procesie zamówienia, której nikt nie zgłosił.

W tym ostatnim punkcie  przydaje się zarówno na etapie odbioru, jak i po przełączeniu: wykrywa zepsute linki wewnętrzne i brakujące obrazy, które mogła spowodować migracja, na PrestaShop 8 i na PrestaShop 9.