Gdzie znaleźć logi błędów w WordPress i jak je czytać

Logi błędów w WordPress – jak ustawić ich zbieranie? Gdzie ich szukać?

Udostępnij

Twittnij

Udostępnij

6 min. czytania

Dzienniki błędów WordPress to bezcenne narzędzia diagnostyczne dla administratorów i deweloperów, którzy chcą szybko zrozumieć i rozwiązać problemy wpływające na działanie witryny.

Gdy w instalacji WordPress coś idzie nie tak — pojawia się biały ekran, występują krytyczne błędy lub funkcje przestają działać — dzienniki błędów dostarczają szczegółów niezbędnych do identyfikacji przyczyn i wdrożenia skutecznych rozwiązań.

W przeciwieństwie do lakonicznych, publicznych komunikatów błędów, dzienniki zawierają techniczne informacje: dokładne ścieżki plików, numery linii, typy błędów i znaczniki czasu, które umożliwiają precyzyjną diagnozę problemów.

Zrozumienie dzienników błędów WordPress i ich roli

Dzienniki błędów WordPress zapisują błędy, ostrzeżenia i uwagi pojawiające się podczas wykonywania kodu. Domyślnie WordPress nie wyświetla tych komunikatów i nie zapisuje ich w miejscu dostępnym dla administratorów.

Takie domyślne zachowanie chroni wrażliwe informacje, ale utrudnia diagnozę. Dlatego warto świadomie włączyć rejestrowanie i korzystać z niego zwłaszcza przy problemach pojawiających się sporadycznie, w żądaniach Ajax lub zadaniach cron działających w tle.

Każdy wpis w logu zawiera kluczowe elementy, które ułatwiają pracę diagnostyczną:

• znacznik czasu,
• typ błędu,
• opis komunikatu,
• ścieżkę pliku i numer linii.

Taki plik logów zamienia abstrakcyjne awarie w konkretne, przeszukiwalne informacje, które pozwalają ustalić co, kiedy i dlaczego przestało działać.

Metody włączania debugowania i rejestrowania błędów w WordPressie

Włączenie debugowania odbywa się w pliku wp-config.php (katalog główny instalacji). Dodaj wpisy przed tym komentarzem:

/* That’s all, stop editing! Happy blogging. */

Poniżej znajdziesz zalecane kroki w formie krótkiej, praktycznej listy:

1. Wykonaj kopię bezpieczeństwa pliku wp-config.php i bazy danych.
2. Otwórz wp-config.php w edytorze tekstu i włącz tryb debugowania za pomocą WP_DEBUG.
3. Wyłącz wyświetlanie błędów w HTML (WP_DEBUG_DISPLAY), aby nie ujawniać informacji użytkownikom.
4. Włącz zapisywanie do pliku (WP_DEBUG_LOG), aby archiwizować komunikaty do późniejszej analizy.
5. (Opcjonalnie) Ustal własną ścieżkę logu poza katalogiem publicznym dla wyższego bezpieczeństwa.
6. Zapisz zmiany, odtwórz problem i przejrzyj plik logu, aby zidentyfikować przyczynę.

Włączenie podstawowego trybu debugowania (na środowisku testowym):define('WP_DEBUG', true);

Ukrycie błędów na froncie (przy aktywnym debugowaniu):define('WP_DEBUG_DISPLAY', false);

Bezpieczna, rekomendowana konfiguracja na produkcji podczas diagnozy (logowanie tak, wyświetlanie nie):

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Ustawienie własnej ścieżki do pliku logu (WordPress 5.1+):

define('WP_DEBUG_LOG', '/var/log/wp-errors.log');

Połączenie trzech stałych (WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY=false) tworzy bezpieczne środowisko: błędy są rejestrowane do analizy, ale nie są pokazywane odwiedzającym.

Jeśli nie chcesz ręcznie edytować plików, skorzystaj z wtyczek (np. WP Debugging), które automatyzują zmiany w wp-config.php. Zmniejsza to ryzyko błędów składniowych i ułatwia pracę mniej technicznym administratorom.

Lokalizowanie i dostęp do dzienników błędów WordPressa

Po włączeniu WP_DEBUG_LOG bez niestandardowej ścieżki, log znajdziesz tu: /wp-content/debug.log (np. /public_html/wp-content/debug.log lub /home/username/public_html/wp-content/debug.log — zależnie od hostingu).

Najwygodniejsze metody dostępu do pliku logu to:

• FTP – połącz się klientem (np. FileZilla), przejdź do wp-content i pobierz debug.log do analizy;
• Menedżer plików – użyj panelu hostingu (np. cPanel, Plesk), aby podejrzeć debug.log w przeglądarce;
• SSH – śledź log w czasie rzeczywistym (np. komendą tail -f wp-content/debug.log), co ułatwia obserwację nowych wpisów podczas testów;
• Panele zarządzane – rozwiązania dostawców (np. MyKinsta) pokazują logi z wyszukiwaniem i filtrami, często wygodniejsze niż surowy plik.

Zrozumienie struktury wpisów i typów błędów

Wpisy w logu mają powtarzalną strukturę: znacznik czasu, typ błędu, opis, ścieżka pliku i numer linii. To pozwala szybko namierzyć problematyczny fragment.

Najczęstsze kategorie błędów w WordPressie i PHP:

• Błędy krytyczne (fatal errors) – zatrzymują wykonywanie skryptu (często „biały ekran”); zwykle wynikają z wywołania niezdefiniowanej funkcji, instancji nieistniejącej klasy lub błędów składni;
• Błędy parsowania (parse errors) – wskazują problemy składniowe w PHP (brak średnika, niedopasowane nawiasy); pojawiają się przed wykonaniem kodu i uniemożliwiają jego start;
• Ostrzeżenia (warnings) – kod działa dalej, ale potencjalnie nieprawidłowo; często dotyczą przestarzałych funkcji lub nieudanych operacji z mechanizmem awaryjnym;
• Uwagi (notices) – najniższa waga; sygnalizują nieoptymalne praktyki (np. użycie niezdefiniowanej zmiennej) i wpływają na kompatybilność i odporność aplikacji.

Przykładowy komunikat błędu, który od razu wskazuje źródło problemu:

Call to undefined function custom_function() in /home/user/public_html/wp-content/plugins/my-plugin/functions.php on line 45

Taki komunikat jednocześnie wskazuje brakującą funkcję, konkretny plik i linię kodu, co przyspiesza naprawę.

Narzędzia i wtyczki do analizy dzienników błędów

Specjalistyczne wtyczki porządkują wpisy, podświetlają ważne elementy i umożliwiają filtrowanie. Oto najbardziej pomocne rozwiązania:

• Debug Bar – dodaje panel z informacjami o zapytaniach, cache i ostrzeżeniach/uwagach PHP; obsługuje SAVEQUERIES do śledzenia kosztownych zapytań;
• Query Monitor – pokazuje zapytania SQL, błędy PHP, hooki/akcje, kolejkę skryptów i stylów, wywołania HTTP API, a także debugowanie Ajax i REST API;
• Error Log Viewer (BestWebSoft) – przegląd logów w kokpicie, wyszukiwanie, filtrowanie i powiadomienia e-mail o zmianach;
• Health Check & Troubleshooting – diagnozuje kondycję witryny (aktualizacje, rozszerzenia PHP, konfigurację serwera), dostarczając cennego kontekstu.

Odczytywanie i interpretacja typowych błędów

Znajomość wzorców błędów ułatwia szybką diagnozę i wybór rozwiązania. Najczęściej spotykane przypadki:

• Konflikty wtyczek – pojawiają się po aktualizacjach WordPressa lub wtyczek; objawy to wywołania niezdefiniowanych funkcji i błędy klas w plikach rozszerzeń;
• Błędy zgodności motywów – wynikają z kolizji z rdzeniem lub użycia przestarzałych funkcji; często w szablonach lub functions.php;
• Błędy połączenia z bazą – nieprawidłowe dane w wp-config.php, niedostępny serwer bazy, brak uprawnień; często widoczny komunikat:

Error establishing a database connection

• Wycieńczenie pamięci – komunikat w stylu:

Allowed memory size exhausted

• Przekroczenie limitu czasu – skrypt trwa zbyt długo (30–60 s) podczas masowych operacji; rozwiązaniem bywa zwiększenie limitu czasu w konfiguracji PHP.

Najczęściej pomaga podniesienie limitu pamięci w wp-config.php w przypadku wyczerpania pamięci oraz optymalizacja wtyczek lub procesów powodujących przeciążenie.

Najlepsze praktyki skutecznego zarządzania logowaniem

Aby debugowanie było skuteczne i bezpieczne, stosuj poniższe zasady:

• Nie zostawiaj debugowania włączonego na produkcji – aktywuj je tylko na czas diagnozy, a po zakończeniu wyłącz, by zminimalizować wpływ na wydajność;
• Przeglądaj log na bieżąco – szukaj wzorców i korelacji z konkretnymi działaniami lub porami dnia;
• Dokumentuj problemy i rozwiązania – budujesz bazę wiedzy dla siebie i zespołu, co skraca czas przyszłych napraw;
• Włącz powiadomienia e-mail o krytycznych błędach – reagujesz szybciej, zamiast odkrywać problem przy rutynowym przeglądzie;
• Pracuj na środowisku testowym/staging – odtwarzaj problem poza produkcją, aby ograniczyć ryzyko przestojów.

Kwestie bezpieczeństwa i ochrona dzienników debugowania

Dzienniki mogą zawierać wrażliwe informacje (np. klucze API, ścieżki plików). Atakujący aktywnie wyszukują publicznie dostępne debug.log, dlatego upewnij się, że nie są widoczne z poziomu przeglądarki.

Zastosuj te środki bezpieczeństwa:

• Trzymaj log poza katalogiem publicznym – ustaw własną ścieżkę w WP_DEBUG_LOG powyżej document root;
• Zablokuj dostęp do debug.log – jeśli musi być w katalogu publicznym, użyj reguł .htaccess lub konfiguracji serwera;
• Wyłącz debugowanie po testach – ustaw WP_DEBUG na false i usuń debug.log po zakończeniu prac;
• Regularnie przeglądaj i usuwaj stare logi – ograniczasz ryzyko wycieku danych i oszczędzasz miejsce;
• Kontroluj dostęp i rozważ szyfrowanie – szczególnie przy dłuższym przechowywaniu logów.

Przykładowa reguła .htaccess blokująca dostęp do pliku debug.log:

<FilesMatch "^debug\.log"> Order allow,deny Deny from all </FilesMatch>

Nie zostawiaj trybu debugowania włączonego na produkcji — to prosta zasada, która najszybciej redukuje ryzyko przypadkowej ekspozycji i poprawia bezpieczeństwo witryny.