Biały ekran śmierci w WordPressie – wyjaśnienie

Biały ekran śmierci to krytyczny błąd PHP, którego nie widzisz. WordPress napotkał błąd nie do naprawienia w trakcie renderowania, PHP się zatrzymał, a ponieważ na serwerach produkcyjnych wyświetlanie błędów jest wyłączone, zamiast wypisać przyczynę, strona zwróciła pustkę. Naprawa prawie nigdy nie polega na zgadywaniu: włącz dziennik debugowania, otwórz wp-content/debug.log i przeczytaj ostatnią linię z błędem krytycznym. Wskazuje ona dokładny plik – niemal zawsze wtyczkę albo szablon – i ta jedna linia to cała naprawa.

Dlaczego ekran jest pusty

PHP ma ustawienie o nazwie display_errors. Na maszynie deweloperskiej zwykle jest włączone, więc błąd krytyczny wypisuje na ekranie ślad stosu. Na prawdziwym serwerze jest domyślnie wyłączone, bo ujawnianie ścieżek plików i błędów odwiedzającym to problem bezpieczeństwa. Więc kiedy coś rzuci błąd krytyczny – wywołanie funkcji, która już nie istnieje, klasa, która nie została załadowana, błąd składni w aktualizacji wtyczki – PHP umiera i nie wysyła nic. Twoja przeglądarka renderuje pusty dokument. To właśnie ten „biały ekran”.

Od WordPressa 5.2 istnieje mechanizm obsługi błędów krytycznych (WP_Fatal_Error_Handler), który próbuje je przechwycić. Kiedy działa, nie widzisz pustej strony – dostajesz komunikat „W witrynie wystąpił błąd krytyczny”, a do tego e-mail na adres administratora, który często zawiera faktyczny błąd i link do trybu odzyskiwania. Naprawdę pusty ekran zwykle oznacza, że błąd wystąpił, zanim ten mechanizm zdążył zadziałać: błąd parsowania/składni (wychwytywany na etapie kompilacji), uszkodzona wtyczka typu must-use albo błąd krytyczny w pliku functions.php aktywnego szablonu. Tak czy inaczej, przyczyna gdzieś jest zapisana. Musisz tylko włączyć zapisywanie.

Napraw to, po kolei

1. Włącz dziennik. Edytuj wp-config.php przez SFTP i dodaj to powyżej linii /* That's all, stop editing! */:

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

WP_DEBUG_DISPLAY ustawione na false trzyma błędy z dala od publicznej strony, a WP_DEBUG_LOG zapisuje je do wp-content/debug.log. Odśwież raz uszkodzoną stronę, żeby wygenerować świeży wpis.

2. Przeczytaj ostatni błąd krytyczny. Otwórz wp-content/debug.log i spójrz na sam dół:

tail -n 30 wp-content/debug.log

Szukasz linii takiej jak ta:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

Ścieżka wskazuje winowajcę: plugins/some-addon. To twoja odpowiedź. Jeśli ślad jest długi albo komunikat jest zagadkowy (Allowed memory size exhausted, Cannot redeclare, nazwa klasy, której nie rozpoznajesz), wklej go do naszego dekodera dziennika błędów – usuwa on szum, mówi, na którą wtyczkę albo szablon wskazuje ścieżka, i wyjaśnia, co oznacza dany typ błędu.

3. Wyłącz wskazany komponent. Nie masz dostępu do /wp-admin, więc zrób to przez SFTP. Zmień nazwę folderu problematycznej wtyczki, np. some-addon → some-addon.off. WordPress nie może załadować folderu, którego nie znajdzie, więc wyłącza wtyczkę i witryna wraca do życia. Jeśli dziennik wskazuje na szablon, przełącz się na domyślny szablon, zmieniając nazwę folderu aktywnego szablonu – WordPress wróci do dołączonego twentytwentysomething.

4. Jeśli dziennik nie chce się zapisywać, oznacza to, że wp-content nie jest zapisywalny albo błąd jest na poziomie serwera. Sprawdź zamiast tego dziennik błędów PHP na hostingu:

find . -name "error_log" -newermt "-1 hour"

Ta sama informacja, inny plik. Stosy cPanel/Apache często zrzucają plik error_log w katalogu głównym witryny albo w problematycznym katalogu.

Czego nie robić

Nie zwiększaj tylko limitu pamięci. Najczęściej powtarzana rada w sieci to podbicie WP_MEMORY_LIMIT do 256M albo 512M. To naprawia WSOD tylko wtedy, gdy dziennik faktycznie mówi Allowed memory size of N bytes exhausted. Jeśli błąd brzmi Call to undefined function, więcej pamięci nic nie da – zmieniłeś ustawienie na chybił trafił, a ekran nadal jest biały. Najpierw przeczytaj dziennik, a dopiero potem zwiększaj pamięć, jeśli to pamięć jest wskazanym problemem.

Nie czyść pamięci podręcznej i nie nazywaj tego diagnozą. Biały ekran to PHP umierający na serwerze, zanim powstanie jakikolwiek HTML. Przestarzały zasób z pamięci podręcznej nie może spowodować pustego dokumentu. (Uszkodzona wtyczka do cache’owania może – ale dziennik ją wskaże, o to właśnie chodzi.)

Nie edytuj ani nie instaluj ponownie rdzenia WordPressa. Błąd krytyczny prawie nigdy nie jest w wp-includes czy wp-admin; jest we wtyczce albo szablonie, na który wskazuje dziennik. Ponowna instalacja rdzenia jest powolna, ryzykowna i leczy objaw, którego nie potwierdziłeś.

Nie wyłączaj wszystkich wtyczek i nie włączaj ich po kolei na ślepo. Bisekcja działa, ale to powolna droga. Dziennik wskazuje dokładny folder w jednym kroku. Po metodę „wyłącz wszystko” sięgaj tylko wtedy, gdy nie ma w ogóle żadnego czytelnego błędu.

Nie zostawiaj display_errors włączonego na produkcji. Gdy witryna wróci do życia, usuń definicje debugowania (albo ustaw WP_DEBUG z powrotem na false). Błędy wypisywane odwiedzającym ujawniają twoje ścieżki.

Nadal utknąłeś?

Jeśli dziennik wskazuje wtyczkę, ale jej wyłączenie nie usuwa ekranu, oznacza to, że pod pierwszym błędem krytycznym kryje się drugi – włącz dziennik z powrotem i przeczytaj nową ostatnią linię; błędy krytyczne się nawarstwiają. Jeśli to sam komunikat jest murem nie do przejścia, wrzuć go do dekodera dziennika błędów i pozwól mu przetłumaczyć typ błędu oraz ścieżkę pliku za ciebie. Biały ekran pozostaje tajemnicą tylko dopóki dziennik jest wyłączony.