Błąd krytyczny WordPress i biała strona, przyczyny i naprawa
Wchodzisz na swoją stronę, a zamiast niej widzisz komunikat „Wystąpił błąd krytyczny na tej witrynie" albo po prostu pustą, białą stronę bez żadnej treści. Panel administracyjny często też przestaje działać. To jedna z najczęstszych i najbardziej stresujących awarii WordPressa, bo wygląda, jakby cała strona zniknęła. Dobra wiadomość: w większości przypadków da się to naprawić, a dane są całe. Poniżej tłumaczymy, co ten błąd oznacza, od czego się zaczyna i jak go usunąć krok po kroku, nie robiąc przy okazji większej szkody.
Co oznacza „Wystąpił błąd krytyczny na tej witrynie"
To komunikat, którym WordPress zasłania poważny błąd PHP, żeby nie pokazać odwiedzającym technicznych szczegółów. Dawniej w tym miejscu pojawiał się po prostu „biały ekran śmierci" (White Screen of Death), czyli pusta strona. Sens jest ten sam: kod, który buduje stronę, zatrzymał się w połowie i nie ma jak dokończyć. Najczęściej winna jest jedna konkretna wtyczka, motyw albo brak pamięci, a nie „cały WordPress".
Jeśli zamiast tego komunikatu widzisz suche „HTTP ERROR 500", to trochę inna ścieżka, opisujemy ją w osobnym wpisie o błędzie 500 (Internal Server Error).
Ważny trop: WordPress zwykle wysyła na adres e-mail administratora wiadomość zatytułowaną „Twoja witryna ma problem techniczny". W środku bywa nazwa wtyczki lub pliku, który wywołał błąd, oraz specjalny link do trybu odzyskiwania. Zajrzyj tam w pierwszej kolejności, to często gotowa odpowiedź, co się zepsuło.
Najczęstsze przyczyny
- Aktualizacja lub konflikt wtyczki. Zdecydowanie najczęstszy powód. Wtyczka po aktualizacji gryzie się z inną albo z wersją PHP na serwerze i wywala całą stronę.
- Motyw (szablon). Ten sam mechanizm co przy wtyczkach: aktualizacja motywu lub jego uszkodzony plik potrafi zatrzymać renderowanie strony.
- Za mały limit pamięci PHP. Przy rozbudowanych stronach serwer po prostu nie daje radę zbudować strony w przydzielonej pamięci i przerywa.
- Zmiana wersji PHP na hostingu. Starsza wtyczka albo motyw nie działa na nowym PHP, co objawia się błędem krytycznym z dnia na dzień, nawet gdy nic nie zmieniałeś.
- Uszkodzony plik rdzenia lub ślad włamania. Rzadziej, ale się zdarza: podmieniony albo doklejony złośliwy kod również kończy się białą stroną. O tym niżej.
Zanim zaczniesz: zrób kopię
Cokolwiek będziesz robić, najpierw zrób kopię plików i bazy danych, choćby przez panel hostingu. Naprawa awarii bez kopii to praca bez siatki: jeśli coś pójdzie nie tak, nie ma jak się cofnąć. Jeśli nie wiesz, jak, mamy to rozpisane w osobnym wpisie o kopiach zapasowych strony.
Jak naprawić krok po kroku
Idź od najprostszego. Po każdym kroku odśwież stronę i sprawdź, czy błąd zniknął.
- Sprawdź e-mail administratora i tryb odzyskiwania. Jeśli WordPress wysłał wiadomość o problemie technicznym, kliknij link do trybu odzyskiwania. Wejdziesz do panelu w bezpiecznym trybie i wyłączysz element, który wywołał błąd.
- Wyłącz wtyczki, nawet bez dostępu do panelu. Przez menedżera plików w panelu hostingu lub FTP zmień nazwę folderu
wp-content/pluginsna przykład naplugins-off. To hurtowo dezaktywuje wszystkie wtyczki. Jeśli strona wstaje, winna jest jedna z nich. Przywróć nazwę folderu i włączaj wtyczki pojedynczo, aż trafisz na tę, która psuje. - Przełącz motyw na domyślny. Jeśli wtyczki to nie one, w folderze
wp-content/themeszmień nazwę aktywnego motywu. WordPress wróci do motywu domyślnego. Jeśli to pomoże, problem jest w Twoim szablonie. - Zwiększ limit pamięci PHP. W pliku
wp-config.phpdodaj liniędefine('WP_MEMORY_LIMIT', '256M');. Jeśli błąd wynikał z braku pamięci, strona ruszy. - Włącz log błędów. W
wp-config.phpustawdefine('WP_DEBUG', true);orazdefine('WP_DEBUG_LOG', true);. Błędy zapiszą się do plikuwp-content/debug.logz dokładną nazwą pliku i linii, która się wywala. To najszybsza droga do przyczyny. Po diagnozie pamiętaj, żeby wyłączyć debug, bo nie powinien być włączony na żywej stronie. - Sprawdź wersję PHP. W panelu hostingu zobacz, czy niedawno nie zmieniła się wersja PHP. Cofnięcie do poprzedniej bywa szybkim obejściem, zanim zaktualizujesz podatny komponent.
Kiedy biała strona to znak włamania
Jeśli po wyłączeniu wszystkich wtyczek i zmianie motywu błąd zostaje, albo w plikach widzisz obcy, nieczytelny kod (długie ciągi znaków, eval, base64_decode), to nie zwykła awaria, tylko możliwy ślad infekcji. Wtedy nie chodzi już o naprawę jednego pliku, ale o znalezienie i zamknięcie furtki, którą ktoś wszedł. Zacznij od bezpłatnego testu infekcji strony, a jeśli potwierdzi problem, przeczytaj jak poznać, że strona ma wirusa. Samo usunięcie złośliwego kodu bez zamknięcia luki sprawia, że infekcja wraca po kilku dniach.
Kiedy oddać to specjaliście
Jeśli nie masz dostępu do plików, log nie wskazuje jednoznacznej przyczyny albo boisz się, że przy grzebaniu zepsujesz więcej, to rozsądny moment, żeby przekazać to komuś, kto robi takie awarie na co dzień. Zajmujemy się właśnie tym: stroną, która nie działa. Diagnozę robimy bezpłatnie, pracujemy na kopii i mówimy wprost, co się stało i ile potrwa naprawa.
Najczęstsze pytania
Czy przy błędzie krytycznym tracę dane i treści?
Nie. Ten błąd zatrzymuje wyświetlanie strony, ale nie kasuje wpisów, zdjęć ani ustawień, one siedzą w bazie i w plikach. Dlatego naprawa polega na usunięciu przyczyny, a nie odtwarzaniu strony od zera.
Strona działała wczoraj, dziś biały ekran, choć nic nie zmieniałem. Jak to możliwe?
Najczęściej zmienił się serwer, zwykle wersja PHP, albo w tle zainstalowała się automatyczna aktualizacja wtyczki lub motywu. Z Twojej perspektywy „nic się nie działo", a jednak coś się przełączyło pod spodem.
Nie mam dostępu do panelu WordPress. Da się cokolwiek zrobić?
Tak. Większość powyższych kroków (wyłączenie wtyczek, zmiana motywu, edycja wp-config.php, log błędów) robi się z poziomu plików przez menedżer plików w panelu hostingu lub FTP, bez wchodzenia do panelu WordPressa.
Ile trwa naprawa błędu krytycznego?
Typowe przypadki, gdzie winna jest jedna wtyczka lub pamięć, rozwiązuje się w kilkanaście minut do godziny. Trudniej, gdy w grę wchodzi konflikt wielu komponentów albo infekcja, bo trzeba znaleźć źródło, a nie tylko wyłączyć objaw.