Biały ekran śmierci w WordPressie: jak odczytać błąd przed naprawą

„Błąd krytyczny” czy biały ekran: ta sama awaria

Biały ekran to najczęściej błąd krytyczny PHP (fatal error): plik strony zażądał czegoś niemożliwego i wykonanie zatrzymało się, zanim cokolwiek zostało wyświetlone. Od wersji 5.2 WordPress przechwytuje te błędy: zamiast pustej strony wyświetla „W witrynie wystąpił błąd krytyczny.” i wysyła e-mail na administracyjny adres e-mail strony.

Strona pozostaje całkiem biała w kilku przypadkach: starsza wersja WordPressa, błąd, który wystąpił przed załadowaniem tego mechanizmu, stała WP_DISABLE_FATAL_ERROR_HANDLER ustawiona na true albo wtyczka pamięci podręcznej, która serwuje pustą stronę zapisaną w czasie awarii. Poniższa metoda działa we wszystkich tych przypadkach.

Trzy kroki mogą poczekać, aż błąd zostanie odczytany: ponowna instalacja WordPressa, usuwanie wtyczek, przywracanie starej kopii zapasowej. Każdy z nich może usunąć ustawienia lub świeże dane, a komunikat o błędzie zwykle wskazuje, który składnik wyłączyć, bez żadnej straty.

Skrót: tryb awaryjny

Gdy WordPress przechwyci błąd, wysyła na administracyjny adres e-mail strony wiadomość z tematem „[Nazwa witryny] Twoja witryna ma problemy techniczne”. Wskazuje ona winną wtyczkę lub motyw i zawiera link, który otwiera panel w trybie awaryjnym.

• W tym trybie wadliwy składnik jest wstrzymany tylko dla Państwa: odwiedzający nadal widzą błąd.
• W menu Wtyczki lub Wygląd > Motywy proszę wyłączyć wskazany składnik, a potem kliknąć „Wyjdź z trybu awaryjnego” na pasku administracyjnym.
• Link jest ważny przez 24 godziny, a WordPress wysyła najwyżej jeden taki e-mail dziennie. Jeśli e-mail nie dotrze, proszę sprawdzić folder spamu, a potem przejść do następnej metody.

Odczytać błąd: dziennik debugowania

Proszę połączyć się ze stroną przez SFTP lub menedżer plików firmy hostingowej, otworzyć wp-config.php w katalogu głównym i zastąpić wiersz define( 'WP_DEBUG', false ); tymi czterema wierszami:

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

Wstawia się je nad komentarzem, który zamyka edytowalną część pliku (/* That's all, stop editing! Happy publishing. */, po angielsku również w WordPressie zainstalowanym w języku polskim). Następnie proszę ponownie załadować stronę z błędem i otworzyć wp-content/debug.log. WP_DEBUG_DISPLAY ustawione na false zatrzymuje komunikaty w pliku, poza stroną, którą widzą odwiedzający.

Jeśli debug.log pozostaje pusty lub się nie pojawia, błąd zapisał bezpośrednio PHP: proszę poszukać pliku error_log w katalogu głównym strony lub w wp-admin albo sekcji logów błędów w panelu firmy hostingowej.

Co mówi komunikat i jaki krok mu odpowiada

Błąd krytyczny mieści się w jednym wierszu: typ błędu, jego opis, potem in i pełna ścieżka pliku oraz numer wiersza. Ścieżka to najcenniejsza informacja: wp-content/plugins/nazwa/ wskazuje wtyczkę, wp-content/themes/nazwa/ motyw.

define( 'WP_MEMORY_LIMIT', '256M' );

Wyłączyć winny składnik bez panelu administracyjnego

Przez SFTP lub menedżer plików

Proszę zmienić nazwę katalogu wtyczki wskazanej w komunikacie, na przykład wp-content/plugins/nazwa-wtyczki na nazwa-wtyczki.off. WordPress nie znajduje już wtyczki i przestaje ją ładować; jej ustawienia pozostają zapisane w bazie danych, a WordPress wyłącza ją przy następnym otwarciu ekranu wtyczek.

W przypadku motywu zmiana nazwy jego katalogu w wp-content/themes przywraca dostęp do panelu, ale odwiedzający widzą pustą stronę, dopóki żaden motyw nie jest aktywny. Proszę od razu otworzyć Wygląd > Motywy: WordPress stwierdza, że aktywny motyw jest uszkodzony, i wraca do zainstalowanego motywu domyślnego.

Przez WP-CLI

wp plugin list --status=active
wp plugin deactivate nazwa-wtyczki
wp theme list
wp theme activate twentytwentyfive

Pierwsze polecenie zachowuje listę aktywnych wtyczek, przydatną przed zbiorczym wyłączeniem. Jeśli samo WP-CLI zatrzymuje się na błędzie, proszę dodać do polecenia --skip-plugins --skip-themes: uruchomi się wtedy bez ładowania wtyczek i motywu. Wtyczki z katalogu wp-content/mu-plugins ładują się mimo to; jeśli błąd pochodzi z jednej z nich, proszę zmienić nazwę jej pliku.

Gdy komunikat nie wskazuje żadnego składnika, wp plugin deactivate --all wyłącza wszystkie wtyczki. Jeśli strona wróci, proszę włączać je po kolei, odświeżając stronę po każdej: ostatnia włączona przed powrotem błędu jest tą właściwą.

Gdy strona wróci

1. Proszę przywrócić define( 'WP_DEBUG', false ); i usunąć WP_DEBUG_LOG z wp-config.php.
2. Proszę usunąć wp-content/debug.log: w katalogu dostępnym z internetu może go przeczytać każdy, a zawiera ścieżki serwera.
3. Proszę zaktualizować lub wymienić winny składnik, czytając jego listę zmian.
4. Proszę wyczyścić pamięć podręczną wtyczki cache oraz pamięć podręczną firmy hostingowej, jeśli ją ma.
5. Na przyszłość: aktualizacje warto testować na kopii strony, zanim trafią na stronę działającą online.