PrestaShop 9.2 One Page Checkout: szansa czy pułapka dla B2B?

Największa zmiana w procesie zamówienia mieści adres, dostawę i płatność na jednym ekranie bez przeładowywania strony. Benchmark IMRG/Ecommpay wyniósł 61% dla checkoutu jednostronicowego i 56% dla wielostronicowego, lecz nie gwarantuje takiego wyniku. W sklepie B2B decyzję o migracji poprzedź audytem modułów i ERP.

Co naprawdę zmienia One Page Checkout w 9.2?

W PrestaShop 9.2 pojawia się natywny moduł ps_onepagecheckout, który skupia kontakt, adres, dostawę, płatność i podsumowanie na jednej stronie. Nie usuwa przy tym dotychczasowego checkoutu. W panelu, w sekcji Design > Checkout, możesz wybrać układ jednostronicowy albo zachować wariant czterostronicowy.

Natywny One Page Checkout daje ekosystemowi PrestaShop jeden wspólny przebieg zamówienia, pod który można przygotowywać motywy, płatności i dostawy.

Wcześniej sklep potrzebował płatnego modułu lub własnej implementacji, jeśli standardowy proces był zbyt długi. Każde takie rozwiązanie mogło inaczej przejmować szablony i obsługiwać zależności między adresem, przewoźnikiem oraz metodą płatności. Właśnie dlatego oficjalna prezentacja ps_onepagecheckout mówi dużo o zgodności z resztą ekosystemu, a nie wyłącznie o wyglądzie formularza.

Zobacz cały checkout na jednym ekranie

Klient od razu widzi strukturę finalizacji zakupu. Pola kontaktowe, adres, dostępne formy dostawy, płatności i podsumowanie znajdują się w jednym widoku. Sekcje zależne od wcześniejszych danych pozostają nieaktywne, dopóki nie można ich poprawnie uzupełnić. Przykładowo lista przewoźników wymaga adresu dostawy, a część metod płatności zależy od kraju lub wybranego sposobu transportu.

Taki układ zmniejsza liczbę zmian kontekstu. Nie oznacza jednak, że klient musi oglądać ogromny formularz. Dobrze przygotowany OPC stopniowo odsłania pola i komunikaty, zachowując czytelną kolejność decyzji.

Jak AJAX przyspiesza finalizację zamówienia?

Zmiana adresu odświeża dostępnych przewoźników bez ponownego ładowania strony. Po wyborze dostawy aktualizują się płatności i podsumowanie. AJAX skraca oczekiwanie, lecz zwiększa znaczenie poprawnej obsługi stanów pośrednich, błędów walidacji i wolnych odpowiedzi z zewnętrznych usług.

Od strony technicznej moduł przejmuje renderowanie przez hookDisplayOverrideTemplate. Nowy hook actionCheckoutBuildProcess, dodany w PR #41047, pozwala innym modułom wejść w proces budowania checkoutu. Twórca motywu musi natomiast zachować kontrakt szablonów, DOM i stylowania. W praktyce oznacza to testowanie pełnego zachowania strony, a nie samego faktu, że formularz się wyświetla.

Podczas testów obserwuj również kolejność żądań. Szybka zmiana adresu albo przewoźnika może uruchomić kilka aktualizacji niemal jednocześnie. Odpowiedź starszego żądania nie powinna nadpisać nowszego wyboru klienta. Sprawdź też zachowanie po utracie internetu, powrocie do karty przeglądarki i użyciu przycisku Wstecz. W tych sytuacjach podsumowanie musi odpowiadać danym widocznym w formularzu.

Dlaczego klient zaczyna tylko od e-maila?

W trybie gościa pierwszym wymaganym kontaktem jest adres e-mail. Pozostałe dane pojawiają się wtedy, gdy są potrzebne do dostawy lub płatności. Logowanie i tworzenie konta przeniesiono poza checkout, więc kupujący nie przerywa finalizacji zamówienia, aby rozstrzygnąć, czy chce się rejestrować.

PrestaShop zachowuje możliwość odzyskiwania porzuconych koszyków. Dane potrzebne do tego procesu są zapisywane w tle. To ważne, bo wygodniejszy guest checkout nie powinien odbierać sklepowi informacji potrzebnych do późniejszej komunikacji.

Przetestuj również powrót z wiadomości przypominającej, aby klient zobaczył aktualny koszyk, poprawny adres i nadal dostępne metody dostawy.

Natywny OPC czy płatny moduł: co wybrać?

Wybór zależy od tego, jak bardzo Twój obecny checkout odbiega od standardu. ps_onepagecheckout jest dołączony do PrestaShop 9.2 bez osobnej licencji i rozwijany w organizacji PrestaShop. The Checkout, SuperCheckout oraz podobne moduły mogą natomiast oferować funkcje lub układy, których natywny OPC jeszcze nie ma.

Brak osobnej licencji nie oznacza wdrożenia bez kosztów, ponieważ nadal trzeba sprawdzić motyw, płatności, dostawy, analitykę i wszystkie rozszerzenia koszyka.

Natywny moduł można aktualizować niezależnie od rdzenia. Zyskujesz też oficjalną dokumentację dla twórców modułów i motywów. Aktualne funkcje rozwiązań zewnętrznych sprawdź jednak bezpośrednio u ich producentów. Listy z wcześniejszych porównań szybko się starzeją, szczególnie gdy zmieniają się integracje płatnicze i wymagania PrestaShop.

Porównaj funkcje przed zmianą checkoutu

Zanim wyłączysz używane rozwiązanie, zestaw potrzeby sklepu z realnymi możliwościami każdej opcji:

Jeśli sklep używa rozbudowanego cross-sellingu, pól branżowych albo niestandardowej kolejności kroków, pozostanie przy obecnym module może być rozsądne. Przy nowym wdrożeniu lub prostym checkoutcie natywny wariant ogranicza liczbę zależności od zewnętrznych dostawców.

Jak sprawdzić moduły płatności i dostawy?

Samo pojawienie się logo operatora w checkoutcie niczego jeszcze nie potwierdza. Test powinien objąć cały cykl zamówienia:

1. Wykonaj płatność udaną, odrzuconą i przerwaną, a następnie sprawdź callback oraz zmianę statusu zamówienia.
2. Zweryfikuj Przelewy24, PayU, Stripe i PayPal w tych wersjach, które faktycznie działają w Twoim sklepie.
3. Sprawdź InPost, DPD i DHL, w tym mapę punktów, paczkomaty, walidację kodu pocztowego i ponowne otwarcie wyboru dostawy.
4. Przetestuj faktury, zgody RODO, kupony, darmową dostawę oraz reguły zależne od kraju i wartości koszyka.
5. W analityce porównaj zdarzenia rozpoczęcia checkoutu, wyboru dostawy, płatności i zakupu, aby po zmianie nie stracić ciągłości danych.

Takie testy wykonaj na stagingu z kopią konfiguracji produkcyjnej. Wynik z czystej instalacji nie mówi jeszcze, jak zachowa się sklep z własnym motywem i kilkudziesięcioma modułami.

Decyzję zapisz w krótkiej macierzy wymagań: funkcja obowiązkowa, funkcja przydatna i element do usunięcia. Dzięki temu nie odtworzysz przyzwyczajeń, które powstały wyłącznie dlatego, że pozwalał na nie stary moduł. Porównuj też koszt utrzymania przez dwa lub trzy lata, obejmujący aktualizacje, wsparcie producenta i poprawki po zmianach operatorów płatności.

Czy One Page Checkout pasuje do sklepu B2B?

W firmowym procesie zakupowym jeden ekran pomaga tylko wtedy, gdy nie ukrywa złożonych reguł. PrestaShop 9.2 One Page Checkout może dobrze obsłużyć szybkie ponowienia zamówień i zakupy przedstawicieli handlowych na telefonie. Sklep z wielostopniową akceptacją, koszykiem współdzielonym oraz dokumentami zamówienia potrzebuje dodatkowej logiki.

W B2B jednokrokowy checkout skraca finalizację wtedy, gdy ceny, uprawnienia i integracja ERP są już poprawnie rozstrzygnięte przed złożeniem zamówienia.

Jak OPC obsługuje indywidualne ceny?

Ceny zależne od klienta, grupy, wolumenu lub umowy trafiają do koszyka przez standardowe mechanizmy PrestaShop albo przez moduł B2B. OPC wyświetla wynik tych obliczeń, lecz asynchroniczne odświeżenia wymagają uwagi. Zmiana adresu, ilości lub sposobu dostawy może uruchomić ponowne przeliczenie podatków, rabatów i kosztów transportu.

Jeśli cena pochodzi z ERP, sprawdź, czy każde odświeżenie otrzymuje ten sam wynik i czy interfejs wyraźnie sygnalizuje oczekiwanie. Klient nie może zaakceptować jednej wartości, a po chwili zobaczyć innej bez wyjaśnienia. Przy 150+ autorskich modułach Webixy zgodność trzeba oceniać według konkretnej wersji i sposobu działania rozszerzenia, a nie według samej nazwy.

Przykładowy test zacznij od klienta przypisanego do umowy ramowej. Dodaj produkt objęty progiem ilościowym, zmień liczbę sztuk, adres oddziału i przewoźnika. Potem wyloguj się, zaloguj ponownie i wróć do koszyka. Na każdym etapie porównaj cenę netto, VAT, rabat oraz sumę z danymi w ERP. Taki przebieg szybciej ujawnia problemy niż pojedyncze zamówienie testowe.

Gdzie kończy się standard, a zaczyna custom?

Approval workflows nie są natywną funkcją 9.2. Jeżeli pracownik tworzy koszyk, a kierownik zatwierdza limit lub warunki handlowe, potrzebujesz własnego modułu albo dostosowania istniejącego procesu. OPC może wtedy pozostać ostatnim etapem po akceptacji, lecz nie powinien udawać całego workflow.

Podobnie wygląda multi-user editing. Wspólna praca nad koszykiem, numery PO, limity kupieckie i załączniki wymagają reguł wykraczających poza standardowy checkout. W takich sklepach pozostanie przy układzie wielostronicowym bywa czytelniejsze, dopóki wersja jednokrokowa nie zostanie zaprojektowana pod konkretny proces.

Zwróć uwagę na role użytkowników. Osoba składająca zamówienie może widzieć ceny, ale nie powinna zmieniać adresu rozliczeniowego lub przekraczać przyznanego limitu. OPC musi respektować te ograniczenia również w żądaniach AJAX, nie wyłącznie przez ukrycie pola. Walidacja po stronie serwera pozostaje konieczna, bo widok w przeglądarce nie stanowi zabezpieczenia reguł handlowych.

Improved Shipments: co właściwie obsługuje?

Eksperymentalny model Improved Shipments porządkuje obsługę kilku przesyłek i przewoźników w jednym zamówieniu. Funkcja rozwijana od 9.1 dotyczy przede wszystkim fulfillmentu i prezentacji multicarrier. Oficjalny opis Improved Shipments wskazuje wysyłkę na wiele adresów jako przyszły potencjał, a nie gotową możliwość natywnego OPC.

Nie zakładaj więc, że włączenie flagi rozwiąże podział zamówienia między biuro, magazyn i oddział klienta. Taki scenariusz trzeba osobno zaprojektować i przetestować z ps_onepagecheckout, ERP, dokumentami sprzedażowymi oraz kosztami dostawy.

Czy One Page Checkout podnosi konwersję?

Same dane sugerują przewagę krótszego procesu, lecz nie pozwalają obiecać wzrostu każdemu sklepowi. W raporcie IMRG i Ecommpay brytyjscy sprzedawcy z checkoutem jednostronicowym osiągali średnio 61% konwersji, a grupa z checkoutem wielostronicowym 56%. Badanie porównywało różne sklepy, więc nie było testem przyczynowym jednej zmiany.

Wynik 61% vs 56% traktuj jako benchmark do postawienia hipotezy, a nie prognozę dla Twojego sklepu.

Sprawdź, co mówią wyniki 61% i 56%

Raport IMRG i Ecommpay obejmuje okres od 1 stycznia do 30 czerwca 2024 roku. Średnia konwersja checkoutu wyniosła 58%. Dla single-page było to 61%, a dla multi-page 56%. W kolejnych stronach procesu wielostronicowego obserwowano spadki rzędu 5–7 punktów procentowych.

W tej samej analizie goście konwertowali na poziomie 52%, a zalogowani klienci na poziomie 64%. Jednocześnie goście odpowiadali za 59% zamówień. Dane pokazują więc, że łatwy guest checkout ma znaczenie, lecz nie dowodzą, że sam układ strony odpowiada za całą różnicę.

Kiedy krótszy checkout ma największy sens?

Najlepszym kandydatem jest sklep, w którym większość klientów kupuje na telefonie, koszyk nie wymaga konfiguracji, a zamówienie ma stosunkowo niską wartość. Przy wysokim AOV, produktach konfigurowanych, finansowaniu lub procesie B2B rozbicie informacji na etapy może zwiększać poczucie kontroli.

Jak policzyć scenariusz ROI dla Twojego sklepu?

Załóż 10 000 sesji checkout miesięcznie, AOV 200 zł i obecną konwersję 56%. Taki lejek daje 5600 zamówień oraz 1,12 mln zł miesięcznego przychodu. Przy hipotetycznych 61% byłoby to 6100 zamówień i 1,22 mln zł. Różnica wynosi 100 000 zł miesięcznie, czyli 1,2 mln zł rocznie.

Ta kalkulacja pokazuje mechanikę scenariusza, a nie obietnicę. Do modelu dodaj koszt wdrożenia, testów, ryzyko regresji, marżę i rzeczywisty udział ruchu objętego zmianą. Audyt przedwdrożeniowy Webixy może policzyć wariant ostrożny, bazowy i ambitny na danych Twojego sklepu, a później porównać je z wynikiem testu A/B.

Nie oceniaj testu wyłącznie po liczbie zamówień. Obserwuj wartość koszyka, marżę, użycie rabatów, błędy płatności oraz kontakt z obsługą. Jeśli OPC zwiększy konwersję, ale obniży AOV albo wygeneruje więcej błędnych adresów, wynik biznesowy może być słabszy. Segmentuj dane przynajmniej według urządzenia, nowego i powracającego klienta oraz rynku.

Kiedy przejść na PrestaShop 9.2? 3 scenariusze

Termin zależy bardziej od punktu startowego niż od listy nowości. Oficjalny Update Assistant obsługuje sklepy od wersji 1.7, ale dostępność narzędzia nie gwarantuje bezpiecznego przejścia z dowolnym motywem i zestawem modułów. Szerszy kontekst zmian znajdziesz w materiale PrestaShop 9: co nowego i czy warto migrować.

Im starsza wersja i większa liczba customizacji, tym częściej aktualizacja techniczna zamienia się w pełny projekt migracyjny.

PrestaShop 1.7: update czy nowa instancja?

Update Assistant jest przeznaczony dla PrestaShop 1.7 i nowszych wydań. Techniczna ścieżka istnieje, lecz przy sklepie rozwijanym przez kilka lat trzeba sprawdzić overrides, moduły bez wsparcia, niestandardowy motyw, dane oraz integracje. Czasem bezpieczniej zbudować nową instancję i kontrolowanie przenieść katalog, klientów, zamówienia oraz treści.

Wybór powinien wynikać z audytu, dopuszczalnego downtime i możliwości rollbacku. Jeżeli potrzebujesz przebudowy architektury, tworzenie sklepów PrestaShop można połączyć z migracją danych zamiast odtwarzać stare ograniczenia. Orientacyjny projekt trwający 3–6 miesięcy zawsze wymaga indywidualnej wyceny. Case studies Syfonik i Vetplanet pomagają zobaczyć, jak różne mogą być zakresy takich prac.

PrestaShop 8.x: przygotuj się na duży skok

Linia 8.x bazuje na Symfony 4.4, natomiast 9.x na Symfony 6.4. Dokumentacja zmian PrestaShop 9.0 opisuje też wymagania PHP i różnice istotne dla modułów. Przed aktualizacją sprawdź wersję interpretera, zależności Composer, motyw oraz rozszerzenia dotykające Back Office i checkoutu.

Classic nie obsługuje natywnego OPC bez dodatkowego dostosowania. Sam sklep może działać po aktualizacji, a nowy checkout nadal może wymagać pracy z szablonami. Przedział 1–3 miesięcy ma sens wyłącznie jako szacunek po audycie.

PrestaShop 9.0 i 9.1: prostsza aktualizacja

Wersja 9.2 jest wydaniem minor i ma zachować możliwie szeroką kompatybilność z 9.1.x. Symfony 6.4 pozostaje bez zmian, a OPC jest opcjonalny. Nadal trzeba przetestować moduły, motyw i integracje, ponieważ nowy przebieg zamówienia dotyka płatności oraz dostaw.

Beta 1 nie ma standardowej ścieżki aktualizacji do RC i Stable przez kanał Update Assistant. Plan 2–4 tygodni może wystarczyć na testy prostszego sklepu 9.x, lecz uruchomienie produkcyjne powinno poczekać na wersję Stable.

W każdym scenariuszu utwórz listę funkcji, których nie możesz utracić. Dopiero później dopasuj do niej wersję docelową, moduły i motyw. Taka kolejność chroni przed migracją prowadzoną dla jednej atrakcyjnej nowości, gdy pozostałe elementy sprzedaży pozostają niegotowe. Termin wdrożenia powinien uwzględniać także sezonowość i okres zamrożenia zmian przed szczytem sprzedaży.

Jak przygotować sklep B2B z ERP do migracji?

W sklepie z Subiektem, Comarch ERP, SAP, IFS, Enovą lub Impulsem checkout jest częścią większego obiegu danych. Pobiera ceny i stany, rezerwuje towar, wysyła zamówienie, a czasem odbiera limity kredytowe. OPC zmienia momenty odświeżania interfejsu, więc integrację trzeba prześledzić od pierwszego adresu do potwierdzenia płatności.

Największe ryzyko nie leży w wyglądzie formularza, lecz w tym, czy każda asynchroniczna zmiana zachowuje spójne dane między PrestaShop i ERP.

Jak przetestować Subiekt, Comarch i SAP?

Każdy system ma inną architekturę, ale sensowny plan testów obejmuje pięć wspólnych obszarów:

1. Sprawdź pobieranie cen indywidualnych, rabatów, podatków i waluty po zmianie klienta, adresu, ilości oraz dostawy.
2. Zmierz liczbę i czas wywołań API, aby odświeżenia AJAX nie powodowały timeoutów ani przekroczenia limitów.
3. Zweryfikuj rezerwację stanów, szczególnie gdy ten sam produkt trafia do kilku koszyków lub magazynów.
4. Porównaj zamówienie w PrestaShop i ERP, w tym pozycje, koszty transportu, numery PO, komentarze oraz dane fakturowe.
5. Przetestuj błąd ERP i procedurę fallback, aby klient nie złożył zamówienia z niepotwierdzoną ceną lub stanem.

Nie każde odświeżenie OPC musi wywoływać ERP. Dobrze zaprojektowany cache może ograniczyć ruch, ale powinien mieć jasny czas ważności i regułę ponownej walidacji przed złożeniem zamówienia.

Które moduły Webixy trzeba sprawdzić?

Webixa ma ponad 150 autorskich modułów związanych między innymi z cenami B2B, rolami, dostępami i integracjami. Taka liczba nie oznacza, że wszystkie rozszerzenia dotykają checkoutu. Audyt powinien wskazać te, które modyfikują koszyk, klienta, adresy, przewoźników, płatności, zamówienie albo zdarzenia analityczne.

Szczególnej uwagi wymagają moduły z indywidualnymi cenami, approval workflow oraz synchronizacją Subiekta lub Comarchu. Trzeba ustalić, czy korzystają z actionCheckoutBuildProcess, czy poprawnie reagują na AJAX i czy nie zakładają przeładowania kolejnej strony. Jeśli używasz rozszerzenia Webixy, sprawdzenie jego konkretnej wersji powinno znaleźć się w planie przed zmianą checkoutu.

Co powinien zawierać audyt przedwdrożeniowy?

Dobry audyt kończy się planem, a nie samą listą modułów. Powinien opisać wersję PrestaShop, motyw, overrides, integracje ERP, PIM i WMS, wymagania PHP, wydajność, bezpieczeństwo, dane oraz proces rollbacku. Do tego dochodzi macierz testów płatności, dostaw i scenariuszy B2B.

Wynikiem powinien być zakres prac, kolejność wdrożenia, ryzyka, odpowiedzialności oraz szacunek czasu i kosztu. Webixa prowadzi takie analizy dla sklepów B2B i B2C, korzystając z 19 lat doświadczenia przy wdrożeniach PrestaShop. Kontakt w sprawie audytu: kontakt@webixa.pl, tel. +48 784 355 027.

W audycie wyznacz również kryteria odbioru. Mogą obejmować maksymalny czas synchronizacji ceny, zgodność sum między systemami, brak podwójnych zamówień i poprawny rollback. Dzięki mierzalnym warunkom łatwiej rozstrzygniesz, czy staging jest gotowy do próby generalnej. Ustal też właściciela każdego błędu, ponieważ problemy na styku sklepu i ERP często trafiają między zespoły.

Dołącz do wyników audytu kolejność testów oraz wymagane dane wejściowe.

Kiedy PrestaShop 9.2 będzie gotowy na produkcję?

Na 21 sierpnia 2026 roku dostępna jest wersja Beta 1, przeznaczona do testów. Feature Freeze rozpoczął się 9 lipca, a publiczną betę wydano 22 lipca. PrestaShop nie podał oficjalnej daty Release Candidate ani Stable, więc kalendarz migracji produkcyjnej nie powinien opierać się na niepotwierdzonych prognozach.

PrestaShop 9.2 Beta 1 instaluj na świeżym środowisku testowym, a nie na działającym sklepie.

Co oznacza status Beta 1 dla Twojego sklepu?

Ogłoszenie PrestaShop 9.2 Beta 1 wprost odradza używanie tej wersji na produkcji. Możesz już testować ps_onepagecheckout, Ask AI, Extra Properties, Improved B2B mode i funkcje eksperymentalne, ale implementacja oraz dokumentacja nadal mogą się zmieniać.

Beta otwiera najlepszy moment na sprawdzenie modułów i motywu. Błąd znaleziony teraz można zgłosić przed Stable. Nie jest to jednak skrót do wcześniejszego wdrożenia. Standardowy kanał Update Assistant nie prowadzi z Beta 1 do RC ani do wersji końcowej, dlatego PrestaShop rekomenduje świeżą instalację do realnych testów.

Kiedy pojawią się RC i wersja Stable?

Komunikat o Feature Freeze potwierdza etap stabilizacji, lecz nie zawiera daty końcowego wydania. RC pojawi się wtedy, gdy liczba i waga błędów pozwolą traktować build jako kandydata do wydania. Dopiero Stable powinien uruchomić finalne testy migracji produkcyjnej.

Jeśli chcesz śledzić cały cykl, pomocne są wersje PrestaShop: historia i aktualności. Przed publikacją lub decyzją budżetową sprawdź ponownie GitHub Releases, devdocs i blog Build. Data w artykule może szybko stracić aktualność.

Po publikacji Stable nie planuj wdrożenia na następny dzień. Daj producentom płatności, dostaw i motywu czas na potwierdzenie zgodności, a potem sprawdź ich aktualizacje na własnym stagingu. W sklepie o dużej sprzedaży warto obserwować pierwsze poprawki wydania i zgłoszenia dotyczące checkoutu. Stabilna etykieta oznacza gotowość projektu do produkcji, lecz nie certyfikuje Twojego zestawu rozszerzeń.

Jak bezpiecznie przetestować OPC na stagingu?

Przygotuj środowisko zbliżone do produkcji, ale odseparowane od klientów i prawdziwych płatności. Kolejność prac powinna wyglądać następująco:

1. Zrób pełny backup plików i bazy, a potem sprawdź, czy kopię da się odtworzyć.
2. Postaw świeżą instalację Beta 1 albo staging zgodny z oficjalną instrukcją testów.
3. Wgraj reprezentatywne dane i konfigurację, usuwając dane osobowe, których nie potrzebujesz.
4. Przejdź pełną macierz checkoutu: gość, klient zalogowany, mobile, rabaty, podatki, płatności, dostawy i błędy usług.
5. Zapisz regresje, plan rollbacku i metryki, które porównasz po wydaniu RC oraz Stable.

Przy produkcyjnym wdrożeniu wróć do testów na stabilnym pakiecie. Wynik osiągnięty na becie jest przygotowaniem, a nie odbiorem końcowym.

Próba generalna powinna odtworzyć planowaną kolejność operacji i zmieścić się w ustalonym oknie serwisowym. Zmierz czas backupu, aktualizacji, migracji danych, testu dymnego i ewentualnego powrotu. Jeśli rollback trwa dłużej niż dopuszczalna przerwa, zmień strategię przed dotknięciem produkcji.

Jakie inne nowości wnosi PrestaShop 9.2?

Poza checkoutem wersja 9.2 rozwija rozszerzalność danych, B2B, ceny, SEO i narzędzia administracyjne. Oficjalne devdocs zmian w PrestaShop 9.2 pozostają najlepszym źródłem dla twórców modułów, ponieważ opisują stan funkcji beta i ostrzegają, które interfejsy mogą się jeszcze zmienić.

Najbardziej użyteczne nowości dla rozbudowanych sklepów to Extra Properties, core-side JSON-LD oraz fundament nowego trybu B2B, lecz część z nich nadal ma status eksperymentalny lub beta.

Co zmienią new_pricing, JSON-LD i Ask AI?

Flaga new_pricing wprowadza rozwijaną architekturę cen i ma status beta. Dla sklepu B2B z cenami kontekstowymi jest istotna, ale nie należy jeszcze budować na niej krytycznego procesu bez sprawdzenia finalnej dokumentacji i migracji danych.

Core-side JSON-LD przenosi składanie danych strukturalnych z szablonów do ustandaryzowanego mechanizmu. Moduł może przez getStructuredData() i actionFrontControllerSetVariables dodawać lub zmieniać między innymi AggregateRating, MerchantReturnPolicy i ContactPoint. Łatwiej wtedy rozwijać SEO bez ręcznego edytowania wielu templatek.

Ask AI działa w Back Office przez PrestaShop MCP Server i pozwala połączyć własnego providera, na przykład ChatGPT, Claude albo Gemini. Oficjalne materiały potwierdzają pytania o dane sklepu i uruchamianie działań po akceptacji. Nie potwierdzają natomiast sterowania konfiguracją OPC, więc takiej funkcji nie należy obiecywać.

Jak Extra Properties upraszcza własne pola?

Do tej pory własne dane produktu, klienta lub zamówienia zwykle wymagały osobnych tabel i logiki zapisu w module. Extra Properties tworzy natywny punkt rozszerzenia. Pole może działać w wielu sklepach i językach, pojawiać się w formularzach oraz gridach Back Office, a także być dostępne w Front Office i Admin API.

Nie znaczy to, że wersja 9.2 nie zmienia bazy. Plik 9.2.0.sql zawiera zmiany schematu potrzebne do działania nowego systemu. Korzyść polega na tym, że autor modułu nie musi projektować własnych tabel dla każdego pola. Kod nadal jest oznaczony jako @experimental, dlatego jego kontrakt trzeba sprawdzić ponownie przed produkcyjnym wdrożeniem.

Czy Improved B2B mode jest gotowy do użycia?

Flaga improved_b2b jest domyślnie wyłączona. Po jej aktywacji i włączeniu trybu B2B otrzymujesz fundament native business entities, profili klientów firmowych, identyfikatorów biznesowych, adresów B2B oraz role-based access. Funkcję rozwijają wspólnie Soledis i zespoły PrestaShop SA.

Schemat bazy oraz API mogą zmienić się przed finalnym wydaniem, a dokumentacja wprost odradza budowanie na tym produkcyjnie. Improved B2B mode nie zawiera natywnych approval workflows. Traktuj go więc jako kierunek rozwoju i pole do testów, a nie gotowy zamiennik sprawdzonego systemu B2B.

Do eksperymentów przygotuj osobny zestaw danych firmowych i ról. Sprawdź, jak nowe encje wpływają na istniejące grupy klientów, adresy, uprawnienia oraz integrację ERP. Nie łącz testu Improved B2B mode z odbiorem OPC w jednym scenariuszu. Gdy pojawi się błąd, rozdzielenie zmian pozwoli szybciej wskazać jego źródło.

FAQ: 15 pytań o PrestaShop 9.2 i OPC

Czy PrestaShop 9.2 jest już wersją stabilną?

Nie. Na 21 sierpnia 2026 roku oficjalnie dostępna jest Beta 1. Data RC i Stable nie została ogłoszona, dlatego przed podjęciem decyzji sprawdź aktualny status w oficjalnych kanałach projektu.

Możesz już rozpocząć analizę zgodności, lecz harmonogram produkcyjny powinien zawierać bufor na poprawki po wydaniu stabilnym.

Czy OPC zastąpi dotychczasowy checkout?

Nie. Czterostronicowy checkout pozostaje dostępny. W Design > Checkout możesz przełączać układ między wariantem jednostronicowym i dotychczasowym, co ułatwia testy oraz ewentualny powrót.

Przełączenie układu nie zwalnia z kontroli danych zamówienia i zdarzeń analitycznych po obu ścieżkach.

Czy OPC działa z motywem Classic bez zmian?

Nie działa bez dodatkowego przygotowania. Motywy oparte na Hummingbird mają wsparcie out of the box, natomiast Classic może wymagać nadpisania szablonów modułu i dostosowania stylów.

Oceń zakres zmian przed migracją, szczególnie gdy motyw zawiera własne modyfikacje koszyka lub checkoutu.

Czy Przelewy24 i PayU będą działać z OPC?

Nie ma jednej gwarancji dla wszystkich wersji tych modułów. Sprawdź deklarację producenta, a następnie przetestuj płatność, callback, status zamówienia, anulowanie i zwrot na stagingu.

Wykonaj próbę osobno dla każdej waluty, kraju oraz metody dostawy używanej przez klientów.

Czy One Page Checkout zawsze zwiększa konwersję?

Nie. Benchmark 61% vs 56% porównywał grupy sklepów i nie dowodzi, że sam layout daje wzrost o 5 punktów procentowych. Wynik sprawdź w swoim lejku lub teście A/B.

Przed testem określ minimalny czas, wymaganą próbę i główną metrykę, aby nie zakończyć go po przypadkowym skoku sprzedaży.

Czy natywny OPC sprawdzi się w sklepie B2B?

Może się sprawdzić przy prostych zamówieniach i dużym udziale mobile. Approval workflows, koszyki współdzielone, numery PO oraz złożone ceny zwykle wymagają customizacji i testów z ERP.

Najpierw rozpisz role i reguły akceptacji, a potem oceń, czy jeden ekran nadal zachowuje czytelność procesu.

Czy z PrestaShop 1.7 można przejść na 9.2?

Update Assistant obsługuje wersje od 1.7, więc ścieżka techniczna istnieje. Przy starym motywie, overrides i wielu integracjach audyt może jednak wskazać nową instancję oraz kontrolowaną migrację danych.

Zadbaj o próbne odtworzenie danych i porównanie zamówień, klientów, haseł, rabatów oraz historii statusów.

Czy Improved Shipments współpracuje z OPC?

Oficjalne materiały nie potwierdzają kompletnego checkoutu OPC z wysyłką na wiele adresów. Improved Shipments dotyczy przede wszystkim wielu przesyłek i przewoźników, a zgodność z Twoim procesem trzeba sprawdzić osobno.

Nie projektuj więc procesu multi-address na podstawie samej zapowiedzi dalszego rozwoju tej funkcji.

Czy Ask AI może zmieniać konfigurację checkoutu?

Nie ma oficjalnego potwierdzenia takiej funkcji. Ask AI działa w Back Office i korzysta z MCP Server, lecz nie należy przedstawiać go jako narzędzia do włączania lub wyłączania OPC.

Zakres dostępnych działań potwierdzaj w dokumentacji wersji, którą rzeczywiście instalujesz.

Czy warto czekać na PrestaShop 10 z migracją?

Nie ma oficjalnej daty stabilnej wersji 10. Decyzję oprzyj na bezpieczeństwie, wsparciu obecnej wersji i potrzebach sklepu. PrestaShop 9.2 wdrażaj produkcyjnie dopiero po Stable i audycie.

Czekanie bez planu może zwiększyć dług techniczny i koszt późniejszego przejścia.

Czy natywny OPC działa w sklepie headless?

ps_onepagecheckout jest modułem frontowym związanym z systemem motywów. Sklep headless potrzebuje własnej integracji API i osobnego interfejsu checkoutu, a kompatybilność nie wynika automatycznie z instalacji modułu.

Czy AJAX poprawi Core Web Vitals sklepu?

Brak pełnych przeładowań nie gwarantuje lepszych wyników. Zmierz LCP, INP i CLS na rzeczywistym motywie z używanymi płatnościami oraz dostawami przed wdrożeniem i po nim.

Czy Klaviyo odzyska koszyki z natywnego OPC?

Beta ponownie zawiera PrestaShop Automation with Klaviyo, a OPC zapisuje dane potrzebne do odzyskiwania koszyka. Pełną zgodność konkretnej wersji modułu potwierdź jednak testem na stagingu.

Ile trwa migracja sklepu B2B z systemem ERP?

Orientacyjnie może to być 3–6 miesięcy, lecz zakres zależy od wersji, customizacji, liczby modułów, ERP, PIM, WMS i jakości danych. Wiarygodny termin powstaje dopiero po audycie.

Czy PrestaShop 9.2 Beta można testować na produkcji?

Nie. PrestaShop wyraźnie odradza używanie bety w działającym sklepie. Testuj na świeżej instalacji lub stagingu, z backupem i planem odtworzenia środowiska.