Logi błędów WordPress – jak znaleźć i analizować?
Gdy WordPress wyświetla błędy, działa wolniej albo przestaje reagować, najważniejszym źródłem informacji są WordPress error logs – logi błędów PHP, logi błędów serwera oraz debug.log file. To właśnie one zapisują każdy błąd, ostrzeżenie i komunikat generowany wewnątrz Twojej strony. W tym artykule pokażemy Ci, jak przeprowadzić WordPress debug mode krok po kroku, gdzie znaleźć debug.log file, jak czytać logi błędów PHP i jak na tej podstawie skutecznie rozwiązywać problemy w WordPressie, nawet bez dostępu do kokpitu.
Czym są WordPress error logs i dlaczego warto je czytać
WordPress error logs to dzienniki tekstowe, w których zapisywane są błędy i ostrzeżenia WordPress, generowane przez PHP, WordPress i serwer. Wyróżniamy trzy główne typy: logi błędów PHP: informacje o błędach w kodzie, logi błędów serwera – problemy z hostingiem (limity pamięci, błędy 500), oraz debug.log – wewnętrzny dziennik WordPress tworzony w katalogu wp-content. Razem tworzą kompletny obraz tego, co dzieje się wewnątrz Twojej witryny.
Regularne sprawdzanie logów błędów WordPress pozwala wyłapać problemy zanim przerodzą się w poważne awarie. Jeśli chcesz zbudować pełniejszy system diagnostyki, sprawdź też nasz artykuł o monitorowaniu WordPress i wykrywaniu awarii.
Jak włączyć WordPress debug mode – edycja wp-config.php i narzędzia
Uruchomienie WordPress debug mode wymaga edycji pliku wp-config.php w katalogu głównym strony. Połącz się z serwerem przez FTP/SFTP lub file manager w panelu hostingu i wstaw lub zmodyfikuj poniższe stałe:
- WP_DEBUG – uruchamia WordPress debug mode; bez WP_DEBUG pozostałe opcje nie zadziałają,
- WP_DEBUG_LOG – włącza zapis do error log file w katalogu wp-content,
- WP_DEBUG_DISPLAY – decyduje, czy błędy wyświetlają się na stronie (na produkcji zawsze ustaw na false).
Po ustawieniu WP_DEBUG na true rejestrowanie błędów PHP startuje automatycznie, a WordPress error logs zaczynają się wypełniać wpisami. Edycja pliku wp-config.php to standardowy sposób uruchamiania debug mode w każdej instalacji. Pełną listę stałych debugowania opisuje oficjalna dokumentacja WordPress Debugging Constants.
Jeśli nie czujesz się pewnie przy ręcznej edycji konfiguracji, użyj plugin WP Debugging, który automatycznie włącza tryb debugowania WordPress i ustawia WP_DEBUG, WP_DEBUG_LOG oraz WP_DEBUG_DISPLAY na wartości rekomendowane. Do bieżącej pracy z logami przydatny będzie też plugin Query Monitor, który prezentuje komunikaty błędów bezpośrednio w kokpicie, bez konieczności pobierania debug.log file z serwera.
Gdzie znaleźć debug.log file i logi błędów serwera
Po włączeniu WP_DEBUG_LOG WordPress automatycznie tworzy plik debug.log w katalogu wp-content. Aby znaleźć debug log:
- Zaloguj się na serwer przez FTP/SFTP lub the file manager w panelu hostingu.
- Przejdź do katalogu wp-content.
- Odszukaj i otwórz debug.log – to Twój główny WordPress debug log z wszystkimi zarejestrowanymi błędami.
Jeśli plik z logami jeszcze nie istnieje, wywołaj błąd na stronie (np. odwiedź problematyczną podstronę) i sprawdź katalog ponownie. WordPress tworzy debug.log przy pierwszym zapisie błędu. Pamiętaj, że plik log rośnie z każdym wpisem. Warto go regularnie czyścić po zakończeniu diagnostyki.
Oprócz debug log warto sprawdzić WordPress error logs po stronie serwera. W panelu hostingu znajdź sekcję „Logi błędów” lub „error logs” i otwórz plik error_log lub inny error log file z logami PHP. Porównaj te wpisy z wpisami w debug log – razem pomogą ustalić, czy problem leży w samym WordPressie, czy w konfiguracji hostingu.
Jak czytać WordPress error logs – typy błędów i diagnostyka
Każdy error logs (dziennik błędów) zawiera datę, typ błędu, nazwę pliku i numer linii. Najczęściej spotkasz trzy poziomy: Notice – drobna sugestia, kod działa; Warning – poważniejszy problem, strona zwykle się ładuje; PHP Fatal error – krytyczny błąd PHP, często powoduje biały ekran lub błąd krytyczny WordPress. Kiedy komunikat błędu WordPress wskazuje konkretny plik wtyczki lub motywu, wiesz od czego zacząć.
Praktyczna procedura diagnostyczna: powtórz czynność wywołującą błąd, otwórz log file i znajdź najnowszy wpis z aktualną datą. Sprawdź, czy komunikat dotyczy wtyczki, motywu, bazy danych czy core WordPressa. Na tej podstawie podejmij działania: aktualizacja, wyłączenie wtyczki lub poprawka w kodzie. Dzięki wpisom do dziennika błędów WordPress nie zgadujesz, po prostu czytasz z WordPress error logs, skąd biorą się błędy i ostrzeżenia. Dziennik błędów PHP i po stronie serwera wzajemnie się uzupełniają – komunikaty błędów w obu miejscach razem tworzą pełen obraz sytuacji.
Typowe problemy w WordPress error logs i rozwiązywanie problemów
Konflikty między wtyczkami to najczęstsza przyczyna wpisów w WordPress error logs. Wtyczki WordPress mogą na siebie wzajemnie wpływać. W logach zobaczysz wtedy ścieżki do plików w katalogach wp-content/plugins lub wp-content/themes. Tymczasowo wyłącz problematyczną wtyczkę, zaktualizuj motyw lub przełącz się na motyw domyślny i sprawdź, czy wpisy znikają z pliku debug log. Rozwiązywanie problemów z konfliktami jest zazwyczaj szybkie, po zidentyfikowaniu winowajcy w logach.
Jeśli w WordPress error logs pojawiają się komunikaty takie jak „Error establishing a database connection” lub komunikaty powiązane z błędami 500, problem może dotyczyć bazy danych albo konfiguracji PHP. Sprawdź logi błędów serwera w hostingu. Znajdziesz tam informacje o przekroczonych limitach pamięci, błędnych uprawnieniach do plików rdzenia WordPress lub brakujących rozszerzeniach. Rozwiązywanie problemów tego typu wymaga analizy obu źródeł – log file WordPressa i logów serwera jednocześnie.
Gdy strona całkowicie przestaje reagować mimo analizy WordPress error logs, sięgnij po nasz poradnik: co zrobić, gdy Twoja strona internetowa nie działa. Jeśli po naprawie błędów chcesz przywrócić witrynę do stanu sprzed zmian, przydatny będzie też artykuł o resecie WordPress i przywracaniu ustawień fabrycznych.
Bezpieczeństwo, dobre praktyki i kiedy skorzystać ze wsparcia specjalisty
WordPress error logs mogą zawierać wrażliwe informacje – ścieżki plików, nazwy zmiennych, fragmenty zapytań SQL. To kluczowy aspekt zabezpieczenia WordPressa: na stronie produkcyjnej zawsze ustaw WP_DEBUG_DISPLAY na false i upewnij się, że debug.log file nie jest publicznie dostępny przez przeglądarkę. Ogranicz dostęp do panelu hostingu i FTP. Pełniejsze zabezpieczenia WordPressa, zarówno w zakresie logów, jak i całej infrastruktury opisujemy na stronie bezpieczeństwo stron WordPress.
Po zakończeniu diagnostyki usuń debug.log file. Pobierz go wcześniej jako archiwum i skasuj z serwera. WordPress automatycznie stworzy nowy plik przy kolejnym zapisie błędu. Jeśli chcesz kontynuować error logging, pozostaw WP_DEBUG_LOG włączone. Warto też skonfigurować monitoring uptime WordPress z alertami, by reagować na awarie zanim pojawią się w logach.
Jeśli mimo analizy dziennika błędów WordPress problem wraca, w logach pojawiają się złożone błędy bazy danych lub niepokojące wpisy sugerujące próby nieautoryzowanego dostępu – warto skonsultować się z doświadczonym administratorem WordPress. Specjalista szybko odczyta nawet skomplikowane logi błędów WordPress, wdroży stałe procedury monitoringu i wzmocni zabezpieczenia WordPressa na poziomie serwera.
FAQ – logi błędów WordPress
Debug.log file tworzony jest automatycznie w katalogu wp-content, po włączeniu stałej WP_DEBUG_LOG w pliku wp-config.php. Dostęp do niego uzyskasz przez FTP/SFTP lub file manager w panelu hostingu. Wejdź do katalogu wp-content i otwórz plik o nazwie debug.log.
Uruchamianie WordPress debug mode wymaga edycji pliku wp-config.php. Ustaw WP_DEBUG na true, WP_DEBUG_LOG na true i WP_DEBUG_DISPLAY na false. Możesz też użyć plugin WP Debugging, który automatycznie konfiguruje tryb debugowania WordPress bez ręcznej edycji pliku.
PHP Fatal error to krytyczny błąd PHP, który najczęściej powoduje biały ekran lub komunikat o błędzie krytycznym. W WordPress error logs znajdziesz nazwę pliku, który je wywołuje, a to punkt startowy do diagnozy. Najczęstsza przyczyna to konflikt wtyczek WordPress lub nieaktualne pliki motywu.
Nie – debug.log file nie powinien być dostępny publicznie, ponieważ może zawierać wrażliwe dane o strukturze Twojej strony. To podstawowy element zabezpieczenia WordPressa. Po zakończeniu analizy logów błędów usuń plik z serwera lub zablokuj do niego dostęp z poziomu przeglądarki.
Usuń WordPress error logs, w tym the log file po zakończeniu diagnostyki błędów, a szczególnie gdy plik urósł do dużych rozmiarów. Jeśli chcesz kontynuować error logging, pozostaw WP_DEBUG_LOG włączone. WordPress automatycznie stworzy nowy log przy kolejnym zapisie.
Na Twojej stronie pojawiły się błędy?
Nie musisz samodzielnie analizować logów, reagować na błędy PHP ani śledzić awarii serwera. Przejmiemy za Ciebie monitoring WordPress error logs, naprawę błędów krytycznych i stałą kontrolę stabilności Twojej strony, tak, byś mógł skupić się na prowadzeniu biznesu.