Kompatybilność z PrestaShop 9: Wszystkie nasze moduły są gotowe

PrestaShop 9 jest tutaj. Czy Twój zestaw modułów jest gotowy?

PrestaShop 9 pojawił się z najbardziej znaczącą przebudową architektoniczną od czasu, gdy platforma po raz pierwszy przyjęła Symfony w wersji 1.7. Przygotowywałem nasze moduły do tego wydania od wczesnych buildów alfa, a w tym procesie dowiedziałem się dokładnie, co się psuje, co po cichu degraduje i co właściciele sklepów muszą sprawdzić, zanim w ogóle pomyślą o kliknięciu “Aktualizuj”.

To nie jest podsumowanie changelogu. To praktyczny przewodnik, jakiego mi brakowało, kiedy po raz pierwszy otworzyłem PrestaShop 9 beta i obserwowałem, jak połowa zewnętrznych modułów w moim testowym sklepie wyrzucała błędy 500. Niezależnie od tego, czy jesteś właścicielem sklepu oceniającym swój zestaw modułów, freelancerem przygotowującym migrację klienta, czy agencją zarządzającą dziesiątkami instalacji PrestaShop, ten przewodnik przeprowadzi Cię przez pełny proces audytu kompatybilności.

Co naprawdę zmieniło się w PrestaShop 9 (i dlaczego to psuje rzeczy)

Zanim będziesz mógł zaudytować swoje moduły, musisz zrozumieć, co PrestaShop 9 zmienił na poziomie architektonicznym. To nie są zmiany kosmetyczne. To fundamentalne przesunięcia, które dotykają każdego modułu wchodzącego w interakcję z back office, warstwą bazy danych lub motywem front-end.

Symfony 6.4: Wielka zmiana

PrestaShop przeskoczył z Symfony 4.4 na Symfony 6.4. To nie jest przyrostowa aktualizacja. To skok przez dwie główne wersje Symfony, z których każda wprowadziła swój własny zestaw deprecjacji i usunięć. Dla deweloperów modułów najważniejszą konsekwencją jest sposób działania kontrolerów.

W Symfony 4.4 mogłeś używać $this->get('service_name') wewnątrz kontrolerów, aby pobrać dowolną usługę z kontenera. W Symfony 6.4 kontrolery muszą być zdefiniowane jako usługi z właściwym dependency injection. Stary FrameworkBundleAdminController nadal działa w PrestaShop 9, ale jest oficjalnie oznaczony jako deprecated i zostanie usunięty w PrestaShop 10. Każdy moduł rozszerzający tę klasę żyje na pożyczonym czasie.

Co to oznacza dla Ciebie: jeśli strony administracyjne modułu działają dziś na PrestaShop 9, ale używają starszego wzorca kontrolerów, mogą całkowicie przestać działać na PrestaShop 10. Chcesz modułów, które już zmigrowały do PrestaShopAdminController z constructor injection.

Usunięte biblioteki, od których prawdopodobnie zależysz

PrestaShop 9 usunął kilka bibliotek z rdzenia, z których moduły wcześniej korzystały za darmo:

• Klient HTTP Guzzle został zastąpiony przez klienta HTTP Symfony. Każdy moduł wykonujący zewnętrzne wywołania API przez Guzzle wyrzuci fatalny błąd “class not found”, chyba że dołącza własną kopię.
• SwiftMailer został zastąpiony przez Symfony Mailer. Moduły wysyłające e-maile bezpośrednio (powiadomienia o zamówieniach, alerty, raporty) muszą używać nowego interfejsu mailera.
• Szyna poleceń Tactician została zastąpiona przez Symfony Messenger. Moduły używające wzorców CQRS z Tactician wymagają pełnego przepisania obsługi poleceń/zapytań.

Podstępna część: te awarie nie zawsze ujawniają się natychmiast. Moduł może się zainstalować i wyświetlić swoją stronę konfiguracyjną idealnie, ale zacrashować w momencie, gdy spróbuje wysłać żądanie HTTP lub wysłać polecenie. Nie wyłapiesz tego w szybkim teście “czy się instaluje?”.

33 hooki zostały usunięte

PrestaShop 9 usunął 33 hooki. To nie jest literówka. Trzydzieści trzy punkty integracji, na których moduły wcześniej polegały, po prostu nie istnieją. Usunięcia dzielą się na trzy kategorie:

• Hooki starej strony produktowej (cały stary interfejs edycji produktu został usunięty, zabierając ze sobą wszystkie hooki): actionAdminProductsControllerXxx, actionAdminActivateAfter/Before, actionAdminDeactivateAfter/Before, actionAdminDeleteAfter/Before i actionAdminSortAfter/Before
• Hooki kontrolera logowania (teraz obsługiwane przez zabezpieczenia Symfony): actionAdminLoginControllerBefore, actionAdminLoginControllerLoginBefore/After, actionAdminLoginControllerForgotBefore/After i actionAdminLoginControllerResetBefore/After
• Hooki układu powiązane ze starym cyklem życia AdminController (initHeader, initContent, initFooter, display) są faktycznie martwe, ponieważ PrestaShop 9 obsługuje układ przez komponenty Twig

Jeśli moduł rejestruje którykolwiek z tych hooków, nie zacrashuje, ale hook po prostu nigdy się nie uruchomi. Moduł po cichu traci funkcjonalność. Jest to wątpliwie gorsze niż crash, ponieważ możesz nie zauważyć przez tygodnie, że funkcja przestała działać.

PHP 8.1 minimum, PHP 8.4 rekomendowane

PrestaShop 9 wymaga minimum PHP 8.1. To eliminuje sklepy nadal pracujące na PHP 7.4 lub 8.0. Co ważniejsze, oznacza to, że moduły muszą obsługiwać funkcje PHP 8.1+ i ściślejsze sprawdzanie typów. Funkcje, które wcześniej zwracały typy mieszane, teraz potrzebują jawnych deklaracji typów zwracanych. Parametry nullable wymagają prefiksu ? lub union types. Czasy luźnego typowania PHP się skończyły.

Testuję wszystkie nasze moduły na PHP 8.1, 8.2, 8.3 i 8.4 konkretnie dlatego, że każda mniejsza wersja PHP wprowadza nowe ostrzeżenia o deprecjacji, które mogą zapełnić Twoje logi i, w środowiskach ze ścisłym raportowaniem błędów, powodować widoczne ostrzeżenia dla klientów.

Zaawansowane zarządzanie magazynem: Usunięte

Cały system Advanced Stock Management został usunięty z PrestaShop 9. Obejmuje to zamówienia zaopatrzenia, magazyny i stary interfejs zarządzania magazynem. Jeśli którykolwiek z Twoich modułów wchodzi w interakcję z danymi magazynowymi, hookami zamówień zaopatrzenia lub API zarządzania zaawansowanym magazynem, ulegnie awarii. To usunięcie wpływa także na tabele bazy danych, więc moduły odpytujące tabele związane z magazynem bezpośrednio dostaną błędy SQL.

Deprecjacja singletona Context

Singleton Context, który każdy deweloper PrestaShop zna i kocha (lub toleruje), jest stopniowo wycofywany. PrestaShop 9 wprowadził dedykowane usługi kontekstu: EmployeeContext, ShopContext, CurrencyContext, CountryContext, LanguageContext i inne. Moduły używające Context::getContext() nadal działają, ale moduły budowane zgodnie z nowoczesnymi praktykami powinny przechodzić na te dedykowane usługi.

Funkcja tłumaczenia nie escape'uje już HTML

To subtelna, ale niebezpieczna zmiana. Funkcja trans() w PrestaShop 9 nie escape'uje już automatycznie encji HTML. W poprzednich wersjach przekazywanie danych wejściowych użytkownika przez trans() zapewniało warstwę ochrony XSS niemal przypadkowo. W PrestaShop 9 moduły muszą jawnie używać htmlspecialchars() na wszelkich dynamicznych treściach przekazywanych do tłumaczeń. Moduły, które tego nie zaktualizują, potencjalnie wprowadzają luki bezpieczeństwa.

Motyw Hummingbird i Bootstrap 5

PrestaShop 9 jest dostarczany z motywem Hummingbird jako domyślnym, zbudowanym na Bootstrap 5. PrestaShop 9.1 zaktualizował dalej do Bootstrap 5.3.3. Dla każdego modułu renderującego szablony front-end oznacza to:

• Nazwy klas Bootstrap 4 już nie działają (np. .no-gutters staje się .g-0, .custom-checkbox staje się .form-check)
• Atrybuty data są namespacowane (data-toggle staje się data-bs-toggle)
• jQuery jest oficjalnie deprecated w Hummingbird i zostanie usunięty w następnej głównej wersji motywu. Moduły polegające na jQuery dla funkcjonalności front-end potrzebują ścieżki migracji do vanilla JavaScript
• Selektory CSS oparte na klasach specyficznych dla PrestaShop są zastępowane atrybutami data-ps-*

Jak zaudytować zainstalowane moduły: Proces krok po kroku

Teraz, gdy rozumiesz, co się zmieniło, oto systematyczny proces, którego używam do oceny kompatybilności modułów. Nie musisz być deweloperem, aby wykonać większość tych kroków.

Krok 1: Zinwentaryzuj swoje moduły

Przejdź do back office PrestaShop, nawiguj do Moduły > Menedżer modułów i wyeksportuj lub zrób zrzut ekranu pełnej listy zainstalowanych modułów. Dla każdego modułu zanotuj:

• Nazwę modułu i aktualną wersję
• Nazwę dostawcy/dewelopera
• Datę ostatniej aktualizacji
• Czy to moduł bezpłatny, płatny z PrestaShop Addons, czy zewnętrzny

Skategoryzuj każdy moduł według tego, jak krytyczny jest dla Twojego biznesu. Moduł bramki płatności jest krytyczny. Widget udostępniania w mediach społecznościowych jest miły do posiadania. Ta priorytetyzacja określa Twój harmonogram aktualizacji.

Krok 2: Sprawdź oświadczenia o kompatybilności dostawców

Dla każdego dostawcy modułu poszukaj wyraźnego oświadczenia o kompatybilności z PrestaShop 9. Oto czego szukać i jakie są czerwone flagi:

Zielone flagi:

• Dostawca ma wpis na blogu lub w changelogu wyraźnie wymieniający kompatybilność z PrestaShop 9.0 i 9.1
• Wersja modułu została zaktualizowana po dacie wydania PrestaShop 9
• Dostawca wspomina o testowaniu na Symfony 6.4 i PHP 8.1+
• Zachowana jest kompatybilność wsteczna z PrestaShop 8.x (pokazuje, że rozumieją wsparcie wielowersyjne)

Czerwone flagi:

• Brak wzmianki o PrestaShop 9 gdziekolwiek na stronie dostawcy
• Ostatnia aktualizacja modułu była przed wydaniami alfa PrestaShop 9
• Inne moduły dostawcy również nie zostały zaktualizowane (sugeruje porzuconą linię produktów)
• Opis modułu wspomina “kompatybilność z PrestaShop 1.7” bez jakiegokolwiek odniesienia do 8.x lub 9.x

Krok 3: Sprawdź kod modułu pod kątem znanych wzorców problemowych

Jeśli masz podstawową wiedzę o PHP, lub ma ją Twój deweloper, otwórz pliki modułu i wyszukaj te konkretne wzorce, które gwarantują problemy na PrestaShop 9:

Szukaj $this->get( w kontrolerach administracyjnych — To starszy wzorzec dostępu do usług Symfony 4.4. Działa na PrestaShop 9, ale jest deprecated. Moduły używające tego nie zostały zmodernizowane.

Szukaj use GuzzleHttp — Jeśli moduł importuje Guzzle, ale nie dołącza go we własnym katalogu vendor, ulegnie awarii na PrestaShop 9, gdzie Guzzle został usunięty z rdzenia.

Szukaj Swift_ lub SwiftMailer — Ta sama sytuacja. SwiftMailer został usunięty z rdzenia.

Szukaj Tools::displayPrice — To zostało deprecated. Moduły powinny używać usługi Locale do formatowania cen.

Szukaj data-toggle= w plikach .tpl — Atrybuty danych Bootstrap 4. Powinny być data-bs-toggle= dla kompatybilności z Hummingbird.

Szukaj $.ajax lub $(document) w plikach .js — Użycie jQuery. Nadal działa na motywie Classic, ale ulegnie awarii na Hummingbird, gdy jQuery zostanie usunięty.

Krok 4: Skonfiguruj środowisko staging

Nigdy nie testuj kompatybilności modułów na swoim sklepie produkcyjnym. Oto minimum setupu staging:

1. Sklonuj swoją produkcyjną bazę danych do osobnej bazy (lub użyj funkcji staging swojego dostawcy hostingu)
2. Zainstaluj PrestaShop 9 od zera lub użyj modułu aktualizacji na sklonowanej instalacji
3. Instaluj moduły po jednym, sprawdzając log błędów po każdej instalacji. Kolejność ma znaczenie: instaluj moduły płatności i wysyłki najpierw, potem moduły SEO, potem moduły kosmetyczne
4. Przetestuj podstawową funkcjonalność każdego modułu, nie tylko “czy strona konfiguracyjna się ładuje”. Złóż testowe zamówienie. Uruchom import produktów. Wygeneruj mapę witryny. Cokolwiek moduł robi na produkcji

Porada: Sprawdź log błędów PHP (/var/log/php_errors.log lub log błędów Twojego hostingu) po każdej instalacji modułu. Wiele problemów kompatybilności ujawnia się jako ostrzeżenia o deprecjacji PHP, a nie jako pełne awarie. Dzisiejsze ostrzeżenie to jutrzejszy fatalny błąd.

Krok 5: Przetestuj renderowanie front-end na obu motywach

Jeśli używasz PrestaShop 9 z nowym motywem Hummingbird, przetestuj każdy moduł, który cokolwiek wyświetla na front-endzie. Zwróć szczególną uwagę na:

• Modyfikacje strony checkout (formularze modułów płatności, wybór przewoźnika, walidacja adresu)
• Widgety strony produktowej (recenzje, listy życzeń, przewodniki po rozmiarach, niestandardowe pola)
• Hooki nagłówka i stopki (mega menu, paski wyszukiwania, podglądy koszyka)
• Filtry i sortowanie na stronach kategorii

Jeśli pozostajesz na motywie Classic, Twoje ryzyko kompatybilności front-end jest niższe, ale zmiany Bootstrap 5 mogą nadal wpływać na moduły, które wstrzykują własny CSS.

Co pytać dostawców modułów

Kiedy kontaktujesz się z dostawcą modułu w sprawie kompatybilności z PrestaShop 9, nie pytaj po prostu “czy jest kompatybilny?” To pytanie daje Ci odpowiedź tak/nie, która może być błędna. Zamiast tego zadaj te konkretne pytania:

1. “Czy moduł został przetestowany na PrestaShop 9.0 I 9.1?” — Wersja 9.1 wprowadziła dodatkowe zmiany łamiące kompatybilność (Bootstrap 5.3.3, deprecjacja jQuery, nowe zmiany hooków). Testowanie tylko na 9.0 nie wystarczy.
2. “Czy moduł nadal obsługuje PrestaShop 8.x z tym samym plikiem ZIP?” — Jeśli dostawca wymaga osobnej wersji dla PrestaShop 9, to obciążenie utrzymaniowe dla Ciebie. Dobrze zbudowany moduł obsługuje wykrywanie wersji wewnętrznie.
3. “Czy zmigrowaliście się z deprecated wzorców Symfony 4.4?” — Jeśli dostawca nie rozumie tego pytania, to mówi Ci coś o ich głębi technicznej.
4. “Czy moduł używa jQuery na front-endzie?” — Jeśli tak, zapytaj o ich harmonogram migracji do vanilla JavaScript, zanim Hummingbird porzuci wsparcie jQuery.
5. “Jaki jest Wasz zakres testowania wersji PHP?” — Chcesz usłyszeć od 8.1 do 8.4, nie tylko “PHP 8”.

Ramowy model decyzji o aktualizacji

Na podstawie mojego doświadczenia z aktualizacjami środowisk testowych i pomagania właścicielom sklepów w ocenie ich gotowości, oto praktyczny model do decydowania, kiedy aktualizować:

Aktualizuj teraz, jeśli:

• Wszystkie Twoje moduły mają potwierdzoną kompatybilność z PrestaShop 9 od swoich dostawców
• Już pracujesz na PHP 8.1+
• Masz środowisko staging, gdzie przetestowałeś pełną ścieżkę aktualizacji
• Twój motyw to Classic, Hummingbird lub motyw potomny któregoś z nich

Poczekaj 3-6 miesięcy, jeśli:

• Jeden lub dwa niekrytyczne moduły nie mają potwierdzenia kompatybilności
• Twój motyw to mocno dostosowany motyw zewnętrzny (dostawcy motywów często opóźniają się ze wsparciem głównych wersji)
• Polegasz na Advanced Stock Management (musisz najpierw znaleźć zastępcze przepływy pracy)

Nie aktualizuj jeszcze, jeśli:

• Krytyczne moduły (płatności, wysyłka, integracja ERP) nie mają oświadczenia o kompatybilności z PrestaShop 9
• Pracujesz na PHP 7.4 lub 8.0 (musisz najpierw zaktualizować PHP, co jest osobnym projektem)
• Twój dostawca modułu milczy od ponad roku (moduł może być porzucony)

Jak przygotowaliśmy nasze moduły (Studium przypadku z prawdziwego świata)

W mypresta.rocks zacząłem testowanie na buildach alfa PrestaShop 9 na miesiące przed stabilnym wydaniem. Oto jak wyglądał ten proces, ponieważ uważam, że jest pouczający dla zrozumienia, co “kompatybilny” naprawdę oznacza.

Faza 1: Automatyczne skanowanie kompatybilności

Uruchomiłem analizę statyczną przez każdy moduł, szukając wzorców opisanych powyżej: użycie starszych kontrolerów, importy usuniętych bibliotek, wywołania deprecated funkcji, klasy Bootstrap 4 w szablonach i użycie jQuery w plikach JavaScript. Dało to priorytetyzowaną listę wymaganych zmian.

Faza 2: Migracja na Symfony 6.4

Każdy kontroler administracyjny został przejrzany pod kątem wzorców dostępu do kontenera usług. Tam, gdzie moduły używały $this->get(), zmigrowaliśmy na constructor injection. Tam, gdzie moduły rozszerzały deprecated klasę bazową, zaktualizowaliśmy klasę nadrzędną. To była najbardziej czasochłonna faza, ponieważ dotyka rdzeniowej architektury każdego modułu skierowanego do panelu administracyjnego.

Faza 3: Audyt hooków

Porównaliśmy każdą rejestrację hooków w każdym module z listą 33 usuniętych hooków. Tam, gdzie moduły używały usuniętych hooków, albo zmigrowaliśmy na zastępcze hooki, albo wdrożyliśmy warunkową rejestrację hooków zależną od wersji, która automatycznie używa prawidłowego hooka dla wykrytej wersji PrestaShop.

Faza 4: Testowanie wielowersyjne

Każdy moduł został przetestowany na PrestaShop 1.7.6, 1.7.7, 1.7.8, 8.0, 8.1, 9.0 i 9.1. Na każdej wersji testowaliśmy z PHP 8.1, 8.2, 8.3 i 8.4. Pojedynczy plik ZIP modułu działa we wszystkich tych kombinacjach, ponieważ moduł wykrywa wersję PrestaShop w czasie wykonania i odpowiednio dostosowuje swoje zachowanie.

Właśnie to “kompatybilność wsteczna” naprawdę oznacza w praktyce. To nie są dwa osobne buildy. To jedna baza kodu, która obsługuje różnice wersji wewnętrznie.

Faza 5: Testowanie motywów front-end

Każdy moduł z wyjściem front-end został przetestowany na motywie Classic i motywie Hummingbird. Nazwy klas Bootstrap, atrybuty danych i JavaScript zostały zweryfikowane na obu. Tam, gdzie wymagane były różnice szablonów, użyliśmy wbudowanego wykrywania wersji PrestaShop do ładowania odpowiedniego szablonu.

Rezultat: wszystkie moduły mypresta.rocks są w pełni kompatybilne z PrestaShop 9.0 i 9.1, zachowując kompatybilność wsteczną z PrestaShop 1.7.6+ i wszystkimi wersjami 8.x. Bez osobnych pobrań, bez specjalnych kroków instalacji, bez cennika “edycji PrestaShop 9”.

Typowe problemy po aktualizacji i jak je naprawić

Nawet z kompatybilnymi modułami możesz napotkać te problemy po aktualizacji do PrestaShop 9:

Biały ekran / Błąd 500 po instalacji modułu

Zazwyczaj spowodowane brakującą zależnością Composer. Sprawdź log błędów PHP pod kątem błędów “Class not found”. Naprawa to albo aktualizacja modułu (jeśli dostawca ma nową wersję), albo ręczne dodanie brakującej biblioteki do katalogu vendor modułu.

Strony administracyjne ładują się, ale brakuje funkcji

To problem cichego usunięcia hooków. Moduł zainstalował się pomyślnie, ale jego hooki nie uruchamiają się na PrestaShop 9. Sprawdź rejestracje hooków modułu z listą usuniętych hooków. Skontaktuj się z dostawcą po zaktualizowaną wersję używającą zastępczych hooków.

Zepsute stylowanie front-end na Hummingbird

Zmiany nazw klas z Bootstrap 4 na 5. Moduł działa na Classic, ale wygląda na zepsutym na Hummingbird. To wymaga aktualizacji szablonów od dostawcy modułu. Jako tymczasowe obejście możesz przełączyć się na motyw Classic, czekając na aktualizację dostawcy.

Błędy JavaScript w konsoli przeglądarki

Często spowodowane zależnością od jQuery w środowisku Hummingbird. Sprawdź konsolę deweloperską przeglądarki (F12) pod kątem błędów “$ is not defined” lub “jQuery is not defined”. Długoterminowa naprawa to vanilla JavaScript, ale w krótkim terminie możesz ręcznie dołączyć jQuery w zasobach motywu.

Powiadomienia e-mail przestały działać

Jeśli moduł wysyła e-maile bezpośrednio przez SwiftMailer zamiast funkcji mail PrestaShop, ulegnie awarii na PrestaShop 9, gdzie SwiftMailer został zastąpiony przez Symfony Mailer. Skontaktuj się z dostawcą po aktualizację.

PrestaShop 9.1: Dodatkowe zmiany do obserwacji

PrestaShop 9.1 wprowadził własny zestaw zmian ponad 9.0. Jeśli aktualizujesz bezpośrednio do 9.1 (zalecane, ponieważ to najnowsza stabilna wersja), bądź świadomy tych dodatkowych czynników kompatybilności:

• Theme::getDefaultTheme() nie zwraca już zahardkodowanego ciągu “classic”. Moduły zakładające, że domyślny motyw to Classic, wymagają aktualizacji.
• Hook displaySearch został usunięty z Hummingbird, ponieważ powodował konflikty na stronach 404. Moduły podpinające się do displaySearch dla dostosowań wyszukiwania front-end muszą używać alternatywnych hooków.
• Biblioteki graficzne D3 i NVD3 zostały zaktualizowane do nowszych wersji. Widgety dashboardu używające tych bibliotek mogą renderować się niepoprawnie.
• Selektory JavaScript zmigrowały na konwencję data-ps-*, zastępując selektory oparte na klasach. Moduły używające querySelector z nazwami klas specyficznymi dla PrestaShop mogą przestać targetować prawidłowe elementy.

Twoja checklista przed aktualizacją

Wydrukuj to, przyklej na ścianie i nie aktualizuj, dopóki każdy punkt nie jest odhaczony:

1. Zinwentaryzuj wszystkie zainstalowane moduły z nazwami dostawców i aktualnymi wersjami
2. Sprawdź stronę każdego dostawcy pod kątem oświadczeń o kompatybilności z PrestaShop 9
3. Zaktualizuj wszystkie moduły do najnowszych wersji (nawet przed aktualizacją PrestaShop)
4. Skonfiguruj środowisko staging z kopią produkcyjnej bazy danych
5. Zainstaluj PrestaShop 9.1 na staging
6. Instaluj moduły po jednym, sprawdzając logi błędów po każdym
7. Przetestuj podstawową funkcjonalność każdego modułu (nie tylko “czy strona konfiguracyjna się ładuje”)
8. Przetestuj renderowanie front-end na swoim aktywnym motywie
9. Przeprowadź kompletne zamówienie testowe przez checkout
10. Sprawdź logi błędów PHP pod kątem ostrzeżeń o deprecjacji
11. Zweryfikuj wysyłanie e-maili ze wszystkich modułów wysyłających powiadomienia
12. Wykonaj kopię zapasową wszystkiego: bazy danych, plików i konfiguracji
13. Zaplanuj aktualizację w godzinach niskiego ruchu
14. Zachowaj kopię zapasową PrestaShop 8.x dostępną przez co najmniej 30 dni po aktualizacji

Podsumowanie

PrestaShop 9 to znaczące ulepszenie. Symfony 6.4 przynosi lepszą wydajność, nowoczesne praktyki PHP i bardziej utrzymywalną architekturę. Motyw Hummingbird jest szybszy i bardziej dostępny niż Classic. Nowe API administracyjne otwiera możliwości, które wcześniej nie były dostępne.

Ale nic z tego nie ma znaczenia, jeśli Twoje moduły ulegną awarii podczas aktualizacji. Poświęć czas na prawidłowy audyt. Użyj środowiska staging. Wymagaj od swoich dostawców wyraźnych oświadczeń o kompatybilności, nie niejasnych odpowiedzi “powinno działać”.

Jeśli szukasz modułów rygorystycznie przetestowanych na PrestaShop od 1.7.6 do 9.1, sprawdź katalog modułów mypresta.rocks. Każdy moduł jest dostarczany jako pojedynczy plik ZIP, który działa we wszystkich wspieranych wersjach, a kompatybilność z PrestaShop 9 jest zawarta w każdej licencji, nie sprzedawana jako osobna aktualizacja.

Masz pytania dotyczące Twojego konkretnego scenariusza aktualizacji? Skontaktuj się z nami, a pomogę Ci ocenić Twój zestaw modułów.