Komunikat o nowej, blokowej kasie w panelu WooCommerce to nie polecenie do natychmiastowego kliknięcia, tylko decyzja, którą da się podjąć na spokojnie i z wiedzą, co się po drodze zepsuje. Sam block checkout WooCommerce, czyli strona zamówienia zbudowana z bloków zamiast starego shortcode’u, jest dziś kierunkiem, w którym idzie cała platforma. Ale to, że jest kierunkiem, nie znaczy, że Twój sklep musi tam być jutro rano.
Ten tekst jest dla właściciela sklepu, który ma przed sobą jedno pytanie: włączyć czy zostać przy klasycznym checkoucie. Nie piszę tu, jak dodać pole kodem, jak skrócić formularz ani jak naprawić kasę, która już padła - to są osobne tematy i do każdego odsyłam niżej. Tu chodzi o samą decyzję i o to, jak ją podjąć bez ryzyka dla sprzedaży.
Czym różni się blokowy checkout od klasycznego
Klasyczny checkout to strona, na której stoi shortcode [woocommerce_checkout]. Formularz składa PHP po stronie serwera, a wtyczki i motywy od lat modyfikują go swoimi akcjami i filtrami. Większość działających sklepów, które widzę, nadal stoi na tej wersji - bo tak zostało od wdrożenia.
Blokowy checkout to ta sama strona złożona z bloków w edytorze WordPressa. Formularz renderuje się w przeglądarce i rozmawia z serwerem przez osobne API sklepu. Dla klienta różnica bywa niewielka - widzi kasę, wpisuje dane, płaci. Dla Ciebie różnica jest duża, bo zmienia się sposób, w jaki wtyczki wpinają się w formularz.
Trzy fakty z dokumentacji WooCommerce, które ustawiają tę decyzję:
- Nowe sklepy dostają bloki domyślnie. Sklepy założone po WooCommerce 8.3 startują od razu na blokowym koszyku i blokowej kasie. Jeśli Twój sklep jest starszy, najpewniej nadal masz klasyczną.
- Nie wszystko z klasycznej kasy działa w blokach. Dokumentacja dla programistów mówi wprost, że część akcji i filtrów znanych z shortcode’u działa w blokach, ale nie wszystkie. Czyli każda modyfikacja kasy w Twoim sklepie to pozycja do sprawdzenia.
- Rozszerzenia mają deklarować zgodność. Wtyczka, która zmienia koszyk albo kasę, powinna zadeklarować, czy jest zgodna z blokami. Kiedy aktywne rozszerzenie zgłasza brak zgodności, WooCommerce pokazuje ostrzeżenie w ustawieniach bloku kasy razem z przyciskiem powrotu do klasycznej.
Sprawdzenie, którą wersję masz, zajmuje chwilę: otwórz stronę „Zamówienie” w edytorze. Jeden blok z shortcode’em to klasyczna, zestaw bloków z podglądem formularza to blokowa.
Koszt przejścia: dostosowanie pól, wtyczek płatności i dostaw
Kwoty nie podam, bo przy tym temacie zależy ona wyłącznie od tego, co Twój sklep ma dziś doklejone do kasy. Mogę za to pokazać, z czego się składa, żebyś sam ocenił, czy u Ciebie to drobiazg, czy projekt.
Najwięcej pracy generują trzy rzeczy:
- Własne pola. Pole dodane kiedyś snippetem albo wtyczką do edycji pól w klasycznej kasie nie przenosi się samo. W blokach pola rejestruje się osobną funkcją
woocommerce_register_additional_checkout_field(), w jednej z trzech lokalizacji: dane kontaktowe, adres albo zamówienie. Każde stare pole trzeba więc przepisać albo znaleźć wtyczkę, która obsługuje bloki. Jak to wygląda od strony kodu, rozłożyłem w tekście o własnych polach w checkoucie WooCommerce. - Bramki płatności. Dokumentacja WooCommerce podaje, że niezgodna bramka może po prostu nie pojawić się wśród metod płatności. To najgroźniejszy scenariusz, bo sklep nie zgłasza błędu - klient widzi kasę bez swojej ulubionej metody.
- Wtyczki dostaw i faktur. Wybór paczkomatu, pole NIP, zgody, dopłaty za pobranie - wszystko, co wtyczka wstawia do formularza, trzeba sprawdzić osobno.
Do tego dochodzą rzeczy mniej widoczne: własny CSS motywu pisany pod klasyczny formularz, skrypty analityki podpięte pod stare zdarzenia kasy, tłumaczenia komunikatów.
Skalę czasu da się opisać tylko słowami. Kiedy przy awarii kasy przyczyną jest konfliktowa wtyczka albo cache, mówimy o godzinach, nie o dniach - a dłużej trwa wtedy, gdy integrację trzeba przepisać pod kasę blokową. Pisałem o tym w tekście checkout WooCommerce nie działa. Przy samym przejściu działa ta sama logika: sklep z gołą kasą i zgodnymi wtyczkami to mała robota, sklep z kilkoma własnymi polami i niszową bramką to projekt, który wyceniam dopiero po przejrzeniu listy rozszerzeń. Wszystko zależy od zakresu.
Jak zdecydować: lista wtyczek do sprawdzenia i test na kopii
Decyzję podejmuję zawsze w tej samej kolejności i polecam ją każdemu, kto robi to sam.
Najpierw lista. Spisz wszystkie wtyczki, które dotykają koszyka albo kasy:
- Bramki płatności - każda osobno, łącznie z tymi, których używa mały procent klientów.
- Integracje wysyłki - paczkomaty, kurierzy, wybór punktu odbioru.
- Edytory pól, wtyczki do faktur i NIP-u, zgody marketingowe.
- Rabaty, kupony, programy lojalnościowe, dopłaty i opłaty dodatkowe.
- Własne snippety w motywie potomnym albo w małej wtyczce - one nie mają żadnej deklaracji zgodności, bo nikt ich nie deklarował.
Przy każdej pozycji sprawdź dwie rzeczy: czy jest aktualna i czy autor deklaruje zgodność z blokami koszyka i kasy. Rozszerzenia z WooCommerce.com pokazują to na stronie produktu, w sekcji o zgodności. Przy reszcie zostaje dokumentacja autora albo test.
Potem test na kopii. Ostrzeżenie w edytorze o niezgodnym rozszerzeniu to dobry sygnał, ale nie jedyny - snippet w motywie ostrzeżenia nie wywoła. Dlatego przełączenie robisz na kopii sklepu, nie na produkcji, i składasz tam prawdziwe zamówienia testowe każdą metodą płatności i każdą metodą dostawy.
Z tego wychodzą trzy możliwe decyzje:
- Włączasz - wszystkie wtyczki są zgodne, zamówienia testowe przechodzą, pola się zapisują.
- Zostajesz na razie - jedna albo dwie wtyczki nie są gotowe, ale autorzy je rozwijają. Wracasz do tematu przy kolejnej rundzie aktualizacji.
- Zostajesz świadomie - sklep ma rozbudowaną kasę na kodzie i przepisanie jej teraz nic Ci nie daje. Klasyczny checkout nadal działa, a dokumentacja WooCommerce sama opisuje powrót do niego, więc to też jest uczciwa odpowiedź.
Jedno zastrzeżenie: przejście na bloki samo w sobie nie jest sposobem na więcej zamówień. Jeśli kasa ma za dużo pól i wymusza konto, bloki tego nie naprawią - o tym, co realnie skraca ścieżkę, piszę w tekście o krótszym checkoucie.
Gdy przejście już zrobisz i coś pójdzie nie tak, powrót istnieje. Dokumentacja WooCommerce opisuje go tak: w edytorze zaznaczasz blok kasy, wybierasz zamianę na klasyczny shortcode i zapisujesz. Zalecenie jest jedno - cofasz oba bloki naraz, koszyk i kasę, bo działają w parze.
Co robię inaczej - przejście na stagingu z testem zamówień
Przy sklepach klientów nie przełączam kasy na żywym sklepie. Tak samo jak przy aktualizacjach, które opisałem w checkliście bezpiecznych aktualizacji WooCommerce, robię to w czterech krokach:
- Kopia zapasowa przed czymkolwiek. Pliki i baza, z możliwością odtworzenia, a nie tylko „backup gdzieś jest”.
- Staging. Kopia sklepu pod osobnym adresem, niewidoczna dla klientów i dla Google. Tam przełączam kasę i tam szukam problemów.
- Pełna ścieżka zakupu. Składam zamówienia testowe każdą bramką i każdą metodą dostawy, sprawdzam, czy dane z własnych pól trafiają do panelu zamówienia i do maili, czy działa na telefonie i czy nic nie gubi się po zmianie metody wysyłki.
- Plan wycofania. Zanim zmiana trafi na produkcję, wiem, jak ją cofnąć - u kasy to powrót do shortcode’u dla koszyka i kasy, sprawdzony wcześniej na stagingu.
Własne pola, które trzeba przepisać pod bloki, piszę w motywie potomnym albo w osobnej małej wtyczce, nigdy w plikach motywu nadrzędnego. Kod trafia na repozytorium klienta, więc po moim wyjściu wiadomo, co jest w kasie i dlaczego.
Jeśli wolisz, żeby ktoś przeszedł tę listę za Ciebie, tym właśnie zajmuję się w ramach rozwoju i optymalizacji stron i sklepów - od przeglądu wtyczek po przełączenie na stagingu i wdrożenie.
Block checkout WooCommerce - najczęstsze pytania
Jak dodać własne pole w blokowym checkoucie?
Przez funkcję woocommerce_register_additional_checkout_field(), rejestrowaną przy inicjalizacji WooCommerce, albo wtyczką do pól, która deklaruje obsługę bloków. Stary snippet z filtrem dla klasycznej kasy trzeba sprawdzić - nie zakładaj, że zadziała.
Jak wrócić do klasycznego checkoutu? W edytorze strony zamówienia zaznacz blok kasy, zamień go na klasyczny shortcode i zapisz. To samo zrób na stronie koszyka. Jeśli aktywne rozszerzenie zgłasza brak zgodności, WooCommerce pokazuje przy bloku kasy gotowy przycisk do tego przełączenia.
Które wtyczki nie działają z checkout blocks? Nie ma jednej stałej listy, bo autorzy dodają zgodność z kolejnymi wersjami. Sprawdzasz własne: deklarację zgodności autora, ostrzeżenie w edytorze bloku kasy i zamówienie testowe na kopii sklepu. Snippety bez autora testujesz zawsze.
Masz to u siebie i nie wiesz, od czego zacząć? Przyspieszam i naprawiam istniejące strony i sklepy - Core Web Vitals, awarie, rozbudowa o funkcje, których brakuje. Zobacz, jak to wygląda u mnie: rozwój i optymalizacja stron i sklepów.