Jak czytać logi błędów WordPress i WooCommerce

Wchodzisz na stronę i widzisz białą, pustą kartkę. Albo komunikat „Wystąpił błąd krytyczny na tej witrynie”. Albo w sklepie WooCommerce klient pisze, że przy próbie zapłaty widzi „coś poszło nie tak” i nie może dokończyć zamówienia. Nie wiesz, co się stało. Nic nie zmieniałeś – a przynajmniej tak Ci się wydaje. Dzwonisz do informatyka albo otwierasz panel hostingu i nie masz pojęcia, od czego zacząć.

W takiej sytuacji pierwszym miejscem, do którego warto zajrzeć, nie jest wtyczka, nie jest motyw i nie jest telefon do supportu hostingu. Pierwszym miejscem są logi błędów. To zapis tego, co dokładnie działo się na serwerze w momencie awarii – z dokładnością do pliku, linii kodu i typu błędu. W tym artykule pokazujemy, jak włączyć logowanie błędów w WordPressie, gdzie fizycznie znaleźć plik z logami, jak odróżnić logi WooCommerce od logów samego WordPressa i jak czytać pojedynczy wpis błędu, żeby wiedzieć, co robić dalej.

Dlaczego logi to pierwsze miejsce, w które warto zajrzeć

Biały ekran śmierci WordPress to nazwa, która przyjęła się dla sytuacji, w której strona przestaje się wyświetlać całkowicie – zamiast treści widzisz pustą, białą stronę. Czasem towarzyszy jej krótki komunikat, czasem nie ma nic. To najbardziej frustrujący rodzaj błędu, bo z poziomu przeglądarki nie masz żadnej wskazówki, co poszło nie tak. Strona po prostu milczy.

Błąd 500 działa podobnie. Serwer informuje, że coś się nie powiodło, ale nie mówi co. To komunikat na poziomie protokołu HTTP, nie na poziomie aplikacji. WordPress i przeglądarka nie pokażą Ci szczegółów, bo domyślnie są one ukryte – i słusznie, bo pokazywanie surowych błędów PHP wszystkim odwiedzającym byłoby ryzykiem bezpieczeństwa.

Logi błędów to miejsce, gdzie te szczegóły są zapisywane, nawet jeśli na stronie ich nie widać. Zamiast zgadywać, która wtyczka namieszała, albo próbować włączać i wyłączać funkcje po kolei, sprawdzasz log i widzisz dokładnie, który plik, która linia kodu i jaki typ błędu spowodował awarię. To oszczędza godziny prób i błędów. Diagnostyka bez logów przypomina szukanie usterki w samochodzie z zamkniętą maską – można zgadywać, ale szybciej jest po prostu zajrzeć do środka.

Jak włączyć debug log w WordPressie

WordPress ma wbudowany system rejestrowania błędów, tylko domyślnie jest wyłączony na stronach produkcyjnych – i to jest prawidłowe ustawienie dla działającego sklepu czy strony firmowej. Kiedy jednak pojawia się problem i chcesz zobaczyć, co dokładnie się dzieje, włączasz debug log tymczasowo, żeby zebrać informacje, a potem go wyłączasz.

Robi się to w pliku wp-config.php, który znajduje się w głównym katalogu instalacji WordPressa. Szukasz w nim linii zawierającej stałą WP_DEBUG – jeśli jej nie ma, dodajesz ją przed linią „That’s all, stop editing!”. Potrzebujesz trzech ustawień razem:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Każda z tych linii ma inne zadanie. WP_DEBUG włącza tryb debugowania w ogóle – bez niego WordPress nie zapisuje ani nie pokazuje żadnych błędów. WP_DEBUG_LOG to ustawienie, które każe WordPressowi zapisywać wszystkie błędy do pliku tekstowego zamiast tylko wyświetlać je w przeglądarce. To właśnie ta opcja tworzy plik z logami, o którym mowa w dalszej części artykułu. WP_DEBUG_DISPLAY ustawione na false pilnuje, żeby błędy nie wyświetlały się bezpośrednio na stronie, widoczne dla każdego odwiedzającego – trafiają tylko do pliku, do którego masz dostęp Ty.

Ta kombinacja jest bezpieczna nawet na działającej stronie, bo nie ujawnia niczego klientom ani przypadkowym gościom. Po zebraniu potrzebnych informacji warto wrócić do WP_DEBUG ustawionego na false, żeby nie zaśmiecać pliku logów kolejnymi wpisami i nie zostawiać otwartej furtki do informacji technicznych na dłużej niż trzeba.

Gdzie fizycznie znaleźć plik z logami

Po włączeniu WP_DEBUG_LOG WordPress domyślnie zapisuje logi w pliku o nazwie debug.log, w katalogu wp-content. Żeby się do niego dostać, potrzebujesz dostępu do plików strony – przez menedżer plików w panelu hostingu (najczęściej w cPanelu, DirectAdminie albo panelu własnym dostawcy) albo przez klienta FTP, taki jak FileZilla, po połączeniu się danymi dostępowymi od hostingu.

Plik debug.log to zwykły plik tekstowy, więc otwiera się go dowolnym edytorem tekstu albo podglądem w menedżerze plików. Jeśli strona działa od dłuższego czasu z włączonym logowaniem, plik może być spory – warto otwierać go od dołu, bo najnowsze wpisy pojawiają się na końcu pliku, w kolejności chronologicznej.

Zdarza się, że pliku debug.log nie widać wcale, mimo poprawnie ustawionych stałych w wp-config.php. Zwykle oznacza to jeden z dwóch scenariuszy: albo od włączenia logowania nie wystąpił jeszcze żaden błąd (co jest dobrą wiadomością), albo katalog wp-content nie ma uprawnień do zapisu i WordPress nie może utworzyć pliku. W tym drugim przypadku konieczna jest zmiana uprawnień katalogu przez panel hostingu albo kontakt z supportem dostawcy.

Część wtyczek do zarządzania stroną albo bezpieczeństwem ma własny podgląd logów w panelu administracyjnym WordPressa, co bywa wygodniejsze niż logowanie się przez FTP. Warto sprawdzić, czy taka funkcja jest już dostępna na stronie, zanim zaczniesz szukać dostępu do plików.

Logi WooCommerce – osobne miejsce, osobna logika

Gdzie znaleźć logi błędów WooCommerce to pytanie, które wraca regularnie, bo WooCommerce prowadzi własny, niezależny system logowania – osobny od pliku debug.log opisanego wyżej. Logika jest inna: WooCommerce zapisuje w swoich logach zdarzenia związane ze sklepem – płatnościami, dostawą, integracjami z zewnętrznymi systemami, kolejkami zadań w tle – niezależnie od tego, czy ogólny debug WordPressa jest włączony, czy nie.

Logi WooCommerce znajdziesz w panelu administracyjnym, w menu WooCommerce, Status, Logi. Zamiast jednego pliku widzisz tam listę osobnych plików logów, posortowanych według źródła i daty – na przykład osobny log dla bramki płatności, osobny dla wysyłki e-maili transakcyjnych, osobny dla integracji z magazynem czy systemem księgowym. Każdy plik można otworzyć bezpośrednio w przeglądarce, bez potrzeby logowania się przez FTP.

To rozróżnienie ma znaczenie praktyczne. Jeśli klient zgłasza błąd przy składaniu zamówienia albo płatność się nie kończy powodzeniem, w pierwszej kolejności warto sprawdzić logi WooCommerce, a nie ogólny debug.log WordPressa – to tam najczęściej trafiają komunikaty zwrotne od operatora płatności, informacje o odrzuconych transakcjach czy błędach komunikacji z bramką. Diagnostyka problemów z bramką płatności WooCommerce to zresztą temat na tyle rozległy, że wymaga osobnego, dokładniejszego omówienia – tutaj wystarczy zapamiętać, że pierwszy trop szukasz właśnie w tym panelu, nie w pliku debugowania samego WordPressa.

Warto też wiedzieć, że logowanie w WooCommerce można włączyć lub wyłączyć dla poszczególnych integracji osobno, w ustawieniach danej wtyczki płatności czy dostawy. Jeśli logów dla konkretnego problemu brakuje, sprawdź w ustawieniach danej bramki, czy jej własne logowanie jest aktywne.

Jak czytać typowy wpis błędu (poziom, komponent, komunikat)

Pojedynczy wpis w logu wygląda z pozoru jak ściana tekstu, ale ma stałą, powtarzalną strukturę. Przykładowy, uproszczony wpis może wyglądać tak:

[DD-Mon-RRRR HH:MM:SS UTC] PHP Fatal error:  Uncaught Error: Call to undefined function
przykladowa_funkcja() in /wp-content/plugins/przykladowa-wtyczka/plugin.php:42
Stack trace:
#0 /wp-content/plugins/przykladowa-wtyczka/plugin.php(15): przykladowa_funkcja()
#1 /wp-settings.php(578): include_once()
#2 {main}
  thrown in /wp-content/plugins/przykladowa-wtyczka/plugin.php on line 42

Analiza logów WordPress zawsze zaczyna się od tych samych trzech elementów. Pierwszy to znacznik czasu – data i godzina, kiedy błąd wystąpił. To pozwala połączyć błąd z konkretnym zdarzeniem, na przykład aktualizacją wtyczki, którą wykonałeś kilka minut wcześniej.

Drugi element to poziom błędu. Najczęściej spotykane to Fatal error (błąd krytyczny, który zatrzymuje działanie strony – to on odpowiada za biały ekran), Warning (ostrzeżenie – coś poszło nie tak, ale strona działa dalej) oraz Notice albo Deprecated (drobna informacja, często nieszkodliwa, sygnalizująca przestarzały fragment kodu). Poziom błędu od razu mówi Ci, jak pilna jest sprawa – Fatal error wymaga natychmiastowej reakcji, Notice można zwykle odłożyć na później.

Trzeci element to komponent, czyli źródło błędu – konkretna ścieżka do pliku, w którym błąd wystąpił. W przykładzie powyżej jest to plik wewnątrz katalogu wp-content/plugins/przykladowa-wtyczka/, co od razu wskazuje, że winowajcą jest konkretna wtyczka, a nie rdzeń WordPressa ani motyw. To najważniejsza informacja z całego wpisu – dzięki niej wiesz, gdzie szukać dalej, zamiast podejrzewać całą stronę.

Czwarty element to sam komunikat – opis tego, co się nie powiodło. W przykładzie to „Call to undefined function”, czyli wtyczka próbowała wywołać funkcję, która nie istnieje – typowy objaw niezgodności wersji, na przykład po aktualizacji WordPressa albo innej wtyczki, z którą ta funkcja była powiązana. Linie oznaczone jako „Stack trace” pokazują kolejność wywołań, które doprowadziły do błędu – dla nietechnicznego czytelnika nie trzeba ich analizować w szczegółach, wystarczy zwrócić uwagę na pierwszą linię po komunikacie głównym, bo ona najczęściej wskazuje faktyczne źródło problemu.

Najczęstsze błędy i co oznaczają

Większość problemów, które trafiają do logów, powtarza się w podobnych wariantach. Znajomość kilku najczęstszych typów pozwala od razu ocenić powagę sytuacji, zanim jeszcze wezwiesz kogoś na pomoc.

• PHP Fatal error: Uncaught Error: Call to undefined function – kod próbuje użyć funkcji, której nie ma. Najczęściej pojawia się po aktualizacji, kiedy jedna wtyczka lub motyw nie nadążył za zmianami w innej. To jeden z głównych powodów białego ekranu śmierci WordPress.
• PHP Fatal error: Allowed memory size exhausted – strona zużyła cały limit pamięci przydzielony przez hosting. Zdarza się przy dużych importach danych, ciężkich wtyczkach albo po prostu zbyt niskim limicie pamięci ustawionym przez dostawcę hostingu.
• PHP Parse error: syntax error – w kodzie jest literówka lub błąd składni, zwykle po ręcznej edycji pliku motywu albo niedokończonej instalacji wtyczki. Strona przestaje działać natychmiast po zapisaniu takiego pliku.
• Warning: Cannot modify header information – headers already sent – coś zostało wysłane do przeglądarki, zanim WordPress zdążył ustawić własne nagłówki. Często nieszkodliwe wizualnie, ale bywa objawem głębszego konfliktu między wtyczkami.
• Deprecated: Function [nazwa] is deprecated since version – funkcja, z której korzysta wtyczka lub motyw, jest przestarzała i w przyszłości zostanie usunięta. Strona nadal działa, ale to sygnał, że dana wtyczka lub motyw wymaga aktualizacji albo wymiany.
• WooCommerce: Payment error / Gateway response error – komunikacja z bramką płatności nie powiodła się. Wpis w logu WooCommerce zwykle zawiera dokładny komunikat zwrotny od operatora płatności, co pozwala ustalić, czy problem leży po stronie sklepu, czy po stronie dostawcy płatności.

Warto zwrócić uwagę, że spora część takich błędów pojawia się dokładnie po aktualizacji wtyczki albo rdzenia WordPressa. To nieprzypadkowe – nowa wersja kodu może być niezgodna z czymś, co już działa na stronie. Dlatego bezpieczny proces aktualizacji, który zakłada wcześniejszą kopię zapasową i sprawdzenie strony po każdej zmianie, jest najlepszym sposobem, żeby taki błąd złapać od razu, zanim zdąży wpłynąć na klientów.

Kiedy logi WordPressa nie wystarczą i trzeba sięgnąć po logi serwera

Logi WordPressa i WooCommerce opisują to, co dzieje się na poziomie aplikacji – kodu PHP, wtyczek, motywu. Nie każdy problem da się jednak zobaczyć z tego poziomu. Czasem strona pokazuje błąd 500 albo jest w ogóle niedostępna, a plik debug.log pozostaje pusty, bo WordPress nie zdążył nawet się uruchomić na tyle, żeby zapisać cokolwiek.

W takich sytuacjach źródłem problemu bywa coś poniżej warstwy WordPressa – limit zasobów serwera, błędna konfiguracja pliku .htaccess, wygasły certyfikat, niekompatybilna wersja PHP po aktualizacji przez hosting, albo tymczasowa awaria samego serwera. Te zdarzenia są zapisywane w logach serwerowych, dostępnych zwykle z poziomu panelu hostingu, często pod nazwą „error log” albo „logi błędów serwera”, osobno od plików samego WordPressa.

Sygnałem, że warto sprawdzić logi serwera zamiast logów WordPressa, jest sytuacja, w której strona jest całkowicie niedostępna (nie pokazuje nawet białego ekranu, tylko błąd połączenia albo błąd 500 bez żadnej treści), a plik debug.log milczy mimo włączonego logowania. To znak, że problem leży na wyższym poziomie niż kod WordPressa – i że dalsza diagnostyka wymaga dostępu do panelu hostingu albo kontaktu z jego działem technicznym.

Nie każdy właściciel strony musi umieć samodzielnie czytać logi serwerowe – to już bardziej techniczna warstwa, wymagająca czasem znajomości konfiguracji serwera. Ważne jest jednak, żeby wiedzieć, że taki poziom istnieje, i że kiedy logi WordPressa nic nie pokazują, problem nie zniknął – po prostu trzeba szukać go wyżej.

Jest też grupa awarii, których nie znajdziesz w żadnym logu po stronie serwera, bo dzieją się w przeglądarce odwiedzającego. Tak wygląda zepsuty przycisk albo formularz po zmianie ustawień wydajności: PHP nie zgłasza błędu, serwer odpowiada poprawnie, a funkcja nie działa. Wtedy zamiast logów otwiera się konsolę przeglądarki, co opisaliśmy przy okazji optymalizacji psującej funkcje strony.

Jak my z tym pracujemy

Debug log włączamy wtedy, gdy przychodzi zgłoszenie o nieprawidłowym działaniu, a zwłaszcza gdy strona wywala błąd krytyczny, którego front w ogóle nie pokazuje. W takim przypadku log najczęściej wskazuje konkretną ścieżkę z problemem i to jest jego największa wartość. Jeśli natomiast strona niczego nie wywala, tylko zwolniła, nie zaglądamy do debug logu, bo to złe narzędzie do tego zadania. Wtedy uruchamiamy Query Monitor i przeglądamy stronę po stronie w poszukiwaniu punktu zaczepienia, bo winowajcą bywa baza danych albo kod, nie błąd PHP.

Najlepiej pokazuje to realna sytuacja ze sklepu: zamówienia powstają normalnie, ale ich statusy nie aktualizują się po płatności. Nie zaczynamy wtedy od debug logu, tylko od access loga serwera i sprawdzamy, czy zapytania od bramki płatności w ogóle docierają na stronę. Jeśli nie docierają, problem jest przed WordPressem i szukanie w jego logach to strata czasu. Jeśli docierają, robimy transakcję testową i patrzymy w error log w jej trakcie oraz zaraz po niej, a następnie szukamy błędów pojawiających się bezpośrednio po utworzeniu zamówienia.

Na sklepie z ruchem logi włączamy tylko na chwilę, żeby zebrać minimum danych potrzebnych do namierzenia błędu, a nie po to, żeby zbierać wszystko na wszelki wypadek. Przy dużym logu szukanie powtarzalnych wzorców warto skonsultować z asystentem AI, bo ręczne czytanie tysięcy linii nie ma sensu. Gdy okazuje się, że problemem jest infekcja, na czas debugowania wyłączamy niemal wszystkie krytyczne funkcje strony, żeby nie dochodziło do replikacji, a w logach szukamy charakterystycznych, powtarzających się ruchów: dodania komentarza albo odpytania jednego bardzo konkretnego pliku PHP. Szerzej opisaliśmy to w anatomii włamania na WooCommerce.

Paradoksalnie trudniejsze bywają wizytówki i firmowe blogi. Ruchu prawie nie ma, więc log milczy i nie ma z czego wyciągać wniosków. Wtedy dopytujemy klienta, w jakich dokładnie warunkach błąd wystąpił, i odtwarzamy go u siebie z włączonym debug logiem. Jeśli nie da się ustalić powtarzalnego scenariusza, samo włączenie logowania niczego nie rozwiąże: najpierw scenariusz, potem log.

Co zrobić z informacją znalezioną w logach

Sam odczytany log rzadko jest końcem sprawy – to punkt wyjścia do konkretnego działania. Kiedy już wiesz, który komponent (wtyczka, motyw, integracja) i jaki typ błędu spowodował problem, kolejne kroki zależą od tego, co dokładnie znalazłeś.

Jeśli błąd wskazuje na konkretną wtyczkę i pojawił się po jej aktualizacji, najszybszym rozwiązaniem bywa tymczasowe jej wyłączenie i sprawdzenie, czy strona wraca do normy. Jeśli tak – masz potwierdzone źródło problemu i możesz szukać nowszej wersji wtyczki, alternatywy albo zgłosić błąd twórcy. Jeśli błąd dotyczy wyczerpanej pamięci, rozwiązaniem bywa podniesienie limitu pamięci PHP w konfiguracji hostingu albo znalezienie wtyczki, która zużywa jej zbyt wiele. Jeśli problem leży w bramce płatności, warto sprawdzić dokładny komunikat zwrotny w logu WooCommerce – często zawiera on informację wprost od operatora płatności, co ułatwia dalszą rozmowę z jego supportem.

Zanim zaczniesz cokolwiek zmieniać na żywej stronie na podstawie tego, co znalazłeś w logu, warto zrobić kopię zapasową – tak samo jak przed każdą aktualizacją. Nawet drobna poprawka wykonana w pośpiechu, bez zabezpieczenia, może pogłębić problem zamiast go rozwiązać.

Warto też zapamiętać, że nie każdy wpis w logu wymaga natychmiastowej reakcji. Pojedyncze ostrzeżenia i informacje typu Deprecated można zwykle zebrać i zaplanować ich naprawę przy najbliższej aktualizacji, zamiast reagować na każdy wpis osobno. Priorytetem są zawsze błędy krytyczne (Fatal error) oraz wszystko, co dotyczy płatności i procesu zamówienia w sklepie – te sprawy wpływają bezpośrednio na klientów i przychód.

Logi błędów nie są tajemną wiedzą dostępną tylko programistom. To zwykły plik tekstowy, który mówi wprost, co się popsuło, gdzie i kiedy. Znajomość podstaw – jak włączyć logowanie, gdzie szukać pliku, jak odróżnić poziom błędu od jego źródła – pozwala właścicielowi strony zrozumieć, z czym ma do czynienia, zanim jeszcze zadzwoni po pomoc. A jeśli pomoc jest potrzebna, rozmowa z technikiem czy agencją idzie dużo sprawniej, kiedy potrafisz powiedzieć dokładnie, co znalazłeś w logu, zamiast tylko „strona nie działa”.

Nie chcesz sam ścigać się z logami przy każdej awarii?
Regularne monitorowanie, aktualizacje z kopią zapasową i szybka reakcja na błędy to część opieki nad stroną WordPress, którą prowadzimy dla naszych klientów. Umów się na bezpłatną konsultację wstępną i sprawdźmy razem, w jakim stanie jest Twoja strona.