WooCommerce 11.0 wychodzi 28 lipca — 5 audytów przed aktualizacją i jedna cicha zmiana w stanach magazynowych

Co dokładnie wychodzi 28 lipca?

We wtorek 28 lipca 2026 premierę ma WooCommerce 11.0. To nie zaskoczenie: beta krąży od 13 lipca, a WooCommerce wydaje kolejne „majory” w stałej kadencji co 5 tygodni. Drobiazg praktyczny: przez 24-godzinny „cooldown” WordPress.org duża część sklepów zobaczy 11.0 w panelu dopiero 29 lipca (przy 10.9 było identycznie).

Skala jest spora: WooCommerce to największa platforma e-commerce świata pod względem liczby sklepów — ok. 4,3–4,5 mln aktywnych instalacji i ok. 33,4% rynku liczonego liczbą sklepów (StoreLeads, styczeń 2026; W3Techs podaje 49% — różnica metodologii). Każdy major dotyka więc milionów sklepów naraz.

Czy sklep naprawdę przyspieszy o te 9–12%?

Wydajność to największy klaster zmian w 11.0 — 28 pull requestów otagowanych performance/caching/scalability. WooCommerce deklaruje w poście pre-release z 13 lipca: strony produktów wariantowych ładują się 9–12% szybciej, a checkout produktów pakietowych (bundle) przetwarza się 6–12% szybciej. Ważne zastrzeżenie: to deklaracje WooCommerce, nie zweryfikowane niezależnie — i dotyczą wąskich scenariuszy, a nie każdej podstrony sklepu.

Dwa haczyki. Po pierwsze, product object caching jest domyślnie włączony tylko dla nowych sklepów — istniejące muszą włączyć go same, więc przekaz „sklep sam przyspieszy” jest mylny. Po drugie, na hostingu współdzielonym wąskim gardłem bywa serwer, nie core — tam różnica może być niezauważalna. Realne korzyści odczują głównie duże sklepy: optymalizacja zapytań HPOS na ekranie zamówień i limitowanie żądań collection-data w Store API.

Dlaczego zmiana stanów magazynowych to najważniejszy punkt dla polskich sklepów?

Od 11.0 zamówienia, które przechodzą w status „nieudane” (failed), automatycznie przywracają stany magazynowe — nowy hook wc_maybe_increase_stock_levels() podpięty pod woocommerce_order_status_failed (advisory WooCommerce z 17 lipca 2026). Powód jest sensowny: przy płatnościach asynchronicznych zamówienie potrafiło utknąć w sekwencji „oczekujące → nieudane” i blokować towar w nieskończoność. To poprawka od dawna zgłaszanej niespójności, nie bug.

I tu jest polski kontekst, którego nie znajdziesz w changelogu: Przelewy24, PayU i inne bramki asynchroniczne to dokładnie ten scenariusz — płatność nie rozstrzyga się od razu, a status zmienia się z opóźnieniem. Po aktualizacji stany zaczną „wracać” automatycznie w momentach, w których dotąd nie wracały. Dla większości sklepów to zmiana niewidoczna albo korzystna (WooCommerce: „most stores need no changes”). Groźna robi się, gdy sklep używa statusu „nieudane” niestandardowo (np. do nieudanych dostaw) albo gdy integracja ERP/BaseLinker liczy stany po swojemu — wtedy automatyczny zwrot stanu może cicho rozjechać magazyn między systemami. Stare zachowanie przywraca jedna linia: remove_action( 'woocommerce_order_status_failed', 'wc_maybe_increase_stock_levels' ); — trzeba tylko wiedzieć, że problem może wystąpić.

Czy Checkout Recovery uratuje porzucone koszyki już teraz?

WooCommerce 11.0 zawiera pierwszą w historii platformy natywną funkcję ratowania porzuconych koszyków — dotąd ten obszar należał wyłącznie do wtyczek. Z kwalifikującego się zamówienia można ręcznie wysłać e-mail ratunkowy; jest one-click unsubscribe i obsługa prywatności.

Uczciwie: to nadal beta i nie nadaje się na produkcję. Digital Applied w analizie pre-release z 14 lipca nazywa ją „first native cart/checkout-abandonment tool WooCommerce has shipped” — i w tym samym tekście odradza włączanie w sklepach produkcyjnych w tym miesiącu. Jeśli używasz CartFlows, FunnelKit czy podobnych wtyczek — nie migruj jeszcze; betę testuj na stagingu (WooCommerce → Ustawienia → Zaawansowane → Funkcje).

Jakie 5 rzeczy sprawdzić przed kliknięciem „Aktualizuj”?

Dla deweloperów jeszcze jedno: get_queried_object() na stronie sklepu zwraca teraz WP_Post zamiast WP_Post_Type.

Aktualizować 28 lipca, czekać na 11.0.1 — czy najpierw audyt?

Najpierw szczypta trzeźwości: „11.0” brzmi jak rewolucja, ale to rutynowe wydanie w 5-tygodniowej kadencji. Skok z 10.9 na 11.0 to arytmetyka wersjonowania, nie przełom — wydanie przeszło normalny cykl beta i RC, a większość zmian jest ewolucyjna. Odruch „zawsze czekaj na .0.1” bywa więc przesadny; ślepe klikanie „Aktualizuj” w dniu premiery też nie jest planem.

Z praktyki AD AWARDS przy utrzymaniu sklepów WooCommerce dla polskich MŚP: przy majorach niemal nigdy nie wykłada się core. Wykładają się wtyczki premium z wygasłą licencją (bez dostępu do aktualizacji zgodnościowych) i szablony z nadpisanymi plikami templates sprzed kilku wersji. Dlatego kolejność ma znaczenie: kopia i staging, najpierw aktualizacja wszystkich wtyczek i przegląd WooCommerce → Status, potem test pełnej ścieżki zakupowej z bramką w trybie sandbox (bo zmiana stanów przy „failed” dotyka płatności asynchronicznych) — i dopiero na końcu core na produkcję.

Na koniec argument kalendarzowy, żeby nie odkładać sprawy na jesień: okno od 28 lipca do połowy sierpnia to sezonowy dołek sprzedażowy w polskim e-commerce — najlepszy moment w roku na taką operację. Następny major wyjdzie zgodnie z kadencją około początku września, a potem zaczyna się rozbieg do Q4, kiedy dotykanie działającego sklepu to zupełnie inna kategoria ryzyka.