WooCommerce 11.2 wychodzi 6 października. Zmienia układ kasy, kolejność kuponów i dni w raportach. Przetestuj, zanim zaktualizujesz przed Q4

Każde duże wydanie platformy przed sezonem to decyzja o ryzyku, nie o funkcjach. Zespół WooCommerce opublikował 21 września notatki do wersji 11.2: beta jest do pobrania, wydanie zaplanowano na tydzień 6 października. Przeczytałem je z perspektywy właściciela sklepu, nie programisty, i wyszły mi trzy zmiany, które dotykają wyglądu kasy i pieniędzy, plus kilka, które warto znać. Zaczynam od tych trzech.
Kasa w blokach zmienia szerokość i próg układu
Jeśli Twój koszyk i kasa działają na blokach (Cart i Checkout block), to najważniejszy punkt. Zespół pisze wprost, w sekcji dla deweloperów: kolumna z podsumowaniem zamówienia „staje się stałą kolumną o szerokości 360 px zamiast 35%”, a próg, od którego układ przechodzi w dwie kolumny, „przesuwa się z 700 px na 920 px szerokości kontenera”. I dalej: własny CSS oparty na procentach albo na media query 700 px „będzie się rozjeżdżał”.
W praktyce: na tablecie w pionie i na węższych laptopach z otwartym panelem bocznym kasa, która dziś ma dwie kolumny, po aktualizacji może przejść w jedną, z podsumowaniem pod formularzem. Na dużym ekranie podsumowanie będzie węższe albo szersze niż dziś, zależnie od szerokości kontenera motywu. Sama zmiana nie jest zła, ale każdy sklep, w którym ktoś kiedyś „poprawił kasę” w CSS, ma coś do sprawdzenia. Kasa to ostatnie miejsce, w którym chcesz odkryć rozjechany układ w listopadzie.
Kupony sekwencyjne liczą się w kolejności klienta
Druga zmiana dotyczy tylko sklepów, które mają włączone naliczanie rabatów z kuponów sekwencyjnie (ustawienie w Ustawieniach ogólnych, przy włączonych kuponach). Do tej pory kupony o równym priorytecie i tym samym limicie pozycji WooCommerce nakładał od najniższej kwoty rabatu. Od 11.2 nakłada je „w kolejności, w jakiej klient je wpisał”. Zespół dodaje: „ponieważ każdy kupon liczy się od ceny, którą zostawił poprzedni, sumy koszyka mogą się zmienić”.
Policzmy na prostym przykładzie. Koszyk 300 zł, dwa kupony: −10% i −20 zł.
- Kupon procentowy pierwszy: 300 → 270 → 250 zł. Rabat 50 zł.
- Kupon kwotowy pierwszy: 300 → 280 → 252 zł. Rabat 48 zł.
Różnica to 2 zł na zamówienie, czyli procent z kwoty kuponu kwotowego. Mało, ale systematycznie i w stronę, którą wybierze klient, bo szybko nauczy się wpisywać procent jako pierwszy. Przy kuponie −20% i −50 zł na koszyku 500 zł różnica rośnie do 10 zł. Jeśli w Q4 planujesz akcje z dwoma łączonymi kodami, policz oba warianty od marży, a nie od przychodu. Przy marży pokrycia 30% zysk brutto z zamówienia za 500 zł to 150 zł, a rabaty z tego przykładu zabierają z niego 140 albo 150 zł. Kolejność wpisania kuponów decyduje, czy na zamówieniu zostaje 10 zł, czy zero.
Dzień sklepu zamiast UTC w zapytaniach o daty
Trzecia zmiana jest niewidoczna w panelu, a widoczna w liczbach. Funkcje, którymi wtyczki i integracje pobierają zamówienia oraz produkty po dacie (wc_get_orders() i wc_get_products()), czytają teraz datę „jako dzień w strefie czasowej sklepu zamiast UTC”. Polska jest dwie godziny przed UTC latem i godzinę zimą, więc zamówienia złożone między północą a drugą w nocy dotąd lądowały w takich zapytaniach w poprzednim dniu. Po aktualizacji trafią do właściwego.
Zespół precyzuje zasięg: „zapytania o produkty zmieniają się w każdym sklepie; zapytania o zamówienia tylko w sklepach, które nadal przechowują zamówienia jako wpisy”. Jeśli Twój sklep jest po migracji na tabele HPOS, zamówień to nie dotyczy. Jeśli nie, to eksport dzienny do księgowości, raport wtyczki albo integracja z systemem magazynowym mogą pokazać w październiku inny podział na dni niż we wrześniu. To nie błąd, tylko zmiana definicji dnia. Warto ją zapisać przy porównaniach miesiąc do miesiąca.
Co znika, co dochodzi
Z notatek warto wynotować jeszcze pięć rzeczy.
Znikają eksperymenty z porzuconymi koszykami i Agentic Checkout. Obie funkcje były domyślnie wyłączone. Zespół usuwa je razem z trasami API wc/agentic/v1, „bez zastępczego endpointu”, a aktualizacja bazy „anuluje zaplanowane akcje odzyskiwania i usuwa tabelę wc_email_unsubscribes”. Kto włączył eksperymentalne e-maile o porzuconym koszyku, po aktualizacji ich nie ma i musi je zastąpić wtyczką. Kto podpinał agentów zakupowych pod eksperymentalną trasę, zostaje bez niej. Dla sklepów na otwartych platformach gotowego modułu do kasy dla agentów AI nadal nie ma i WooCommerce właśnie to potwierdził: eksperyment zamknięto, zanim stał się funkcją.
Dochodzą konfigurowalne e-maile o zgłoszeniu odstąpienia od umowy. WooCommerce dodaje dwa e-maile: potwierdzenie dla klienta i powiadomienie dla sprzedawcy, gdy klient złoży zgłoszenie odstąpienia. Zarządzasz nimi w WooCommerce → Ustawienia → E-maile: odbiorcy, dodatkowa treść, podgląd, włączenie lub wyłączenie. To techniczna strona obowiązku, o którym pisała Anna w tekście o przycisku „Odstąp od umowy”: unijny termin minął w czerwcu, polskiej ustawy nadal nie ma, a platforma i tak dostarcza mechanikę.
Import CSV dopasowuje produkty po GTIN, UPC, EAN i ISBN. Przy włączonym „Aktualizuj istniejące produkty” importer szuka wiersza najpierw po ID, potem po SKU, na końcu po globalnym identyfikatorze. Identyfikator, który nie pasuje do niczego, pomija wiersz zamiast tworzyć nowy produkt, a dopasowanie do produktu innego typu jest odrzucane. Dla każdego, kto przed sezonem wgrywa ceny i stany z pliku od dostawcy, to koniec przypadkowych duplikatów. Zespół dodaje, że sprzątanie po imporcie nie robi już „usuwania osieroconych danych w całej witrynie”, które na dużych katalogach potrafiło „usunąć niepowiązane dane”.
Pola daty w kasie. Rozszerzenia mogą dodać do kasy w blokach pole daty z natywnym selektorem przeglądarki, z ograniczeniem zakresu, na przykład „od jutra do 30 dni w przód”. Preferowany termin dostawy prezentów w grudniu to klasyczny przypadek. Wymaga wtyczki albo programisty, sam WooCommerce dodaje tylko mechanizm.
Drobiazgi. W klasycznych szablonach karty produktu kategorie wyświetlają się teraz od nadrzędnej („Elektronika, Aparaty” zamiast „Aparaty, Elektronika”), edytor zamówień nie przyjmuje ujemnych ilości, blok filtrów produktów może być przyklejony do ekranu przy przewijaniu, a Store API zwraca kod 429 zamiast 400 przy przekroczeniu limitu zapytań.
Aktualizować przed sezonem czy po
Pisałem we wrześniu, że zmiany w sklepie przed Q4 zamrażamy, a wyjątkiem są łatki bezpieczeństwa. Wersja 11.2 nie jest łatką, tylko wydaniem funkcjonalnym, więc domyślna odpowiedź brzmi: na produkcji dopiero po sezonie. Ale są dwa powody, żeby jednak rozważyć październik: import po GTIN, jeśli w listopadzie wgrywasz duże pliki cen, i e-maile o odstąpieniu, jeśli już obsługujesz zgłoszenia ręcznie. W obu przypadkach warunkiem jest test na kopii z prawdziwym motywem i prawdziwymi wtyczkami, nie na czystej instalacji.
Sklep, który nie aktualizuje, nie zostaje bez wsparcia: poprawki bezpieczeństwa dla bieżącej gałęzi wychodzą osobno. A jeśli Twój sklep jest wciąż na PHP 7.4 lub 8.0, temat aktualizacji zaczyna się gdzie indziej.
Co zrobić w najbliższym tygodniu
- Sprawdź, na czym działa Twoja kasa. Bloki czy klasyczny shortcode. Jeśli bloki, poszukaj w motywie i wtyczkach CSS z wartościami 35% i 700px odnoszącymi się do kasy. To kandydaci do rozjechania.
- Sprawdź ustawienie kuponów sekwencyjnych. Jeśli włączone i planujesz łączenie kodów w Q4, policz oba warianty kolejności od marży i zdecyduj, czy zostawiasz łączenie.
- Sprawdź, gdzie są zamówienia. HPOS czy wpisy. Jeśli wpisy, zapisz, które eksporty i integracje pobierają zamówienia po dacie, i uprzedź księgowość o innym podziale dni.
- Sprawdź, czy używasz eksperymentów. Porzucone koszyki albo Agentic Checkout włączone w ustawieniach eksperymentalnych: po aktualizacji znikają bez zamiennika.
- Postaw kopię z betą 11.2. Wtyczka WooCommerce Beta Tester, kanał Beta, wersja 11.2.0-beta.1. Przejdź pełne zamówienie na trzech szerokościach ekranu i z dwoma kuponami.
- Zdecyduj o terminie i zapisz go. Październik z testem albo styczeń bez pośpiechu. Obie odpowiedzi są dobre, zła jest tylko aktualizacja automatyczna w listopadzie.
Jeśli chcesz, żebyśmy przejrzeli listę wtyczek, kasę i plan aktualizacji Twojego sklepu przed sezonem, odezwij się.

Marcin Janczewski
IT & e-commerce · Pro1.pl
Współzałożyciel Pro1.pl i DrTusz.pl. Z branżą ecommerce związany jest ponad 20 lat. Swoją karierę rozpoczynał od własnego sklepu internetowego z asortymentem do drukarek, który z sukcesami prowadzi do dziś. Obecnie DrTusz.pl jest nie tylko wiodącym ecommercem w branży, ale także marką samą w sobie, kojarzoną z najwyższym poziomem marketingu. Wspiera sklepy internetowe na każdym etapie ich rozwoju, od momentu wejścia w sprzedaż online po budowanie i optymalizację procesów. Programista z wykształcenia, marketer i sprzedawca z pasji.
Czytaj też
Gemius zapytał 1768 kupujących, co wyrzuca ich ze sklepu: koszt wysyłki 47%, cena 44%, wyskakujące okienka 26%. Sprawdź swój koszyk przed Q4
Nowy raport „E-commerce w Polsce 2026” czytam nie jako ranking platform, tylko jako listę powodów, dla których klient porzuca konkretny sklep. Większość z nich poprawisz w tydzień, bez programisty i bez dokładania do budżetu na ruch. Pokazuję liczby, ich podstawę i to, czego z nich nie wolno wyczytać.
Google łączy tag Google z Menedżerem tagów. Uaktualnienie kontenera jest dobrowolne i nie jest na Q4
Google zapowiedziało połączenie tagu Google z Menedżerem tagów: nowy układ kontenera, ustawienia w osobnej karcie i tagowanie wizualne w becie. Nic nie zmieni się samo, więc decyzja należy do Ciebie. Wyjaśniam, co dokładnie się zmienia i dlaczego początek października jest lepszy niż listopad.
Google: filtry nie zatrzymają fałszywych zgłoszeń z formularzy. Sprawdź, o co naprawdę licytują kampanie Twojego sklepu
Nowa strona pomocy Google Ads mówi wprost: filtry nieprawidłowego ruchu chronią budżet, ale nie zatrzymają fałszywych zgłoszeń z formularzy. Pokazuję, gdzie sklep ma takie formularze, jak sprawdzić, czy kampanie nie licytują o zapisy do newslettera zamiast o zamówienia, i co zabezpieczyć, zanim lista e-mailowa zacznie pracować na Black Friday.