Biały ekran w WordPressie. Od logów do naprawy krok po kroku

Co oznacza biały ekran i jak go odtworzyć

Biały ekran sam w sobie nie jest diagnozą. To jedynie objaw mówiący, że WordPress lub PHP nie wygenerowały poprawnej odpowiedzi, którą przeglądarka mogłaby wyświetlić. Przyczyn może być wiele, dlatego zamiast szukać jednego „sposobu na biały ekran”, warto najpierw ustalić, na którym etapie przetwarzania żądania pojawia się problem. W nowszych instalacjach WordPressa część błędów krytycznych kończy się komunikatem o problemie technicznym zamiast całkowicie pustej strony. WordPress ma również wbudowany Recovery Mode. Jeśli system wykryje odpowiedni błąd krytyczny PHP, może wysłać administratorowi wiadomość z linkiem pozwalającym zalogować się w specjalnym trybie odzyskiwania. Nie zawsze jednak mechanizm zdąży zadziałać. Błąd może wystąpić wcześniej, wiadomość może nie dotrzeć albo źródłem problemu może być konfiguracja środowiska. Dlatego podstawowym narzędziem diagnostycznym pozostają logi. Na początek warto również sprawdzić, jaki status HTTP zwraca faktyczne żądanie do strony. Możesz wykorzystać terminal: curl -sS -o /dev/null -w "%{http_code}\n" https://example.pl/. Jeżeli otrzymasz 500, trop prowadzi przede wszystkim do błędu po stronie aplikacji, PHP lub konfiguracji serwera. Pusty dokument z kodem 200 wymaga szerszego spojrzenia. Problem może wtedy dotyczyć motywu, mechanizmu generowania treści, cache albo kodu, który kończy wykonywanie bez wyrzucenia typowego błędu HTTP.

Zanim przystąpisz do naprawy, zabezpiecz punkt wyjścia. Awaria nie jest dobrym momentem na wykonywanie wielu zmian jednocześnie. Jeśli wyłączysz kilka wtyczek, zmienisz PHP, podmienisz motyw i dodatkowo zmodyfikujesz wp-config.php, możesz przywrócić witrynę, ale nie będziesz wiedzieć, która operacja naprawdę pomogła. Możesz też dołożyć kolejny problem. Przed diagnostyką wykonaj kopię plików i bazy danych albo upewnij się, że masz aktualny backup, do którego faktycznie możesz wrócić. Zanotuj również, co wydarzyło się bezpośrednio przed awarią. Aktualizacja pluginu? Wdrożenie kodu? Zmiana PHP? Import danych? Przywrócenie kopii? Taki kontekst potrafi skrócić analizę bardziej niż kilkanaście przypadkowych testów.

Diagnostyka oparta na logach - error.log i debug.log

Na początek warto sprawdzić log błędów serwera i PHP. error.log ma jedną ważną przewagę nad mechanizmem debugowania WordPressa: może zarejestrować problem również wtedy, gdy aplikacja nie uruchomiła się na tyle poprawnie, aby zapisać własny debug.log. W cyber_Folks logi możesz sprawdzić bezpośrednio w panelu. W cyber_Admin przejdź do ustawień wybranej strony i sekcji z bieżącymi logami, a następnie wybierz log błędów. Dokładną ścieżkę oraz informacje o logach archiwalnych znajdziesz w instrukcji jak sprawdzić logi strony. Teraz najważniejszy krok. Otwórz log, w drugiej karcie przeglądarki ponownie wywołaj biały ekran, a następnie odśwież log. Nie analizuj od razu każdego ostrzeżenia z ostatnich kilku dni. Szukasz przede wszystkim wpisu odpowiadającego godzinie właśnie wykonanego żądania. Szczególnie interesujące są komunikaty zawierające: PHP Fatal error - błąd zatrzymał wykonywanie skryptu, Uncaught Error lub Uncaught TypeError - kod próbował wykonać niedozwoloną operację, Allowed memory size exhausted - proces wykorzystał dostępną pamięć PHP, Maximum execution time exceeded - skrypt wykonywał się dłużej niż zezwala konfiguracja, Parse error lub syntax error - PHP nie potrafi poprawnie zinterpretować kodu, ścieżki zawierające /wp-content/plugins/, /themes/ lub /mu-plugins/.

Gdy error.log to za mało, uruchom WP_DEBUG i debug.log. Jeżeli log serwera nie daje jednoznacznej odpowiedzi albo chcesz zobaczyć więcej komunikatów generowanych przez sam WordPress, uruchom jego mechanizm debugowania. Oficjalna dokumentacja debugowania WordPressa rozdziela trzy przydatne ustawienia: aktywację debugowania, zapisywanie komunikatów do pliku oraz ich wyświetlanie użytkownikowi. Na stronie produkcyjnej najbezpieczniejszym wariantem jest zapis do logu bez publikowania błędów w przeglądarce:

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

Dodaj konfigurację w wp-config.php przed komentarzem kończącym część ustawień WordPressa. Po zapisaniu zmian ponownie wykonaj czynność prowadzącą do awarii. Standardowo komunikaty WordPressa trafią do: /wp-content/debug.log. Dlatego nie warto ustawiać WP_DEBUG_DISPLAY na true na działającej stronie - komunikat może zawierać pełne ścieżki plików, fragment stosu wywołań oraz inne informacje techniczne, które nie powinny być prezentowane odwiedzającym. Log daje Ci te same tropy bez umieszczania diagnostyki na froncie.

Jak przejść od komunikatu w logu do konkretnego komponentu

Największym błędem podczas czytania logów jest traktowanie każdego wpisu jako równie ważnego. WordPress potrafi generować ostrzeżenia i informacje, które występowały na stronie od tygodni i nie mają żadnego związku z dzisiejszą awarią. Zamiast szukać „jakiegokolwiek błędu”, zastosuj prosty filtr: Czas, rodzaj błędu, ścieżka pliku, ostatnia zmiana. Co widzisz w logu?

Pierwszy trop - co sprawdzić? Jeśli w komunikacie błędu pojawia się jednoznaczna ścieżka do pluginu, zacznij właśnie od niego. Gdy masz dostęp do panelu, możesz go chwilowo dezaktywować. Jeżeli kokpit również nie działa, skorzystaj z WP-CLI, menedżera plików lub FTP. W awaryjnej sytuacji można zmienić nazwę katalogu konkretnej wtyczki w wp-content/plugins/. WordPress przestanie ją ładować. Rób to jednak dla pluginu wskazanego przez log, zamiast od razu zmieniać nazwę całego katalogu plugins. Błąd prowadzi do motywu lub functions.php. Częstym źródłem awarii jest własny kod dopisany do functions.php, zwłaszciej po zmianie fragmentu PHP. Jeżeli znasz moment ostatniej modyfikacji, porównaj plik z wcześniejszą wersją i wycofaj konkretną zmianę. Jeśli chcesz przetestować inny motyw przez WP-CLI, najpierw sprawdź dostępne motywy, a dopiero później aktywuj jeden z nich. Nie zakładaj, że na każdej instalacji znajduje się ten sam domyślny motyw.

Najczęstsze scenariusze i jak je rozwiązać

Allowed memory size exhausted. Ten komunikat mówi wprost, że PHP próbowało wykorzystać więcej pamięci, niż miało do dyspozycji. Samo zwiększenie limitu może przywrócić witrynę, ale nie zawsze oznacza rozwiązanie przyczyny. Jeżeli jedna wtyczka nagle zaczęła konsumować setki megabajtów pamięci, warto ustalić dlaczego. WordPress pozwala określić własny limit pamięci, na przykład: define( 'WP_MEMORY_LIMIT', '256M' ). Wartość nie może jednak ominąć ograniczeń narzuconych przez konfigurację PHP i hosting. Jeśli podniesienie limitu jedynie przesuwa moment wystąpienia problemu, szukaj procesu, który zużywa pamięć.

Biały ekran pojawił się po zmianie PHP. To bardzo cenna informacja diagnostyczna. Jeżeli przed zmianą wersji PHP strona działała, a chwilę później pojawił się błąd krytyczny, przywróć poprzednią konfigurację i sprawdź log. Następnie ustal, który element nie jest zgodny z docelową wersją PHP. Nie traktuj pozostania na starej wersji jako docelowej naprawy. WordPress.org obecnie rekomenduje PHP 8.3 lub nowsze, dlatego właściwym kierunkiem jest aktualizacja problematycznego kodu, motywu lub pluginu. W środowisku cyber_Folks instrukcję zmiany znajdziesz w poradniku jak zmienić wersję PHP domeny. Aktualne wymagania samego WordPressa możesz sprawdzić również bezpośrednio na WordPress.org. Pamiętaj przy tym, że zgodność WordPress Core nie gwarantuje zgodności każdej zainstalowanej wtyczki i każdego własnego fragmentu kodu.

Parse error po ręcznej edycji kodu. Jeśli problem pojawił się zaraz po zapisaniu zmian w functions.php, własnej wtyczce albo wp-config.php, a log pokazuje błąd składni, nie musisz reinstalować WordPressa. Cofnij ostatnią zmianę, korzystając z menedżera plików, FTP lub SSH. Typowe przyczyny są banalne: brak średnika, niedomknięty nawias, pomylony cudzysłów albo fragment kodu wklejony w nieprawidłowym miejscu. Właśnie dlatego przed ręczną edycją pojedynczego pliku warto zrobić jego kopię. Podejrzenie zmodyfikowanych plików WordPress Core. Jeśli wtyczki, motyw i konfiguracja PHP nie wskazują przyczyny, sprawdź integralność plików WordPressa. WP-CLI potrafi porównać pliki Core z oficjalnymi sumami kontrolnymi: wp core verify-checksums --skip-plugins --skip-themes. Nieprawidłowy wynik nie oznacza, że należy od razu usuwać całą instalację. Najpierw ustal, które pliki różnią się od oryginału i dlaczego. Może to być efekt nieudanego wdrożenia, ręcznej modyfikacji albo incydentu bezpieczeństwa.

Jeśli szukasz hostingu z wbudowanym dostępem do logów i narzędzi diagnostycznych w standardzie, dhosting.pl oferuje to bez dodatkowych kosztów.

Jeśli chcesz zgłębić temat, zajrzyj też do naszych powiązanych poradników: Bezpieczeństwo WordPress na hostingu, Hosting dedykowany WordPress, Backup w hostingu - dlaczego jest ważny, Co to jest certyfikat SSL.

Najczęstsze pytania