Biała strona zamiast witryny — co zrobić, zanim spanikujesz

Wchodzisz na swoją stronę i nie ma nic. Pusto. Ani komunikatu o błędzie, ani logo, ani stopki — czysta biel. Panel administracyjny też nie działa, więc nie możesz nic wyłączyć ani cofnąć.

To najbardziej frustrujący rodzaj awarii, bo WordPress nie mówi ani słowa o tym, co się stało. Ale sama biel jest już informacją, i to całkiem konkretną.

Skąd bierze się pustka

Kiedy PHP napotka błąd, którego nie potrafi obsłużyć, przerywa generowanie strony w połowie. Przeglądarka dostaje odpowiedź, tylko że pustą. Domyślna konfiguracja serwera ukrywa treść błędu przed odwiedzającymi — z dobrym zamiarem, żeby nie pokazywać ścieżek do plików przypadkowym osobom. Efekt uboczny jest taki, że Ty też go nie widzisz.

W środowisku anglojęzycznym nazywa się to White Screen of Death, w skrócie WSOD. Jeśli szukasz rozwiązania w Google, warto wpisać oba warianty — po polsku i po angielsku znajdziesz różne rzeczy.

Przyczyna prawie zawsze siedzi w jednym z czterech miejsc:

• wtyczka — zaktualizowana, świeżo zainstalowana albo taka, która przestała pasować do nowej wersji PHP,
• motyw — najczęściej po aktualizacji albo po ręcznej zmianie w plikach,
• limit pamięci PHP — strona rozrosła się i przestała się mieścić w przydzielonym limicie,
• uszkodzony plik — literówka w functions.php, przerwany transfer FTP, plik nadpisany w połowie.

Sprawdź to najpierw, zanim cokolwiek zmienisz

Zajmie Ci to dwie minuty i często od razu wskaże winowajcę.

Czy panel też jest biały? Wejdź na twojadomena.pl/wp-admin. Jeśli panel działa, a biała jest tylko strona publiczna — problem tkwi w motywie. Jeśli oba są białe, to raczej wtyczka albo pamięć.

Czy biała jest cała strona, czy jedna podstrona? Jeśli tylko jedna, sprawdź, co ją odróżnia. Formularz? Galeria? Koszyk? Winna jest wtyczka odpowiedzialna za ten element.

Co robiłeś tuż przed? Aktualizacja, instalacja, zmiana wersji PHP w panelu hostingu, edycja pliku w edytorze WordPressa. Odpowiedź na to pytanie skraca diagnozę o połowę.

Włącz komunikaty błędów — i przestań strzelać na oślep

To najważniejszy krok, a większość osób go pomija i zamiast tego wyłącza wtyczki na chybił trafił.

Otwórz plik wp-config.php przez FTP albo menedżer plików w panelu hostingu. Znajdź linię:

define( 'WP_DEBUG', false );

Zmień ją na:

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

Odśwież stronę, a potem zajrzyj do pliku wp-content/debug.log. Znajdziesz tam dokładną ścieżkę do pliku i numer linii, w której PHP się wywalił. Zwykle wygląda to tak:

PHP Fatal error: Uncaught Error: Call to undefined function ...
in /wp-content/plugins/nazwa-wtyczki/plik.php on line 214

I już wiesz, która wtyczka jest winna. Bez zgadywania.

Po naprawie ustaw WP_DEBUG z powrotem na false. Zostawiony na produkcji zapisuje wszystko do logu, który z czasem rozrasta się do gigabajtów, a przy nieszczęśliwej konfiguracji bywa publicznie dostępny.

Jak wyłączyć wtyczki bez dostępu do panelu

Jeśli log wskazał wtyczkę albo chcesz po prostu sprawdzić, czy to one — przez FTP zmień nazwę katalogu wp-content/plugins na plugins-off. WordPress nie znajdzie wtyczek i wyłączy wszystkie naraz.

Jeżeli strona wróciła, sprawa jest jasna. Przywróć nazwę katalogu i teraz zmieniaj nazwy pojedynczych wtyczek, aż trafisz na tę właściwą. To nudne, ale skuteczne.

Ten sam trik działa z motywem: zmień nazwę katalogu aktywnego motywu w wp-content/themes. WordPress przełączy się na domyślny, jeśli go masz na serwerze. Strona będzie wyglądać brzydko, ale zadziała — i to potwierdzi, że problem był w motywie.

Kiedy winna jest pamięć

Jeśli w logu widzisz Allowed memory size of ... bytes exhausted, to nie awaria, tylko ciasnota. Dopisz w wp-config.php powyżej linii require_once:

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

Na części hostingów ta linia nie wystarczy, bo limit jest narzucony wyżej, na poziomie serwera. Wtedy trzeba go podnieść w panelu hostingu albo poprosić o to dostawcę — wszystkie trzy miejsca, gdzie zmienia się limit pamięci, opisujemy osobno.

Warto jednak wiedzieć, że rosnące zapotrzebowanie na pamięć to zwykle objaw, nie choroba. Jeśli strona zaczyna potrzebować 512 MB, to gdzieś jest wtyczka, która robi coś nierozsądnego. Podniesienie limitu kupuje czas, ale problem zostaje. Pisaliśmy o tym szerzej przy okazji przyspieszania WordPressa.

Co zrobić, jeśli nic z tego nie pomogło

Zostają dwie możliwości. Pierwsza: uszkodzone pliki rdzenia WordPressa. Pobierz świeżą paczkę z wordpress.org, wgraj przez FTP katalogi wp-admin i wp-includes z nadpisaniem, ale nie ruszaj wp-content ani wp-config.php. Tam siedzą Twoje treści i konfiguracja.

Druga: awaria nie jest po stronie WordPressa, tylko serwera albo bazy danych. Jeśli w logu nie ma nic sensownego, a strona nadal jest biała, sprawdź logi serwera w panelu hostingu.

Kiedy odpuścić i zadzwonić

Powiem szczerze: opisane wyżej kroki większość osób ogarnie samodzielnie w pół godziny, jeśli tylko ma dostęp do FTP i nie boi się otworzyć pliku tekstowego. Warto spróbować.

Ale są momenty, w których lepiej nie eksperymentować:

• strona zarabia i każda godzina przestoju to realne pieniądze,
• nie masz kopii zapasowej, a wchodzisz w edycję plików,
• w logu widzisz coś, co nie wygląda na zwykły błąd wtyczki — obce nazwy plików, dziwne funkcje, kod zakodowany base64. To może być ślad włamania, a wtedy samo przywrócenie białej strony do życia niczego nie rozwiązuje,
• próbowałeś już kilku rzeczy i nie wiesz, co dokładnie zmieniłeś. To najgorszy stan, bo do pierwotnej awarii dochodzą Twoje własne poprawki.

Biała strona to jedna z tych awarii, które przy porządnej diagnozie zamykamy zwykle w godzinę, a nie w trzy — właśnie dlatego, że zaczynamy od logu, nie od zgadywania.

---

Nie chcesz się w to bawić? Naprawimy Twoją stronę — diagnoza i wycena są bezpłatne, a naprawę zaczynamy w ciągu dwóch godzin od zgłoszenia. Rozliczamy się za realny czas pracy, od 120 zł netto za godzinę, i płacisz po wykonaniu.