WooCommerce 11.0 – co się zmieniło i kiedy bezpiecznie aktualizować sklep

10 sierpnia wyszła wersja 11.0.1 i to ona jest dzisiaj wersją, do której warto aktualizować. Zawiera 13 poprawek, w tym kilka o charakterze bezpieczeństwa: sanityzację komunikatu sklepu renderowanego w blokach koszyka i kasy (zakodowany HTML w treści błędu Store API, na przykład nazwa produktu, mógł tam uruchomić skrypt), zablokowanie wycieku skróconych opisów produktów chronionych hasłem przed uwierzytelnieniem, zaostrzone kontrole uprawnień w endpoincie aktywacji subskrypcji Marketplace i w shortcodzie podsumowania zamówienia oraz zmianę haszowania ciasteczek sesji. Doszła też zgodność listy zamówień z WordPressem 7.1 i poprawka w obsłudze tokena koszyka w Store API. WooCommerce nie ogłosił tego jako wydania bezpieczeństwa i nie ma tu numerów CVE, ale przy takim zestawie zmian nie ma sensu instalować 11.0.0.

Nasza rekomendacja jest prosta. Jeśli sklep realnie sprzedaje, nie aktualizuj produkcji dziś. Postaw kopię na stagingu, przeklikaj kasę i panel zamówień, daj temu kilka dni. Jeśli sklep jest mały, ma trzy wtyczki i motyw blokowy, spokojnie możesz zaktualizować od razu, po backupie. W obu przypadkach celujesz w 11.0.1, nie w 11.0.0.

Charakter tego wydania dobrze pokazuje jeden fakt. Premiera miała być 28 lipca i została przesunięta o tydzień, bo w RC1 wykryto błąd krytyczny wywołany przez nową funkcję wydajnościową. Dobry znak dla procesu, ale też sygnał, że ruszono tu rzeczy, które potrafią zaboleć.

Co nowego dla właściciela sklepu

Lista realnych zmian widocznych z panelu jest krótsza, niż sugerowały przedpremierowe zapowiedzi.

Przypisywanie zamówień gościa do konta. Klient, który kupował bez rejestracji, może teraz odnaleźć swoje wcześniejsze zamówienia i podpiąć je do nowo założonego konta, przez weryfikację adresu e-mail. To rozwinięcie mechanizmu z wersji 9.5. W praktyce mniej maili typu „gdzie moje zamówienie z marca”. Doszła też ścieżka, w której zalogowany klient potwierdza, że dany adres należy do niego.

Wydajność. 28 pull requestów dotyczyło wprost wydajności, cache lub skalowalności. Zoptymalizowano zapytania na ekranie zamówień w HPOS przy filtrowaniu po wielu statusach, Store API przestało dublować zapytania o dane kolekcji produktów, a liczniki statusów w liście produktów są teraz trwałe. Dla nowych sklepów domyślnie włączono cache obiektów produktu. WooCommerce podaje 9-12% szybsze ładowanie produktów zmiennych i 6-12% przy produktach typu bundle w kasie. To liczby producenta, u Ciebie mogą wyglądać inaczej. Jeśli sklep jest wolny mimo cache, przyczyna zwykle leży gdzie indziej, opisaliśmy to w tekście o tym, dlaczego WordPress bywa wolny mimo cache.

Raporty. Zwroty trafiają do raportu sprzedaży v3 w podziale na daty, więc sprzedaż netto liczy się poprawniej. Historyczny import danych do Analytics pokazuje nieudane zadania i pozwala je ponowić.

Funkcje eksperymentalne. Maile o porzuconym koszyku, blokowy edytor maili i nowy interfejs ustawień są dostępne, ale wciąż jako eksperyment. Nie włączaj tego na produkcji „żeby zobaczyć”.

Największe zmiany, czyli najważniejsza część tego wpisu

Tu leży całe ryzyko aktualizacji. Pięć zmian, każda potwierdzona osobnym Developer Advisory na blogu WooCommerce.

1. Product Editor beta znika z rdzenia

Blokowy edytor produktu, przez kilkanaście miesięcy dostępny jako eksperyment, został usunięty w całości. Nie ma pakietu @woocommerce/product-editor, przełącznika w ustawieniach, tras ani punktów rozszerzeń.

Dla właściciela sklepu to zdarzenie bez konsekwencji: dane produktów zostają nietknięte, sklep wraca do klasycznego edytora. Ale wtyczka, która dokładała własne bloki lub filtry do tego edytora, może wyrzucić błędy JavaScript. To pytanie do jej autora, nie do Ciebie.

2. get_queried_object() na stronie sklepu zwraca co innego

Do tej pory get_queried_object() na stronie sklepu zwracało obiekt WP_Post_Type dla produktów. To była niezgodność z samym WordPressem i źródło pomyłek. Od 11.0 funkcja zwraca WP_Post, czyli obiekt strony sklepu, tak jak na każdej innej stronie.

Funkcje warunkowe is_shop(), is_archive() i is_post_type_archive( 'product' ) działają bez zmian. Ale motyw albo wtyczka czytająca get_queried_object(), get_queried_object_id() lub $query->queried_object i zakładająca stary typ obiektu może zachować się dziwnie. Poprawne podejście to get_post_type_object( 'product' ). To najbardziej podstępna zmiana w tym wydaniu, bo nie wywołuje błędu, tylko cichy inny wynik.

3. product_shipping_class przestaje być taksonomią publiczną

Klasy wysyłki to wewnętrzny mechanizm, nie treść do przeglądania. Od 11.0 taksonomia jest niepubliczna, więc is_taxonomy_viewable( 'product_shipping_class' ) zwraca false. Jeśli ktoś linkował do archiwum klasy wysyłki albo generował dla niej sitemapę, to przestanie działać. Rzadki przypadek, ale sprawdź, czy nie masz takich adresów w indeksie.

4. Stan magazynowy wraca przy statusie „nieudane”

Do tej pory zamówienie, które przeszło w status „nieudane”, zostawiało zdjęty stan magazynowy. Od 11.0 stan jest przywracany automatycznie. Brzmi jak drobiazg, a potrafi wywrócić pracę magazynu. Jeśli masz własny kod albo wtyczkę robiącą to samo, akcja się zdubluje i stan urośnie dwa razy. Sprawdź to, zanim wpuścisz aktualizację na sklep z ograniczoną liczbą sztuk.

5. Zmiana momentu woocommerce_removed_order_items

Akcja odpala się w innym momencie. Usunięcie pozycji z bazy jest odroczone aż do wywołania save() na zamówieniu, żeby poprawić wznawianie zamówień i uniknąć utraty danych. Kod, który zakładał, że w tym punkcie w bazie już nic nie ma, trzeba przejrzeć.

Do tego – Action Scheduler 4.0.0

Razem z 11.0 wchodzi Action Scheduler w wersji 4.0.0. To nie jest kosmetyka.

• Nieudane akcje są automatycznie czyszczone po 3 miesiącach. Sterujesz tym filtrem action_scheduler_retention_period_for_failed, a całe czyszczenie wyłączasz filtrem action_scheduler_enable_failed_action_cleanup. Jeśli traktowałeś tę tabelę jako archiwum do audytu, ustaw to świadomie.
• Zmieniła się reguła unikalności. Wcześniej porównywano hook i grupę, ignorując argumenty, więc dwie akcje z tym samym hookiem blokowały się nawzajem. Od 4.0.0 argumenty wchodzą do porównania.
• Sprzątanie akcji przeniesiono do osobnego zadania, raz dziennie o 3 w nocy czasu sklepu.

Zmiany wokół kasy

Domyślny czas rezerwacji stanu magazynowego w ReserveStock::reserve_stock_for_order() to teraz 60 minut, gdy wywołujący nie poda własnej wartości. Store API nie tworzy już też trwałego zamówienia roboczego przy pierwszym GET i PATCH w świeżej sesji. Draft powstaje bliżej momentu złożenia zamówienia, więc w bazie zostaje mniej osieroconych wierszy po ludziach, którzy nigdy nie kupili. Jeśli grzebiesz przy kasie, zobacz też nasz materiał o tym, jak wygląda optymalizacja checkoutu w WooCommerce.

Wymagania – minimum kontra zalecenia

Tu jest pułapka. Nagłówek wtyczki w repozytorium WordPress.org podaje inne liczby niż oficjalna dokumentacja serwerowa WooCommerce. Oba źródła są aktualne, tylko mówią o czym innym: readme podaje twarde minimum, przy którym wtyczka wystartuje, a dokumentacja to, co WooCommerce faktycznie wspiera.

Element	Twarde minimum (readme wtyczki)	Zalecane (dokumentacja WooCommerce)
PHP	7.4	8.3 lub nowszy, testowane do 8.4
WordPress	6.9	6.9 lub nowszy
MySQL	5.5.5	8.0 lub nowszy
MariaDB	10.1	10.6 lub nowszy
Limit pamięci WP	brak twardego progu	256 MB lub więcej
HTTPS	zalecane	wymagane

Uwaga: PHP 7.4 i MySQL w wersjach 5.x są dawno po końcu wsparcia, dokumentacja WooCommerce wymienia je już tylko jako „niezalecane”. Jeśli hosting trzyma Cię na PHP 7.4, to nie jest problem WooCommerce 11.0, tylko problem bezpieczeństwa niezależny od tej aktualizacji. Sama wersja 11.0 jest przetestowana z WordPressem do 7.0.

HPOS – czy w 11.0 stał się obowiązkowy

Nie. To najczęstsze pytanie przy każdym majorze i odpowiedź się nie zmieniła.

High-Performance Order Storage jest domyślnie włączony dla nowych instalacji od wersji 8.2. Istniejące sklepy nie są migrowane automatycznie, przełączenie pozostaje opcjonalne. Oficjalna dokumentacja WooCommerce nie podaje daty usunięcia starego magazynu opartego o wp_posts. W obiegu krążą różne terminy graniczne, ale nie znaleźliśmy dla nich potwierdzenia u producenta, więc nie powtarzamy ich jako faktu.

Praktyczny wniosek: WooCommerce 11.0 optymalizuje ekran zamówień właśnie w HPOS. Siedząc na starym magazynie, część zysku z tej aktualizacji tracisz. Migracja jest odwracalna, a tryb kompatybilności trzyma oba magazyny zsynchronizowane. Dobry moment, żeby ją zaplanować. Ale osobno, nie w tym samym oknie serwisowym co aktualizacja do 11.0.

Znane problemy zgłoszone po premierze

Zgłoszenia z GitHuba WooCommerce i forum wsparcia WordPress.org z pierwszego tygodnia po wydaniu, czyli sprzed wersji 11.0.1. Changelog 11.0.1 wymienia poprawki w inicjalizacji ustawień panelu, w tokenie koszyka w Store API, w obsłudze kuponów przy płatności za zamówienie oraz w zapisie logów, więc część z poniższej listy najprawdopodobniej odpadła. WooCommerce nie mapuje poprawek na konkretne zgłoszenia, dlatego nie twierdzimy, które dokładnie. Traktuj tę listę jako mapę miejsc do przeklikania na stagingu, nie jako listę aktualnych błędów.

• Blok Product Filters wygasza całą stronę sklepu, gdy jest ona statyczną stroną główną. Najpoważniejsze zgłoszenie, najprawdopodobniej pokłosie zmiany w get_queried_object().
• Przycisk usuwania pozycji w bloku koszyka bywa nieczuły na kliknięcia, a na Androidzie fokus przeskakuje w złe miejsce.
• Kupujący blokowany przez własną rezerwację stanu. Powiązane z nowym oknem 60 minut.
• Fałszywe ostrzeżenie „Your business location does not match your store location” w ustawieniach płatności.
• Odpowiedzi 403 na POST do admin-ajax.php w panelu.
• Wyjątki przy inicjalizacji koszyka w Store API wychodzą jako błąd 500.
• Rozszerzenia czytające globalne zmienne kasy bez zadeklarowanych zależności potrafią wywalić cały blok.
• Z forum: wyczerpanie pamięci PHP w ActionScheduler_Lock.php oraz konflikt z Divi 5 przy nakładaniu szablonu sklepu.

Wniosek jest jednoznaczny. Najwięcej boli tam, gdzie są bloki koszyka i kasy oraz motywy z własnymi szablonami. Masz jedno i drugie? Staging jest obowiązkowy.

Checklista przed aktualizacją

1. Pełny backup plików i bazy. Sprawdź, że kopia się odtwarza, a nie tylko że plik istnieje.
2. Zapisz obecne wersje WooCommerce, WordPressa i PHP. Bez tego nie wiesz, do czego wracasz.
3. Postaw kopię sklepu na stagingu. Aktualizuj najpierw tam, nigdy od razu na produkcji.
4. Sprawdź PHP na hostingu. Poniżej 8.3 zaplanuj podbicie, ale osobno, nie razem z aktualizacją Woo.
5. Wypisz wtyczki bez aktualizacji od ponad roku. To pierwsi kandydaci do awarii.
6. Zajrzyj w WooCommerce, Status, Szablony. Przestarzałe nadpisania w motywie to najczęstsza przyczyna problemów.
7. Zapytaj autorów płatnych rozszerzeń o zgodność z 11.0. Zwłaszcza tych od kasy, magazynu i wysyłki.
8. Przeszukaj własny kod pod kątem get_queried_object, woocommerce_removed_order_items, product_shipping_class i reserve_stock_for_order.
9. Sprawdź, czy coś u Ciebie przywraca stan magazynowy przy nieudanych zamówieniach. Jeśli tak, wyłącz to, bo 11.0 robi to natywnie.
10. Zdecyduj, co ma się dziać z nieudanymi akcjami Action Schedulera. Domyślnie znikają po 3 miesiącach.
11. Wybierz okno serwisowe poza szczytem sprzedaży. Aktualizacja migruje bazę, więc sklep przez chwilę może zachowywać się nieprzewidywalnie.
12. Miej plan wycofania: przywrócenie backupu albo wtyczka WP Rollback do cofnięcia wersji WooCommerce.

Jak zaktualizować krok po kroku

1. Staging. Sklonuj produkcję na środowisko testowe. Świeżą kopię, nie tę sprzed miesiąca.
2. Kolejność. Najpierw rdzeń WordPressa, potem WooCommerce, na końcu rozszerzenia i motyw. Odwrotna kolejność to proszenie się o białą stronę.
3. Aktualizacja bazy. WooCommerce poprosi o uruchomienie aktualizatora bazy. Uruchom go i poczekaj, aż skończy. Nie przerywaj i nie zamykaj karty.
4. Test kasy. Pełna ścieżka zakupu jako gość i jako zalogowany klient, z realną metodą płatności w trybie testowym i wyborem dostawy.
5. Test panelu i produktów. Lista zamówień, filtrowanie po statusach, zmiana statusu, zwrot. Potem edycja produktu prostego i zmiennego, stany magazynowe, klasy wysyłki. Przy okazji sprawdź, czy nie ucierpiały Twoje ulepszenia strony produktu.
6. Konsola przeglądarki. F12 na stronie sklepu, koszyka i kasy. Czerwone błędy JavaScript to sygnał, że któraś wtyczka nie nadąża za 11.0.
7. Produkcja. Dopiero gdy staging przechodzi wszystko, po backupie i w oknie serwisowym. Przez pierwsze 48 godzin patrz na logi błędów i liczbę zamówień. Spadek o połowę to nie sezon, to zepsuta kasa.

Częsty błąd: aktualizacja WooCommerce i podbicie PHP w tym samym momencie. Gdy coś pęknie, nie wiesz, co było przyczyną. Rób to w dwóch osobnych oknach, z odstępem.

Kiedy poczekać z aktualizacją

Uczciwie: są sytuacje, w których „aktualizuj natychmiast” jest złą radą. Formalnie 11.0 nie jest wydaniem bezpieczeństwa, choć poprawka 11.0.1 zawiera zmiany, które w praktyce dotyczą bezpieczeństwa. Presja czasu jest więc większa niż przy zwykłym majorze, ale nadal nie taka jak przy łatce na aktywnie wykorzystywaną lukę.

• Masz szczyt sprzedaży. Wyprzedaż, premiera produktu, kampania w trakcie. Odłóż na spokojny tydzień.
• Kasa na blokach plus mocno przerobiony motyw. Największe skupisko zgłoszonych błędów po premierze. Aktualizuj od razu do 11.0.1 i zrób to najpierw na stagingu, nie na produkcji.
• Kluczowe rozszerzenie nie deklaruje zgodności z 11.0. Bramka płatności, ERP, system fakturowy, wtyczka kurierska. Jedna niezgodność tutaj zatrzymuje sprzedaż.
• Motyw Divi 5. Zgłoszono konflikt z szablonem sklepu po aktualizacji do 11. Sprawdź stan zgłoszenia, zanim ruszysz.
• Nie masz stagingu ani działającego backupu. Najpierw to załatw. Dopóki nie masz, nie aktualizuj.
• Sklep siedzi na PHP 7.4. Najpierw hosting i PHP, potem WooCommerce.
• Masz własne rozszerzenia bez testów. Najpierw audyt kodu pod kątem pięciu breaking changes z tego wpisu.

Rozsądny kompromis dla większości sklepów: staging teraz na 11.0.1, produkcja w ciągu tygodnia. Pierwsza wersja łatająca już jest, więc argument „poczekam, aż wyjdzie poprawka” się wyczerpał.

Podsumowanie

WooCommerce 11.0 to wydanie, które większość sklepów przejdzie bez emocji. Aktualizacja bazy, kilkanaście procent szybciej przy produktach zmiennych, porządniejsze raporty. Ryzyko nie leży w rdzeniu, tylko w tym, co masz wokół niego: w motywie z własnymi szablonami sklepu, w rozszerzeniu bez aktualizacji od dwóch lat, we własnym kodzie, który czyta get_queried_object() i zakłada stary wynik.

Backup, staging, przeklikanie kasy i panelu zamówień. Godzina pracy zamiast dnia gaszenia pożarów.

Jeśli nie masz kiedy albo na czym tego testować, zajmujemy się tym na co dzień. Robimy wdrożenia i rozwój sklepów WooCommerce, a przy stałej opiece nad WordPress i WooCommerce aktualizacje idą przez staging, backup i checklistę, zanim dotkną sklepu. Zakres i wycenę ustalamy indywidualnie po krótkiej rozmowie, więc jeśli chcesz to zdjąć z głowy, napisz do nas.

FAQ

Czy WooCommerce 11 to duża zmiana dla właściciela sklepu?

Z perspektywy panelu nie. Nie ma nowej funkcji, która zmieniałaby sposób pracy. Największe zmiany to wydajność zapytań, poprawniejsze raporty ze zwrotami i możliwość podpięcia zamówień gościa do konta klienta.

Czy muszę włączyć HPOS przed aktualizacją do 11.0?

Nie. WooCommerce 11.0 działa na starym magazynie zamówień. HPOS jest domyślny tylko dla nowych instalacji od wersji 8.2, a istniejące sklepy przełączają się dobrowolnie.

Jaka wersja PHP jest potrzebna do WooCommerce 11?

Twarde minimum z nagłówka wtyczki to PHP 7.4. Oficjalna dokumentacja serwerowa zaleca jednak PHP 8.3 lub nowszy, z testami do 8.4. Na 7.4 sklep ruszy, ale pracujesz na wersji po końcu wsparcia.

Czy da się cofnąć aktualizację WooCommerce?

Tak, ale nie zawsze bezboleśnie. 11.0 aktualizuje bazę danych, więc czyste cofnięcie to przywrócenie backupu. WP Rollback cofnie samą wersję wtyczki, ale nie odwróci zmian w bazie. Dlatego kopia zapasowa jest tu obowiązkowa, a nie opcjonalna.

Co się stało z blokowym edytorem produktu?

Został całkowicie usunięty z rdzenia w 11.0, razem z pakietem, przełącznikiem i punktami rozszerzeń. Sklepy, które go używały, wracają do klasycznego edytora. Dane produktów zostają nietknięte.

Czy WooCommerce 11 psuje wtyczki?

Sam z siebie nie, ale pięć breaking changes może wpłynąć na rozszerzenia, które ich nie uwzględniły. Najbardziej narażone są wtyczki dotykające bloków kasy i koszyka, klas wysyłki, stanów magazynowych oraz starego edytora produktu.

Czy 11.0 to aktualizacja bezpieczeństwa?

Samo 11.0.0 nie. To wydanie funkcjonalno-wydajnościowe. Ale poprawka 11.0.1 z 10 sierpnia zawiera już zmiany dotyczące bezpieczeństwa: sanityzację komunikatu sklepu w blokach koszyka i kasy, ochronę opisów produktów chronionych hasłem, zaostrzone kontrole uprawnień w dwóch miejscach i nowe haszowanie ciasteczek sesji. Dlatego instaluj 11.0.1, a nie 11.0.0.

Aktualizować do 11.0.0 czy 11.0.1?

Do 11.0.1. Wyszła 10 sierpnia 2026 i jest wersją stabilną w repozytorium WordPress.org. Nie ma sytuacji, w której warto dziś świadomie zostać na 11.0.0.

—