Biały ekran (WSOD - white screen of death) to krytyczny błąd PHP, przy którym serwer nie wyświetla żadnego komunikatu. Przyczyny są te same co przy błędzie 500 - wadliwa wtyczka, motyw, wyczerpana pamięć - różnica polega tylko na tym, że nie widzisz treści błędu. Pierwszym krokiem jest więc zawsze: zmusić serwer, żeby powiedział, co się stało.
Krok 1: sprawdź skrzynkę administratora
Od wersji 5.2 WordPress ma wbudowaną ochronę przed błędami krytycznymi: wysyła na adres administratora wiadomość „Twoja witryna ma problem techniczny” z linkiem do trybu odzyskiwania. Link loguje Cię do panelu z wyłączonym wadliwym dodatkiem - możesz go tam dezaktywować na stałe jednym kliknięciem. Jeśli ten mail jest, oszczędza całą dalszą diagnostykę.
Krok 2: odczytaj treść błędu
Brak maila? Zajrzyj do logu błędów w panelu hostingu albo do pliku error_log w katalogu strony. Możesz też włączyć zapis błędów samodzielnie - w wp-config.php dodaj przed linią „That’s all”:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Po odświeżeniu strony błąd trafi do pliku wp-content/debug.log. Wpis w rodzaju PHP Fatal error: ... in /wp-content/plugins/xyz/plik.php wskazuje winowajcę wprost. Po naprawie wyłącz debugowanie (wartości na false).
Krok 3: wyłącz winowajcę bez dostępu do panelu
Biały ekran często obejmuje też wp-admin - wtedy działasz przez FTP (jak się połączyć - w przewodniku o FTP i SFTP):
- Wtyczka wskazana w logu: zmień nazwę jej katalogu w
wp-content/plugins/(np. naxyz.off) - WordPress natychmiast ją pominie. - Nie wiesz która: przemianuj cały katalog
plugins, sprawdź stronę, przywróć nazwę i włączaj wtyczki po jednej w panelu. - Motyw: przemianuj katalog aktywnego motywu w
wp-content/themes/- WordPress przełączy się na domyślny. Ten wariant jest najczęstszy po ręcznych zmianach wfunctions.php.
Krok 4: przyczyny spoza kodu
- Wyczerpana pamięć PHP - log z wpisem „Allowed memory size exhausted”; jak podnieść limit, opisujemy w tekście o limicie pamięci PHP w WordPressie.
- Zmiana wersji PHP na serwerze - stary kod na nowym PHP potrafi paść bez ostrzeżenia; cofnij wersję w panelu i zaplanuj aktualizacje (kontekst: PHP 8.4 na hostingu).
- Niedokończona aktualizacja - plik
.maintenancew katalogu strony po przerwanej aktualizacji trzyma stronę w trybie konserwacji; usuń go przez FTP. - Pusta strona tylko miejscami (np. sam koszyk) - zwykle konflikt wtyczki z motywem na konkretnej podstronie; diagnoza ta sama, przez debug.log.
Jak zapobiegać
- Testuj większe zmiany na kopii roboczej, nie na żywej stronie - część hostingów oferuje staging jednym kliknięciem.
- Aktualizuj wtyczki partiami, nie wszystkie naraz - łatwiej wskazać winną.
- Trzymaj automatyczne kopie zapasowe z możliwością szybkiego przywrócenia - zasady w tekście o kopiach zapasowych na hostingu.
Najczęstsze pytania
Biały ekran tylko w wp-admin, strona działa - co robić?
To samo, ale zacznij od podniesienia limitu pamięci - panel potrzebuje jej więcej niż front strony. Potem standardowo: log i wtyczki (najczęściej te ładowane tylko w zapleczu).
Czy biały ekran to wina hostingu?
Rzadko - zwykle to kod strony. Hosting bywa winny, gdy biały ekran pojawia się falami bez żadnych zmian na stronie (limity zasobów) albo po zmianie konfiguracji serwera. Wtedy porównaj logi z godzinami awarii i dopytaj pomoc techniczną.
Widzę „Wystąpił krytyczny błąd na Twojej witrynie” - to biały ekran?
To jego nowsze, ładniejsze opakowanie - WordPress przechwycił błąd krytyczny. Diagnoza identyczna: mail z trybem odzyskiwania albo debug.log; pokrewny scenariusz z kodem 500 opisujemy w tekście o błędzie 500 w WordPressie.
Podsumowanie
Biały ekran różni się od zwykłej awarii tylko brakiem komunikatu - więc najpierw go zdobądź (mail odzyskiwania, error_log, WP_DEBUG_LOG), a potem wyłącz wskazany dodatek przez FTP. Cała operacja rzadko trwa dłużej niż kwadrans, a kopia zapasowa sprowadza najgorszy scenariusz do jednego kliknięcia „przywróć”.