PrestaShop 9 nie jest kosmetyczną aktualizacją. To skok z Symfony 4.4 na Symfony 6.4 LTS — cztery lata rozwoju frameworka w jednym kroku. Dla kogoś, kto tylko korzysta ze sklepu, ta zmiana jest niewidoczna. Dla kogoś, kto pisze lub utrzymuje moduły, zmienia się wiele: sposób zarządzania zależnościami, system mailingu, a nawet minimalna wersja PHP. Poniżej pokazujemy, co dokładnie się zmieniło i jak napisać moduł, który przetrwa tę i kolejne migracje.
Jak działa system hooków — podstawa architektury modułów
PrestaShop od zawsze pozwala rozszerzać funkcjonalność sklepu bez modyfikowania jego głównego kodu. Mechanizm, który to umożliwia, nazywa się hookiem. W konkretnym miejscu w kodzie sklepu (np. przy renderowaniu strony produktu, przy zapisie zamówienia, przy walidacji koszyka) PrestaShop „wywołuje” hook o określonej nazwie. Każdy moduł, który się do tego hooka zarejestrował, dostaje szansę zareagować — dodać coś do strony, zmienić dane, zablokować akcję.
To rozwiązuje konkretny problem. Bez hooków, żeby dodać własną funkcję, trzeba by edytować kod źródłowy sklepu. Każda aktualizacja PrestaShop nadpisałaby tę zmianę. Z hookami moduł żyje osobno od jądra systemu. Aktualizacja sklepu nie niszczy Waszej logiki, o ile trzymacie się tego mechanizmu, a nie edytujecie plików core’a na własną rękę.
Co realnie zmienia migracja z Symfony 4.4 na 6.4
To jest sedno tego, co różni pisanie modułów pod PrestaShop 9 od pisania ich pod wersję 8.
Zależności są teraz zarządzane inaczej. Wcześniej PrestaShop korzystał z jednej, zbiorczej zależności symfony/symfony. Od wersji 9 każdy pakiet Symfony jest dołączany osobno. Jeśli Wasz moduł opierał się na czymś, co „przypadkiem” było dostępne przez tę zbiorczą zależność, może przestać działać — trzeba jawnie zadeklarować, czego moduł potrzebuje.
System wysyłki maili się zmienił. PrestaShop 9 przeszedł z biblioteki Swift Mailer na Symfony Mailer. Jeśli moduł wysyłał powiadomienia mailowe, korzystając ze starych klas Swift Mailera, trzeba to przepisać pod nowy system. To nie jest kosmetyczna zmiana nazw — zmienia się też sposób konfiguracji szyfrowania połączenia (SSL zostało wycofane na rzecz TLS, ze względów bezpieczeństwa).
Minimalna wersja PHP to teraz 8.1, z pełnym wsparciem do PHP 8.4 w wersji 9.0 i 8.5 w 9.1. Moduł pisany pod starsze wersje PHP, korzystający z przestarzałej składni, może się wysypać już na etapie instalacji.
Pojawiły się nowe hooki. Przykładem jest actionValidateCartRule, pozwalający na własną logikę walidacji reguł koszyka — otwiera to możliwości, których wcześniej trzeba było obchodzić przez override’y klas rdzenia (rozwiązanie znacznie bardziej ryzykowne, bo override’y łatwiej konfliktują z przyszłymi aktualizacjami).
Doszło nowe Admin API oparte na API Platform. To osobna, w pełni RESTful warstwa integracji z back office’em. Dla modułów, które wcześniej komunikowały się ze sklepem przez własne, niestandardowe endpointy, to okazja do uproszczenia integracji — i zgodnie z tym, co pisaliśmy o gotowości sklepów na agentów zakupowych AI, to też krok w stronę architektury łatwiejszej do podłączenia pod zewnętrzne systemy.
Jak pisać moduł kompatybilny z 8.x i 9.x jednocześnie
Wiele sklepów B2B wciąż działa na stabilnej gałęzi 8.2, bo ma rozbudowane integracje z ERP i BaseLinkerem, których migracja wymaga starannego planowania. Jeśli piszecie moduł do dystrybucji, a nie na potrzeby jednego, konkretnego wdrożenia, warto zaprojektować go tak, żeby działał na obu gałęziach:
- Nie zakładajcie konkretnej wersji Symfony w kodzie modułu. Trzymajcie logikę biznesową możliwie oddzieloną od warstwy frameworka, korzystając głównie z API PrestaShop, nie z wewnętrznych klas Symfony bezpośrednio.
- Deklarujcie zależności jawnie w pliku composer.json modułu, zamiast liczyć na to, że coś „będzie dostępne” przez zależności core’a.
- Testujcie instalację na obu gałęziach przed wydaniem nowej wersji modułu — najlepiej zautomatyzowanie tego procesu w CI, nie ręcznie przy każdej aktualizacji.
- Unikajcie override’ów klas rdzenia, gdzie tylko można. Hooki przetrwają migrację między wersjami. Override’y klas rdzenia bardzo często się psują, bo struktura tych klas zmienia się między wersjami.
Dlaczego architektura modułu ma znaczenie długoterminowo
Moduł napisany szybko, bez przemyślenia struktury, działa na starcie tak samo dobrze jak moduł dobrze zaprojektowany. Różnica ujawnia się przy pierwszej dużej migracji frameworka — dokładnie takiej, jak ta z 4.4 na 6.4. Moduł, który mocno opierał się na wewnętrznych, niedokumentowanych mechanizmach Symfony 4.4, wymaga w praktyce przepisania. Moduł zbudowany wokół publicznego API PrestaShop i systemu hooków przechodzi migrację ze znacznie mniejszym nakładem pracy.
Przykład z praktyki (Klient R, dystrybutor komponentów elektronicznych — przykład poglądowy, dane uśrednione dla tej skali projektu)
Firma korzystała z niestandardowego modułu integrującego sklep z systemem ERP, napisanego kilka lat wcześniej przez innego dostawcę. Moduł mocno opierał się na override’ach klas rdzenia i bezpośrednim odwołaniu do wewnętrznych komponentów Symfony 4.4. Przy planowaniu migracji na PrestaShop 9 okazało się, że praktycznie cała logika integracji wymaga przepisania od zera, bo mechanizmy, na których się opierała, przestały istnieć w nowej wersji frameworka.
Nowa wersja modułu została zbudowana wokół systemu hooków i jawnie zadeklarowanych zależności, zamiast override’ów. Koszt migracji był wyższy niż przy standardowej aktualizacji, ale firma zyskała moduł, który przy kolejnej dużej zmianie wersji Symfony (planowanej przez PrestaShop w kolejnych latach) będzie wymagał znacznie mniejszej pracy.
FAQ
Czy moduł napisany dla PrestaShop 8 zadziała bez zmian na PrestaShop 9? Zależy od tego, jak został napisany. Moduł oparty głównie na hookach i publicznym API ma dobre szanse zadziałać z niewielkimi poprawkami. Moduł mocno opierający się na override’ach klas rdzenia lub wewnętrznych mechanizmach Symfony 4.4 zwykle wymaga istotnych zmian.
Czym różni się hook od override’u klasy w PrestaShop? Hook to zaczepienie się modułu w konkretnym, przewidzianym miejscu w kodzie, bez modyfikowania plików rdzenia — przetrwa aktualizacje. Override zmienia zachowanie samej klasy rdzenia, co daje większą elastyczność, ale zwiększa ryzyko konfliktu przy każdej aktualizacji PrestaShop.
Czy trzeba migrować wszystkie moduły natychmiast po wydaniu PrestaShop 9? Nie, jeśli sklep stabilnie działa na aktualnej wersji 8.2.x, która wciąż otrzymuje poprawki bezpieczeństwa. Migrację warto planować z wyprzedzeniem, testując najpierw kompatybilność kluczowych, niestandardowych modułów.
Co konkretnie psuje się najczęściej przy migracji modułu na PrestaShop 9? Najczęstsze problemy to: użycie starej biblioteki Swift Mailer zamiast Symfony Mailer, poleganie na zbiorczej zależności symfony/symfony zamiast jawnie zadeklarowanych pakietów, oraz override’y klas rdzenia, których struktura zmieniła się między wersjami frameworka.
Czy nowe Admin API zastępuje system hooków? Nie, to dwa różne mechanizmy do różnych celów. Hooki służą do rozszerzania funkcjonalności sklepu od wewnątrz. Admin API służy do integracji sklepu z zewnętrznymi systemami przez REST, niezależnie od hooków.
Macie moduł napisany kilka lat temu, który wymaga migracji na PrestaShop 9, albo planujecie napisać nowy moduł od zera? Umówcie bezpłatną konsultację przez formularz szybkiej wyceny — jako certyfikowany PrestaShop Expert sprawdzimy, czy wystarczy aktualizacja, czy potrzebne jest przepisanie logiki integracji.
