Log błędów PHP to plik tekstowy, do którego serwer dopisuje każdy błąd, ostrzeżenie i powiadomienie zgłoszone przez skrypty PHP, w tym przez WordPressa, jego wtyczki i motyw. Znajdziesz go w panelu hostingu w sekcji „Logi” albo „Error log”, a dokładniejszy log samego WordPressa włączasz stałą WP_DEBUG_LOG. Jeden wpis z datą, poziomem błędu i ścieżką do pliku wskazuje wtyczkę lub motyw, które zepsuły stronę, więc nie musisz wyłączać ich po kolei na ślepo.
Czym jest log błędów PHP i czym różni się od logu WordPressa?
Log błędów PHP prowadzi hosting niezależnie od WordPressa i obejmuje wszystkie skrypty w Twojej domenie, a plik wp-content/debug.log zapisuje sam WordPress dopiero po włączeniu stałej WP_DEBUG_LOG. Pierwszy widzisz w panelu hostingu bez żadnej konfiguracji, drugi musisz włączyć sam, za to zbiera błędy rdzenia, wtyczek i motywu z dokładniejszym kontekstem.
- Log serwera (error log PHP/Apache): obejmuje wszystko, co działa na koncie hostingowym, w tym ograniczenia narzucone przez hosting, np. przekroczony limit pamięci PHP.
- Log WordPressa (debug.log): zapisuje tylko to, co dzieje się wewnątrz WordPressa, za to ze szczegółami, których w logu serwera zwykle nie ma, np. ostrzeżenia o przestarzałej funkcji wywołanej przez wtyczkę.
Przy niedziałającej stronie warto zajrzeć do obu: limit pamięci ustawiony na poziomie serwera zobaczysz w logu hostingu, a ostrzeżenie o przestarzałej funkcji we wtyczce często tylko w debug.log.
Gdzie znaleźć log błędów w panelu hostingu?
Log błędów jest w panelu hostingu w sekcji „Logi”, „Błędy” albo „Error log” przy nazwie domeny. W każdym panelu nazywa się nieco inaczej i leży w innym miejscu menu, ale wzorzec jest ten sam.
- cPanel: sekcja Metryki → Błędy (Errors). Wpisy są ułożone od najnowszego, każdy zawiera datę i godzinę, adres IP, typ błędu i ścieżkę do pliku, którego dotyczy.
- DirectAdmin: Informacje o koncie → Podsumowanie witryny / Statystyki / Logi → przy wybranej domenie „Dziennik błędów (Error Log)”. Domyślnie widać ostatnie 100 linii, a błędy serwera Apache i PHP są w nich wymieszane.
- Plesk i panele autorskie hostingów: sekcja z logami przy domenie, zwykle nazwana „Logi” lub „Error log”. Gdy panel nie ma takiej sekcji, plik logu leży w katalogu domeny (często w folderze
logs/) i otwierasz go przez FTP lub SFTP; dokładną ścieżkę podaje dokumentacja hostingu.
Plik wp-content/debug.log otwierasz zawsze przez menedżer plików w panelu albo klienta FTP/SFTP, bo kokpit WordPressa nie ma wbudowanej przeglądarki logu.
Jak włączyć log WordPressa przez WP_DEBUG_LOG?
Log WordPressa włączasz trzema liniami dopisanymi do wp-config.php w katalogu głównym strony. Od tego momentu WordPress zapisuje błędy, ostrzeżenia i powiadomienia do wp-content/debug.log.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Trzecia linia jest obowiązkowa na stronie dostępnej publicznie: WP_DEBUG_DISPLAY ustawione na false zatrzymuje wyświetlanie błędów odwiedzającym, którzy inaczej zobaczyliby ścieżki serwera i fragmenty kodu. Plik debug.log powstaje sam po pierwszym zapisanym błędzie i rośnie z każdym wpisem, dlatego po diagnozie wyłączasz WP_DEBUG_LOG albo go czyścisz.
Część wtyczek do cache i optymalizacji ma przełącznik trybu debugowania we własnym panelu, bez edycji wp-config.php. Sprawdź w opisie takiej opcji, gdzie wtyczka zapisuje log, bo nie każda używa pliku debug.log.
Jak czytać wpis „Fatal error” w logu?
Wpis o błędzie krytycznym czytasz w takiej kolejności: najpierw ścieżka do pliku z numerem linii, potem treść komunikatu, na końcu data. Typowy wpis w logu serwera wygląda tak:
[30-Jan-2025 11:46:00 UTC] PHP Fatal error: Uncaught Error: Class "WP_Widget" not found in /home/uzytkownik/public_html/wp-content/plugins/przykladowa-wtyczka/widget.php:17
Stack trace:
#0 {main}
thrown in /home/uzytkownik/public_html/wp-content/plugins/przykladowa-wtyczka/widget.php on line 17Taki wpis składa się z pięciu elementów:
Data i godzina
W nawiasie kwadratowym, zwykle w strefie UTC, czyli o godzinę lub dwie wcześniej niż na zegarze w Polsce. Zestaw ten czas z momentem, w którym strona przestała działać albo klient zgłosił problem.
Poziom błędu
Tu PHP Fatal error. To on decyduje, jak pilna jest sprawa (tabela w następnej sekcji).
Treść komunikatu
Class "WP_Widget" not found mówi, że skrypt odwołał się do klasy, której PHP w tym momencie nie znał. Inne częste komunikaty: Call to undefined function (wywołanie nieistniejącej funkcji), Allowed memory size exhausted (przekroczony limit pamięci), syntax error, unexpected (błąd składni, zwykle po ręcznej edycji pliku).
Ścieżka do pliku i numer linii
wp-content/plugins/przykladowa-wtyczka/widget.php:17. To najważniejsza informacja we wpisie, bo wskazuje, gdzie błąd wystąpił.
Stack trace
Kolejność wywołań, które doprowadziły do błędu. Czytasz tylko górę: linia #0 wskazuje, skąd wywołano problematyczny kod, a {main} oznacza, że błąd wystąpił bezpośrednio przy ładowaniu pliku, bez pośredników. Wiersz thrown in powtarza plik i numer linii z początku wpisu.
Błąd krytyczny przerywa skrypt w miejscu, w którym się pojawił, więc zamiast strony użytkownik widzi biały ekran, komunikat „Na tej witrynie wystąpił krytyczny błąd” albo kod 500, czyli błąd serwera 5xx. Wpis w logu i kod odpowiedzi serwera opisują wtedy to samo zdarzenie z dwóch perspektyw: kod mówi, że strona nie zadziałała, log mówi dlaczego.
Co oznaczają poziomy błędów PHP: Fatal error, Warning, Notice i Deprecated?
Poziom błędu mówi, czy skrypt przerwał pracę, czy tylko zgłosił problem i działa dalej. W logu strony na WordPressie spotkasz cztery poziomy i każdy znaczy co innego dla pilności naprawy:
| Poziom w logu | Co dzieje się ze stroną | Przykład komunikatu | Co z tym zrobić |
|---|---|---|---|
| PHP Fatal error, Uncaught Error, Parse error | Skrypt przerywa pracę: biały ekran, komunikat o krytycznym błędzie lub kod 500 | Class not found, syntax error, unexpected | Działać od razu |
| PHP Warning | Strona zwykle działa, ale część funkcji może nie zadziałać | failed to open stream (brakujący plik dołączany), nieprawidłowy typ argumentu funkcji | Sprawdzić przy najbliższej okazji |
| PHP Notice | Informacja o niskiej pilności, strona działa | odwołanie do niezdefiniowanej zmiennej | Zanotować: bywa zapowiedzią Fatal error po zmianie wersji PHP |
| PHP Deprecated | Kod używa funkcji lub składni oznaczonej jako przestarzała, strona działa | Function … is deprecated | Zaplanować aktualizację wtyczki lub motywu przed zmianą wersji PHP |
Kolejność pilności: Fatal error i Parse error od razu, Warning przy najbliższej okazji, Notice i Deprecated do zanotowania przed planowaną zmianą wersji PHP. Seria wpisów Deprecated z jednego folderu wtyczki to sygnał, że autor jej nie aktualizuje.
Granica między Warning a Notice przesuwa się z wersji na wersję PHP: część dawnych powiadomień nowsze wydania zgłaszają już jako ostrzeżenia. Dlatego po przełączeniu wersji PHP w panelu hostingu w logu przybywa ostrzeżeń, choć w kodzie strony nic się nie zmieniło.
Jak po ścieżce pliku ustalić, czy winna jest wtyczka, motyw czy rdzeń?
Folder w ścieżce do pliku wskazuje sprawcę: wp-content/plugins/ to wtyczka, wp-content/themes/ to motyw, a wp-includes/ lub wp-admin/ to rdzeń WordPressa.
- wp-content/plugins/<nazwa-wtyczki>/: błąd we wtyczce z tego folderu. Nazwa folderu zwykle odpowiada nazwie wtyczki na liście w kokpicie.
- wp-content/themes/<nazwa-motywu>/: błąd w motywie, także w potomnym, często w pliku
functions.phppo ręcznej edycji. - wp-includes/ lub wp-admin/: rdzeń WordPressa. Sam rdzeń rzadko bywa winny; taki wpis częściej oznacza niezgodność z wersją PHP albo wtyczkę, która wywołała funkcję rdzenia z niewłaściwymi danymi. Wtedy odpowiedź jest w stack trace: pierwsza linia z folderem
plugins/lubthemes/wskazuje faktyczne źródło.
Kilka wpisów z tą samą ścieżką w krótkim czasie to nie seria awarii, tylko jeden problem powtarzany przy każdym wejściu na stronę. Na tym kończy się czytanie logu: co zrobić ze wskazaną wtyczką lub motywem, czyli naprawa błędu 500 w WordPressie, to temat na osobną instrukcję.
Masz błąd Fatal error w logu swojej strony?
Napiszemy, co pokazuje log, i podpowiemy, co zrobić dalej.
Co zrobić, gdy log jest pusty albo nie ma w nim wpisu z dnia awarii?
Pusty log przy niedziałającej stronie oznacza zwykle, że PHP nie zapisuje błędów albo że hosting usunął już starsze wpisy. Sprawdzasz trzy rzeczy:
Czy PHP zapisuje błędy
W panelu hostingu w sekcji ustawień PHP (często „Wybierz wersję PHP” lub „Opcje PHP”) opcja log_errors musi być włączona.
Czy działa WP_DEBUG_LOG
Log WordPressa zapisuje się niezależnie od konfiguracji serwera. Po dopisaniu stałej do wp-config.php odśwież stronę z błędem i sprawdź, czy wpis pojawił się w wp-content/debug.log.
Jak długo hosting trzyma logi
Część hostingów czyści je co kilka dni i wpis sprzed tygodnia może już nie istnieć. Gdy awaria jest starsza niż okno przechowywania, zostaje jedno wyjście: wywołać błąd ponownie i odczytać świeży wpis.
Log mówi, co stało się po stronie serwera. Czy w tym samym czasie na błąd trafił też Googlebot, sprawdzisz w karcie „Według odpowiedzi” w raporcie Statystyki indeksowania w Google Search Console: udział odpowiedzi „Błąd serwera (5XX)” w dniu awarii pokazuje, ile żądań robota skończyło się błędem.
Jakie pojęcia wiążą się z logiem błędów PHP?
- Błąd 500 / błąd serwera 5xx: kod odpowiedzi HTTP, który serwer zwraca, gdy skrypt zakończył się błędem krytycznym; przyczynę takiego kodu znajdziesz dopiero w logu.
- Biały ekran (WSOD, white screen of death): pusta strona po błędzie krytycznym, bez żadnej informacji, co się stało; nowsze wersje WordPressa pokazują w tym miejscu komunikat o błędzie, a szczegóły zostawiają w logu.
- Stack trace: lista wywołań funkcji od miejsca błędu wstecz, dopisana pod komunikatem Fatal error.
- WP_DEBUG: stała w
wp-config.php, która włącza tryb debugowania WordPressa;WP_DEBUG_LOGiWP_DEBUG_DISPLAYdecydują, czy błędy trafiają do pliku i czy są wyświetlane na stronie. - Log dostępu (access log): osobny plik z listą wszystkich żądań do serwera wraz z kodem odpowiedzi; pokazuje, że strona zwróciła 500, ale nie dlaczego.
FAQ
Tak. Plik wp-content/debug.log zawiera tylko zapis błędów, więc WordPress nie potrzebuje go do działania i przy kolejnym błędzie utworzy go od nowa, jeśli WP_DEBUG_LOG jest nadal włączone. Przed usunięciem zapisz kopię wpisów, które chcesz pokazać wykonawcy strony lub wsparciu hostingu.
Nie. Tryb debugowania włączasz na czas diagnozy, bo log rośnie z każdym wpisem, a WP_DEBUG bez WP_DEBUG_DISPLAY ustawionego na false wyświetla błędy odwiedzającym. Po znalezieniu przyczyny przywracasz WP_DEBUG na false albo usuwasz dopisane linie.
Nie. Log dostępu (access log) zapisuje każde żądanie do serwera z adresem, kodem odpowiedzi i nazwą przeglądarki lub robota, a log błędów tylko komunikaty o błędach ze skryptów PHP i serwera. Przy diagnozie kodu 500 log dostępu potwierdza, kiedy i pod jakim adresem błąd wystąpił, a log błędów mówi, co go wywołało.
Skrypt PHP przekroczył limit pamięci (memory_limit) ustawiony dla strony i został przerwany. Ścieżka w takim wpisie wskazuje plik, który próbował użyć pamięci powyżej limitu, ale przyczyną bywa suma wszystkich aktywnych wtyczek, a nie ten jeden plik. Zmiana limitu w ustawieniach PHP hostingu to już element naprawy, nie odczytu logu.
Źródła
- PHP Manual, „Predefined Constants” (poziomy błędów E_ERROR, E_WARNING, E_NOTICE, E_DEPRECATED): php.net/manual
- WordPress Developer Resources, „Debugging in WordPress”: developer.wordpress.org
- Dokumentacja cPanel, sekcja Metrics → Errors
- Dokumentacja DirectAdmin, Error Log przy domenie
