Błąd krytyczny w WooCommerce - jak zdiagnozować biały ekran po aktualizacji

Łukasz Palej

Technical Implementation Expert

22.07.2026

Błąd krytyczny w WooCommerce - jak zdiagnozować biały ekran po aktualizacji

Wdrażamy i obsługujemy WooCommerce

Łukasz PalejTechnical Implementation Expert

Błąd krytyczny w WooCommerce, czyli komunikat „W witrynie wystąpił błąd krytyczny” albo pusty, biały ekran po aktualizacji, to prawie zawsze błąd PHP we wtyczce, motywie lub własnym kodzie, który przestał współpracować z nową wersją WordPressa, WooCommerce albo PHP. Diagnozę zaczynasz od e-maila z linkiem do trybu awaryjnego, logu fatal-errors w WooCommerce i pliku debug.log, a sklep przywracasz, wyłączając winny dodatek albo cofając zmianę z kopii zapasowej.

Biały ekran w sklepie to stres, bo każda minuta to klienci, którzy nie mogą dodać produktu do koszyka ani zapłacić. Dobra wiadomość jest taka, że w większości przypadków przyczynę da się znaleźć w kilkanaście minut, jeśli wiesz, gdzie patrzeć. W tym wpisie pokazujemy, skąd bierze się błąd krytyczny, gdzie WordPress i WooCommerce zapisują jego szczegóły, jak przejść przez diagnozę krok po kroku i jak ograniczyć ryzyko, że kolejna aktualizacja znowu wyłączy sklep.

[#wazne] W skrócie: błąd krytyczny w WooCommerce to błąd PHP, który przerywa ładowanie strony. Od WordPressa 5.2 zamiast samego białego ekranu działa tryb awaryjny: administrator dostaje e-mail z linkiem, po którym loguje się do panelu z wstrzymaną wadliwą wtyczką lub motywem. Szczegóły błędu znajdziesz w logu fatal-errors WooCommerce i w pliku debug.log. W Vinson budujemy i rozwijamy sklepy na WooCommerce oraz integrujemy je z Allegro i Base, a aktualizacje robimy po testach na kopii sklepu.

Czym jest błąd krytyczny w WooCommerce

Błąd krytyczny (fatal error) to błąd PHP, po którym serwer przerywa generowanie strony. Kod nie może iść dalej, bo np. wywołuje funkcję, której już nie ma, odwołuje się do klasy z innej wersji wtyczki albo przekracza limit pamięci. Dawniej kończyło się to pustą stroną, nazywaną białym ekranem śmierci (White Screen of Death). Dziś WordPress zwykle pokazuje odwiedzającym komunikat „W witrynie wystąpił błąd krytyczny.” z odnośnikiem do porad, a w tle uruchamia mechanizm ochrony przed takimi błędami.

Według dokumentacji WordPressa tryb awaryjny (Recovery Mode) został wprowadzony w wersji 5.2. Włącza się automatycznie, gdy WordPress wykryje błąd krytyczny PHP podczas zwykłego ładowania strony. Nie zadziała przy błędach w zadaniach cron i innych procesach w tle. Wtedy na stronie widać komunikat o problemach technicznych, a na adres e-mail administratora trafia wiadomość ze szczegółami błędu i specjalnym odnośnikiem do logowania.

Najczęstsze przyczyny białego ekranu po aktualizacji

Błąd krytyczny rzadko pojawia się bez powodu. Najczęściej poprzedza go jakaś zmiana w sklepie lub na serwerze. Gdy pojawia się po aktualizacji, przyczyna zwykle leży w jednym z tych obszarów:

Wtyczka niezgodna z nową wersją WooCommerce - dodatek korzysta z funkcji lub klas, które w nowej wersji zmieniły się albo zniknęły.
Motyw z własnym kodem - kod w pliku functions.php albo nadpisane szablony WooCommerce, które nie nadążają za zmianami.
Zmiana wersji PHP na serwerze - hosting podniósł PHP, a starsza wtyczka używa składni, która w nowej wersji nie działa.
Przerwana aktualizacja - część plików wtyczki zdążyła się podmienić, a część nie, np. przez limit czasu na serwerze.
Brak pamięci - nowa wersja dodatku potrzebuje więcej pamięci, niż pozwala limit ustawiony dla WordPressa.
Własny fragment kodu - snippet dodany kiedyś „na szybko”, który odwołuje się do funkcji usuniętej w nowej wersji.

Dlatego pierwsze pytanie przy białym ekranie brzmi: co zmieniło się w sklepie w ostatnich godzinach? Zapisz, które wtyczki, motyw lub wersję PHP aktualizowano, kto to zrobił i o której. Sprawdź też, czy hosting nie przeprowadzał prac na serwerze. Taka notatka często skraca diagnozę do kilku minut, bo od razu wskazuje podejrzanego.

Gdzie szukać przyczyny błędu krytycznego w WooCommerce

Komunikat na ekranie niewiele mówi o przyczynie. Konkrety, czyli nazwę pliku, numer linii i wtyczkę, z której pochodzi błąd, znajdziesz w kilku miejscach. Warto znać je wszystkie, bo w zależności od sytuacji nie każde będzie dostępne:

[#chart:woo74a]

Najszybszym źródłem jest zwykle e-mail z trybu awaryjnego, ale nie zawsze dociera. Dokumentacja WordPressa wyjaśnia, że wtyczki ładują się w ustalonej kolejności. Jeśli sklep wysyła e-maile przez wtyczkę SMTP, a błąd pojawi się, zanim ta wtyczka się załaduje, wiadomość wyjdzie bezpośrednio z serwera. Gdy serwer nie ma poprawnie skonfigurowanej poczty, e-mail może trafić do spamu albo nie dotrzeć wcale. Dlatego przy białym ekranie zawsze sprawdź też folder spamu na adresie administratora i od razu przejdź do logów.

Bezpłatna konsultacja WooCommerce

Sprawdź potencjał swojego sklepu WooCommerce

Przegląd sklepu, wtyczek i wydajności
Płatności, wysyłki i integracje
Plan rozwoju sklepu

Konsultację poprowadzi Łukasz Palej, Technical Implementation Expert

Zobacz szczegóły usługi →

Jak zdiagnozować biały ekran w WooCommerce krok po kroku

Diagnoza idzie najszybciej, gdy działasz według stałej kolejności, zamiast na ślepo wyłączać wtyczki. Taki schemat stosujemy przy awariach sklepów:

[#chart:woo74b]

Tryb awaryjny WordPressa - jak z niego skorzystać

Jeśli e-mail z trybu awaryjnego dotarł, dokumentacja WordPressa opisuje cztery kroki:

zaloguj się przez specjalny odnośnik z wiadomości wysłanej na adres administratora,
odszukaj w panelu komunikat wskazujący wtyczkę lub motyw, który spowodował błąd, i dezaktywuj go w sekcji wtyczek albo motywów,
jeśli błąd wynika z edytowanego kodu, np. w functions.php, popraw go przed wznowieniem pracy,
po naprawie wyjdź z trybu awaryjnego przyciskiem „Wyjdź z trybu awaryjnego” na pasku administracyjnym i sprawdź, czy strona działa.

Pamiętaj, że w trybie awaryjnym wadliwy dodatek jest wstrzymany tylko w Twojej sesji administratora. Klienci nadal widzą błąd, dopóki nie dezaktywujesz wtyczki lub nie naprawisz kodu. Dokumentacja wprost nazywa dezaktywację rozwiązaniem tymczasowym, które pozwala szybko przywrócić stronę, ale nie usuwa przyczyny.

Włączenie trybu debugowania w wp-config.php

Gdy e-mail nie dotarł, sięgnij po tryb debugowania WordPressa. Dokumentacja dla administratorów zaleca zestaw stałych w pliku wp-config.php, dodanych przed linią kończącą edycję pliku: WP_DEBUG ustawione na true włącza tryb debugowania, WP_DEBUG_LOG ustawione na true zapisuje błędy do pliku debug.log w katalogu wp-content, a WP_DEBUG_DISPLAY ustawione na false ukrywa komunikaty przed odwiedzającymi. Dzięki temu widzisz błędy w pliku, a klienci nie oglądają ścieżek z serwera na stronie sklepu.

[#uwaga] Dokumentacja WordPressa nie zaleca używania WP_DEBUG i innych narzędzi diagnostycznych na działających stronach. Jeśli musisz włączyć logowanie na produkcji, rób to na krótko, z wyłączonym wyświetlaniem błędów, a po diagnozie przywróć wartości false i usuń plik debug.log. Przed każdą zmianą w wp-config.php zrób kopię tego pliku.

Log fatal-errors w WooCommerce

WooCommerce prowadzi własny dziennik błędów krytycznych. Znajdziesz go w panelu w menu WooCommerce, w zakładce Status, w sekcji logów (Logs), wybierając plik fatal-errors z listy plików. Według dokumentacji WooCommerce log zapisuje błędy krytyczne PHP, błędy czasu wykonania i błędy celowo wywołane w kodzie, a każdy wpis zawiera czas, treść błędu, plik i linię oraz ślad wywołań (stack trace). Nie obejmuje natomiast błędów serwera WWW, takich jak przekroczenie czasu odpowiedzi.

Ślad wywołań to dla diagnozy najcenniejsza część. Ścieżka w rodzaju wp-content/plugins/nazwa-wtyczki od razu wskazuje winowajcę. Jeśli logu WooCommerce nie da się otworzyć, bo panel nie działa, dokumentacja podpowiada szukanie pliku error.log na serwerze, np. w katalogu public_html, albo pliku debug.log w wp-content, gdy włączone jest debugowanie.

Gdy nie masz dostępu do panelu

Jeśli panel administracyjny też pokazuje błąd, a e-mail nie dotarł, wtyczkę można wyłączyć z poziomu plików. Dokumentacja WordPressa opisuje tymczasowe wyłączenie wtyczki przez zmianę nazwy jej folderu w katalogu wp-content/plugins, przez FTP lub menedżer plików w panelu hostingu. WordPress nie znajdzie wtedy wtyczki i ją dezaktywuje. Po naprawie przywróć oryginalną nazwę folderu i włącz wtyczkę ponownie w panelu. Gdy nie masz dostępu do plików, zgłoś się do wsparcia hostingu.

Test konfliktów wtyczek i motywu w WooCommerce

Czasem log wskazuje na WooCommerce, choć prawdziwą przyczyną jest inna wtyczka, która wywołuje jego funkcje w niewłaściwy sposób. Wtedy pomaga test konfliktów. Dokumentacja WooCommerce zaleca go robić na kopii sklepu lub po zrobieniu kopii zapasowej, w takiej kolejności: aktualizacja wszystkich wtyczek i motywu, przełączenie na domyślny motyw, np. Twenty Twenty-Five lub Storefront, dezaktywacja wszystkich wtyczek poza WooCommerce i rozszerzeniami, których dotyczy problem, a potem włączanie ich po jednej, aż błąd wróci.

Dokumentacja przypomina też o dwóch pułapkach. Pierwsza to wtyczki typu must-use i drop-iny, których nie wyłączysz zwykłym przyciskiem, a które często instaluje hosting, np. do pamięci podręcznej. Druga to pamięć przeglądarki, która potrafi pokazywać starą wersję strony. Na czas testów wyłącz pamięć podręczną w narzędziach deweloperskich przeglądarki. Do testów bez wpływu na klientów służy też wtyczka Health Check & Troubleshooting z repozytorium wordpress.org, której tryb rozwiązywania problemów wyłącza wtyczki i przełącza motyw tylko dla zalogowanego użytkownika. Przed instalacją sprawdź jednak w repozytorium, czy jest zgodna z Twoją wersją WordPressa, bo jej ostatnia aktualizacja jest sprzed lat.

Wyniki diagnozy warto zestawić z typowymi objawami. Poniższa tabela pomaga szybko zawęzić poszukiwania:

Objaw	Prawdopodobna przyczyna	Pierwszy krok
Błąd na całej stronie zaraz po aktualizacji wtyczki	Niezgodność tej wtyczki z WooCommerce lub PHP	Tryb awaryjny lub zmiana nazwy folderu wtyczki
Błąd tylko w koszyku lub zamówieniu	Wtyczka płatności, wysyłki lub nadpisany szablon	Log fatal-errors i sekcja szablonów w raporcie systemowym
Błąd po zmianie wersji PHP	Przestarzała wtyczka lub motyw	Powrót do poprzedniej wersji PHP i test na kopii
Biały ekran bez komunikatu i bez e-maila	Błąd przed załadowaniem WordPressa lub wyłączone wyświetlanie	Plik error.log na serwerze i debug.log
Błąd tylko w panelu administracyjnym	Wtyczka działająca wyłącznie w panelu	Test konfliktów na kopii sklepu

Jak przywrócić sklep WooCommerce po błędzie krytycznym

Kiedy wiesz już, co jest przyczyną, masz zwykle trzy drogi. Pierwsza to pozostawienie wadliwej wtyczki wyłączonej i zgłoszenie błędu autorowi, jeśli sklep może przez chwilę działać bez niej. Druga to powrót do poprzedniej wersji wtyczki, sprawdzonej na kopii sklepu. Trzecia to przywrócenie całego sklepu z kopii zapasowej sprzed aktualizacji. Najczęstsze sytuacje i rozwiązania:

[#chart:woo74c]

Przy przywracaniu kopii zapasowej pamiętaj o zamówieniach. Jeśli sklep działał częściowo, np. błąd dotyczył tylko panelu, a klienci w tym czasie składali zamówienia, przywrócenie starej bazy danych je usunie. W takiej sytuacji lepiej przywrócić tylko pliki wtyczki albo motywu, a bazę zostawić. Po każdej naprawie złóż zamówienie testowe i sprawdź płatność, e-maile oraz synchronizację z Base czy Allegro.

Jak zapobiegać błędom krytycznym po aktualizacji WooCommerce

Większości błędów krytycznych da się uniknąć dzięki kilku nawykom, które stosujemy w sklepach klientów:

aktualizuj najpierw na kopii sklepu (staging), a dopiero potem na stronie z klientami,
przed każdą aktualizacją zrób kopię zapasową plików i bazy danych i upewnij się, że da się ją przywrócić,
aktualizuj wtyczki pojedynczo, a nie wszystkie naraz, żeby wiedzieć, która zmiana wywołała problem,
czytaj listę zmian przy dużych wersjach WooCommerce i wtyczek płatności,
sprawdzaj w raporcie systemowym WooCommerce sekcję szablonów, która oznacza przestarzałe szablony nadpisane w motywie,
przed zmianą wersji PHP przetestuj sklep na kopii z nową wersją,
aktualizuj w godzinach małego ruchu, gdy ktoś może od razu zareagować.

Raport systemowy otworzysz w menu WooCommerce, w zakładce Status. Przycisk „Pobierz raport systemowy” pozwala skopiować go i przekazać wsparciu technicznemu, co skraca rozmowę o tym, jakie wersje WordPressa, PHP i wtyczek działają w sklepie. Szerzej o aktualizacjach, kopiach i uprawnieniach piszemy w liście kontrolnej, jak zabezpieczyć sklep WooCommerce na WordPressie. Jeśli błędy wynikają z ograniczeń serwera, np. limitu pamięci, przyda się też tekst o tym, jaki hosting dla WooCommerce wybrać.

Jak Vinson pomaga, gdy w WooCommerce pojawia się błąd krytyczny

W Vinson budujemy i rozwijamy sklepy na WooCommerce oraz integrujemy je z Allegro i Base. Przy awariach liczy się czas, dlatego działamy według sprawdzonej procedury, a potem usuwamy przyczynę, żeby błąd nie wrócił przy następnej aktualizacji. W praktyce:

diagnozujemy błąd krytyczny na podstawie logów WooCommerce, debug.log i logów serwera,
przywracamy działanie sklepu bez utraty zamówień złożonych w międzyczasie,
poprawiamy niezgodny kod w motywie lub zastępujemy porzucone wtyczki,
ustawiamy proces aktualizacji z kopią zapasową i testami na stagingu.

Więcej o naszej pracy przy sklepach przeczytasz na stronie sklepy na WooCommerce z Vinson.

Najczęściej zadawane pytania

Co oznacza komunikat „W witrynie wystąpił błąd krytyczny”?

To informacja, że podczas ładowania strony wystąpił błąd PHP, który przerwał jej generowanie. Najczęściej powoduje go wtyczka, motyw lub własny kod niezgodny z nową wersją WordPressa, WooCommerce albo PHP. Szczegóły błędu znajdziesz w e-mailu wysłanym do administratora i w logach.

Jak naprawić biały ekran w WooCommerce?

Sprawdź e-mail z trybem awaryjnym i zaloguj się przez odnośnik, a potem dezaktywuj wskazaną wtyczkę lub motyw. Jeśli e-maila nie ma, odczytaj log fatal-errors WooCommerce, debug.log albo error.log na serwerze. W ostateczności wyłącz wtyczkę, zmieniając nazwę jej folderu przez FTP.

Nie dostałem e-maila o trybie awaryjnym. Co teraz?

Sprawdź folder spamu na adresie administratora, bo e-mail mógł zostać wysłany bezpośrednio z serwera. Jeśli go nie ma, włącz zapis błędów do debug.log w wp-config.php lub poszukaj error.log na serwerze. Pomóc może też wsparcie techniczne hostingu.

Gdzie znajdę logi błędów w WooCommerce?

W panelu w menu WooCommerce, w zakładce Status, w sekcji logów, gdzie wybierasz plik fatal-errors. Log zawiera czas błędu, plik, linię i ślad wywołań. Nie zapisuje błędów serwera WWW, takich jak przekroczenie czasu odpowiedzi, więc te sprawdzisz w logach hostingu.

Czy włączenie WP_DEBUG na sklepie jest bezpieczne?

Dokumentacja WordPressa nie zaleca używania narzędzi debugowania na działających stronach. Jeśli to konieczne, włącz zapis do pliku z wyłączonym wyświetlaniem błędów, czyli WP_DEBUG_DISPLAY ustawionym na false. Po diagnozie wyłącz debugowanie i usuń plik debug.log.

Błąd krytyczny w WooCommerce wygląda groźnie, ale z logami w ręku zwykle szybko prowadzi do konkretnej wtyczki lub fragmentu kodu. Jeśli chcesz, żeby aktualizacje w Twoim sklepie przechodziły bez białych ekranów i nerwowych poranków, sprawdź sklep na WooCommerce z Vinson.