Błąd „Call to a member function get_cart() on null” w WooCommerce może całkowicie przerywać generowanie feedów produktowych, zadania WP-Cron oraz wybrane integracje REST API, ERP i marketplace. Problem występuje, gdy kod obliczający podatek od dostawy próbuje odczytać zawartość koszyka, mimo że w danym kontekście WooCommerce nie utworzył obiektu koszyka.
W potwierdzonym zgłoszeniu dotyczącym WooCommerce 11.2.1 wskazano błąd w pliku class-wc-tax.php, przy wywołaniu metody WC_Tax::get_shipping_tax_rates(). Awaria może pojawić się nawet wtedy, gdy sklep działa prawidłowo dla klientów, a standardowy koszyk i checkout nie zgłaszają żadnych problemów.
Najważniejszą konsekwencją jest możliwość zatrzymania procesów działających w tle. Jeżeli generator feedu nie kończy pracy, dane wysyłane do Google Merchant Center lub marketplace mogą przestać się aktualizować. W rezultacie sklep może przekazywać nieaktualne informacje o produktach, ich dostępności i kosztach dostawy, mimo że dane w samym WooCommerce pozostają poprawne.
Rozwiązaniem tymczasowym dla programistów integracji może być jawne przekazanie właściwej klasy podatkowej lub prawidłowe zainicjowanie wymaganych obiektów WooCommerce. Zgłoszono również zmianę w kodzie WooCommerce eliminującą odwołanie do nieistniejącego koszyka. Przed zastosowaniem poprawki należy jednak sprawdzić jej status i zgodność z używaną wersją sklepu.
Co oznacza „Call to a member function get_cart() on null” w WooCommerce?
Komunikat Call to a member function get_cart() on null oznacza, że kod PHP próbuje wywołać metodę get_cart() na zmiennej, która nie zawiera obiektu koszyka, lecz wartość null.
W zgłoszonym przypadku pełny komunikat wygląda następująco:
Error: Call to a member function get_cart() on null
in wp-content/plugins/woocommerce/includes/class-wc-tax.php:658Błąd występuje w kodzie odpowiedzialnym za obliczanie podatków, a nie bezpośrednio w systemie przechowywania zamówień czy bazie danych.
WooCommerce udostępnia globalny obiekt, za pośrednictwem którego inne komponenty mogą korzystać między innymi z koszyka:
WC()->cartW standardowym procesie zakupowym obiekt ten zawiera dane koszyka klienta. W przypadku wybranych zadań wykonywanych w tle może jednak nie zostać zainicjowany.
Jeśli kod wywołuje:
WC()->cart->get_cart()bez uprzedniego sprawdzenia, czy WC()->cart jest rzeczywiście obiektem, może dojść do nieobsłużonego wyjątku PHP. Taki błąd przerywa bieżące wykonanie skryptu.
Nie oznacza to automatycznie uszkodzenia całego sklepu. Jego wpływ zależy od tego, który proces uruchomił problematyczną funkcję.
WooCommerce 11.2.1 – potwierdzony błąd podczas obliczania podatku od wysyłki
26 października 2026 roku w oficjalnym repozytorium WooCommerce na GitHubie utworzono zgłoszenie numer 70253 dotyczące awarii metody WC_Tax::get_shipping_tax_rates() w kontekstach, w których koszyk nie istnieje.
Autor opisał rzeczywistą sytuację ze sklepu produkcyjnego, w którym dedykowany generator feedów produktowych obliczał koszty wysyłki i związane z nimi podatki. Zadanie uruchamiane przez WP-Cron kończyło się krytycznym błędem PHP.
Problem został odtworzony również bez dodatkowych wtyczek i bez niestandardowego motywu.
Konfiguracja środowiska zgłoszonego przez użytkownika:
- WooCommerce: 11.2.1
- WordPress: 7.1
- PHP: 8.5.3
- Dodatkowy test PHP: 8.3.30
- HPOS: włączony
- Problem: błąd krytyczny podczas obliczania podatku od dostawy poza sesją kupującego
Zespół WooCommerce potwierdził zgłoszenie i nadał mu priorytet High. Uzasadnieniem była możliwość całkowitego zatrzymania integracji, która korzysta z problematycznej metody w określonych warunkach.
Nie jest to jednak nowa awaria wprowadzona dopiero w WooCommerce 11.2.1. Autor ustalił, że problematyczne odwołanie do koszyka istniało również we wcześniejszym kodzie, a refaktoryzacja z lipca 2025 roku nie wyeliminowała braku odpowiedniego zabezpieczenia.
Nie można zatem wskazać WooCommerce 11.2.1 jako jedynej wersji dotkniętej błędem. Jest to wersja, na której problem został jednoznacznie udokumentowany i odtworzony.
Dlaczego WC_Tax::get_shipping_tax_rates() powoduje PHP Fatal Error?
Metoda WC_Tax::get_shipping_tax_rates() odpowiada za uzyskanie stawek podatkowych stosowanych do kosztów dostawy.
Przy jej wywołaniu można przekazać klasę podatkową. Jeżeli klasa nie zostanie podana, a ustawienia sklepu przewidują dziedziczenie klasy podatkowej od produktów w koszyku, WooCommerce próbuje ustalić odpowiednią klasę na podstawie zawartości koszyka.
Odpowiada za to pomocnicza metoda:
get_shipping_tax_class_from_cart_items()W kodzie WooCommerce 11.2.1 występuje następujący fragment:
private static function get_shipping_tax_class_from_cart_items() {
$standard_tax_class = '';
$cart = WC()->cart;
if ( ! $cart->get_cart() ) {
return $standard_tax_class;
}
}Fragment przedstawia istotną dla błędu część metody, bez jej dalszej logiki.
Problem znajduje się w instrukcji:
if ( ! $cart->get_cart() )Kod zakłada, że zmienna $cart zawsze zawiera obiekt WooCommerce Cart. W rzeczywistości podczas określonych wywołań WP-Cron, REST API i zapytań administracyjnych jej wartością może być null.
PHP nie może wywołać metody obiektu, który nie istnieje. Z tego powodu wykonanie funkcji kończy się błędem krytycznym.
Dlaczego koszyk nie zawsze jest dostępny?
WooCommerce nie inicjalizuje wszystkich komponentów systemu podczas każdego żądania HTTP. Standardowy koszyk jest przede wszystkim elementem procesu zakupowego obsługiwanego w kontekście klienta.
Zadania uruchamiane przez WP-Cron, indywidualne integracje REST API oraz niektóre operacje administracyjne mogą działać bez aktywnej sesji zakupowej.
Przykładowo generator feedu produktowego nie musi znać zawartości koszyka konkretnego klienta. Potrzebuje natomiast informacji o produkcie, kosztach dostawy i odpowiednich stawkach podatkowych.
Jeśli taki generator wywoła funkcję zakładającą istnienie koszyka, może uruchomić błąd, mimo że nie jest wykonywana żadna operacja związana z zakupem.
W jakich warunkach występuje błąd get_cart() on null?
Zgłoszenie wskazuje trzy istotne warunki, które muszą wystąpić w opisywanej ścieżce wykonania.
1. WooCommerce ma włączone obliczanie podatków
Sklep korzysta z mechanizmu podatkowego WooCommerce, a integracja wykonuje obliczenia dotyczące stawek podatku od wysyłki.
2. Klasa podatkowa dostawy jest dziedziczona z produktów koszyka
W ustawieniach WooCommerce opcja Shipping tax class ma wartość:
Shipping tax class based on cart itemsOdpowiada jej wewnętrzna wartość konfiguracji:
inheritJest to standardowy sposób ustalania klasy podatkowej wysyłki na podstawie produktów znajdujących się w koszyku.
3. Funkcja zostaje wywołana bez klasy podatkowej i bez aktywnego koszyka
Problematyczne wywołanie wygląda następująco:
WC_Tax::get_shipping_tax_rates();W kontekście, w którym WC()->cart jest wartością null, takie wywołanie może doprowadzić do błędu krytycznego.
Ważne jest rozróżnienie braku koszyka od pustego koszyka. Pusty koszyk jest prawidłowym obiektem, który nie zawiera produktów. Brak koszyka oznacza, że sam obiekt nie został zainicjowany.
To właśnie ta druga sytuacja nie była odpowiednio zabezpieczona w zgłoszonym fragmencie kodu.
Które integracje WooCommerce mogą przestać działać przez ten błąd?
Problem może wystąpić w różnych rozwiązaniach, które wykonują obliczenia podatkowe poza standardowym procesem zakupowym.
Generatory feedów produktowych
Właściciel sklepu może korzystać z wtyczki generującej feed XML, CSV lub inne źródło danych dla Google Merchant Center, porównywarek cenowych i marketplace.
Jeżeli podczas generowania feedu wtyczka oblicza podatek od dostawy przy użyciu WC_Tax::get_shipping_tax_rates(), zadanie może zakończyć się błędem PHP.
Skutkiem może być brak nowej wersji pliku, niedostępny adres feedu lub przerwana aktualizacja informacji produktowych.
Jeżeli Merchant Center nadal korzysta z wcześniejszego pliku, może pojawić się rozbieżność między bieżącą ofertą sklepu a danymi przekazywanymi do Google. Takie sytuacje wymagają sprawdzenia zgodności cen i dostępności, co opisuje również artykuł o tym, dlaczego Google Merchant Center odrzuca produkty przez niezgodność danych w feedzie i sklepie.
Sama awaria generatora nie oznacza automatycznie odrzucenia produktów. Znaczenie ma sposób, w jaki integracja zapisuje plik oraz jak długo i z jakiego źródła Google pobiera dane.
Integracje ERP i systemów magazynowych
System ERP może pobierać informacje o produktach, podatkach i kosztach dostawy niezależnie od aktywności użytkowników sklepu.
Jeżeli integracja korzysta z problematycznej metody, może przestać wykonywać określone obliczenia, synchronizować wybrane dane albo zakończyć całą operację błędem.
Nie oznacza to, że wszystkie integracje ERP korzystające z WooCommerce są zagrożone. Problem dotyczy tych, które rzeczywiście wywołują wskazaną funkcję w warunkach braku aktywnego koszyka.
Integracje marketplace
Zewnętrzna platforma handlowa może wymagać określenia ceny produktu wraz z podatkiem i kosztami wysyłki dla danego kraju.
Wtyczka integracyjna może próbować samodzielnie obliczyć odpowiednie stawki bez tworzenia sesji kupującego. Jeśli obliczenie uruchamia nieprawidłową ścieżkę WooCommerce, synchronizacja może zostać przerwana.
Dedykowane endpointy REST API
Problem może również dotyczyć indywidualnych endpointów REST API wykorzystujących WooCommerce do obliczania stawek dostawy.
Przykładem jest aplikacja, która na podstawie identyfikatora produktu, kraju dostawy i klasy podatkowej próbuje obliczyć pełny koszt zamówienia.
Jeżeli endpoint uruchamia funkcję wymagającą koszyka, ale nie przekazuje odpowiednich danych, serwer może zwrócić błąd HTTP 500.
Należy odróżnić takie niestandardowe wywołania od standardowego WooCommerce Store API, które według analizy zespołu WooCommerce nie jest objęte tym konkretnym problemem.
WP-Cron i zadania działające w tle
Błąd może występować w zadaniach uruchamianych automatycznie, bez udziału administratora i bez aktywnego klienta.
W praktyce sklep może działać poprawnie przez cały dzień, a problem pojawiać się wyłącznie podczas zaplanowanego generowania pliku lub synchronizacji danych.
To szczególnie niebezpieczne, gdy administrator nie monitoruje wyników zadań i przez kilka dni nie zauważa, że informacje produktowe przestały być aktualizowane.
Jak zdiagnozować „Call to a member function get_cart() on null” w WooCommerce?
Sprawdź logi błędów WooCommerce
Otwórz panel WordPress i przejdź do WooCommerce → Status → Logs. Wybierz dziennik błędów krytycznych lub log odpowiadający integracji, która przestała działać.
Wyszukaj komunikat:
Call to a member function get_cart() on nullSprawdź, czy ścieżka błędu prowadzi do:
wp-content/plugins/woocommerce/includes/class-wc-tax.phpSzczególnie istotna jest obecność funkcji:
get_shipping_tax_class_from_cart_items()oraz:
WC_Tax::get_shipping_tax_rates()Jeżeli stack trace wskazuje te metody, istnieje mocna przesłanka, że problem odpowiada potwierdzonemu zgłoszeniu WooCommerce.
Sam tekst get_cart() on null nie jest jednak wystarczającym dowodem. Inne wtyczki mogą wywoływać podobny błąd we własnym kodzie. Dlatego należy porównywać również ścieżkę pliku i pełny stos wywołań.
Sprawdź zadania harmonogramu
Przejdź do WooCommerce → Status → Scheduled Actions i sprawdź zadania oznaczone jako Failed.
Warto zweryfikować:
- Nazwę zadania i jego identyfikator.
- Datę ostatniego poprawnego wykonania.
- Datę wystąpienia pierwszego błędu.
- Komunikaty zapisane przez harmonogram.
- Powiązanie zadania z generatorem feedu lub integracją zewnętrzną.
Nie wszystkie zadania WP-Cron są widoczne w harmonogramie Action Scheduler. Jeżeli integracja korzysta ze zwykłych zdarzeń WP-Cron lub własnego mechanizmu serwerowego, należy sprawdzić także ich logi i harmonogramy.
Nie należy wielokrotnie uruchamiać nieudanego zadania na produkcji bez ustalenia jego skutków. Niektóre integracje mogą wykonywać operacje zapisu, wysyłać dane do systemów zewnętrznych lub wywoływać powiadomienia.
Sprawdź ustawienia podatku od wysyłki
Otwórz WooCommerce → Ustawienia → Podatek i znajdź ustawienie klasy podatkowej wysyłki.
Jeżeli wybrano dziedziczenie klasy podatkowej z produktów koszyka, a problematyczna integracja nie przekazuje własnej klasy, konfiguracja odpowiada jednemu z warunków opisanego błędu.
Nie należy jednak zmieniać ustawień podatkowych wyłącznie w celu ukrycia błędu PHP. Inna klasa podatkowa może powodować nieprawidłowe rozliczenia dostaw w rzeczywistych zamówieniach.
Sprawdź ostatnie poprawne wykonanie integracji
W przypadku generatora feedów porównaj datę ostatniego udanego eksportu z datą pojawienia się błędu w logach.
Jeżeli wszystkie kolejne uruchomienia kończą się tym samym błędem, problem może całkowicie blokować bieżącą synchronizację.
Warto również sprawdzić rozmiar i datę modyfikacji pliku XML lub CSV. Plik może istnieć na serwerze, lecz zawierać nieaktualne dane, ponieważ generator nie zdołał utworzyć nowej wersji.
Jak odtworzyć błąd WooCommerce na środowisku testowym?
Autor zgłoszenia przedstawił sposób odtworzenia problemu przy użyciu WP-CLI, z wymuszonym kontekstem WP-Cron.
Test wymaga działającej instalacji WooCommerce, aktywnych podatków oraz odpowiedniej konfiguracji dziedziczenia klasy podatkowej.
Przykładowe polecenie:
wp --exec='define( "DOING_CRON", true );' eval 'var_dump( null === WC()->cart ); WC_Tax::get_shipping_tax_rates();'W środowisku z problematyczną wersją kodu oczekiwanym wynikiem jest najpierw:
bool(true)a następnie błąd:
Fatal error: Uncaught Error:
Call to a member function get_cart() on null
in includes/class-wc-tax.php:658Ten test należy wykonywać wyłącznie na kontrolowanym środowisku testowym. Nie jest przeznaczony do uruchamiania przez przypadkowych użytkowników na aktywnym sklepie produkcyjnym.
Warto też pamiętać, że zwykłe wywołanie wp eval bez wymuszenia kontekstu WP-Cron może nie odtworzyć błędu. Według autora zgłoszenia standardowy kontekst WP-CLI może doprowadzić do zainicjowania koszyka, przez co problematyczna ścieżka nie zostanie uruchomiona.
Brak błędu w zwykłym poleceniu WP-CLI nie wyklucza więc awarii zadania wykonywanego przez rzeczywisty WP-Cron.
Jak naprawić błąd get_cart() on null w WooCommerce?
Dostępne sposoby postępowania zależą od tego, czy administrator ma możliwość zmiany kodu integracji, czy korzysta z gotowej wtyczki zewnętrznej.
Rozwiązanie 1: jawne przekazanie klasy podatkowej
W zgłoszeniu WooCommerce przedstawiono tymczasowe rozwiązanie stosowane w działającym sklepie: integracja samodzielnie ustala odpowiednią klasę podatkową, a następnie przekazuje ją do funkcji obliczającej stawki podatku od dostawy.
Zamiast:
WC_Tax::get_shipping_tax_rates();kod może przekazywać odpowiednio ustaloną klasę, na przykład standardową:
WC_Tax::get_shipping_tax_rates( '' );Pusty ciąg w tym przykładzie oznacza standardową klasę podatkową WooCommerce.
Nie jest to jednak uniwersalna wartość odpowiednia dla wszystkich sklepów i wszystkich produktów. Sklep może korzystać z obniżonych stawek podatkowych, różnych klas produktów, odmiennych zasad opodatkowania dostawy oraz sprzedaży międzynarodowej.
Programista musi ustalić prawidłową klasę podatkową dla rzeczywistej operacji. Przekazanie standardowej klasy tylko po to, aby uniknąć błędu, może spowodować nieprawidłowe obliczenia podatkowe.
Rozwiązanie 2: prawidłowe zainicjowanie koszyka
Zespół WooCommerce wskazał również możliwość użycia wc_load_cart() przed obliczaniem stawek podatkowych przez metodę wysyłki.
Takie rozwiązanie wymaga jednak ostrożności. Zadania działające w tle nie zawsze posiadają kontekst sesji klienta, a inicjalizowanie koszyka może wprowadzać dodatkowe zależności.
Jeżeli operacja dotyczy feedu produktowego lub obliczenia kosztów dla określonego kraju, często właściwszym rozwiązaniem jest jawne przekazanie potrzebnych danych zamiast sztucznego tworzenia sesji zakupowej.
Nie należy również zakładać, że sama inicjalizacja koszyka dostarczy prawidłowy adres klienta, klasę podatkową lub rzeczywistą zawartość zamówienia.
Rozwiązanie 3: uwzględnienie adresu docelowego dostawy
Przy obliczaniu podatków dla zewnętrznych marketplace’ów trzeba uwzględnić nie tylko klasę podatkową produktu, ale również kraj i region dostawy.
Metoda WC_Tax::get_shipping_tax_rates() przyjmuje opcjonalny obiekt WC_Customer, który może służyć do określenia lokalizacji wykorzystywanej przy obliczeniach.
Jeżeli integracja generuje oferty dla klientów z różnych państw, powinna przekazywać odpowiednio przygotowany kontekst lokalizacji.
Bez niego WooCommerce może korzystać z ustawień lokalizacji bazowej sklepu albo innych danych wynikających z konfiguracji podatków. Zniknięcie błędu PHP nie gwarantuje więc jeszcze prawidłowej wartości podatku.
Rozwiązanie 4: sprawdzenie aktualnej wersji WooCommerce
Przed aktualizacją należy ustalić, czy poprawka zgłoszona w repozytorium została zaakceptowana, połączona z główną gałęzią kodu i opublikowana w stabilnej wersji WooCommerce.
Sam fakt utworzenia pull requestu nie oznacza, że poprawka jest dostępna w oficjalnym pakiecie instalacyjnym.
Na dzień 2 listopada 2026 roku propozycja numer 70487 pozostawała otwarta. Nie należy więc traktować jej jako potwierdzonej poprawki dostępnej we wszystkich aktualnych instalacjach.
Co zmienia poprawka WooCommerce #70487 z 1 listopada 2026 roku?
1 listopada 2026 roku opublikowano propozycję poprawki powiązaną ze zgłoszeniem numer 70253.
Zmiana dotyczy zabezpieczenia funkcji get_shipping_tax_class_from_cart_items() przed odwołaniem do nieistniejącego koszyka.
W proponowanej implementacji zastosowano następujący warunek:
if ( ! $cart instanceof WC_Cart || ! $cart->get_cart() ) {
return $standard_tax_class;
}Warunek sprawdza najpierw, czy zmienna $cart zawiera prawidłowy obiekt klasy WC_Cart.
Jeżeli koszyk nie istnieje albo jest pusty, funkcja zwraca standardową klasę podatkową zamiast próbować wywoływać metodę na wartości null.
W ten sposób brak koszyka jest obsługiwany podobnie jak istniejący, lecz pusty koszyk.
Autor poprawki poinformował o przeprowadzeniu testów jednostkowych, obejmujących między innymi 1962 testy dotyczące podatków i wysyłki oraz 7030 asercji. Zgłosił również pozytywne wyniki kontroli standardów kodowania i analizy statycznej.
Takie wyniki potwierdzają zakres testów zadeklarowanych przez autora, ale nie zastępują końcowego zatwierdzenia poprawki przez zespół projektu.
Co ważne, propozycja nie rozstrzyga wszystkich kwestii dotyczących obliczania podatku od dostawy przy braku koszyka. Nie obejmuje również automatycznie każdej potencjalnie podobnej ścieżki kodu. W zgłoszeniu technicznym wskazano także osobne odwołanie do koszyka w mechanizmie obliczania podatku dla poszczególnych pozycji wysyłki.
Nie należy więc kopiować przedstawionego fragmentu bezpośrednio do działającej instalacji. Bezpieczna aktualizacja powinna korzystać z zatwierdzonej wersji WooCommerce lub odpowiednio przetestowanej zmiany utrzymywanej przez programistę integracji.
Jak sprawdzić, czy awaria WP-Cron wpłynęła na Google Merchant Center?
Przerwanie generowania feedu może spowodować, że Google Merchant Center nie otrzyma aktualnych informacji o ofercie.
Nie zawsze oznacza to natychmiastowe odrzucenie produktów. Wiele zależy od tego, czy wcześniejsza wersja feedu pozostaje dostępna oraz czy Google korzysta także z innych mechanizmów aktualizacji danych.
Porównaj daty aktualizacji
Sprawdź godzinę ostatniego poprawnego wykonania generatora, czas modyfikacji pliku produktowego oraz datę ostatniego pobrania źródła danych w Merchant Center.
Jeżeli feed nie aktualizował się przez kilka dni, a ceny i stany magazynowe w sklepie ulegały zmianie, może występować ryzyko rozbieżności.
Sprawdź liczbę produktów
Porównaj liczbę produktów zapisanych w wygenerowanym pliku z liczbą produktów, które powinny znaleźć się w danym źródle.
Jeżeli generator przerwał pracę w połowie, mógł pozostawić niekompletny plik. Nie każda integracja zapisuje wynik atomowo, dlatego zachowanie zależy od sposobu implementacji eksportu.
Sprawdź status produktów w Merchant Center
W Google Merchant Center przejrzyj komunikaty diagnostyczne dotyczące aktualności źródła danych, cen i dostępności.
Jeśli produkty są zatwierdzone, ale ich widoczność lub wyniki reklam uległy pogorszeniu, nie należy od razu przypisywać tego awarii WP-Cron. Osobnej diagnostyki wymaga sytuacja, w której produkty mają prawidłowy status w Merchant Center, a ruch i sprzedaż z Google mimo to spadają.
Ustalenie związku przyczynowego wymaga porównania dat awarii, historii źródeł danych oraz zmian w raportach sklepu.
Czy błąd WooCommerce get_cart() on null może zniekształcić dane sprzedażowe?
Tak, jeżeli problematyczna funkcja jest wykorzystywana przez integrację, która dostarcza dane do systemu analitycznego, ERP lub hurtowni danych.
Przykładowo firma może korzystać z dedykowanego procesu, który okresowo pobiera informacje o zamówieniach, uzupełnia je o koszty dostawy i podatki, a następnie przekazuje do zewnętrznej bazy raportowej.
Jeżeli proces zakończy się błędem krytycznym przed zapisaniem danych, zewnętrzny system może nie otrzymać kompletnego zestawu informacji.
Nie oznacza to, że WooCommerce usunął zamówienia z własnej bazy. Problem może dotyczyć wyłącznie przepływu danych między sklepem a zewnętrznym narzędziem.
Dlatego w ramach analizy danych sprzedażowych należy rozróżniać rzeczywisty stan zamówień w sklepie od danych przetwarzanych przez integracje.
Warto porównywać liczbę unikalnych zamówień, ich identyfikatory, daty, statusy i wartości, zamiast opierać się wyłącznie na całkowitej kwocie przychodów prezentowanej w zewnętrznym raporcie.
Podobna zasada ma zastosowanie przy ocenie rozbieżności między konwersjami Google Analytics 4, Google Ads a zamówieniami sklepu. Brak aktualizacji danych w jednym systemie nie oznacza automatycznie, że sprzedaż rzeczywiście spadła.
Jak sprawdzić, czy WooCommerce i integracje działają prawidłowo po naprawie?
Po zastosowaniu poprawki lub zmianie sposobu wywoływania funkcji podatkowej należy zweryfikować nie tylko brak błędu PHP, ale także poprawność całego procesu.
Kontrola powinna obejmować:
- Ponowne uruchomienie problematycznego zadania w bezpiecznym środowisku testowym.
- Potwierdzenie, że wywołanie
WC_Tax::get_shipping_tax_rates()nie powoduje błędu przy braku koszyka. - Sprawdzenie poprawności obliczanych stawek podatku od wysyłki.
- Porównanie wyników dla różnych klas podatkowych.
- Sprawdzenie obliczeń dla odpowiednich krajów i regionów dostawy.
- Wygenerowanie kompletnego feedu produktowego.
- Porównanie liczby produktów przed naprawą i po niej.
- Sprawdzenie wyników synchronizacji ERP lub marketplace.
- Kontrolę logów WooCommerce i harmonogramu WP-Cron.
- Przeprowadzenie testowego zakupu, aby upewnić się, że standardowy checkout nadal działa prawidłowo.
Jeżeli poprawka eliminuje błąd krytyczny, ale powoduje naliczanie niewłaściwych podatków, nie można uznać problemu za rozwiązany.
Równie ważne jest sprawdzenie, czy integracja nie ponawia wcześniej wykonanych operacji w sposób prowadzący do duplikowania danych. Dotyczy to szczególnie procesów zapisujących zamówienia, dokumenty, stany magazynowe lub wartości sprzedaży w systemach zewnętrznych.
Najczęściej zadawane pytania o WooCommerce get_cart() on null
Co oznacza „Call to a member function get_cart() on null”?
Komunikat oznacza, że kod PHP próbuje pobrać zawartość koszyka, mimo że zmienna przeznaczona na obiekt koszyka ma wartość null. W potwierdzonym zgłoszeniu WooCommerce błąd występuje w metodzie służącej do ustalania klasy podatkowej dostawy.
Czy błąd get_cart() on null może zatrzymać WP-Cron?
Może przerwać wykonanie zadania, które uruchamia problematyczną funkcję. Nie oznacza to jednak, że wszystkie zadania WP-Cron lub cały mechanizm harmonogramu WordPressa przestaną działać.
Czy problem dotyczy WooCommerce 11.2.1?
Tak. Błąd został odtworzony w WooCommerce 11.2.1. Autor zgłoszenia wskazał również, że problematyczny kod istniał wcześniej, dlatego nie należy ograniczać diagnostyki wyłącznie do tej wersji.
Czy PHP 8.5 jest przyczyną błędu?
Nie ma podstaw do takiego wniosku. Problem odtworzono na PHP 8.5.3 oraz 8.3.30. Przyczyną jest brak odpowiedniej kontroli istnienia obiektu koszyka, a nie udokumentowana niezgodność wyłącznie z jedną wersją PHP.
Czy wyłączenie HPOS naprawi błąd?
Nie ma potwierdzenia, że wyłączenie HPOS rozwiązuje ten problem. Zgłoszenie dotyczy mechanizmu obliczania podatków od dostawy, a nie sposobu przechowywania zamówień. Nie należy zmieniać ustawień HPOS bez odrębnej przyczyny diagnostycznej.
Dlaczego standardowy checkout działa, a feed produktowy nie?
Standardowy proces zakupowy dysponuje kontekstem koszyka klienta. Generator feedu uruchamiany przez WP-Cron może działać bez tego obiektu. Jeżeli integracja wywołuje funkcję zakładającą obecność koszyka, może zakończyć pracę błędem krytycznym.
Czy zmiana klasy podatkowej wysyłki rozwiąże problem?
Zmiana sposobu ustalania klasy podatkowej może ominąć konkretną ścieżkę błędu, ale nie oznacza naprawy jego przyczyny. Ponieważ ustawienia te wpływają na rzeczywiste obliczenia podatków, nie powinny być modyfikowane bez oceny konsekwencji podatkowych i technicznych.
Czy można użyć wc_load_cart() w zadaniu WP-Cron?
WooCommerce wskazał inicjalizację koszyka jako jedną z możliwych metod obejścia problemu. Jej zastosowanie powinno jednak zależeć od kontekstu konkretnej integracji i wymaga testów. Zadania działające bez sesji klienta często powinny korzystać z jawnie przekazanych danych podatkowych.
Czy poprawka WooCommerce #70487 jest już dostępna?
2 listopada 2026 roku propozycja poprawki pozostawała otwarta w repozytorium WooCommerce. Przed aktualizacją należy sprawdzić jej aktualny stan i informacje o zmianach w oficjalnych wydaniach.
Czy błąd oznacza utratę zamówień WooCommerce?
Nie ma podstaw, aby uznać ten problem za automatyczne usuwanie zamówień ze sklepu. Potwierdzony przypadek dotyczy awarii obliczania podatku od wysyłki. Jeżeli integracja odpowiedzialna za przesyłanie zamówień do zewnętrznego systemu korzysta z problematycznej metody, może przerwać synchronizację i doprowadzić do niekompletnych danych poza WooCommerce.
WooCommerce powinien obsługiwać obliczanie podatków również bez aktywnego koszyka
Błąd Call to a member function get_cart() on null pokazuje, że funkcje WooCommerce wykorzystywane przez integracje nie zawsze są bezpieczne do wywoływania w dowolnym kontekście.
W potwierdzonym przypadku metoda WC_Tax::get_shipping_tax_rates() próbuje ustalić klasę podatkową dostawy na podstawie produktów w koszyku, mimo że wywołanie następuje podczas zadania, w którym koszyk nie został zainicjowany.
Skutkiem może być przerwanie generowania feedów, działania dedykowanych endpointów REST API oraz określonych procesów integracyjnych ERP i marketplace. Problem nie musi być widoczny podczas zwykłych zakupów, dlatego jego wykrycie wymaga kontroli logów i procesów działających w tle.
Tymczasowe rozwiązania obejmują prawidłowe przekazywanie klasy podatkowej i danych lokalizacji albo odpowiednio uzasadnione inicjalizowanie wymaganych komponentów. Docelowa poprawka powinna eliminować możliwość wywołania metody na nieistniejącym obiekcie, bez niezamierzonej zmiany zasad opodatkowania.
Po naprawie należy zweryfikować zarówno poprawne działanie kodu, jak i kompletność danych przekazywanych do systemów zewnętrznych. Brak błędów PHP jest ważnym warunkiem, ale dopiero prawidłowe wyliczenia podatkowe i zakończona synchronizacja potwierdzają przywrócenie działania konkretnej integracji.