Jak włączyć WP_DEBUG w wp-config.php i sprawdzić log błędów

WP_DEBUG włącza raportowanie błędów, ostrzeżeń i powiadomień PHP w WordPressie, WP_DEBUG_LOG zapisuje komunikaty do pliku, a WP_DEBUG_DISPLAY steruje ich wyświetlaniem w kodzie strony. WordPress przeznacza te ustawienia przede wszystkim do kopii lokalnych i stagingu, a nie do stałego użycia na działającej witrynie.

Ostrzeżenie PHP wskazuje problematyczny lub przestarzały fragment kodu, a błąd krytyczny może przerwać generowanie strony. WP_DEBUG diagnozuje błędy obsługiwane przez WordPress i PHP po uruchomieniu aplikacji; awaria wcześniejsza, na przykład błąd serwera WWW, może wymagać logu hostingu.

Tabela rozróżnia trzy podstawowe stałe. WP_DEBUG_LOG i WP_DEBUG_DISPLAY działają jako ustawienia towarzyszące włączonemu WP_DEBUG.

Włącz diagnostykę na stagingu, jeśli możesz tam odtworzyć problem bez wpływu na klientów. Gdy błąd występuje wyłącznie na produkcji, ogranicz czas działania logowania i zabezpiecz plik przed pierwszym zapisem.

Plik wp-config.php leży zwykle w katalogu instalacji WordPressa obok wp-admin, wp-content i wp-includes, choć może znajdować się katalog wyżej. Zawiera podstawową konfigurację witryny, w tym dane połączenia z bazą, więc nie udostępniaj jego pełnej zawartości osobom, które nie muszą jej znać.

Połącz się przez SFTP albo menedżer plików hostingu i potwierdź domenę oraz katalog aktywnej instalacji. Przy kilku witrynach na jednym koncie łatwo edytować plik stagingu albo innej domeny.

Przed zmianą pobierz kopię pliku i otwórz ją w edytorze tekstowym, nie w edytorze tekstu sformatowanego. Nie twórz nowego wp-config.php dla działającej witryny, jeśli właściwy plik tylko trudno znaleźć. Gdy host przeniósł plik katalog wyżej, sprawdź katalog nadrzędny instalacji.

Wstaw stałe debugowania przed komentarzem kończącym edycję w aktywnym wp-config.php. Dokumentacja WordPress podaje tę lokalizację i zaleca kopię zapasową lub pracę na stagingu przed modyfikacją konfiguracji.

Na stagingu użyj ustawień:

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

Na produkcji najpierw zabezpiecz miejsce zapisu. Preferuj ścieżkę poza publicznym katalogiem witryny, jeśli hosting ją obsługuje:

define( 'WP_DEBUG_LOG', '/sciezka/poza/publicznym_katalogiem/wp-errors.log' );

Jeśli stała już istnieje, zmień jej wartość zamiast dodawać drugą definicję. Wartości true i false zapisuj bez cudzysłowów; tekst 'false' jest ciągiem znaków, a nie wartością logiczną. Nie wklejaj przykładowej ścieżki bez sprawdzenia, czy katalog rzeczywiście istnieje i czy proces PHP ma do niego prawo zapisu.

Po zapisie otwórz stronę i powtórz scenariusz, który wywołuje błąd. Jeśli pojawi się błąd składni PHP albo witryna przestanie działać, przywróć kopię pliku. Gdy awaria blokuje sprzedaż lub formularze, naprawa WordPressa może objąć analizę konfiguracji i logu.

Gdy WP_DEBUG i WP_DEBUG_LOG mają wartość true, WordPress zapisuje komunikaty domyślnie w wp-content/debug.log, jeśli PHP może utworzyć i zapisać plik. WP_DEBUG_LOG może też wskazywać inną poprawną ścieżkę, w tym lokalizację poza katalogiem publicznym.

Na produkcji zabezpiecz dostęp do logu przed włączeniem zapisu, ponieważ plik w wp-content może być osiągalny przez WWW. WordPress wskazuje lokalizację poza publicznym katalogiem jako bezpieczniejszą; jeśli hosting jej nie udostępnia, zablokuj dostęp HTTP do pliku regułą serwera lub ustawieniem hostingu.

Po zabezpieczeniu logu wykonaj czynność wywołującą błąd i zanotuj czas. Pobierz plik przez SFTP lub menedżer plików hostingu, a następnie porównaj godzinę, komunikat i ścieżkę. Wpis może pochodzić z żądania AJAX albo zadania wp-cron, nawet gdy użytkownik nie widzi błędu na stronie.

Nie wysyłaj całego logu publicznym kanałem wsparcia. Zawartość może ujawniać ścieżki serwera, adresy lub dane przekazane w żądaniu; przekaż tylko fragment potrzebny do diagnozy.

Ustaw WP_DEBUG_DISPLAY na false i dodaj @ini_set( 'display_errors', 0 );, aby WordPress nie umieszczał komunikatów debugowania w HTML. W razie potrzeby zapisuj komunikaty do zabezpieczonego logu zamiast pokazywać je użytkownikom.

Konfiguracja PHP hostingu może wpływać na wyświetlanie błędów, dlatego po zmianie otwórz stronę w oknie prywatnym i sprawdź publiczny widok. Szukaj ścieżek serwera, ostrzeżeń PHP i innych szczegółów, których odwiedzający nie powinni widzieć.

Tabela porównuje wartości stałych dla typowych etapów diagnostyki. Produkcyjne logowanie traktuj jako czynność czasową i zabezpiecz lokalizację przed aktywacją.

Staging ogranicza wpływ diagnostyki na klientów, a na produkcji loguj tylko po zabezpieczeniu ścieżki.

Wpis w debug.log zwykle podaje typ komunikatu, czas, ścieżkę pliku i numer linii. Ścieżka w wp-content/plugins może wskazać wtyczkę, a ścieżka w wp-content/themes może wskazać motyw, lecz pojedynczy wpis nie dowodzi, że ten komponent jest jedyną przyczyną.

Zapisz godzinę błędu i zachowaj pierwszy komunikat z danego zdarzenia wraz z kilkoma powiązanymi wpisami. Porównaj czas z aktualizacjami WordPressa, wtyczek, motywu i wersji PHP. Usuń z kopii logu dane, których osoba diagnozująca nie potrzebuje.

Na kopii witryny wyłączaj podejrzane wtyczki pojedynczo i po każdej zmianie odtwórz ten sam scenariusz. Jeśli błąd ustąpi, sprawdź wymagania i zgodność komponentu przed wprowadzeniem zmiany na produkcji.

Jeżeli log wskazuje plik wtyczki, zanotuj jej nazwę i wersję z panelu oraz sprawdź, czy problem pojawia się po wyłączeniu tylko tego rozszerzenia. Jeżeli komunikat wskazuje motyw, wykonaj próbę na kopii po przełączeniu na motyw domyślny. Nie testuj przypadkowego wyłączania komponentów na aktywnym sklepie, bo może to zmienić działanie koszyka lub płatności.

Po zebraniu potrzebnych danych ustaw WP_DEBUG, WP_DEBUG_LOG i WP_DEBUG_DISPLAY na false albo usuń tymczasowe definicje, jeśli wcześniej ich nie było. Wyłączenie stałych i zabezpieczenie pliku logu to osobne działania.

Zachowaj tylko niezbędny fragment logu w kontrolowanym miejscu, a następnie usuń plik z serwera albo ogranicz jego dostęp. Odśwież stronę, która wywoływała problem, i sprawdź, czy publiczny widok nie pokazuje komunikatów PHP.

Zamknij diagnozę krótką kontrolą:

• Stałe debugowania mają docelowe wartości.
• Log nie jest publicznie dostępny.
• Niepotrzebny plik z logiem i lokalne kopie zostały usunięte.
• Strona publiczna nie pokazuje komunikatów PHP.

Jeżeli pozostawiasz log w celu dalszej obserwacji, wyznacz właściciela i termin wyłączenia. Bez tego tymczasowe ustawienie może pozostać aktywne po zakończeniu naprawy.

Jeśli debug.log się nie pojawia, sprawdź, czy WP_DEBUG i WP_DEBUG_LOG mają wartość true, definicje są przed końcowym komentarzem i test rzeczywiście wywołał komunikat PHP. WP_DEBUG_LOG nie zapisuje komunikatów, gdy WP_DEBUG jest wyłączone.

Następnie sprawdź ścieżkę oraz możliwość zapisu przez proces PHP. Nie ustawiaj szerokich praw zapisu; poproś hosting o potwierdzenie uprawnień procesu i wskazanie obsługiwanej lokalizacji logów. Upewnij się też, że patrzysz na plik właściwej instalacji, jeśli konto hostingu obsługuje kilka witryn.

Tabela przypisuje kolejny krok do objawu. Błąd powstały przed uruchomieniem WordPressa może znajdować się wyłącznie w logu PHP hostingu.

Jeśli witryna nadal nie działa, serwis naprawy WordPressa może pomóc ustalić przyczynę i przywrócić stronę.

Najbardziej użyteczny log powstaje, gdy błąd można odtworzyć w znanym scenariuszu na stagingu. Z naszych wdrożeń wynika, że powiązanie czasu komunikatu z działaniem użytkownika i ostatnimi zmianami skraca szukanie źródła problemu.

Zalecamy zapisać, kto włączył diagnostykę, jaki scenariusz sprawdzał i kiedy wyłączył stałe. Krótka notatka ułatwia powtórzenie diagnozy i przypomina o usunięciu logu.

Jeżeli problem dotyczy ogólnej awarii witryny, poradnik naprawy najczęstszych błędów WordPress pomoże rozpoznać właściwą ścieżkę diagnozy. Przy konfliktach komponentów przydatne jest także debugowanie WordPress i analiza logów. Przy zmianach konfiguracji sprawdź rozwiązywanie problemów z konfiguracją WordPress, a przy pustym ekranie naprawę białego ekranu WordPress.

Jeżeli potrzebujesz wykonawcy do analizy błędu i zmian na stronie, usługa naprawy WordPressa obejmuje prace przy tej platformie.

• WordPress: jak bezpiecznie zaktualizować bazę danych po aktualizacji
• Dlaczego sklep internetowy na WordPressie nie działa? Diagnostyka problemów
• Jak użyć wbudowanego trybu naprawy i optymalizacji bazy WordPress
• Błąd strony po przeniesieniu WordPressa: jak znaleźć przyczynę i naprawić problem