PrestaShop 9.1: Hummingbird 2.0, wysyłka przez wielu przewoźników i przewodnik po migracji

PrestaShop 9.1.0 stał się wersją stabilną 23 marca 2026 roku, dwa i pół tygodnia po RC1. Używamy go we własnej infrastrukturze deweloperskiej od wersji beta i przepuściliśmy przez niego sporą część naszych 159 modułów. Poniżej znajdziesz taką wersję informacji o wydaniu, jaką sami chcielibyśmy wcześniej przeczytać. Co naprawdę się zmieniło, co jest tylko marketingowym szumem i na co trafiliśmy w praktyce.

Jeśli tkwisz na 1.7 albo 8.x i czekasz na właściwy moment na przeskok, 9.1 jest rozsądnym celem. Nie jest jednak magicznym rozwiązaniem. Oto czego nie mówi changelog.

Hummingbird 2.0, domyślny motyw świeżej instalacji, ale z zastrzeżeniami

Najważniejsza zmiana: Hummingbird jest domyślnym motywem w świeżych instalacjach PS 9.1. Pierwszy Hummingbird pojawił się w 9.0 jako nowoczesny motyw do samodzielnego włączenia; 2.0 to prawdziwa przebudowa, nie tylko nowa warstwa lakieru.

• Bootstrap 5.3.3 zamiast wersji alfa używanej w Hummingbird 1.x. Dostajesz stabilne API utility, działające punkty zaczepienia dla trybu ciemnego i właściwości niestandardowe CSS, na których naprawdę można polegać w motywie potomnym.
• Prace nad dostępnością EAA, zespół deklaruje zgodność „ponad 95%” z Europejskim Aktem o Dostępności (obowiązującym od czerwca 2025). Lepsze ARIA, lepszy kontrast, nawigacja klawiaturą, która faktycznie działa. Warto powiedzieć to wprost: 95% to nie 100%, a my zdążyliśmy już poprawić kilka błędów stanów fokusu w naszych nakładkach finalizacji zakupu. Testuj, zanim wdrożysz sklep dla klienta objętego regulacjami.
• jQuery jest przestarzałe, ale nie usunięte. Nadal znajduje się w paczce, z adnotacją, że zostanie wycięte w PrestaShop 10. Jeśli piszesz nowy JS do modułu, pisz go w czystym JavaScripcie. Zrobiliśmy taką konwersję w naszych modułach części sklepowej w zeszłym roku i ani razu za tym nie zatęskniliśmy.
• Nowe atrybuty hooków JS, data-ps-ref, data-ps-action, data-ps-target zastępują doraźne selektory CSS jako rekomendowaną powierzchnię wiązania JS. Chodzi o to, aby projektanci mogli zmieniać nazwy klas bez psucia skryptów modułów. Ta zmiana nam się podoba.
• Zmiany w hookach: displayOrderDetail i displayModalContent są nowe. displaySearch znika, jeśli Twój moduł był do niego zarejestrowany, potrzebujesz zamiennika.

Samą pracę nad motywem potomnym opisaliśmy osobno: przewodnik po motywach potomnych. W skrócie, zacznij od startera Hummingbird 2.0, nie forkuj motywu nadrzędnego.

Hummingbird 1.x → 2.0: co potrafi ugryźć

Jeśli masz już wdrożony motyw potomny oparty o Hummingbird 1.x, tutaj spędzisz swój dzień migracji:

• Zmiany nazw klas Bootstrap 5.3. ml-*/mr-* → ms-*/me-*. data-toggle → data-bs-toggle. .custom-control → .form-check. Przeszukaj motyw potomny i szablony modułów. Znaleźliśmy takie rzeczy w modułach, których nie dotykaliśmy od dwóch lat.
• Selektory JS. Selektory oparte na klasach, takie jak .product-add-to-cart, nadal działają, ale konwencja przesuwa się w stronę data-ps-ref. Migruj stopniowo. Na razie nie ma jednego sztywnego terminu przełączenia.
• Nadpisania kolorów. Bootstrap 5.3 kompiluje wartości kolorów do lokalnych dla komponentu właściwości niestandardowych CSS. Nadpisanie globalnego tokena :root nie wystarczy dla elementów takich jak .btn-primary, potrzebujesz .btn-primary { --bs-btn-bg: #yourcolor; }. To pierwsza rzecz do sprawdzenia przy każdym zgłoszeniu typu „kolor marki się nie zastosował”.

Wysyłka przez wielu przewoźników, funkcja, o którą sprzedawcy prosili od 1.5

To jest właśnie ta zmiana. Jedno zamówienie może być teraz wysłane przez kilku przewoźników, z niezależnym śledzeniem i statusami dla każdej przesyłki.

Do wersji 9.0 włącznie jedno zamówienie oznaczało jednego przewoźnika. Sprzedajesz brodzik ważący 200 kg plus tubę silikonu? Sprzedawca musiał ręcznie dzielić zamówienie, budować własny moduł albo brać różnicę kosztów na siebie. Każdy nasz klient z branży wetroomów chciał tego od lat.

9.1 wprowadza przypisywanie przewoźnika na poziomie przesyłki:

• Podział zamówienia na wiele przesyłek, każda z własnym przewoźnikiem i śledzeniem
• Ponowne łączenie przesyłek, jeśli magazyn zmieni plan
• Niezależne śledzenie każdej przesyłki w procesie obsługi zamówienia
• Daty dostawy i statusy dla każdej przesyłki osobno

Dwa ważne zastrzeżenia. Po pierwsze, funkcja jest dostarczana za flagą funkcji; trzeba ją włączyć, nie należy zakładać, że działa od razu. Po drugie, zespół core oznacza API wprost jako „może się zmienić”, więc jeśli dziś napiszesz pod nie integrację, spodziewaj się powrotu do kodu przed 10.0. Nie podpinamy jej jeszcze produkcyjnie do naszych modułów wysyłkowych, bo czekamy przynajmniej na jedno mniejsze wydanie, które ustabilizuje API.

Jeśli sprzedajesz mieszany katalog (meble plus akcesoria, sprzęt plus materiały eksploatacyjne, cokolwiek, gdzie DHL obsługuje drobnicę, a resztę kurier paletowy), to jest dobry powód do aktualizacji.

Nowy system rabatów

Stary silnik reguł koszyka ma następcę. On również jest za flagą funkcji i domyślnie wyłączony. Nowy model dzieli rabaty na cztery wyraźne typy:

• Rabaty katalogowe, stosowane do produktów przed koszykiem
• Rabaty koszyka, stosowane podczas finalizacji zakupu na podstawie warunków
• Darmowa wysyłka, osobny typ rabatu, a nie checkbox w regule koszyka
• Darmowy prezent, produkty dodawane automatycznie

Stare reguły koszyka nadal działają, aktualizacja niczego nie psuje. Nowy system jest szybszy (widzieliśmy sklep z 600 regułami koszyka, w którym strona administracyjna była nieużywalna; nowy model radzi sobie z tym bez narzekania) i łatwiejszy do zrozumienia. Raportowanie też staje się czytelniejsze: wreszcie można oddzielić „przychód utracony przez darmową wysyłkę” od „przychodu utraconego przez rabaty procentowe” bez parsowania jednej monolitycznej tabeli.

Nie przenieśliśmy jeszcze żadnego klienta ze starych reguł koszyka w sytuacji produkcyjnej. „Za flagą funkcji” oznacza: testuj na stagingu i nie włączaj w produkcji bez planu wycofania.

Zmiany po stronie deweloperskiej, które warto znać

Poniższe punkty to te, które naprawdę interesują nas jako autorów modułów, a nie pełny changelog:

• Nowe hooki: actionModuleEnable, actionModuleDisable, actionModuleUpgradeAfter, actionConfigurationUpdateValueBefore. actionModuleUpgradeAfter to ten, na który czekaliśmy. Pozwala nam niezawodnie uruchamiać migracje po aktualizacji, bez dopinania się do kolejności naszych własnych plików upgrade-*.php.
• Nowe komendy CLI: prestashop:thumbnails:regenerate, prestashop:search:index, prestashop:translation:export-module. Sama komenda od miniatur oszczędza nam godzinę przy każdym wdrożeniu odświeżenia katalogu.
• Usprawnienia automatycznego mapowania Doctrine dla encji modułów, mniej boilerplate w services.yml.
• PHP 8.1–8.5 oficjalnie wspierane. Nasz kontener deweloperski działa na 8.4 i nie trafiliśmy na problemy.
• Zaktualizowane stawki VAT dla Estonii i Rumunii.
• D3 i NVD3 zaktualizowane, jeśli masz własne widżety pulpitu, zrób im testy regresji.
• Motyw Classic przechodzi do 3.1.1 dla sklepów, które jeszcze z niego nie zeszły.

Dlaczego 9.1 jest rozsądnym celem migracji

Pytanie, które słyszymy od klientów przy każdej rozmowie: „Jestem na 1.6 / 1.7 / 8.x, aktualizować teraz czy czekać?” Przez ostatni rok odpowiadaliśmy: „czekać na 9.1”. Teraz odpowiedź brzmi: „ruszać”.

Z PrestaShop 1.6

1.6 jest po zakończeniu wsparcia od października 2023. Brak łatek bezpieczeństwa, brak prac nad kompatybilnością, a PHP 7.x jest martwe u większości hostingodawców. Każdy miesiąc zwiększa ryzyko i koszt migracji.

Realistycznie o nakładzie pracy: migracja 1.6 → 9.1 to przebudowa, nie aktualizacja. Dane (produkty, klienci, zamówienia) migrują. Motyw nie, zaplanuj motyw potomny Hummingbird 2.0 od zera. Większość modułów będzie wymagała zamienników. Dwa do sześciu tygodni pracy dla nietrywialnego sklepu, głównie testowania, nie samej aktualizacji.

Jak wygląda ta praca:

1. Postaw czystą instalację 9.1 na stagingu
2. Wyeksportuj katalog, klientów i zamówienia ze źródłowej 1.6
3. Zaimportuj je oficjalnymi narzędziami albo bezpośrednim skryptem migracji DB, zwykle robimy to skryptem
4. Instaluj i testuj każdy moduł osobno, nie hurtowo
5. Zbuduj motyw potomny na Hummingbird 2.0
6. Zaplanuj przekierowania 301 dla każdego URL-a, którego kształt się zmienia
7. Przetestuj każdą ścieżkę finalizacji zamówienia, bramkę płatności, wysyłkę, e-mail transakcyjny
8. Przełącz DNS w oknie niskiego ruchu

Z PrestaShop 1.7

1.7 było wydaniem przejściowym, pół legacy, pół Symfony. 9.1 popycha migrację dalej, ale jej nie kończy: stare kontrolery administracyjne legacy/Smarty nadal działają przez wrapper LegacyController. Powierzchnia API jest modernizowana, a świeże instalacje PS 9.1 wreszcie dostają domyślnie porządny, nowoczesny i responsywny motyw.

Kompatybilność modułów jest rozsądna. Dobrze utrzymane moduły działają już na ścieżce 1.7 → 9.x. Użyj Update Assistant (starego autoupgrade), ale tylko na kopii stagingowej. Widzieliśmy, jak Update Assistant przerywał działanie w połowie na prawdziwych sklepach przez osierocone wiersze DB albo własny override; jeśli zdarzy się to na produkcji, masz przestój zamiast sesji debugowania.

Co uderza podczas migracji 1.7 → 9.1:

• Pliki override w override/classes/ są największym pojedynczym źródłem bólu przy aktualizacji. Wiele z nich będzie kolidować z nową architekturą. Przejrzyj każdy i tam, gdzie to możliwe, zastąp go hookiem.
• Usunięte API. Tools::displayPrice() zniknęło. AdminController::ajaxDie() zniknęło. Jeśli Twoje własne moduły wywołują je bezpośrednio, zakończy się to błędem krytycznym. My opakowujemy przestarzałe API w naszym pakiecie prestashop-compat, jeśli utrzymujesz własne moduły, warto skopiować ten wzorzec.
• Motywy oparte na Classic z 1.7 w większości działają na 9.x z drobnymi problemami wizualnymi. Motywy potomne Hummingbird 1.x wymagają przejścia przez zmiany nazw Bootstrap 5.3.
• PHP. 9.1 wymaga minimum 8.1. Jeśli Twój hosting nadal działa na 7.4 albo 8.0, to jest pierwsza migracja, zanim dotkniesz PrestaShop.

Z PrestaShop 8.x

To najłatwiejszy przypadek. Duży skok był między 8 → 9.0 (Symfony 4.4 → 6.4, nowe API panelu administracyjnego). 9.0 → 9.1 to zmiana inkrementalna. Jeśli Twoje moduły działają już na 9.0, powinny działać na 9.1 po lekkich testach regresji.

Powody, żeby to zrobić: Hummingbird 2.0 bije Classic przy nowych wdrożeniach, wysyłka przez wielu przewoźników rozwiązuje realny problem operacyjny, a Ty zostajesz na utrzymywanej gałęzi.

Gdzie patrzeć po aktualizacji: wszelkie dostosowania panelu administracyjnego (API panelu zmieniło się w 9.0), moduły w procesie obsługi zamówień (wysyłka przez wielu przewoźników dotyka modelu obiektu zamówienia) oraz widżety pulpitu (aktualizacja D3/NVD3).

Perspektywa długoterminowa

PrestaShop 10 to kolejny cel. jQuery znika całkowicie. Panel administracyjny dalej się modernizuje. Natywna jednostronicowa finalizacja zakupu (funkcja, której sprzedawcy chcieli od dekady) ma już scalony pierwszy kod i jest planowana na przyszłe wydanie minor. Prace B2B trwają w core.

9.1 na Symfony 6.4 LTS to dziś wersja z najdłuższą dostępną perspektywą wsparcia. Zostanie na 1.6 albo 1.7 oznacza zostanie na czymś, co już jest niewspierane.

Checklista migracji

Niezależnie od wersji startowej kolejność działań jest mniej więcej taka sama:

1. Audyt. Spisz każdy moduł, każdą modyfikację motywu, każdy override, każdą zewnętrzną integrację (płatności, ERP, API wysyłkowe).
2. Przejście przez kompatybilność modułów. Dla każdego modułu potwierdź obsługę 9.x u dewelopera albo w changelogu. Niewspierane moduły wymień przed uruchomieniem aktualizacji, nie po niej.
3. Środowisko stagingowe. Sklonuj bazę danych i pliki produkcji na osobny serwer. Produkcja nie jest środowiskiem testowym.
4. Najpierw PHP. 9.1 wymaga 8.1+. Na produkcyjnych stosach klientów domyślnie wybieramy 8.2 albo 8.3. Na własnych maszynach deweloperskich 8.4.
5. Update Assistant dla sklepów 1.7+. Czysta instalacja plus migracja danych dla 1.6.
6. Przetestuj każdą ścieżkę finalizacji zamówienia. Każdą metodę płatności, każdą opcję wysyłki, każdy e-mail transakcyjny. Złóż prawdziwe zamówienia testowe.
7. Zachowaj URL-e. Zrób 301 dla każdego URL-a, którego kształt się zmienił. Obserwuj Search Console przez pierwszy miesiąc.
8. Zresetuj OPcache właściwą drogą. Przez żądanie webowe, nie CLI, to różne pule. To przyczyna połowy zgłoszeń „biały ekran po wdrożeniu”, które widzimy.
9. Obserwuj pierwsze 48 godzin. Logi błędów, współczynnik konwersji, czasy ładowania stron. Miej udokumentowany plan wycofania.

Na czym ludzie najczęściej się potykają

Powtarzające się awarie aktualizacji, które widzimy w migracjach klientów, według częstotliwości:

• Ciche awarie override. Override w override/classes/Foo.php nadal ładuje się zamiast pliku core, nawet gdy sygnatura jest błędna. PrestaShop nie zawsze to zaloguje. Przejrzyj i usuń nieużywane override przed aktualizacją, nie po niej.
• OPcache serwuje przestarzały bytecode. Wgrałeś nowy kod, uruchomiłeś testy przez CLI, wszystko wyglądało dobrze, a pula webowa nadal serwuje starą kompilację. Resetuj przez dostępny z weba endpoint PHP. W każdym projekcie trzymamy plik opcache-reset.php o stałej nazwie właśnie po to.
• Własne kolumny w tabelach core. Jeśli dodawałeś kolumny do ps_order, ps_product itd., sprawdź je względem upgrade/sql/9.1.0.sql. Kolizje schematu potrafią położyć sklep.
• Webhooki płatności wskazują stary URL. Zmiana domeny podczas migracji? Zaktualizuj URL webhooka w Stripe, PayPal, Adyen albo innym używanym systemie. Pominięte webhooki oznaczają brak potwierdzeń zamówień i niezadowolonych klientów.
• Ścieżki cron. 9.x przeniosło część punktów wejścia. Ponownie zweryfikuj każde zadanie zaplanowane po aktualizacji.
• Szablony e-mail. Silnik szablonów zmienił się w 9.x. Własne szablony e-mail z 1.7 nie zawsze renderują się poprawnie. Testuj każdy typ e-maila transakcyjnego, nie tylko potwierdzenie zamówienia.

Awarie aktualizacji konkretnych modułów (i poprawki)

Kilka konkretnych modułów core odpowiada za większość zgłoszeń typu „aktualizacja się skończyła, ale panel administracyjny nie działa”. Warto sprawdzić je przed uruchomieniem aktualizacji, razem z realnymi poprawkami:

• ps_mbo (Marketplace in your Back Office) może położyć panel administracyjny. Aktualizacja do 9.0 z zainstalowanym ps_mbo może sprawić, że panel administracyjny stanie się niedostępny przy ładowaniu, ponowna instalacja na 9.0 odtwarza błąd. Poprawka: odinstaluj ps_mbo przed uruchomieniem aktualizacji do 9.0. (Issue PrestaShop #38983.)
• ps_edition_basic jest tylko dla PrestaShop 8 i nie usuwa się automatycznie. Pozostawiony po aktualizacji może rzucać błędem na stronie głównej. Poprawka: zmień domyślną stronę panelu administracyjnego z pulpitu Edition Basic i odinstaluj ps_edition_basic przed aktualizacją, albo pozwól, aby krok niekompatybilnych modułów w Update Assistant go usunął (teraz odczytuje deklarowaną przez każdy moduł kompatybilność wersji).
• ps_distributionapiclient (DistributionApi) może dać 500 w panelu administracyjnym. Aktualizacja się kończy, ale późniejsza aktualizacja tego modułu kończy się błędem „Too few arguments to function DistributionApi::__construct(), 6 passed and exactly 7 expected”, a wyczyszczenie cache powoduje potem błąd 500 w panelu administracyjnym (front sklepu nadal działa). W chwili pisania ten problem jest wciąż otwarty i bez oficjalnej poprawki (issue #39032), więc nie czyść cache po nieudanej aktualizacji DistributionApi i sprawdź zgłoszenie przed aktualizacją sklepu, który na nim polega.
• Panel administracyjny nadal pokazuje „dostępna aktualizacja” po tym, jak moduł został już zaktualizowany. We wczesnym 9.0 kolumna version w ps_module nie była zapisywana po aktualizacji modułu, więc komunikat nigdy nie znikał. Poprawka: zaktualizuj do 9.0.1 lub nowszej, naprawiono to przez nowy parser wersji modułów (PR #39358). Jeśli utknąłeś na starszym buildzie, społecznościowe obejście polega na ręcznym ustawieniu wiersza: UPDATE ps_module SET version='<installed>' WHERE name='<module>' (czyści komunikat, ale nie jest oficjalną poprawką). (Issue #39151.)
• Update Assistant przerywa na symlinku. Na hostingach, które nie pozwalają na symlinki, uruchomienie 8.2.1 → 9.0.0 może zatrzymać się z błędem „Could not extract link admin/bundles/apiplatform … Failed to create 'symbolic' link”. Poprawka: zaktualizuj moduł Update Assistant (autoupgrade) do aktualnej wersji i upewnij się, że hosting pozwala na symlinki. (Issue #38892.)

Żaden z tych problemów nie jest powodem, żeby nie aktualizować, to powody, żeby najpierw zrobić przejście przez kompatybilność modułów na stagingu, czyli krok 2 checklisty powyżej.

Wydajność, bez ściemy

9.1 na Symfony 6.4 jest szybszy niż starsze wersje, ale powody nie są magiczne:

• Kompilacja kontenera jest tańsza w Symfony 6.4 niż w 4.4. Czas startu spada.
• Hummingbird 2.0 dostarcza mniej CSS i JS niż Classic. Przy przestarzałym jQuery świeże instalacje niosą mniejszy ładunek JS niż kiedykolwiek 1.7.
• PHP 8 JIT. Przesiadka z 7.x na 8.x odpowiada za większość nagłówków typu „PrestaShop przyspieszył”. Typowo 10–30% dla obciążeń katalogowych.
• Cache HTTP / Doctrine w Symfony 6.4 jest o generację dojrzalszy niż w 4.4.

Na naszym kontenerze deweloperskim sklep z 5000 produktów na 9.1 z Hummingbird 2.0 serwuje strony kategorii z ~120 ms TTFB. Ten sam sprzęt na 1.7 z Classic miał ~250 ms. Ta liczba pochodzi ze środowiska deweloperskiego, nie jest deklaracją produkcyjną. Wynik u Ciebie będzie zależał od hostingu, modułów i konfiguracji. Ale kierunek jest realny.

O naszych modułach

Wszystkie 159 modułów mypresta.rocks przeszło przez 9.1, a sam mypresta.rocks działa produkcyjnie na 9.1.3. Dla każdego modułu utrzymujemy jedną bazę kodu, każdy moduł w katalogu deklaruje obsługę od PrestaShop 1.6 aż do aktualnego wydania, bez twardego limitu wersji i bez osobnych forków czy ZIP-ów dla konkretnych wersji.

Elementy ważne dla kompatybilności między wersjami:

• Warstwa administracyjna. Używamy wspólnego frameworka administracyjnego (naszego pakietu prestashop-admin), który opakowuje powłokę Symfony, aby pojedyncze moduły nie musiały tego robić. Zakładki nadrzędne, breadcrumbs, pasek boczny: wszystko działa pod panelem administracyjnym 9.1 bez zmian w poszczególnych modułach.
• Tłumaczenia. Wszędzie używamy $this->module->l(), bo przeżywa kolejne wersje. Usunięte $this->l() w kontrolerach administracyjnych nas nie dotyka.
• Formatowanie cen. Tools::displayPrice() usunięto w 9.0. Opakowujemy je w MyPrestaRocks\Compat\PriceFormatter, wywołuje nowoczesny formatter oparty na locale w 8.x/9.x, a na 1.7 robi fallback. Jeden helper, każda wersja PS, bez porozrzucanych po szablonach if (version_compare(...)).

Jeśli planujesz migrację i chcesz przetestować nasz stos na swoich danych, skorzystaj z darmowego 30-dniowego demo na stagingu, jeśli jest dostępne. Jeśli wolisz wsparcie, oferujemy też konsultacje migracyjne.

FAQ

Czy mogę pominąć 8 i przejść prosto z 1.7 do 9.1?

Tak. Update Assistant obsługuje bezpośrednie przejście 1.7.x → 9.x. Nie potrzebujesz pośredniego kroku przez 8.x. Zastrzeżenie: najpierw potwierdź kompatybilność każdego modułu z 9.x.

Czy mój motyw Classic nadal będzie działał na 9.1?

Tak. Classic jest zaktualizowany do 3.1.1 w 9.1 i pozostaje w pełni wspierany. Po prostu nie jest już domyślnym motywem świeżej instalacji. Motyw potomny Classic powinien działać dalej z drobnymi korektami.

Czy wysyłka przez wielu przewoźników nadaje się na produkcję?

Jest dostarczana za flagą funkcji. PrestaShop uznaje ją za wystarczająco stabilną do użycia, ale zastrzega sobie prawo do zmiany API. Jeśli jest krytyczna dla biznesu, włącz ją na stagingu, napisz testy integracyjne i przygotuj się na powrót do kodu w 9.2.

Która wersja PHP?

8.2 albo 8.3 dla konserwatywnych stosów produkcyjnych. 8.1 to minimum. 8.4 i 8.5 są wspierane, a my używamy 8.4 na devie, ale zweryfikuj cały stos modułów przed wypchnięciem tego na produkcję.

Ile trwa typowa migracja?

8.x → 9.1 bez egzotycznych modułów: jedno popołudnie. 1.7 → 9.1 w sklepie mocno opartym na modułach: tydzień do dwóch tygodni testów. 1.6 → 9.1 z przebudową motywu: dwa do sześciu tygodni. Sama aktualizacja jest szybka, czas zajmuje weryfikacja każdego procesu.

Czekać czy zacząć przygotowania teraz?

Zacznij teraz. 9.1.0 jest stabilny. Następny krok to aktualizacja na stagingu, audyt modułów, test finalizacji zamówienia, weryfikacja motywu, zaplanowanie przełączenia produkcji.

Czy PrestaShop 9 nadaje się na produkcję?

Tak. 9.1.0 jest stabilny od marca 2026 i opiera się na gałęzi Symfony 6.4 LTS, z najdłuższą dostępną dziś perspektywą wsparcia. Sam mypresta.rocks działa na 9.1.3. Uczciwe zastrzeżenie jest takie samo jak przy każdej dużej wersji: nowe silniki wysyłki przez wielu przewoźników i rabatów są dostarczane za flagami funkcji, więc przetestuj je na stagingu, zanim włączysz w produkcji.

Czy moje obecne moduły będą działać na PrestaShop 9.1?

Dobrze utrzymywane moduły zazwyczaj tak. Ścieżka 1.7 → 9.x jest wspierana. Prawdziwe ryzyka to kilka konkretnych modułów core podczas samej aktualizacji (zobacz poprawki dla nazwanych modułów powyżej) oraz każdy moduł, który wywołuje API usunięte w 9.0, na przykład Tools::displayPrice(). Potwierdź obsługę 9.x moduł po module na stagingu przed uruchomieniem produkcyjnym i najpierw wymień te niewspierane.

Najważniejszy wniosek

9.0 było rewolucją: Symfony 6.4, nowe API panelu administracyjnego, nowoczesna architektura. 9.1 to wersja, która czyni 9.0 praktycznym wyborem, nowoczesny motyw gotowy do produkcji, model wysyłki, o który sprzedawcy prosili od czasów 1.x, i silnik rabatów, który nie zapada się pod 600 regułami koszyka.

Niezależnie od tego, z której wersji startujesz, to właśnie na tę warto migrować. Im dłużej czekasz, tym większa luka. Jeśli wstrzymywałeś się na „właściwe wydanie”, 9.1 nim jest.

Powiązane materiały

• Jak migrować do PrestaShop 9: kompletny przewodnik po aktualizacji
• Motywy potomne PrestaShop: przewodnik po dostosowaniu Classic & Hummingbird
• Rozwiązywanie problemów z PrestaShop: białe ekrany & błędy 500
• Optymalizacja wydajności zapytań bazodanowych PrestaShop i cache pełnych stron