WordPress wyswietlanie bledow

WordPress – wyświetlanie błędów i włączenie trybu debugowania

Podczas pracy z WordPressem może zdarzyć się, że strona przestanie działać prawidłowo, pojawi się biały ekran, komunikat „There has been a critical error on this website” albo konkretny błąd PHP. W takiej sytuacji pomocne jest włączenie trybu debugowania WordPress, który pozwala znaleźć przyczynę problemu.

Jak włączyć wyświetlanie błędów WordPress?

Za wyświetlanie i zapisywanie błędów odpowiadają przede wszystkim ustawienia w pliku:

wp-config.php

Plik znajduje się w głównym katalogu instalacji WordPressa.

Najczęściej można znaleźć w nim:

define( 'WP_DEBUG', false );

Aby włączyć debugowanie, zmień wartość na:

define( 'WP_DEBUG', true );

Po zapisaniu zmian WordPress zacznie rejestrować błędy związane między innymi z PHP, motywami i wtyczkami.

Wyświetlanie błędów bezpośrednio na stronie

Podczas pracy na stronie testowej można również włączyć wyświetlanie błędów:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );

Po odświeżeniu strony komunikat błędu może zostać wyświetlony bezpośrednio w przeglądarce.

Nie zaleca się jednak pozostawiania tej konfiguracji na działającej stronie produkcyjnej. Komunikaty PHP mogą ujawniać ścieżki plików, nazwy funkcji lub inne informacje techniczne.

Bezpieczniejsze rozwiązanie – zapis błędów do pliku

Na działającej stronie lepszym rozwiązaniem jest zapisanie błędów do pliku debug.log bez wyświetlania ich użytkownikom:

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

Błędy będą zapisywane zazwyczaj w:

/wp-content/debug.log

Dzięki temu można sprawdzić przyczynę problemu bez pokazywania szczegółów technicznych odwiedzającym stronę.

Jak znaleźć plik debug.log?

Jeżeli korzystasz z FTP lub menedżera plików hostingu, przejdź do:

wp-content

i sprawdź, czy znajduje się tam:

debug.log

Można również wykorzystać panel hostingowy lub SSH, jeżeli hosting udostępnia takie możliwości.

Przykładowy wpis może wyglądać tak:

PHP Fatal error: Uncaught Error...

albo:

PHP Warning: Undefined variable...

W przypadku błędu krytycznego szczególnie istotne są:

• nazwa pliku,
• numer linii,
• nazwa wtyczki lub motywu,
• rodzaj błędu.

Jak rozpoznać, która wtyczka powoduje problem?

Jeżeli w logu pojawia się ścieżka:

/wp-content/plugins/nazwa-wtyczki/

jest to mocna wskazówka, że problem może powodować dana wtyczka.

Przykład:

/wp-content/plugins/example-plugin/includes/file.php:125

oznacza, że błąd wystąpił w pliku znajdującym się w katalogu tej wtyczki.

Podobnie:

/wp-content/themes/nazwa-motywu/

wskazuje na kod związany z aktywnym motywem.

Nie oznacza to jednak automatycznie, że wskazany komponent jest jedyną przyczyną problemu. Błąd może wynikać również z konfliktu pomiędzy wtyczkami, motywem lub wersją PHP.

Debugowanie WordPress po aktualizacji PHP

Tryb debugowania jest szczególnie przydatny po zmianie wersji PHP.

Przykładowo strona może działać prawidłowo na PHP 8.1, a po przełączeniu na PHP 8.3 pojawić się błąd związany z niekompatybilną wtyczką.

Log może wtedy wskazać konkretny plik i linię, w której wystąpił problem.

Przed zmianą PHP na stronie produkcyjnej warto więc wykonać kopię zapasową i sprawdzić zgodność używanych wtyczek oraz motywu.

Debugowanie WordPress a biały ekran

Jeżeli WordPress wyświetla tylko pustą białą stronę, włączenie zapisywania błędów do debug.log może pomóc ustalić przyczynę.

W pierwszej kolejności warto zastosować:

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

Następnie należy odtworzyć problem, wejść na stronę i sprawdzić:

wp-content/debug.log

Ostatnie wpisy w pliku często wskazują komponent odpowiedzialny za błąd.

Debugowanie WordPress – ważne zasady bezpieczeństwa

Tryb debugowania jest bardzo przydatny, ale należy korzystać z niego rozsądnie.

Na stronie produkcyjnej nie powinno się pozostawiać:

define( 'WP_DEBUG_DISPLAY', true );

ponieważ odwiedzający może zobaczyć szczegóły błędów.

Po zakończeniu diagnostyki można wyłączyć debugowanie:

define( 'WP_DEBUG', false );

Jeżeli korzystaliśmy z debug.log, warto również usunąć stary plik z błędami, szczególnie jeśli zawiera informacje techniczne dotyczące strony.

Przydatne ustawienia WordPress Debug

Do diagnostyki można wykorzystać:

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

Do testowania na stronie roboczej:

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

Pierwsza konfiguracja jest zdecydowanie bezpieczniejsza dla działającej strony.

Co zrobić po znalezieniu błędu?

Samo włączenie debugowania nie naprawia problemu. Log pozwala przede wszystkim ustalić jego źródło.

Po znalezieniu błędu można:

• zaktualizować problematyczną wtyczkę,
• wyłączyć konfliktującą wtyczkę,
• zmienić wersję PHP,
• poprawić kod motywu,
• sprawdzić konflikt kilku rozszerzeń,
• przywrócić kopię zapasową,
• skontaktować się z autorem wtyczki,
• poprawić własny kod PHP.

Warto najpierw zidentyfikować przyczynę, a dopiero później wykonywać zmiany.

WordPress – wyświetlanie błędów podczas pracy nad stroną

Włączenie debugowania jest jednym z podstawowych sposobów diagnozowania problemów z WordPressem. Szczególnie przydatne jest podczas aktualizacji WordPressa, wtyczek, motywów oraz wersji PHP.

Na stronie produkcyjnej najlepszym rozwiązaniem jest zazwyczaj zapisywanie błędów do debug.log bez ich wyświetlania użytkownikom. Dzięki temu można uzyskać potrzebne informacje diagnostyczne, jednocześnie nie ujawniając szczegółów technicznych osobom odwiedzającym stronę.