Biały ekran WordPressa: diagnoza i naprawa WSoD

Zapisz adres, godzinę ze strefą czasową i czynność, po której pojawia się problem. Sprawdź, czy pusta jest strona główna, pojedynczy wpis, panel administracyjny czy tylko określony widok. Porównaj sesję zalogowaną i niezalogowaną, jeśli nie wymaga to wykonywania rzeczywistych operacji biznesowych. Różnica pomaga ustalić rolę uprawnień, cache lub konkretnego komponentu.

W narzędziach przeglądarki obejrzyj kod odpowiedzi i treść dokumentu. Biała strona z błędem serwera różni się od dokumentu z poprawnym HTML, którego elementy zostały ukryte przez CSS. Odpowiedź z warstwy proxy może nie dotrzeć do WordPressa. Sam brak widocznego komunikatu nie dowodzi błędu PHP, a kod 200 nie gwarantuje poprawnego działania.

Sprawdź ostatnie zmiany: aktualizację wtyczki, motywu, wersji PHP, wdrożenie kodu lub konfigurację cache. Zbieżność czasowa jest wskazówką, nie rozstrzygnięciem. Zanotuj wersje i dostępne logi, zanim zaczniesz cokolwiek zastępować. Nie czyść od razu wszystkich śladów ani nie wykonuj kilku zmian jednocześnie, bo utrudnisz porównanie.

Zabezpiecz bieżące pliki, bazę oraz konfigurację zgodnie z dostępnymi narzędziami i uprawnieniami. Kopia stanu awarii może być potrzebna do analizy nawet wtedy, gdy masz wcześniejszy backup. Ustal, czy sklep nadal przyjmuje dane przez webhooki, integracje lub zadania w tle. Pusty frontend nie oznacza, że wszystkie zapisy ustały.

Jeżeli dysponujesz kopią testową, odłącz od niej wysyłkę, płatności i pomiar. Problemu z produkcji nie wolno odtwarzać przez prawdziwe zamówienia ani wiadomości. Pierwszym wynikiem diagnozy powinien być konkretny zakres objawu oraz wskazanie warstwy, w której szukasz dalej.

Biały ekran jest objawem wspólnym dla różnych usterek. Poniższa tabela pomaga wybrać kolejny odczyt, ale nie zastępuje logu z aktualnego żądania. W jednej instalacji mogą jednocześnie wystąpić błędny komponent i stary cache, dlatego potwierdzaj każdą hipotezę oddzielnie.

Odczytaj komunikat do końca, razem z typem błędu, plikiem i numerem linii. Ścieżka wskazuje miejsce ujawnienia problemu, które nie zawsze jest miejscem jego powstania. Wywołanie funkcji z wtyczki może nie działać dlatego, że wcześniej nie załadowano zależności. Ostrzeżenie sprzed kilku dni nie tłumaczy automatycznie obecnego pustego ekranu.

Przy poprawnym HTML skontroluj konsolę i zasoby, zanim przejdziesz do wyłączania PHP. Przy odpowiedzi generowanej przez proxy sprawdź logi tej warstwy oraz serwera źródłowego. Jeśli potrzebujesz szerszego kontekstu opóźnień, skorzystaj z diagnozy wydajności WordPressa. Długi czas odpowiedzi i pusta treść mogą się łączyć, ale wymagają potwierdzenia wspólnej przyczyny.

Najpierw sprawdź log PHP udostępniany przez hosting oraz log serwera WWW. Błąd powstający przed uruchomieniem WordPressa może nie znaleźć się w jego własnym pliku diagnostycznym. Dopasuj wpis do czasu, adresu i procesu obsługującego problematyczne żądanie. Upewnij się, jaką strefę czasową stosuje dana warstwa.

Jeżeli potrzebujesz diagnostyki WordPressa, sprawdź istniejące definicje w wp-config.php. Nie dopisuj drugi raz tych samych stałych. Dokumentacja debugowania WordPressa opisuje WP_DEBUG, WP_DEBUG_LOG i WP_DEBUG_DISPLAY. Do próby na kopii można zastosować poniższy układ po dostosowaniu prywatnej ścieżki:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/prywatna-sciezka-poza-www/wordpress-debug.log');
define('WP_DEBUG_DISPLAY', false);

Ścieżka jest przykładem, nie gotową lokalizacją na Twoim serwerze. Katalog musi istnieć, być dostępny do zapisu dla właściwego procesu i pozostawać poza publicznym katalogiem WWW. Ustawienia umieść w odpowiednim miejscu konfiguracji przed uruchomieniem WordPressa. Gdy hosting ogranicza konfigurację logów, skorzystaj z przewidzianego mechanizmu i pomocy administratora.

Odtwórz tylko bezpieczny odczyt powodujący błąd, a potem sprawdź nowe wpisy. Nie generuj rzeczywistych wysyłek, płatności ani zapisów klientów. Zapisz potrzebny fragment diagnostyczny po usunięciu sekretów i danych osobowych. Pełny log może zawierać adresy, parametry żądań oraz informacje o konfiguracji, których nie należy publikować w zgłoszeniu.

Wyłącz tymczasową diagnostykę po zakończeniu i ustal retencję pliku. Nie pozostawiaj logowania bez kontroli rozmiaru. Brak nowych wpisów nie dowodzi braku błędu: sprawdź uprawnienia, rzeczywistą ścieżkę i to, czy żądanie w ogóle dotarło do PHP. Publiczne wyświetlanie ostrzeżeń nie jest potrzebne do ich odczytu przez osobę diagnozującą.

Jeżeli masz już wiadomość WordPressa z informacją o błędzie i linkiem do Recovery Mode, sprawdź jej autentyczność oraz właściwą domenę. Nie udostępniaj linku publicznie. W tej procedurze nie wywołuj specjalnie wysyłki takiej wiadomości. Alternatywą pozostają istniejące logi i dostęp administracyjny zgodny z uprawnieniami.

Recovery Mode może umożliwić wejście do panelu mimo problemu z wtyczką lub motywem. Wstrzymanie komponentu w sesji diagnostycznej nie oznacza, że publiczna strona została naprawiona. Po znalezieniu przyczyny potrzebna jest zgodna poprawka i osobna kontrola zwykłego widoku, poza trybem odzyskiwania.

Jeśli log wskazuje konkretną wtyczkę, sprawdź jej wersję, zależności i ostatnią zmianę. Na kopii porównaj zachowanie po kontrolowanym wyłączeniu tego komponentu. Zapisz stan aktywacji i ustawienia. Nie zaczynaj od zmiany nazwy całego katalogu plugins, bo możesz stracić jasny obraz aktywnych dodatków i uruchomić witrynę bez funkcji potrzebnych do ochrony lub obsługi danych.

Gdy panel jest niedostępny, sposób izolacji przez system plików wymaga planu dla konkretnego katalogu, zależności i powrotu do pierwotnego stanu. Przywrócenie nazwy katalogu nie powinno być traktowane jako dowód odtworzenia całej konfiguracji aktywacji. Sprawdź ją jawnie po naprawie. Pamiętaj też o wtyczkach MU oraz drop-inach, które nie są zwykłymi pozycjami wyłączanymi w ten sam sposób.

Przy konflikcie bez wyraźnego wskazania można na kopii ograniczać zestaw dodatków etapami, zapisując każdy wynik. Metoda dzielenia grup nie rozstrzyga automatycznie konfliktów wymagających kilku komponentów jednocześnie. Po znalezieniu podejrzanej pary odtwórz warunki i zweryfikuj zależność, zamiast obwiniać ostatnio włączony dodatek. Nie usuwaj jego tabel ani ustawień jako elementu diagnostycznego wyłączenia.

Jeśli panel działa, a awaria dotyczy frontendu lub określonego szablonu, sprawdź logi związane z renderowaniem motywu. Ostatnia zmiana w functions.php, szablonie częściowym albo integracji z polami może być użytecznym tropem. Nie edytuj przypadkowo plików bez zachowania oryginalnej wersji i możliwości porównania różnic.

Na kopii możesz przeprowadzić kontrolę ze znanym, zgodnym motywem dostępnym w instalacji. Wcześniej zapisz aktywny motyw, ustawienia i zależności. Samo przełączenie wyglądu może wyłączyć komponenty potrzebne stronie, dlatego nie jest obojętnym eksperymentem na działającym sklepie. Wynik próby pokazuje wpływ konfiguracji, a nie gotowość do pozostawienia zastępczego motywu.

Przy motywie potomnym sprawdź także rodzica. Usunięcie lub zmiana nazwy jednego katalogu nie gwarantuje poprawnego przejścia na drugi. Motyw może wymagać określonej wersji rodzica, wtyczki lub funkcji dostępnej dopiero po inicjalizacji. Sprawdź, czy pliki i zależności odpowiadają wersji wdrożenia, która działała przed awarią.

Błąd danych również może ujawnić się w szablonie. Funkcja oczekująca tablicy zamiast pustej wartości albo identyfikatora obrazu może zatrzymać render tylko jednego wpisu. Zweryfikuj problem na syntetycznych danych oraz popraw obsługę braku wyniku. Szczegóły opisuje bezpieczne użycie ACF w WordPressie.

Po poprawce sprawdź reprezentatywne widoki, nie tylko stronę główną. Uwzględnij wpis, archiwum, wyszukiwanie i ekran wykorzystujący naprawiany komponent. Porównaj także wersję mobilną oraz sesję niezalogowaną. Widoczny nagłówek nie potwierdza, że cały szablon wykonał się bez błędu ani że dalsze elementy odzyskały działanie.

Komunikat o wyczerpaniu pamięci oznacza, że proces przekroczył dostępny limit, ale nie wyjaśnia przyczyny zużycia. Sprawdź miejsce błędu oraz zakres operacji: render strony, przetwarzanie obrazu czy zadanie w tle. Nieskończona pętla, zbyt duży wynik zapytania i rzeczywiście zbyt niski limit wymagają różnych rozwiązań.

Ustal efektywną konfigurację PHP dla żądania WWW. Wartość widoczna w terminalu może dotyczyć innego trybu lub innego pliku konfiguracji. Stałe WordPressa i ustawienia panelu hostingu nie gwarantują, że aplikacja może przekroczyć ograniczenia procesu narzucone przez serwer. Poproś o potwierdzenie właściwej puli PHP, jeśli nie masz dostępu do jej ustawień.

Nie wpisuj automatycznie 512 MB pamięci ani 300 sekund wykonania do każdej instalacji. Większy limit może ukryć objaw, zwiększyć obciążenie lub tylko przesunąć moment awarii. Jeśli podniesienie limitu jest uzasadnione, określ wartość wynikającą z pomiaru, zakres zmiany i warunek wycofania. Ponownie sprawdź zachowanie po usunięciu przyczyny nadmiernego zużycia.

Podobnie potraktuj limity liczby danych formularza i czasu pracy. Nie każdy niepełny zapis oznacza potrzebę ich zwiększenia, a timeout może wystąpić także w proxy lub usłudze zależnej. Zestaw logi odpowiednich warstw. Brak dostępu do konfiguracji jest powodem przekazania konkretnego komunikatu administratorowi, a nie tworzenia kilku sprzecznych plików ustawień.

Po zmianie sprawdź nie tylko brak białego ekranu, ale też nowe błędy i zużycie zasobów. Poprawny pojedynczy odczyt nie dowodzi stabilności zadania, które nadal przetwarza nieograniczony zbiór. Pomiar wykonuj na reprezentatywnych danych i z kontrolowanym zakresem, bez uruchamiania prawdziwych operacji klientów.

Plik .htaccess ma znaczenie tylko tam, gdzie używana konfiguracja serwera go interpretuje. Nginx nie naprawi problemu po zmianie reguł przeznaczonych dla Apache. Przed korektą ustal technologię i zachowaj bieżące reguły, w tym przekierowania oraz zabezpieczenia. Zastąpienie całego pliku minimalnym przykładem może przywrócić jedną stronę, a uszkodzić inne funkcje.

Jeżeli awaria nastąpiła po zmianie PHP, sprawdź zgodność wtyczek, motywu i wymaganych rozszerzeń. Lista wspieranych wersji PHP pomaga ocenić możliwy wariant, ale nie zastępuje testu aplikacji. Nie traktuj powrotu do niewspieranej wersji jako standardowej naprawy. Zapisz też różnice ustawień między starą a nową konfiguracją.

Po przerwanej aktualizacji sprawdź stan procesu i log operacji. Plik .maintenance znajduje się w katalogu głównym WordPressa, nie w wp-content. Zanim uznasz go za pozostałość, potwierdź, że aktualizacja faktycznie się zakończyła i nie trwa inny proces. Usunięcie znacznika podczas zapisu plików może odsłonić niespójne wdrożenie. Dodatkowe sytuacje opisuje FAQ diagnostyczne WordPressa.

Integralność plików rdzenia można sprawdzić przez mechanizm sum kontrolnych WP-CLI, dobierając rzeczywistą wersję i lokalizację instalacji. Dokumentacja wp core verify-checksums określa zakres kontroli. Zgodne sumy nie potwierdzają czystości całej witryny, wtyczek, plików dodatkowych ani bazy danych.

Rozbieżność trzeba wyjaśnić przed zastępowaniem plików. Nie nadpisuj rdzenia przypadkową wersją i nie usuwaj wp-content lub konfiguracji jako części takiej operacji. Nazwa funkcji base64, świeża data modyfikacji czy nietypowa długość index.php nie są samodzielnym dowodem infekcji. Jeśli podejrzewasz incydent, zachowaj materiał do analizy i ogranicz dalsze zmiany.

Pełne przywrócenie backupu jest jedną z możliwych dróg, ale wymaga porównania jego daty z nowszymi zapisami. W sklepie mogą to być zamówienia, stany magazynowe, płatności i zwroty, a na stronie usługowej zgłoszenia lub nowe treści. Przywrócenie samej bazy z wcześniejszej chwili może cofnąć informacje nadal obecne w zewnętrznych systemach.

Zanim wybierzesz restore, ustal zakres uszkodzenia oraz najmniejszą wystarczającą zmianę. Czasem potrzebna jest korekta jednego pliku lub zgodna wersja dodatku, a nie cofnięcie wszystkich danych. Przy pełnym odtworzeniu zaplanuj zabezpieczenie obecnego stanu, kontrolę spójności plików i bazy oraz uzgodnienie nowych zapisów z integracjami. W tej procedurze nie wykonuj rzeczywistego restore w ramach próby.

Sprawdź możliwość odtworzenia na izolowanym środowisku zgodnie z poradnikiem diagnostyki kopii zapasowych. Pomyślny status tworzenia archiwum nie potwierdza kompletności danych ani poprawnego uruchomienia aplikacji. Kopia bez zależnych mediów, konfiguracji lub właściwej wersji kodu może nie rozwiązać problemu.

Jeśli przyczyną było naruszenie bezpieczeństwa, samo przywrócenie wcześniejszych plików nie zamyka incydentu. Trzeba wyjaśnić drogę dostępu, ocenić uprawnienia i zaplanować odpowiednie zmiany po zabezpieczeniu dowodów. Ogólne zasady prewencji opisuje ochrona WordPressa przed atakami.

Po naprawie zapisz przyczynę, poprawkę i warunek wykrycia nawrotu. Aktualizacje sprawdzaj na kopii, utrzymuj listę zależności i kontroluj dostęp do logów. Monitoring powinien badać oczekiwany widok, ponieważ odpowiedź HTTP 200 może towarzyszyć pustej stronie. Nie zastępuj utrzymania samym harmonogramem automatycznych aktualizacji.

Naprawa kończy się po sprawdzeniu funkcji, nie po pierwszym pojawieniu się treści. Zweryfikuj adres z pierwotnym problemem, panel i reprezentatywne widoki. Sprawdź logi z nowych żądań, stan aktywacji dodatków, motyw oraz ustawienia diagnostyczne. Jeśli użyto Recovery Mode, kontrola publiczna musi odbyć się również poza tą sesją.

Warstwy cache odświeżaj świadomie po wdrożeniu poprawki. Ustal, czy oglądasz aktualny HTML, czy poprzednią odpowiedź. Nie używaj wyczyszczenia cache jako zamiennika wyjaśnienia błędu, który może wrócić przy kolejnym odczycie. Odbiór formularzy i sklepu prowadź na kopii z mockami, bez realnych wysyłek, płatności i sztucznych konwersji.

Przekaż sprawę osobie technicznej, jeśli brak dostępu do potrzebnych logów, pojawiają się oznaki incydentu albo kolejna próba zagraża danym. Przygotuj adres, godzinę ze strefą, objaw, wersje, ostatnie zmiany i bezpiecznie zredagowany fragment błędu. Dodaj informację o dostępnej kopii oraz wykonanych już działaniach. Nie wysyłaj pełnych haseł, tokenów ani danych klientów zwykłym zgłoszeniem.

Zakres pomocy możesz omówić przez kontakt i sprawdzić usługi WordPress. Czas i koszt zależą od przyczyny, dostępu oraz zakresu odzyskiwania; sam biały ekran nie uzasadnia obietnicy naprawy w określonej liczbie minut. Najbardziej użyteczny kolejny krok to zebranie dowodu pozwalającego wybrać konkretną, odwracalną poprawkę zamiast serii zmian wykonywanych na próbę.