WooCommerce i blokowy koszyk
---
Wątek wraca regularnie, więc zbieram konkrety w jedno miejsce, bo sytuacja w 2026 wygląda inaczej niż w poradnikach sprzed dwóch lat.
Stan faktyczny. Blokowy koszyk i checkout są domyślne dla nowych instalacji od WooCommerce 8.3. Stary `[woocommerce_checkout]` nie został usunięty i Woo deklaruje, że nie ma planów jego wycofania — ale oficjalnie jest w trybie utrzymaniowym: dostaje poprawki bezpieczeństwa i błędów, nie dostaje nowych funkcji. Cały rozwój idzie w bloki. To nie jest „za chwilę wywalą shortcode", to jest „shortcode zamarł".
Argument za migracją, który warto znać. W lutym Woo pokazało własne dane telemetryczne: sklepy na blokowym checkoucie notują ok. 27% wyższą konwersję w kroku zakupowym niż na klasycznym. Traktowałbym to ostrożnie - sklepy, które migrowały, są zwykle lepiej utrzymane niż te, które zostały na starym, więc część różnicy to selekcja próbki. Ale kierunek jest jednoznaczny.
**Argument przeciw, który zatrzymuje większość migracji.** Zgodność wtyczek. To jest realny, ciągle nierozwiązany problem:
- listy kompatybilności rozszerzeń nadal, w 2026, mieszają statusy „gotowe", „w toku" i „niekompatybilne",
- portfele ekspresowe (Apple Pay / Google Pay) potrafią zniknąć z checkoutu, jeśli bramka nie ma wsparcia dla bloków - przy czym te same metody działają na shortcode,
- część rozszerzeń do dodatków w koszyku i odbiorów osobistych po prostu nie działa z blokami,
- niezgodna wtyczka nie zawsze krzyczy błędem. Czasem po prostu nie renderuje pola. Zauważysz to po spadku zamówień, nie w logach.
Realny check przed migracją. Zanim cokolwiek ruszysz na produkcji, wypisz i sprawdź jedno po drugim:
1. bramka płatnicza (u nas najczęściej Przelewy24, PayU, Autopay, Stripe) - czy oficjalnie wspiera Cart i Checkout Blocks, i czy wspiera też portfele ekspresowe,
2. integracja przewoźnika i paczkomatów (InPost, Furgonetka, Apaczka) - wybór punktu w checkoucie to najczęstsze miejsce, gdzie się wykłada,
3. wtyczka do faktur i JPK,
4. dodatkowe pola w checkoucie i wszelkie „checkout add-ons",
5. wtyczka do NIP / faktury firmowej,
6. cokolwiek, co Twój deweloper podpiął hookiem do szablonów `woocommerce/templates/checkout/`.
Punkt 6 jest krytyczny i najczęściej pomijany. Blokowy checkout to aplikacja Reactowa, nie szablon PHP renderowany po stronie serwera. Nadpisania szablonów w motywie i większość snippetów z hooków przestają obowiązywać. Customizacja idzie przez filtry bloków i bloki zagnieżdżone, a stylowanie przez `theme.json`. Jeśli ktoś przez pięć lat dokładał Wam poprawki do checkoutu, migracja oznacza przepisanie tego, nie przeklikanie.
Jak testować bezpiecznie. Staging, nie produkcja. Bloki Koszyk i Kasa mają w pasku narzędzi przycisk „Przekształć" - możesz przełączyć je na klasyczny shortcode i z powrotem. Jedna pułapka: **koszyk i kasa działają w parze**, więc jeśli cofasz, cofnij oba. Sprawdź pełną ścieżkę: dodanie do koszyka, kupon, kalkulacja wysyłki, wybór punktu odbioru, wszystkie metody płatności, faktura, mail potwierdzający.
Przy okazji: HPOS. Jeśli migrujesz sklep, sprawdź też, czy siedzicie już na High-Performance Order Storage. Nowe sklepy mają to domyślnie, starsze często nadal trzymają zamówienia jako wpisy w "postmeta". To osobna sprawa niż bloki, ale zwykle wychodzi przy tym samym audycie.
Moja rekomendacja: nowy sklep — bloki, bez dyskusji. Sklep działający, z bramką i integracją paczkomatów, które nie mają statusu „compatible" - zostajesz na shortcode i wracasz do tematu za pół roku. Sklep w trakcie redesignu - migrujesz teraz, bo i tak przepisujesz szablony.
Jeśli ktoś dopiero wchodzi w logikę bloków i chce zrozumieć, czym w ogóle różni się blok od shortcode'a, zanim podejmie decyzję o sklepie - [podstawy edytora blokowego opisane są tutaj](https://boostwave.pl/pl-gutenberg-w-wor ... o-to-jest/).
Pytanie do Was: czy ktoś ma już blokowy checkout z InPostem i P24 na produkcji i działa to bez obejść? Bo teoria mówi „compatible", a wątki supportowe mówią różnie.