Jak włączyć debug php w WordPress?

Błąd 500 w WordPressie nie wskazuje przyczyny awarii. Najszybciej znajdziesz ją, włączając logowanie w pliku wp-config.php i sprawdzając /wp-content/debug.log. Ustaw WP_DEBUG_DISPLAY na false, aby komunikaty nie pojawiały się publicznie.

Jak włączyć debugowanie w WordPressie?

Przed edycją wykonaj kopię pliku wp-config.php. Potrzebujesz dostępu przez FTP, SFTP albo Menedżer plików w panelu hostingu. Plik znajduje się zwykle w głównym katalogu instalacji WordPressa, często obok folderów wp-admin, wp-content i wp-includes.

1. Pobierz kopię wp-config.php albo skopiuj jego zawartość do bezpiecznego miejsca.
2. Otwórz plik w edytorze tekstu dostępnym w panelu hostingu lub na komputerze.
3. Znajdź komentarz /* That's all, stop editing! Happy publishing. */.
4. Wklej poniższe stałe bezpośrednio nad tym komentarzem i zapisz plik.

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

Nie umieszczaj kodu poniżej wskazanego komentarza. W takiej sytuacji konfiguracja może nie zadziałać zgodnie z oczekiwaniami. Jeśli dane stałe już istnieją w pliku, zmień ich wartości zamiast dodawać drugą wersję.

Każda z nich ma osobne zadanie:

Po zapisaniu pliku ponownie wykonaj czynność, która powoduje błąd 500. Jeśli problem pojawia się przy otwieraniu konkretnej podstrony, załaduj ją ponownie. Jeśli występuje podczas zapisywania wpisu, logowania albo składania zamówienia, powtórz właśnie tę operację.

Gdzie znaleźć i jak czytać debug.log?

Standardowy plik logu znajduje się tutaj:

/wp-content/debug.log

Otwórz go przez FTP, SFTP lub Menedżer plików. Nie musisz analizować całej zawartości. Zacznij od wpisów utworzonych w chwili ponownego wystąpienia awarii. Typowa linia zawiera datę i godzinę, rodzaj błędu, opis, ścieżkę do pliku oraz numer linii.

[22-Oct-2026 09:14:03 UTC] PHP Fatal error: Uncaught Error: ...
in /home/konto/public_html/wp-content/plugins/nazwa-wtyczki/plik.php:118

Najważniejsze fragmenty logu to:

• PHP Fatal error – krytyczny błąd, który zatrzymał wykonywanie kodu i często powoduje błąd 500.
• Uncaught Error lub Uncaught TypeError – nieobsłużony błąd w kodzie.
• Allowed memory size exhausted – przekroczenie limitu pamięci PHP.
• Parse error lub syntax error – błąd składni w pliku PHP.
• Ścieżka zawierająca /plugins/ albo /themes/ – wskazówka, że problem może dotyczyć wtyczki lub motywu.

Jeśli ścieżka wskazuje plik wtyczki, nie oznacza to jeszcze, że rozszerzenie jest jedynym winowajcą. Przyczyną może być konflikt z inną wtyczką, motywem, wersją PHP albo własnym kodem. Mimo to od wskazanego elementu warto rozpocząć testy.

Czym różni się debug.log od error.log?

debug.log jest logiem tworzonym przez mechanizm debugowania WordPressa. Zapisuje komunikaty pochodzące z WordPressa, wtyczek, motywów i kodu PHP uruchamianego przez aplikację.

error.log to log serwera lub PHP. Może zawierać błędy powstające zanim WordPress zostanie uruchomiony, na przykład problemy z plikiem .htaccess, konfiguracją PHP, limitem pamięci albo uprawnieniami. Jeśli debug.log pozostaje pusty, sprawdź w panelu hostingu sekcję logów błędów, plik error_log lub katalog /logs/.

W panelu cyber_Admin bieżący log serwera znajdziesz zwykle w ustawieniach witryny, w sekcji logów, po wybraniu wpisu ERROR. Nazwy i lokalizacja opcji mogą zależeć od hostingu.

Co zrobić po znalezieniu przyczyny?

Dobierz działanie do komunikatu i momentu wystąpienia problemu:

• Wtyczka – jeśli nie masz dostępu do kokpitu, zmień nazwę jej folderu w wp-content/plugins/, na przykład z nazwa-wtyczki na nazwa-wtyczki-off. WordPress tymczasowo ją wyłączy.
• Motyw – sprawdź, czy błąd wskazuje pliki motywu. Możesz tymczasowo przełączyć stronę na motyw domyślny, jeśli masz dostęp do panelu lub bazy danych.
• Zmiana wersji PHP – porównaj wymagania wtyczki i motywu z używaną wersją PHP. Jeśli awaria zaczęła się natychmiast po zmianie, testowy powrót do poprzedniej wersji może potwierdzić niezgodność.
• Limit pamięci – przy komunikacie Allowed memory size exhausted sprawdź parametr memory_limit w ustawieniach PHP. Samo zwiększenie limitu nie usunie błędu w kodzie lub wadliwej wtyczki.
• .htaccess – jeśli problem zaczął się po jego edycji, pobierz kopię i tymczasowo zmień nazwę pliku. Nie usuwaj bez analizy reguł odpowiadających za przekierowania i zabezpieczenia.

Jeżeli debug.log nie powstaje, przyczyną może być brak prawa zapisu do katalogu wp-content, przechwytywanie błędów przez hosting albo błąd występujący jeszcze przed uruchomieniem WordPressa. Nie ustawiaj uprawnień katalogu na 777. Bezpieczniej sprawdzić konfigurację hostingu lub poprosić administratora o wskazanie właściwego logu.

Jak wyłączyć debugowanie po diagnozie?

Tryb debugowania włączaj tylko na czas potrzebny do zebrania informacji. Log może zawierać ścieżki serwera, nazwy plików, fragmenty zapytań i inne dane ułatwiające rozpoznanie struktury witryny. Jeśli plik jest dostępny z adresu publicznego, jego zawartość może zostać odczytana przez osobę postronną.

Po naprawie przywróć w wp-config.php ustawienia produkcyjne:

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

Po zakończeniu prac wykonaj następujące czynności:

• Przywróć wartości debugowania w pliku wp-config.php.
• Usuń plik /wp-content/debug.log z serwera.
• Sprawdź, czy strona, panel administracyjny i problematyczna operacja działają poprawnie.
• Usuń tymczasowe kopie lub fragmenty kodu użyte wyłącznie do diagnostyki.

Jeśli błąd nadal występuje po wyłączeniu wtyczek, zmianie motywu i analizie logów, przekaż administratorowi godzinę awarii, adres problematycznej podstrony, opis wykonywanej czynności oraz odpowiedni fragment debug.log lub error.log. To pozwoli kontynuować diagnozę bez zgadywania.