Czym jest PrestaShop 9.2 i jak czytać numerację wydań

PrestaShop numeruje wydania w schemacie major.minor.patch. To nie kosmetyka — od tego zależy, ile pracy Cię czeka i czy aktualizacja to piątkowe popołudnie, czy projekt na cały miesiąc.

• 9.0.5 — patch. Poprawki błędów i bezpieczeństwa, bez nowych funkcji. Ryzyko niskie: podmiana plików, wyczyszczenie cache, test koszyka i płatności. Zwykle 1–2 godziny.
• 9.1 / 9.2 — minor. Nowe funkcje, nowe API, zapowiedzi deprecacji. Ryzyko średnie: moduły i motyw trzeba przetestować, część starych wywołań zaczyna sypać warningami.
• 10.0 — major. Zmiany niekompatybilne i usunięcia legacy. Ryzyko wysokie, liczone w tygodniach.

Skąd bierze się fraza „prestashop 9 2”? Z dwóch miejsc: z przyzwyczajenia do numeracji łat, gdzie „9.2” brzmi jak kolejna poprawka, oraz z automatycznie generowanych stron typu „release date”, które wyprzedzają fakty o kilka miesięcy. Zanim cokolwiek zaplanujesz, sprawdź status sam.

Wersja Twojego sklepu: zaplecze → Parametry zaawansowane → Informacje (Advanced Parameters → Information) pokazuje pełny numer, np. 9.0.5. Drugie źródło to plik app/AppKernel.php, w którym siedzi stała VERSION, oraz composer.json — jeśli widzisz tam prestashop/prestashop w wersji 9.0.x, to nie masz 9.2, tylko 9.0.x.

Oficjalna weryfikacja: release notes i tagi w repozytorium PrestaShop/PrestaShop na GitHubie, devdocs.prestashop-project.org (wymagania i zmiany dla deweloperów) oraz changelog dołączony do paczki. Jeśli w tych miejscach nie ma taga 9.2.x — wydania nie ma.

Rozstrzygnięcie: jeżeli numer 9.2 nie jest jeszcze opublikowany, mówimy o przygotowaniu do linii 9.x, a nie o istniejącym pliku do pobrania. Planuj horyzont, nie pobieranie. Szerszy kontekst skoków major opisuje nasz materiał o audycie i przygotowaniu sklepu do migracji na PrestaShop 10.

Co realnie zmienia linia PrestaShop 9.x względem 8.x

Różnica między 8.x a 9.x nie sprowadza się do nowych ikonek w panelu. To zmiana architektury, a co za tym idzie — zakresu testów, które musisz wykonać przed wdrożeniem.

Symfony jako fundament. W 8.x backend opiera się na starszej gałęzi frameworka, linia 9.x przeskakuje na nowszą. Praktyczna konsekwencja: moduł, którego kontroler admina korzysta z usuniętego serwisu albo z API wyciętego w nowszym Symfony, wywali błąd 500 przy pierwszym wejściu w konfigurację. Dokładny numer frameworka sprawdzasz w composer.json w paczce wydania, nie w blogpostach. Moduły pisane po staremu — globalne Db::getInstance(), wartości z Tools::getValue() bez walidacji, brak wstrzykiwania zależności — działają do pierwszej zmiany.

Admin API obok webservice. Stary webservice /api zostaje, ale równolegle rośnie nowe Admin API: inne uwierzytelnianie, inna struktura odpowiedzi, inne endpointy. Dla integracji z ERP to pytanie „przepisywać teraz czy za rok”. Jeśli ERP ciąga stany magazynowe po starym /api, ta ścieżka nadal działa, ale nowe funkcje mogą być dostępne wyłącznie w Admin API. Zanim podpiszesz umowę na kolejną integrację, sprawdź, na którym API pracuje dostawca — typowe pułapki opisujemy w tekście o zakresie i ograniczeniach modułów w PrestaShop.

Hummingbird kontra classic. Hummingbird to nowy motyw domyślny oparty na Bootstrapie 5, z innym podziałem szablonów. Classic zostaje jako kompatybilny. Child theme napisany dla classic nie przenosi się 1:1 — inne nazwy plików, inne hooki, inna struktura CSS. Przy katalogu z indywidualnymi szablonami produktu licz raczej dni niż godziny.

Co wypada bez refaktoru: stare kontrolery admina, przestarzałe helpery tłumaczeń, część hooków wyświetlania i wywołania usuniętych klas. Lista rośnie z każdym wydaniem minor, więc im później zaczniesz, tym drożej.

Wymagania techniczne PrestaShop 9.x: PHP, MySQL, pamięć, cache

Twarde progi, po których od razu widać, czy hosting podoła, czy trzeba szukać VPS-a.

PHP. Linia 9.x startuje z PHP 8.1 jako minimum, realnie celuj w 8.2 lub 8.3. Pamiętaj o kalendarzu php.net: wsparcie bezpieczeństwa dla 8.1 kończy się 31 grudnia 2025, dla 8.2 — 31 grudnia 2026. Sklep na gałęzi bez wsparcia to otwarte drzwi. Dokładny dozwolony zakres wersji sprawdź w dokumentacji dla deweloperów PrestaShop przed zmianą — projekt zawęża go wraz z patchami.

Baza danych. MySQL 8.0 lub MariaDB 10.4+ to bezpieczny start; starsze wersje mogą nie przejść instalatora. Kluczowy jest charset: utf8mb4 i spójne collation na wszystkich tabelach. Migracja z mieszanym collation kończy się błędami „Illegal mix of collations” przy JOIN-ach. Sprawdź przed kopiowaniem:
SELECT TABLE_NAME, TABLE_COLLATION FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'twoja_baza';

Progi serwerowe — wartości, nie „powinno wystarczyć”:

• memory_limit: 256M minimum, 512M przy dużym katalogu i importach CSV;
• max_execution_time: 60 s na co dzień, 300 s na czas migracji i przebudowy cache;
• OPcache: włączony, 128–256 MB; na stagingu validate_timestamps=1, na produkcji 0 dopiero po testach;
• Redis jako backend cache, jeśli katalog ma powyżej 5 tys. produktów;
• Varnish przed PHP tylko wtedy, gdy masz procedurę czyszczenia cache po zmianie ceny lub stanu.

Kiedy shared hosting mówi „nie”. Brak CLI i composera, brak możliwości zmiany memory_limit, konto MySQL bez uprawnień ALTER i DROP (migracja ich wymaga), limit 1 GB na bazę, backupy bez możliwości przywrócenia na żądanie. Przed zakupem VPS sprawdź w panelu: przełączanie wersji PHP, dostęp po SSH, eksport bazy powyżej 100 MB przez phpMyAdmin, limity inode i politykę backupów. Zakres takich wdrożeń opisujemy w dziale PrestaShop w DropDigital.

Czy Twoje moduły i motyw zadziałają w PrestaShop 9.x

Audyt rozszerzeń zacznij od override'ów, nie od listy modułów. Katalog override/ zawiera pliki, które podmieniają logikę klas core. Po aktualizacji core się zmienia, a override zostaje ze starym kodem — i wtedy najczęściej sypie się koszyk albo panel administracyjny. Polecenie find override -type f -name "*.php" pokaże skalę problemu. Jeśli lista ma więcej niż 3–5 plików, masz dług do spłacenia przed migracją. Każdy plik porównaj z nową wersją klasy core (diff) i sprawdź, który moduł go wrzucił — najprościej po dacie modyfikacji pliku z dnia instalacji modułu.

Moduł oceniaj po trzech sygnałach: dacie ostatniego wydania, deklarowanej kompatybilności w config.xml (sekcja <compatibility> z wartościami min i max) oraz użyciu API oznaczonych w dokumentacji jako przestarzałe. Brak wpisu max oznacza, że autor nic nie deklaruje. W kodzie szukaj wywołań typu Tools::jsonEncode() czy Db::getInstance()->ExecuteS() — to stare aliasy, które w nowszej linii mogą zniknąć. Metodę przeglądu rozszerzeń i granice tego, co moduł może bezpiecznie robić, opisujemy szerzej w tekście o zakresie i ograniczeniach modułów w PrestaShop.

Najwyższe ryzyko: płatności i kurierzy. Testuj w tej kolejności: autoryzacja płatności, webhook/IPN, zwrot, generowanie etykiety, tracking, pobranie (COD), mapa punktów. Dopiero potem maile, feedy i moduły marketingowe. Kiedy czekać, a kiedy pisać własny? Jeśli integrujesz się z niszowym ERP i dostawca podaje termin „w tym kwartale, bez daty”, a zakres to 3–4 endpointy (zamówienia, stany, faktury), własny moduł to zwykle 3–5 dni pracy i pełna kontrola. Przy płatnościach kartowych i certyfikowanych integracjach — nie.

Aktualizacja do PrestaShop 9.x krok po kroku (na stagingu, nie na produkcji)

Kolejność jest stała. Najpierw kopia: archiwum plików (tar) plus zrzut bazy przez mysqldump --single-transaction. Pamiętaj o katalogach img/ i download/ — potrafią mieć kilka GB. Zrzut od razu odtwórz na testowej bazie. Kopia, której nie sprawdziłeś, nie jest kopią.

Staging postaw na tym samym stacku: identyczna wersja PHP (ta sama minor), ta sama wersja MySQL/MariaDB, te same rozszerzenia intl, mbstring, gd, te same memory_limit i max_execution_time. Inaczej błędy z testów nie przeniosą się na produkcję. Potem aktualizacja modułem 1-Click Upgrade albo ręcznie (wymiana plików + uruchomienie skryptu upgrade). Ograniczenie 1-Click: nie przeskoczysz majora jednym kliknięciem. Historycznie przejścia idzie się etapami — 1.7 → 8.x → 9.x — i każdy etap testuj osobno. W stagingu włącz tryb debug, wyłącz cache i sprawdź logi błędów po każdym kroku.

Testy po aktualizacji rób w tej kolejności: koszyk, checkout gościa, checkout zalogowanego, każda metoda płatności, mail potwierdzający (SMTP, nie mail()), faktura PDF, zwrot i korekta. Rollback przygotuj przed startem: dump bazy sprzed wdrożenia, snapshot VM, stare pliki w osobnym katalogu, obniżone TTL DNS do 300 s, tryb maintenance. Ustal też okno — rollback bazy oznacza utratę zamówień złożonych w trakcie migracji, więc rób to w nocy i zablokuj zamówienia na czas przełączenia. Kontekst całego przygotowania sklepu opisujemy w sekcji PrestaShop w DropDigital.

SEO i wydajność po aktualizacji: gdzie najczęściej spada ruch

Po zmianie wersji PrestaShop generuje plik .htaccess od nowa — z zakładki SEO i URL. Jeśli pracujesz na Nginx, reguły przepisań są ręczne i nikt ich za Ciebie nie odtworzy. Sprawdź 10 adresów przez curl -I: produkt, kategoria, kategoria z paginacją, strona CMS, sitemap.xml, robots.txt. Szukaj kodów 200, ale też łańcuchów 301 → 301 — maksymalnie jeden przeskok. Zasada: 301, gdy zmieniłeś schemat URL i stary adres ma linki; 410, gdy produkt został trwale wycofany i nie ma odpowiednika; 404 tylko przy błędzie. Szczegóły wdrożenia opisuje tekst o Friendly URL w PrestaShop.

Lista kontrolna w Google Search Console: Sitemaps (czy data ostatniego odczytu się zmienia), Page indexing (czy nie rośnie grupa „Wykluczone”), Crawl stats (czy nie spadła liczba żądań), URL Inspection na pięciu najlepszych produktach. Canonical musi być absolutny, na https, bez parametrów. hreflang sprawdź w obie strony, z x-default.

Nowy motyw to nowe Core Web Vitals. Zmierz przed i po w PageSpeed Insights (dane laboratoryjne) oraz w raporcie CWV w GSC (dane terenowe). Progi: LCP ≤ 2,5 s, CLS ≤ 0,1, INP ≤ 200 ms — opisane w dokumentacji Web Vitals. Najczęstsze regresje: obraz hero powyżej 300 KB, fonty bez preload, bannery bez zadeklarowanych wymiarów powodujące przesunięcia.

Na koniec e-commerce: w GA4 DebugView sprawdź add_to_cart, begin_checkout, purchase. Upewnij się, że zakup nie leci dwa razy (moduł + GTM) i że waluta oraz wartość są poprawne. Które etapy mierzy moduł, rozpisujemy w artykule o etapach sprzedaży mierzonych przez moduł GA4 dla PrestaShop.

Integracje, które psują się najczęściej: płatności, kurierzy, ERP

Z aktualizacją PrestaShop jest jak z remontem: przez tydzień wszystko wygląda dobrze, a psuje się to, co dotyka pieniędzy. Płatności, etykiety i ERP to trzy miejsca, w których błąd po migracji oznacza niedokończone zamówienie, paczkę bez numeru nadania albo stany magazynowe rozjeżdżające się z magazynem.

Płatności (Przelewy24, PayU, Stripe). Po pierwsze URL powrotu i webhooka w panelu operatora — musi wskazywać domenę, na której sklep faktycznie działa, z https i bez starego prefiksu. Po drugie hooki modułu: actionValidateOrder i paymentReturn powinny być zarejestrowane po aktualizacji. Po trzecie mapowanie statusów: „oczekiwanie na płatność” → „płatność zaakceptowana” → „w realizacji”. Sprawdź idempotencję — podwójny callback nie może zdublować zamówienia — oraz weryfikację podpisu (signature/checksum). W Stripe zanotuj wersję API w module: zmieniona po cichu potrafi zmienić format zdarzenia.

Kurierzy (InPost Paczkomaty, DPD, DHL). Generowanie etykiety, wybór paczkomatu w checkout i webhooki statusów. Najczęstsza pułapka to dane produktu: waga 0 kg albo brak wymiarów blokuje nadanie. Druga — strefa czasowa i format daty w API. Trzecia — brak listy punktów pickup po zmianie sposobu ich pobierania. Co przygotować przed startem, opisałem w tekście o integracji InPost z PrestaShop.

ERP. Sprawdź mapowanie statusów po ID, nie po nazwie — moduł może dopisać własne statusy i rozjechać całą siatkę. Ustal kierunek synchronizacji stanów (ERP → sklep czy sklep → ERP) i jej częstotliwość. Przy 9.x zweryfikuj, czy moduł nie korzysta z elementów legacy wycofanych w nowej linii — punktem wyjścia jest dokumentacja deweloperska PrestaShop i changelog modułu.

Sposób testu: na stagingu jedno zamówienie od początku do końca — produkt fizyczny, płatność w trybie sandbox, etykieta, faktura, e-mail, zwrot. Dopiero potem produkcja.

Aktualizować teraz czy poczekać? Decyzja w 5 pytaniach

Decyzję o aktualizacji podejmuje się na podstawie stanu sklepu, nie kalendarza wydawcy. Pięć pytań, na które odpowiedź „nie” oznacza „czekamy”:

1. Z jakiej wersji startujesz? 9.0.x → 9.x to inna skala niż 1.7 → 9.x.
2. Które moduły są krytyczne? Płatności, kurierzy, ERP, feedy, moduły B2B. Wypisz wersje i sprawdź deklarowaną kompatybilność.
3. Jaki masz sezon? Jeśli większość obrotu robisz w Q4, nie dotykasz produkcji w październiku i listopadzie.
4. Masz staging i procedurę rollbacku? Bez kopii bazy i plików oraz planu powrotu nie ma testu, jest loteria.
5. Jaki jest budżet godzinowy i kto robi wdrożenie? Wewnętrzny zespół czy agencja — z konkretną datą w kalendarzu.

Orientacyjne widełki z naszych projektów (to nie wycena, a punkt wyjścia do rozmowy):

Rekomendacja. Patch w obrębie 9.0.x ma sens, gdy nie zmienia się API modułów, a lista krytycznych integracji przechodzi smoke test. Pełną migrację planuj, gdy wychodzisz z 1.7, masz overrides w rdzeniu albo moduły bez wsparcia dla 9.x.

Aktualizacja jest projektem, gdy zmieniasz motyw, moduły i dane. Jest zwykłym utrzymaniem, gdy domykasz patch: kopia, staging, test, wdrożenie w oknie serwisowym. Kryteria wejścia w opiekę z SLA są proste: dostęp do stagingu, lista modułów z wersjami, procedura rollbacku, monitoring i uzgodnione okno serwisowe. Punkt wyjścia do szerszego planu: audyt i przygotowanie sklepu do migracji oraz usługi PrestaShop.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Potwierdź status wydania 9.2 — Sprawdź listę tagów w release notes na GitHubie PrestaShop i wpis w devdocs.prestashop-project.org. Bez tego nie planuj terminu.
• Zapisz obecną wersję sklepu — Zaplecze → Parametry zaawansowane → Informacje; dodatkowo plik konfiguracyjny jądra aplikacji i composer.json.
• Sprawdź wersję PHP — Panel hostingu lub phpinfo(). Porównaj z wymaganiami podanymi w release notes dla konkretnego wydania z linii 9.x.
• Sprawdź bazę danych — Wersja MySQL/MariaDB oraz charset i collation tabel. Dla nowych instalacji standardem jest utf8mb4 — sprawdź to przed migracją, nie po.
• Sprawdź memory_limit — W panelu lub przez phpinfo(). Wartość z niskim limitem to najczęstsza przyczyna przerwanej aktualizacji.
• Sprawdź max_execution_time — Szczególnie jeśli baza ma duże tabele (zamówienia, koszyki, logi). Długi import potrafi przekroczyć typowy limit.
• Sprawdź OPcache — Czy jest włączony i czy ma wystarczający rozmiar. Po aktualizacji wyczyść cache OPcache i cache sklepu.
• Wypisz moduły spoza rdzenia — Dla każdego: data ostatniego wydania, deklarowana kompatybilność, czy korzysta z przestarzałych klas i hooków.
• Zinwentaryzuj override/ — Przejrzyj folder override/ i zanotuj, który moduł go zostawił. To pierwszy podejrzany przy błędach po aktualizacji.
• Sprawdź motyw i child theme — Ustal, czy sklep korzysta z classic, czy z motywu opartego o Hummingbird, i które szablony są nadpisane ręcznie.
• Sprawdź integracje zewnętrzne — ERP, systemy magazynowe i księgowe: czy łączą się przez stary webservice, czy przez nowe Admin API. To wpływa na kolejność testów.
• Wykonaj kopię plików i bazy — Kopia z datą i możliwością szybkiego przywrócenia. Sprawdź, czy da się ją odtworzyć na stagingu, zanim zaczniesz aktualizację.
• Postaw staging na tym samym stacku — Ta sama wersja PHP, ta sama baza, te same rozszerzenia. Inny stack = testy bez wartości.
• Przygotuj listę testów i plan rollbacku — Koszyk, checkout gościa i zalogowanego, płatność, mail potwierdzający, panel administracyjny. Zapisz, jak wrócisz do poprzedniej wersji, jeśli testy nie przejdą.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• web.dev – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów