WooCommerce 11.2.1: dwie poprawki i decyzja, którą musisz podjąć sam

Trzy sytuacje, różne decyzje

Masz sklep na 11.1.x, w panelu pojawiła się 11.2.1, a wkrótce zamykasz miesiąc. Albo korzystasz już z 11.2.0 i nie wiesz, czy poprawki Cię dotyczą. Możliwe też, że prowadzisz sklep z własnym kodem filtrującym daty w raportach i każda aktualizacja wymaga kilku godzin testów.

To różne sytuacje i różne decyzje. Wersja 11.2.1 poprawia błędy wprowadzone dwa dni wcześniej. Sklep przechodzący z 11.1.x dostaje również cały pakiet zmian z 11.2.0: poprawki bezpieczeństwa, aktualizację bazy i modyfikacje, które mogą zmienić wyniki własnego kodu bez komunikatu o błędzie.

Co dokładnie naprawiono 9 października

WooCommerce 11.2.0 ukazało się 7 października 2026 r., dzień później niż planowano, po dołączeniu dodatkowych poprawek bezpieczeństwa. Wydanie obejmuje 642 zgłoszenia zmian od 93 współtwórców oraz aktualizację bazy. Wersja 11.2.1 pojawiła się 9 października. Sama nie wprowadza nowej aktualizacji bazy ani poprawek bezpieczeństwa, lecz naprawia dwie regresje kasy.

Pierwsza dotyczy klasycznej kasy w sklepach, które własnymi filtrami ukrywają pola adresowe. W 11.2.0 podczas odświeżania podsumowania mogło pojawić się żądanie brakującego adresu, a podatek lub opcje wysyłki mogły zniknąć. Problem dotyczy między innymi sklepów z usługami i produktami cyfrowymi. Poprawka przywraca wcześniejszy sposób przesyłania danych.

Druga dotyczy kasy blokowej. Przywrócono akceptację argentyńskich kodów pocztowych bez litery prowincji, na przykład 1213, oraz niektórych formatów z Salwadoru, Saint Vincent i Grenadyn oraz Brytyjskich Wysp Dziewiczych.

Ze starszej gałęzi można przejść bezpośrednio do 11.2.1 lub nowszej zgodnej, stabilnej wersji. Jeśli korzystasz z 11.2.0 i dotyczy Cię jedna z regresji, zaplanuj szybką aktualizację. W innych przypadkach termin zależy od ryzyka i możliwości przeprowadzenia testów — odkładanie aktualizacji nie daje gwarancji bezpieczeństwa.

Co doszło w 11.2.0

Importer CSV dopasowuje produkty po GTIN, UPC, EAN lub ISBN, gdy nie ma identyfikatora produktu ani SKU i włączono aktualizację istniejących produktów. Kolejność to ID, SKU i identyfikator globalny. Niepusty identyfikator bez dopasowania powoduje pominięcie wiersza, a dopasowanie do innego typu produktu jest odrzucane.

Można konfigurować dwa powiadomienia dotyczące odstąpienia od umowy: dla klienta i sklepu. Deweloperzy otrzymali obsługę pól daty w kasie blokowej i formularzach konta. Bloki zyskały dodatkowe ustawienia wyglądu, między innymi obrazów, przycisków ilości i etykiet filtrów, a filtr produktów można przypiąć podczas przewijania.

Wydanie usprawnia zmianę kolejności produktów, obsługę produktów zmiennych i zapytania raportów. Wydawca nie podaje konkretnych wartości przyspieszenia dla wszystkich sklepów. Sprawdź też kupony o równym priorytecie: kolejność ich zastosowania może wpłynąć na sumę koszyka.

Zmienił się układ bloków koszyka i kasy: kolumna podsumowania ma 360 pikseli, a próg układu dwukolumnowego wynosi 920 pikseli szerokości kontenera. Własne style motywu warto obejrzeć zwłaszcza na tablecie.

Bezpieczeństwo i uprawnienia

Kopie wiadomości dotyczących resetu hasła, nowego konta, potwierdzenia adresu i weryfikacji powiadomień o dostępności nie są już domyślnie wysyłane na zapisane adresy kopii. Ustawienia są również niedostępne przez REST API. Integracje korzystające z tych wiadomości trzeba sprawdzić; deweloper może świadomie przywrócić kopie odpowiednimi filtrami.

Linki do pobierania produktów przechodzą dokładniejszą walidację. Standardowe działają bez zmian, ale niektóre ręcznie utworzone lub importowane linki z błędnymi danymi mogą przestać działać. Pomocne może być ponowne wystawienie linku lub naprawa uprawnień. Regeneracja uprawnień może wyzerować liczniki i dzienniki pobrań, więc najpierw zabezpiecz potrzebne dane.

Kierownik sklepu nie może już edytować kont z dodatkowymi rolami spoza dozwolonej listy, na przykład niektórymi rolami forum lub serwisu członkowskiego. Administrator nadal ma taką możliwość, a deweloper może rozszerzyć listę. Import Blueprint w sieci witryn wymaga teraz uprawnień superadministratora.

Daty w raportach i HPOS

Zmiana interpretacji dat może wpłynąć na raporty, eksporty i własne skrypty. Zapytania o produkty interpretują pojedynczą datę jako dzień w strefie czasowej sklepu zamiast UTC. W zapytaniach o datę zapłaty i realizacji zmiana dotyczy zamówień przechowywanych jako wpisy, a nie zamówień w HPOS.

HPOS przechowuje zamówienia w osobnych tabelach; nowe sklepy domyślnie korzystają z niego od WooCommerce 8.2. Ustawienie sprawdzisz w sekcji zaawansowanych funkcji WooCommerce. Zakres dat obejmuje teraz cały ostatni dzień, a wcześniej stosowana ręczna korekta strefy może zostać zastosowana dwukrotnie. Porównaj raporty na granicach dni i okresów przed zamknięciem miesiąca.

Usunięte funkcje i zgodność wtyczek

Usunięto eksperymentalne odzyskiwanie porzuconych koszyków i eksperymentalny Agentic Checkout API. Migracja anuluje związane z odzyskiwaniem zaplanowane zadania i usuwa tabelę rezygnacji z wiadomości; cofnięcie samej wtyczki nie przywraca tych danych. Eksperymentalne Dual API przeniesiono do osobnej wtyczki wymagającej WooCommerce 11.2 i PHP 8.1; usunięte punkty dostępu produktów i kuponów nie mają zamiennika.

Zmiana priorytetu rejestracji ustawień może wpłynąć na własny kod odłączający tę rejestrację. Zmieniły się także zachowania związane z walidacją webhooków i usuwaniem atrybutów. Własne integracje należy przejrzeć i sprawdzić na kopii sklepu.

PublishPress Future w wersjach od 3.0.0 do 4.10.3 może powodować błąd krytyczny z WooCommerce 11.2 przez starszą kopię Action Scheduler, biblioteki obsługującej zadania w tle. Poprawka jest dostępna od wersji 4.10.4. Jeżeli korzystasz z tej wtyczki, zaktualizuj ją przed WooCommerce.

Wymagania techniczne i przyszłość PHP

Gałąź 11.2.x wymaga WordPressa 7.0 lub nowszego, PHP 7.4 lub nowszego oraz MySQL 5.5.5 lub nowszego albo MariaDB 10.1 lub nowszej. Karta wtyczki wskazuje testy do WordPressa 7.1.4. Zalecane środowisko obejmuje PHP 8.3 lub nowsze i limit pamięci WordPressa wynoszący co najmniej 256 MB.

Według planu WooCommerce 11.6, przewidziane na luty 2027 r., będzie wymagać PHP 8.1. W 11.3 planowano ostrzeżenie dla sklepów na PHP 7.4 i 8.0; 11.5 ma być ostatnim wydaniem wspierającym te wersje. WordPress nie powinien automatycznie zainstalować wtyczki niespełniającej wymagań, ale działający sklep nie zostanie przez to wyłączony — brak kolejnych aktualizacji można przeoczyć.

Dobrowolne dane śledzenia wskazują około 7 procent sklepów na PHP 7.4 i 2 procent na 8.0. Nie opisują wszystkich instalacji, dlatego nie pozwalają ustalić rzeczywistego odsetka. Własną wersję sprawdzisz w WooCommerce w sekcji statusu i środowiska serwera.

Terminy i numeracja wydań

Cykl wydań trwa zwykle około pięciu tygodni i obejmuje zamrożenie zmian, wersje beta, kandydata do wydania oraz wersję stabilną. Terminy mogą się przesuwać. Wydanie 11.3 planowano na tydzień rozpoczynający się 9 listopada 2026 r., a 11.4 na grudzień.

WooCommerce stosuje schemat numeracji WordPressa, a nie klasyczną interpretację wersjonowania semantycznego. Trzeci człon oznacza wydanie poprawkowe. Zmiana pierwszego członu numeru nie oznacza automatycznie niezgodności; każdą aktualizację i tak trzeba sprawdzić z używanymi rozszerzeniami.

Wydawca wskazuje najnowszą wersję jako najbezpieczniejszą. Poprawki najpoważniejszych luk mogą trafiać do starszych gałęzi w ograniczonym zakresie, ale odkładanie aktualizacji wiąże się z ryzykiem.

Kopie i środowisko testowe

Przygotuj kompletną kopię bazy danych i plików, w tym konfiguracji i plików wymaganych przez sklep. Kopie wykonane w różnym czasie mogą nie odpowiadać temu samemu stanowi zamówień i plików: ogranicz zmiany w sklepie albo użyj rozwiązania zapewniającego spójność. Przechowuj kopię poza serwerem i sprawdź odtwarzanie na odizolowanym środowisku testowym.

Na środowisku testowym odłącz rzeczywiste płatności, wysyłki, wiadomości i inne integracje, aby nie obciążyć klientów ani nie wysłać im powiadomień. Dane osobowe ogranicz lub zanonimizuj. Sprawdź zgodność motywu, bramek i rozszerzeń z docelową wersją; informacje dewelopera o przetestowanej wersji są przydatne, lecz nie zastępują własnego testu.

Aktualizacja i przywracanie

Po pomyślnych testach zaplanuj okno serwisowe i kolejność zmian dla konkretnego sklepu, w tym wymagane aktualizacje zależności. Przed wykonaniem kopii i migracji ogranicz składanie zamówień oraz sprawdź, czy mechanizm ograniczenia działa także dla używanych integracji.

Tryb „coming soon” nie gwarantuje, że odwiedzający zobaczą katalog bez możliwości zakupu: zależnie od ustawień zastępuje stroną informacyjną całą witrynę lub strony sklepowe, w tym koszyk i kasę. Przetestuj widok niezalogowanego użytkownika i poinformuj klientów o przerwie.

Po aktualizacji plików może pojawić się polecenie aktualizacji bazy. Sklep przechodzący z 11.1.x na 11.2.1 wykona również migracje wprowadzone w 11.2.0. Monitoruj zaplanowane działania i nie uruchamiaj migracji wielokrotnie bez diagnozy.

Automatyczne aktualizacje można kontrolować w panelu wtyczek. Ich wyłączenie daje czas na testy, ale wymaga monitorowania poprawek, w tym bezpieczeństwa. Przywrócenie starszej bazy może spowodować utratę zamówień powstałych po wykonaniu kopii, a cofnięcie samych plików może pozostawić bazę w stanie niezgodnym z kodem. Zabezpiecz nowe dane i zaplanuj ich odzyskanie przed przywracaniem.

Co sprawdzić po aktualizacji

• Stronę produktu, koszyk i kasę jako gość oraz zalogowany klient.
• Pełne zamówienie testowe, płatność, wiadomości, wysyłkę i podatki, szczególnie przy ukrytych polach adresowych.
• Pobieranie plików ze starszego zamówienia oraz uprawnienia zespołu obsługi.
• Raporty na granicach dat, sumy koszyka przy kilku kuponach i wygląd kasy na tablecie.
• Dzienniki, informacje o szablonach nadpisanych przez motyw i nieudane zaplanowane działania.

Aktualizować teraz czy poczekać?

Na 11.1.x lub starszej wersji uwzględnij poprawki bezpieczeństwa z 11.2.0 i zaplanuj aktualizację po sprawdzeniu kopii oraz zgodności. Na 11.2.0 przy błędach kasy lub kodów pocztowych poprawka 11.2.1 ma bezpośrednie znaczenie.

Jeżeli kończysz okres rozliczeniowy, używasz własnych raportów lub nie masz potwierdzenia zgodności rozszerzeń, najpierw ustal zakres testów i możliwie krótki termin wdrożenia. Świadome odroczenie ma koszt: do tego czasu mogą pozostać nierozwiązane błędy i zagrożenia. Niezależnie od decyzji sprawdź PHP oraz plan przejścia na wspieraną wersję.