Jak włączyć debug mode w WordPress?

Tryb debugowania w WordPressie włączysz przez edycję pliku wp-config.php. Wklej poniższe linie bezpośrednio przed komentarzem /* That's all, stop editing! Happy publishing. */:

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

Ta konfiguracja zapisuje błędy do pliku /wp-content/debug.log, ale nie pokazuje ich odwiedzającym. Po zakończeniu diagnostyki ustaw wartości z powrotem na false i usuń plik logu.

Jak edytować plik wp-config.php?

Plik znajdziesz w głównym katalogu instalacji WordPressa, często oznaczonym jako public_html lub www. Do jego edycji potrzebujesz dostępu przez FTP, SFTP albo menedżer plików dostępny w panelu hostingu.

Przed zmianą wykonaj kopię zapasową plików, a najlepiej także bazy danych. Błąd składni w pliku konfiguracyjnym może spowodować niedostępność strony.

Nie otwieraj pliku w programie Microsoft Word ani w edytorze, który dodaje formatowanie. Użyj zwykłego edytora tekstu, na przykład Notepad++ lub Visual Studio Code.

Procedura wygląda następująco:

Połącz się z serwerem przez FTP lub otwórz menedżer plików hostingu.
Przejdź do głównego katalogu WordPressa i znajdź plik wp-config.php.
Wykonaj kopię pliku, a następnie otwórz jego kopię w edytorze tekstu.
Wklej trzy definicje przed komentarzem kończącym konfigurację WordPressa.
Zapisz plik i prześlij go z powrotem na serwer, jeśli korzystasz z FTP.

Jeśli dana stała już znajduje się w pliku, nie dodawaj drugiej definicji. Zmień istniejącą wartość, zachowując średnik na końcu linii.

Co oznaczają stałe debugowania?

Każda z trzech stałych odpowiada za inną część diagnostyki. Ich działanie przedstawia tabela:

Stała	Działanie	Zalecenie dla produkcji
`WP_DEBUG`	Włącza tryb debugowania WordPressa i rejestrowanie komunikatów błędów.	`false`, gdy diagnostyka jest zakończona
`WP_DEBUG_LOG`	Zapisuje błędy do pliku `wp-content/debug.log`.	`false` po zakończeniu prac
`WP_DEBUG_DISPLAY`	Decyduje, czy komunikaty błędów pojawiają się bezpośrednio na stronie.	`false`

Na stronie produkcyjnej WP_DEBUG_DISPLAY powinno pozostać ustawione na false. Komunikaty mogą zawierać ścieżki plików, nazwy wtyczek, zapytania do bazy danych lub inne informacje ułatwiające atak na stronę. Samo logowanie do pliku jest bezpieczniejsze, o ile plik nie jest publicznie dostępny.

Gdzie znaleźć plik debug.log?

Po zapisaniu konfiguracji odwiedź stronę lub podstronę, na której występuje problem. WordPress utworzy plik przy pierwszym zapisanym błędzie. Następnie otwórz katalog:

/wp-content/debug.log

Plik pobierzesz przez FTP albo otworzysz w menedżerze plików hostingu. Jeśli go nie ma, sprawdź następujące elementy:

czy stała WP_DEBUG ma wartość true;
czy stała WP_DEBUG_LOG ma wartość true;
czy edytowany jest właściwy plik wp-config.php;
czy katalog wp-content pozwala serwerowi zapisywać pliki.

Niektóre hostingi zapisują błędy PHP w osobnym logu serwera, na przykład error_log. Jeśli debug.log nadal się nie pojawia, sprawdź w panelu sekcję „Logi błędów” lub skontaktuj się z dostawcą hostingu.

Jak czytać wpisy w debug.log?

Typowy wpis zawiera datę, rodzaj błędu, komunikat, ścieżkę do pliku oraz numer linii. Najpierw odszukaj najnowszy wpis, który powstał po ponownym wywołaniu problemu. Zwróć uwagę na nazwę wtyczki, motywu albo pliku WordPressa wskazanego w komunikacie.

Najczęściej spotykane poziomy komunikatów to:

Notice – informacja o potencjalnym problemie, która zwykle nie zatrzymuje działania strony.
Warning – ostrzeżenie o nieprawidłowym działaniu, przy którym skrypt zazwyczaj nadal się wykonuje.
Fatal error – błąd krytyczny, który przerywa wykonywanie PHP i może powodować biały ekran albo błąd 500.

Jeżeli log wskazuje plik należący do konkretnej wtyczki lub motywu, to ten moduł jest dobrym punktem wyjścia do dalszej diagnostyki. Sam wpis nie zawsze oznacza, że wskazany plik jest jedyną przyczyną problemu, dlatego przed zmianami wykonaj kopię zapasową.

Co zrobić po zakończeniu diagnostyki?

Tryb debugowania nie powinien pozostać włączony bez potrzeby. Po naprawie problemu wykonaj poniższe czynności:

Wyłącz debugowanie – ustaw WP_DEBUG i WP_DEBUG_LOG na false.
Ukryj komunikaty – pozostaw WP_DEBUG_DISPLAY z wartością false.
Usuń log – skasuj wp-content/debug.log albo pobierz go i przechowuj poza publicznym katalogiem serwera.
Sprawdź dostęp – upewnij się, że plik nie jest możliwy do odczytania bezpośrednio przez przeglądarkę.

Najbezpieczniejszy schemat dla działającej strony to logowanie tylko na czas diagnozy, bez wyświetlania błędów użytkownikom. Jeśli komunikaty pozostają niejasne albo dotyczą bazy danych, konfiguracji serwera lub wielu niezależnych komponentów, dalsze zmiany warto poprzedzić konsultacją z administratorem.