Przetestowalismy natywny One Page Checkout w PrestaShop 9.2: co dziala, co nie, i kiedy potrzebujesz wiecej

Testowane w lipcu 2026 na PrestaShop 9.2.0 beta 1.

PrestaShop 9.2 dostarcza natywny One Page Checkout. Dla każdego, kto prowadzi sklep, zamienia to stare założenie w konkretne pytanie: skoro kasa jest już wbudowana, czy nadal potrzebujesz modułu do checkoutu?

Nie chcieliśmy odpowiadać na to na podstawie release notes. Zainstalowaliśmy więc betę 9.2 w czystym kontenerze, włączyliśmy natywny one page checkout i przeszliśmy całą ścieżkę sterowaną skryptem przeglądarką, rejestrując każdą nawigację, każdy skrypt, każde żądanie XHR i dokumentu (zasoby statyczne, takie jak obrazy i czcionki, były wyłączone z logu) razem z czasami. Ten wpis pokazuje, co naprawdę zmierzyły narzędzia.

Najważniejsze przed szczegółami: jest lepiej, niż się spodziewaliśmy. Wchodziliśmy w to z konkretnym podejrzeniem, że dodanie adresu po cichu wymusi przeładowania strony, a "one page" będzie prawdą tylko na papierze. To podejrzenie okazało się błędne i mówimy o tym najpierw, bo właśnie tego najbardziej spodziewaliśmy się znaleźć.

Nie jest bez skazy, ale szorstkie krawędzie są mniejsze, niż początkowo napisaliśmy. Dwa z naszych pierwotnych ustaleń okazały się błędami w naszym własnym skrypcie testowym i wycofujemy je poniżej, zamiast zostawiać. Zostają: zduplikowane żądanie, brakujące atrybuty formularza, problem z układem na telefonie i jedna świadoma decyzja projektowa, która odbiera coś, co potrafiła stara kasa.

Najpierw najważniejsze: nasz konflikt interesów

Sprzedajemy moduły checkoutu do PrestaShop. Natywna kasa w rdzeniu jest dla nas, komercyjnie rzecz biorąc, konkurencją. Czytaj więc wszystko, co o niej piszemy, z tą świadomością.

Oto jak sobie z tym poradziliśmy, żebyś mógł sprawdzić naszą pracę zamiast ufać naszym motywacjom. Każde twierdzenie poniżej to liczba, którą zarejestrowaliśmy, albo zrzut ekranu, który zrobiliśmy, na instalacji, którą każdy może odtworzyć z publicznego obrazu Docker. Tam, gdzie spodziewaliśmy się znaleźć błąd i go nie znaleźliśmy, mówimy o tym. Tam, gdzie nasza pierwsza ocena była błędna, poprawiliśmy ją zamiast zostawić wersję, która nam schlebiała: początkowo sądziliśmy, że w nowej kasie brakuje kodów rabatowych, a to nieprawda. Kroki instalacji, dokładne wersje i wszystko, czego nie mogliśmy przetestować, są wypisane. Jeśli któryś pomiar nie odtworzy się u Ciebie, daj nam znać, a sprawdzimy to.

Co dokładnie testowaliśmy

Każda liczba poniżej pochodzi z tego środowiska. Jeśli coś nie odtwarza się u Ciebie, może to wynikać z Twojej wersji, Twojej konfiguracji albo z naszej metody, a wolimy o tym usłyszeć niż nie.

Dwie uwagi o konfiguracji należą się dla uczciwości. Po pierwsze, domyślna instalacja nie miała przewoźnika obsługującego własny kraj sklepu, bo Wielka Brytania leży w strefie "Europa (poza UE)", a przykładowi przewoźnicy pokrywają tylko dwie inne strefy. Przypisaliśmy przewoźników do tej strefy, co jest zwykłą konfiguracją sklepu, a nie problemem kasy. Po drugie, czasy pochodzą z sieci lokalnej, traktuj je więc jako porównanie obu kas na identycznym sprzęcie, a nie jako wartości, które odtworzy Twój sklep.

Czym naprawdę jest natywny OPC w 9.2

Dostarczany jest jako moduł, ps_onepagecheckout, zawarty w pakiecie 9.2. Dwa szczegóły potwierdzone przez nas przy instalacji warto znać, zanim cokolwiek zaplanujesz:

• Domyślnie jest wyłączony. Po czystej instalacji 9.2 moduł jest obecny i włączony, ale ustawienie PS_ONE_PAGE_CHECKOUT_ENABLED ma wartość 0. Włączasz go w Wygląd > Checkout w panelu i w każdej chwili możesz wrócić do klasycznej czterostronicowej kasy.
• Albo 9.2, albo nic. Moduł deklaruje ps_versions_compliancy z minimum 9.2.0. Sklep na 1.7, 8.x, 9.0 albo 9.1 go nie zainstaluje.

Architektonicznie robi to, co opisuje oficjalne ogłoszenie na blogu build PrestaShop. Wstrzykuje własny proces zamówienia przez hook rdzenia zamiast nadpisywać kontroler zamówienia i zastępuje cztery klasy kroków jednym połączonym krokiem. Logowanie i zakładanie konta celowo wyprowadzono z kasy na osobne strony. Sam projekt opisaliśmy przed premierą w tym, co sprzedawcy i deweloperzy powinni wiedzieć o natywnym OPC w 9.2. Ten wpis zastępuje tamte domysły pomiarami.

Benchmark

Natywny one page checkout 9.2 z uzupełnionym adresem. Metoda dostawy, metoda płatności, regulamin i przycisk zapłaty są na jednym ekranie, a podsumowanie po prawej aktualizuje się na żywo.

Ten sam sklep, ten sam produkt, te same dane adresowe, ci sami przewoźnicy, za każdym razem w świeżym koszyku. Obie ścieżki były równoważne, ale nie identyczne akcja po akcji, bo obie kasy nie oferują tych samych akcji. "Pełne przeładowania strony" liczy nawigacje głównej ramki od otwarcia kasy do strony potwierdzenia zamówienia.

Ten sam sklep z wyłączonym one page checkoutem. Trzy z czterech kroków są niedostępne, dopóki poprzedni nie zostanie ukończony, a każdy zatwierdzony krok kosztuje pełne przeładowanie strony.

Oceń ten kompromis uczciwie i pamiętaj o wielkości próby. To pięć przebiegów w sieci lokalnej, traktuj je więc opisowo. Zwłaszcza różnica w pierwszym renderowaniu mieści się w rozrzucie między przebiegami (one page checkout 152 do 180 ms, klasyczny 148 do 188 ms) i nie nazwalibyśmy jej realną różnicą. Różnica w DOMContentLoaded i liczby bajtów były natomiast spójne we wszystkich przebiegach. One page checkout potrzebuje około 50 ms więcej do DOMContentLoaded i niesie mniej więcej 28 KB więcej JavaScriptu, bo renderuje kontakt, adres, dostawę, płatność i podsumowanie w jednym dokumencie zamiast krok po kroku. W zamian usuwa z drogi klienta trzy pełne przeładowania strony. Na każdym realnym łączu trzy mniej rund do serwera z zapasem wygrywają z 50 ms lokalnego renderowania.

Gdzie umarła hipoteza o adresie

To było dokładnie to, co chcieliśmy przyłapać, więc oto surowe zestawienie na akcję. Każda została zarejestrowana w logu sieciowym przeglądarki.

Dodanie adresu nie przeładowuje strony. Edycja adresu nie przeładowuje strony. Zmiana kraju nie przeładowuje strony, tylko przebudowuje formularz adresu przez AJAX, bo zmieniają się pola wymagane i zachowanie podatkowe. Zmiana przewoźnika zaktualizowała sumę zamówienia na żywo, z 19,12 EUR na 26,12 EUR, całkowicie bez nawigacji.

Logika odświeżania jest też staranniejsza, niż zakładaliśmy. Edycja ulicy, która nie może zmienić ceny dostawy, wywołała jedno żądanie zapisu wersji roboczej i nic więcej. Przewoźnicy i opcje płatności były pobierani ponownie tylko wtedy, gdy zmieniło się coś, co ich naprawdę dotyczy, na przykład kraj albo uzupełniony adres. To rozsądne zachowanie, z jednym zastrzeżeniem: nasi przykładowi przewoźnicy mieli ceny ryczałtowe, więc zmiana kodu pocztowego i tak nie mogła wpłynąć na cenę. Przewoźnik wyceniający według kodu pocztowego wymagałby osobnego testu, bo tutaj zarówno zmiana ulicy, jak i zmiana kodu pocztowego dały wyłącznie zapis wersji roboczej.

Co robi dobrze

Rzetelne uznanie tych rzeczy ma znaczenie, bo to właśnie je sprzedawcy odczują.

• To naprawdę jeden ekran. Kontakt, adres dostawy, metoda dostawy, płatność, podsumowanie zamówienia i przycisk zapłaty są przy pierwszym renderowaniu w jednym formularzu. Nie ma blokowania krokami ani niczego schowanego za przyciskiem "dalej".
• Stany oczekiwania tłumaczą się same. Zanim adres będzie kompletny, bloki dostawy i płatności nie są po prostu puste. Piszą "Uzupełnij powyżej adres dostawy, aby zobaczyć opcje dostawy", a potem wypisują dokładnie, czego brakuje: "Nadal potrzebne: Imię, Nazwisko, Adres, Miasto, Kod pocztowy". To wyjątkowo klarowny mikrotekst jak na domyślną kasę.
• Walidacja inline blokuje błędne dane bez przeładowania. Przy wybranej Francji (która definiuje format kodu pocztowego) wpisanie ABC oznaczyło pole jako nieprawidłowe, pokazało "Nieprawidłowy kod pocztowy, powinien wyglądać jak "NNNNN"", zastąpiło listę przewoźników komunikatem "Popraw zaznaczone pola adresu" i odmówiło wysyłki. Kliknięcie Zapłać wygenerowało zero żądań sieciowych i przywróciło fokus do formularza. Nic nie zginęło i nic się nie przeładowało. W osobnym teście, w którym wyczyściliśmy wymagane pole Miasto, przeglądarka ustawiła fokus dokładnie na tym polu przy próbie wysyłki.
• Przycisk zapłaty pozostaje uczciwy. Jest nieaktywny, dopóki brakuje wymaganej zgody, co zarejestrowaliśmy u powracającego klienta, który miał już ustalonego przewoźnika i płatność, ale nie zaznaczone pole regulaminu, i pokazuje aktualną sumę wprost na sobie. Nie jest pełnym wskaźnikiem gotowości: przy wyczyszczonym wymaganym polu Miasto pozostał aktywny, a wysyłkę zablokowała przeglądarka, a nie kasa ("Zapłać 19,12 EUR", potem "Zapłać 26,12 EUR" po wybraniu płatnego przewoźnika).
• Zapisane adresy obsługuje się bez opuszczania strony. Zalogowany klient ma na liście adresów opcję "Użyj innego adresu dostawy", a zarówno ona, jak i menu edycji przy każdym adresie otwierają okno modalne na tym samym ekranie. Dodawanie i edycja adresu w trakcie zamawiania nigdy nie wyprowadza ze strony.
• Kody rabatowe są obsługiwane i przeliczają na żywo. Podsumowanie zawiera akordeon "Kod rabatowy" z polem "Wklej tutaj swój kupon". Zastosowanie kodu przeliczyło rabat, przewoźników i opcje płatności przez AJAX, całkowicie bez przeładowania strony. Jedno warto wiedzieć: pole pojawia się dopiero wtedy, gdy w sklepie istnieje co najmniej jedna reguła koszyka, bo PrestaShop wyłącza całą funkcję, dopóki żadnej nie ma.
• Powracający klienci dostają naprawdę szybką ścieżkę. Po zalogowaniu z zapisanym adresem formularz kasy pojawił się po 193 ms, a lista adresów, obaj przewoźnicy i wszystkie trzy metody płatności rozstrzygnęły się chwilę później przez AJAX, bez ani jednej interakcji. Dokończenie zamówienia wymagało dwóch akcji: zaznaczyć regulamin, kliknąć zapłać. Pole e-mail znika dla zalogowanego klienta całkowicie, dokładnie tak, jak opisuje ogłoszenie.
• Układ mobilny się trzyma. Przy 375 px nie było żadnego przepełnienia w poziomie (szerokość dokumentu 375 px, viewport 375 px), a pierwsze renderowanie treści zajęło 152 ms. Wiersze przewoźników i wiersz regulaminu mają duże obszary dotykowe (351x136 px i 327x48 px).

Nieprawidłowy francuski kod pocztowy. Pole jest oznaczone inline, lista przewoźników zostaje zastąpiona prośbą o poprawkę, a kliknięcie Zapłać nie wygenerowało żadnych żądań sieciowych.

Zalogowany klient widzi swoje zapisane adresy jako wybieralne karty, z menu przy każdym adresie i możliwością dodania nowego.

Dodanie adresu otwiera okno modalne nad kasą. Strona pod spodem nigdy się nie przeładowuje i nic z już wpisanych danych nie ginie.

Strona potwierdzenia zamówienia również została przebudowana i wygląda wyraźnie czyściej niż ta, którą zastępuje.

Szorstkie krawędzie, które faktycznie zmierzyliśmy

To rzeczy, które potrafimy udowodnić, a nie wrażenia.

1. Endpoint metod płatności jest pobierany dwa razy

Za każdym razem, gdy adres zostaje rozstrzygnięty, kasa pyta o opcje płatności dwukrotnie identycznym co do bajtu adresem URL:

GET /module/ps_onepagecheckout/paymentmethods?ajax=1&action=opcPaymentMethods&id_country=17
GET /module/ps_onepagecheckout/paymentmethods?ajax=1&action=opcPaymentMethods&id_country=17

Zarejestrowaliśmy to sześć razy w czterech niezależnych sesjach przeglądarki: przy pierwszym wpisaniu adresu i przy zmianie kraju w przebiegu gościa, w przebiegu mobilnym, w przebiegu z nieprawidłowym kodem pocztowym oraz przy pierwszym i przy powtórnym zamówieniu zalogowanego klienta. Przypadek powtórnego zamówienia jest najbardziej wymowny, bo występuje przy zwykłym wczytaniu strony, bez żadnej sterowanej skryptem interakcji. To zduplikowane żądanie, a nie dwa różne stany. W sklepie, w którym moduły płatności wykonują przy każdym renderowaniu realną pracę (obliczanie opłat, reguły dostępności, zdalne wywołania), to zmarnowany czas serwera na najbardziej krytycznej dla konwersji stronie. Dokładnie takie rzeczy ma jeszcze do uporządkowania moduł w wersji 0.6.2.

2. Brak podpowiedzi autouzupełniania w polach adresu

Sprawdziliśmy każde pole w bloku adresu dostawy. Żadne nie ma atrybutu autocomplete ani inputmode:

Autouzupełnianie adresu w przeglądarce i telefonie opiera się właśnie na tych tokenach (given-name, address-line1, postal-code i tak dalej). Bez nich to, co najbardziej ogranicza pisanie na telefonie, działa zawodnie, co podkopuje kasę, której deklarowanym celem jest ograniczenie mobilnego tarcia. Wiemy, że to przeoczenie, a nie decyzja, bo strona rejestracji w 9.2 w tym samym szablonie ustawia tokeny poprawnie: email, given-name, family-name, new-password i tel-national. Formularz adresu w kasie, który potrzebuje ich najbardziej, nie ma żadnego. Telefon przynajmniej używa type="tel", więc ta klawiatura jest właściwa.

3. Nie da się założyć konta przy zamawianiu, i to jest regres

Logowanie i rejestracja zostały celowo wyprowadzone z kasy, co ogłoszenie mówi wprost. Warto rozpisać, co to znaczy w praktyce, bo jest to krok wstecz wobec kasy, którą zastępuje.

Porównaliśmy obie kasy w tym samym sklepie. Klasyczna czterokrokowa kasa renderuje prawdziwe <input type="password" name="password"> wewnątrz kasy, kupujący może więc założyć konto przy zamawianiu, a jej "Zaloguj się" to zakładka na tej samej stronie. One page checkout nie ma nigdzie pola hasła, a oba elementy to zwykłe linki wyprowadzające ze strony:

Klient, który chce kupić i zachować konto, musi więc opuścić kasę, zarejestrować się na osobnej stronie i wrócić. Dla kasy pomyślanej przede wszystkim dla gości to spójna decyzja, a kupujący jako goście nigdy tego nie zauważą. Dla sklepu, który liczy na zakładanie kont w momencie zakupu, odbiera to coś, co stara kasa potrafiła. Oznacza też, że moment, w którym klient jest najbardziej zmotywowany do rejestracji, tuż po decyzji o zakupie, jest jedynym momentem, w którym kasa mu na to nie pozwala.

4. Na telefonie przycisk zapłaty jest daleko w dole

One page checkout przy 375 px. Układ trzyma się bez przepełnienia w poziomie, ale cała kasa to jedna bardzo wysoka kolumna.

Umieszczenie wszystkiego na jednym ekranie sprawia, że ten ekran jest wysoki. Na viewporcie 375 px przycisk zapłaty znajduje się 3337 px w dół strony i nie jest przyklejony: jego wyliczona pozycja to static, bez przodka fixed ani sticky. Nawet powracający klient z zapisanym adresem musi przewinąć cały formularz, żeby do niego dotrzeć. Przyklejone podsumowanie albo pasek płatności to standardowa odpowiedź i jeszcze jej nie ma.

5. To moduł sprzed 1.0, i jego własny README to mówi

To nie wada, ale najważniejszy fakt planistyczny na tej stronie. Testowany pakiet bety zawiera moduł w wersji 0.6.2, podczas gdy w repozytorium kilka dni przed naszym testem otagowano już 0.6.5, traktuj więc konkretne numery wersji jako ruchomy cel. A własne ogłoszenie bety PrestaShop jest jednoznaczne: "ta wersja beta to oprogramowanie przedpremierowe. Możliwe, że napotkasz problemy. Nie używaj jej w sklepie produkcyjnym!" Nie da się też zaktualizować bety do release candidate ani do wersji stabilnej normalną ścieżką aktualizacji.

Repozytorium modułu jest jeszcze bardziej dosadne. README PrestaShop/ps_onepagecheckout stwierdza: "Ten moduł jest w intensywnym rozwoju. Nie jest gotowy do produkcji i nie powinien być używany w środowiskach produkcyjnych." W chwili pisania jest tam garść otwartych zgłoszeń, a dwa z nich pokrywają się dokładnie z tym, na co natrafiliśmy niezależnie: #94 zgłasza zduplikowane identyfikatory pól między ukrytym oknem modalnym adresu a formularzem inline, dlatego ten sam identyfikator #field-postcode pojawia się w audytowanej przez nas stronie więcej niż raz, a #102 opisuje stos checkboxów zgód, który umieszcza najcięższy blok na pierwszym ekranie, czyli dokładnie to tarcie, które opisujemy niżej. #132 dotyczy formularza adresu ignorującego kolejność pól właściwą dla kraju, a #105 to otwarta prośba o udostępnienie kontraktu dla express checkoutu. To ostatnie ma znaczenie, jeśli sprzedajesz przez portfele lub płatności ekspresowe, bo powierzchnia, do której miałyby się podpiąć, jest wciąż projektowana.

6. Trzy obowiązkowe zgody stoją między klientem a opcjami

W domyślnej instalacji 9.2 kupujący po raz pierwszy jako gość napotyka trzy obowiązkowe zaznaczenia: prywatność danych klienta, własne pole modułu RODO oraz regulamin. Dla gościa dwa pierwsze blokują opcje dostawy i płatności, które pozostają za komunikatem "zaakceptuj wymagane warunki", dopóki nie zostaną zaznaczone. Dla powracającego klienta jest łagodniej: zmierzyliśmy, że opcje rozstrzygały się normalnie, gdy niezaznaczone pozostawało tylko pole regulaminu, które blokuje przycisk zapłaty, a nie opcje. Ten stos to konfiguracja Twojego sklepu, a nie wina kasy, i da się go usunąć, ale właśnie to świeża instalacja 9.2 pokazuje pierwszemu kupującemu. PrestaShop ma dokładnie na ten temat otwarte zgłoszenie #102.

Sprostowanie: dwa wycofane ustalenia

Wcześniejsza wersja tego artykułu zawierała dwa dodatkowe ustalenia. Oba były błędne i oba wynikały z naszej winy, a nie z kasy. Zostawiamy to tutaj zamiast po cichu usuwać.

Napisaliśmy, że zastosowanie kodu rabatowego resetuje metodę dostawy klienta, a osobno, że kasa potrafi pokazywać jedną metodę dostawy i sumę, podczas gdy zapisany koszyk zawiera inną. Oba wynikały z tego samego błędu: nasz skrypt wybierał przewoźnika programowo zamiast go klikać, więc wybór nigdy nie docierał do serwera, a każde kolejne renderowanie pokazywało po prostu wersję serwera.

Rozstrzygnął to test polegający na dokończeniu prawdziwego zamówienia i odczytaniu wiersza z bazy zamiast ufania ekranowi:

Klikane tak jak robi to człowiek, zamówienie za każdym razem odpowiada temu, co na ekranie, z kuponem i bez. Kody rabatowe działają poprawnie: pole pojawia się, gdy sklep faktycznie ma regułę koszyka, a zastosowanie kodu przelicza rabat, przewoźników i opcje płatności przez AJAX bez przeładowania. Nie powinniśmy byli publikować żadnego z tych twierdzeń i odnotowujemy sprostowanie, bo benchmark, któremu nie można ufać, że sam się poprawi, nie jest wart czytania.

Czego nie mogliśmy przetestować

Powiedzenie tego wprost jest różnicą między benchmarkiem a opinią.

• Prawdziwe bramki płatności. Testowaliśmy wyłącznie metodami offline. Bramka kartowa, przepływ portfela czy krok 3D Secure dołożą każdy własne przekazanie, które może być przekierowaniem, wyskakującym oknem albo osadzoną ramką. Ostatnią zmierzoną przez nas nawigacją było przekazanie przez moduł czeku do jego strony walidacji.
• Szablon classic. Testowaliśmy na hummingbird, szablonie instalowanym przez 9.2. Oficjalne ogłoszenie ostrzega, że szablony classic nie są domyślnie wspierane i że "być może trzeba będzie nadpisać część szablonów modułu One Page Checkout, żeby zadziałał". Nie ukończyliśmy czystej, prawidłowo zmigrowanej instalacji na szablonie classic, więc w tym punkcie cytujemy PrestaShop, a nie własny wynik.
• Obciążenie i współbieżność. Pomiary jedną przeglądarką w sieci lokalnej. Nic tutaj nie mówi, jak dodatkowe endpointy AJAX zachowują się przy realnym ruchu.
• Zewnętrzne moduły checkoutu. Nie testowaliśmy, jak istniejące moduły przewoźników, opłat czy upsellów renderują się w przepływie one page. To najważniejsza rzecz do sprawdzenia na własnej kopii testowej.

Odtwórz to samodzielnie

Nic z tego nie jest wiele warte, jeśli nie możesz tego sprawdzić. Całe stanowisko testowe to publiczny obraz i jakieś dziesięć minut konfiguracji. Oto skrócona wersja pliku compose, którego użyliśmy (dodaj zwyczajowe MYSQL_* i pasujące do nich DB_* oraz skieruj domenę tam, gdzie to uruchamiasz):

services:
  prestashop:
    image: prestashop/prestashop:9.2.0-6.0-beta.1-classic-apache
    ports: ["8088:80"]
    environment:
      DB_SERVER: ps92-db
      PS_INSTALL_AUTO: 1
      PS_DEV_MODE: 0          # zostaw WYLACZONE, inaczej wszystkie czasy sa zawyzone
      PS_DOMAIN: localhost:8088
  ps92-db:
    image: mysql:8.0

Do tego cztery rzeczy, które inaczej zabiorą Ci popołudnie, bo nam zabrały nasze:

• Włącz kasę. Jest dostarczana zainstalowana, ale wyłączona. Wygląd > Checkout albo ustaw PS_ONE_PAGE_CHECKOUT_ENABLED na 1.
• Przypisz przewoźnikom właściwą strefę. Domyślna instalacja umieszcza Wielką Brytanię w "Europa (poza UE)", podczas gdy przykładowi przewoźnicy obsługują tylko dwie inne strefy, więc brytyjski adres całkiem słusznie nie pokazuje żadnych przewoźników. To dane przykładowe, a nie błąd kasy, i o mało nie zgłosiliśmy tego jako błędu.
• Testuj walidację kodu pocztowego na Francji, nie na Wielkiej Brytanii. PrestaShop dostarcza dla GB puste zip_code_format, więc przechodzi każda bzdura, a kasa wygląda na zepsutą, choć nie jest. Francja definiuje NNNNN i waliduje poprawnie.
• Do odtworzenia przypadku z kuponem potrzeba więcej niż domyślnego sklepu. Główny benchmark działał na dwóch przykładowych przewoźnikach, ale test kuponu wymaga przewoźnika, którego strata jest widoczna: dodaliśmy Standard Delivery za 4,90, Economy za 6,90 (za darmo powyżej 100) i Express 24h za 12,90, każdy dla wszystkich stref, a potem utworzyliśmy regułę koszyka 10% z kodem TEST10 i wyłączoną darmową dostawą. Wybierz najdroższego przewoźnika, zastosuj kod, dokończ zamówienie i porównaj metodę dostawy na gotowym zamówieniu z tą, którą wybrałeś. Jedna pułapka: pole kodu rabatowego jest niewidoczne, dopóki nie istnieje choć jedna reguła koszyka, bo PrestaShop ustawia PS_CART_RULE_FEATURE_ACTIVE na 0 w sklepie, który żadnej nie ma.

Do policzenia przeładowań otwórz panel Sieć, przefiltruj na Doc i policz nawigacje głównej ramki między otwarciem kasy a stroną potwierdzenia. Dla zduplikowanego żądania przefiltruj na paymentmethods.

Czy natywny OPC z 9.2 Ci wystarczy?

Na podstawie tego, co zmierzyliśmy, oto uczciwy podział.

Natywny OPC naprawdę wystarczy, jeśli

• I tak przechodzisz na 9.2 i używasz szablonu hummingbird albo szablonu potomnego.
• Twoja kasa jest standardowa: kilku przewoźników, typowe metody płatności, brak własnych pól.
• Sprzedajesz konsumentom, a zamówienia jako gość są normą.
• Chcesz zwinąć czterokrokowy przepływ i mieć sumę aktualizowaną na żywo, co dostarcza dokładnie, z zerową liczbą przeładowań.
• Godzisz się poczekać na stabilne wydanie 9.2, zanim to włączysz.

Dla takiego sklepu odpowiedź jest prosta: platforma już to pokrywa i nie powinieneś kupować modułu, żeby robić to, co robi rdzeń. Jeśli Twoja kasa obecnie gubi zamówienia i chcesz wiedzieć, czy to w ogóle ona jest problemem, zacznij od tego, dlaczego strona zamówienia traci sprzedaż i powodów, dla których klienci odchodzą przed zapłatą.

Nadal uderzysz w ścianę, jeśli

• Nie jesteś na 9.2. To ten twardy punkt. Moduł odmawia instalacji poniżej 9.2.0, a aktualizacje dotykające kasy to dokładnie te, które sprzedawcy odkładają. Sklep na 1.7, 8.x, 9.0 albo 9.1 nie dostaje z tego wydania nic.
• Chcesz, żeby sam krok płatności był jednym dotknięciem. One page checkout usuwa tarcie przed płatnością. Nie zamienia bramki w przycisk portfela. To inna funkcja, opisana w ekspresowej kasie i w zakupach jednym kliknięciem w PrestaShop.
• Mobile to większość Twojego przychodu i potrzebujesz przyklejonego paska płatności albo formularza adresu współpracującego z autouzupełnianiem telefonu. Oba to zmierzone wyżej braki.
• Chcesz, żeby klienci rejestrowali się w momencie zakupu. W kasie nie ma pola hasła, więc założenie konta oznacza jej opuszczenie.
• Potrzebujesz reguł typu "ta metoda płatności tylko między wartością zamówienia X a Y". Taka warunkowa logika płatności i dostawy nie jest częścią natywnego modułu.
• Potrzebujesz własnych pól w kasie, reguł B2B, upsellów na poziomie zamówienia albo wyboru daty dostawy. Nic z tego nie mieści się w zakresie natywnego modułu.

Gdzie moduł nadal ma sens

Sprzedajemy moduły checkoutu, potraktuj więc ten akapit z należnym sceptycyzmem i skonfrontuj go z tabelą powyżej. Braki, które faktycznie zmierzyliśmy, są węższe niż rok temu, a w standardowym sklepie na 9.2 natywna kasa wykonuje teraz podstawową robotę dobrze.

Jedyny brak, który nie jest kwestią gustu, to zasięg wersji. Natywny OPC zaczyna się od 9.2, co potwierdza deklaracja zgodności samego modułu. Nasz Checkout Revolution istnieje po to, żeby dostarczyć jednostronicową kasę na te wersje PrestaShop, na których faktycznie działa dziś większość żywych sklepów, bez ingerencji w rdzeń. Dokładny zakres wspieranych wersji sprawdź na stronie produktu i weź pod uwagę, że nie certyfikowaliśmy go jeszcze pod samą 9.2. Jego historia jest w Checkout Revolution 3.0. Jeśli natomiast chcesz skrócić sam moment płatności, a nie formularz nad nim, to Express Checkout, i pozostaje on istotny niezależnie od tego, która kasa renderuje stronę. Jeśli porównujesz ścieżki, przewodnik po optymalizacji checkoutu i przegląd procesu i alternatyw układają je obok siebie.

Jeśli jesteś na 9.2 ze standardowym katalogiem i standardową kasą, powiedzielibyśmy: użyj natywnej. To właśnie wspierają pomiary.

FAQ

Czy one page checkout w PrestaShop 9.2 jest wystarczająco stabilny na produkcję?

Jeszcze nie, a PrestaShop mówi to dwukrotnie. Ogłoszenie bety 9.2 stwierdza, że to oprogramowanie przedpremierowe i odradza sprzedawcom używanie go w sklepie produkcyjnym, a README modułu mówi: "Ten moduł jest w intensywnym rozwoju. Nie jest gotowy do produkcji i nie powinien być używany w środowiskach produkcyjnych." Sam moduł kasy jest w wersji 0.6.2. Każde złożone przez nas zamówienie odpowiadało temu, co pokazywała kasa, ale moduł sprzed 1.0 na platformie w becie i tak należy trzymać na środowisku testowym, dopóki 9.2 nie będzie stabilne. Nie da się też przejść z bety na release candidate ani na stabilną standardową ścieżką aktualizacji, testuj więc na kopii do wyrzucenia.

Czy zadziała z moim szablonem?

Jest zbudowany pod hummingbird, szablon instalowany przez pakiet 9.2 i ten, na którym testowaliśmy, gdzie zadziałał bez żadnych modyfikacji. Własne ogłoszenie PrestaShop ostrzega, że szablony classic nie są domyślnie wspierane i że być może trzeba będzie nadpisać część szablonów modułu, żeby zadziałał. Przypadku szablonu classic nie zweryfikowaliśmy samodzielnie, potraktuj więc swój szablon jako pierwszą rzecz do przetestowania na środowisku testowym, zwłaszcza jeśli nadpisuje jakiekolwiek szablony kasy.

Czy nadal potrzebuję modułu do checkoutu?

Jeśli jesteś na 9.2, używasz hummingbird albo szablonu potomnego i masz konwencjonalną kasę, to szczerze mówiąc nie. Natywny moduł zwija cztery kroki do jednego ekranu, aktualizuje sumy na żywo, waliduje inline i domyka zamówienie powracającego klienta w dwóch akcjach. Dedykowanego modułu nadal będziesz chcieć do rzeczy, których według naszych testów nie robi: działania na PrestaShop 1.6 do 9.1, płatności portfelem jednym dotknięciem, własnych lub B2B pól w kasie, upsellów na poziomie zamówienia i mobilnych detali w rodzaju przyklejonego paska płatności.

Jak go włączyć?

Wejdź w Wygląd > Checkout w panelu i wybierz układ one page checkout. Moduł jest dostarczany z 9.2 zainstalowany, ale ustawienie jest domyślnie wyłączone, więc świeża instalacja daje Ci klasyczną czterokrokową kasę, dopóki go nie włączysz. W każdej chwili możesz wrócić, a w konfiguracji wielosklepowej wybór jest dokonywany per sklep, a nie globalnie.

Czy klienci mogą używać kodów rabatowych w one page checkout?

Tak. Podsumowanie zamówienia zawiera akordeon "Kod rabatowy" z polem na kupon, a zastosowanie kodu przelicza rabat, przewoźników i opcje płatności przez AJAX bez przeładowania strony. Początkowo zgłosiliśmy, że zastosowanie kodu resetuje przewoźnika wybranego przez klienta. To był nasz skrypt testowy, który wybierał przewoźnika programowo zamiast go klikać, i wycofaliśmy to twierdzenie: przy prawdziwych kliknięciach gotowe zamówienie za każdym razem odpowiadało wybranej metodzie dostawy, z kuponem i bez. Jedyna prawdziwa osobliwość to to, że pole kuponu pozostaje ukryte, dopóki sklep nie ma choć jednej reguły koszyka, bo PrestaShop wyłącza wtedy tę funkcję całkowicie.

Czy one page checkout oznacza brak jakichkolwiek przekierowań?

Nie i to najczęstsze nieporozumienie. Na całej ścieżce zmierzyliśmy dwa pełne przeładowania strony: otwarcie kasy i przekazanie przez moduł płatności po wysłaniu. Wszystko pomiędzy, łącznie z wpisaniem adresu, jego edycją, zmianą kraju, zmianą przewoźnika i wyborem metody płatności, odbyło się bez ani jednego przeładowania. Ale prawdziwa metoda płatności nadal może przekazać sterowanie hostowanej stronie, wyzwaniu 3D Secure, wyskakującemu oknu albo osadzonej ramce. Zmierzyliśmy tylko przekazanie przez offline'owy moduł czeku, a taki krok to normalne zachowanie w e-commerce, a nie wada kasy.

Czy moje obecne moduły płatności i przewoźników będą dalej działać?

Z założenia powinny, bo natywna kasa korzysta ze standardowego mechanizmu wykrywania opcji płatności PrestaShop, zamiast go omijać, a nasze trzy offline'owe metody płatności pojawiły się i zadziałały bez modyfikacji. Zastrzeżenie jest takie, że wszystko renderuje się teraz naraz na jednym ekranie, więc moduły przewoźników reagujące na zmiany adresu na żywo i moduły płatności renderowane w kontekście jednej strony to dokładnie te miejsca, gdzie założenia z przepływu krokowego mogą pęknąć. Zwróć też uwagę, że endpoint opcji płatności jest obecnie odpytywany dwa razy na każdą zmianę adresu, co ma znaczenie, jeśli Twoje moduły płatności wykonują kosztowną pracę przy każdym renderowaniu.

Źródła i metoda testu

Źródła pierwotne, wszystkie publiczne:

• Introducing One Page Checkout in PrestaShop 9.2, oficjalne ogłoszenie na blogu build PrestaShop.
• PrestaShop 9.2 Beta is open for feedback, z cytowanym wyżej ostrzeżeniem o wersji przedpremierowej.
• PrestaShop/ps_onepagecheckout na GitHubie, kod źródłowy modułu, jego README i lista otwartych zgłoszeń.

Metoda. Czysta instalacja PrestaShop 9.2.0 beta 1 z oficjalnego obrazu Docker, szablon hummingbird, tryb debug wyłączony i rozgrzany cache produkcyjny. Ścieżka gościa, ścieżka powracającego klienta i porównanie z klasyczną czterokrokową kasą były prowadzone przez sterowaną skryptem przeglądarkę, która logowała nawigacje oraz żądania XHR, fetch i dokumentów, z pominięciem zasobów statycznych, przy czym nawigacje głównej ramki liczono osobno od wywołań AJAX. Czasy ładowania to mediana z pięciu przebiegów, przed każdym czyszczono cache HTTP. Dwa ustalenia z wcześniejszej wersji tego artykułu zostały wycofane po tym, jak ustaliliśmy, że wynikały z naszego skryptu wybierającego przewoźnika programowo zamiast go klikać; każde zamówienie złożone prawdziwymi kliknięciami odpowiadało temu, co pokazywała kasa, co zweryfikowaliśmy na wierszu zamówienia w bazie danych. Automatyczne zrzuty korzystały z viewportów CSS 1440 px i 375 px; opublikowane obrazy zostały przycięte lub przeskalowane na potrzeby prezentacji, ale ich treść nie jest retuszowana.

Datowane i tymczasowe. Te pomiary opisują PrestaShop 9.2.0 beta 1 z ps_onepagecheckout 0.6.2, testowane 27 lipca 2026. To oprogramowanie przedpremierowe w aktywnym rozwoju, opisane usterki mogą więc zostać naprawione, zanim 9.2 stanie się stabilne, a mogą pojawić się nowe. Zamierzamy powtórzyć dokładnie ten benchmark przy release candidate i ponownie przy wersji stabilnej oraz zaktualizować ten artykuł nowymi liczbami, zamiast po cichu zostawiać stare. Jeśli odtworzysz coś innego, daj nam znać, a poprawimy.