Moja strona WordPress leży: „There has been a critical error"

Co naprawdę znaczy „There has been a critical error"

Gdzieś w twoim stacku - prawie zawsze we wtyczce albo motywie - linia PHP padła na tyle twardo, że WordPress nie mógł działać dalej. Handler błędów fatalnych złapał ją i wydrukował ten komunikat zamiast białej strony. To cały błąd. Twoje pliki dalej są na dysku, twoja baza dalej jest, twój content jest w porządku. Jedno rozszerzenie się wywaliło i zabrało całą stronę ze sobą.

Schemat

Wtyczka się aktualizuje. Albo hosting podbija wersję PHP. Albo ktoś edytuje plik przez edytor motywów. Już następny request odpowiada „There has been a critical error on this website." Frontend leży. wp-login.php też leży, więc nie możesz deaktywować podejrzanej wtyczki - a mail, który mógłby cię wpuścić z powrotem, leci na adres, który akurat siedzi w Ustawienia → Ogólne.

Starsza odmiana tego samego crasha to White Screen of Death: fatal odpala, zanim WordPress zdąży cokolwiek wyrenderować, więc przeglądarka dostaje pustą stronę. Ta sama przyczyna, mniej informacji. Obie pochodzą z tego samego miejsca i obie są omówione niżej.

Co WordPress robi potem - i gdzie się zacina

Od WordPressa 5.2 core ma prawdziwą odpowiedź. Kiedy fatal odpala, handler błędów fatalnych go wykrywa i wysyła link Recovery Mode na adres admina strony. Klikasz link, logujesz się jeszcze raz, a Recovery Mode pauzuje zepsute rozszerzenie - strona wraca z wyłączoną wtyczką i powiadomieniem, które ją nazywa. Mechanizm jest solidny. Dostawa to słaba część.

Link leci na maila z Ustawienia → Ogólne - często skrzynka, której nikt nie czyta
wp_mail() może być wolny, łapany przez spam-filtry albo całkiem wyłączony przez hosting
Strona leży, podczas gdy ty czekasz na wiadomość, która może nigdy nie dolecieć
Każda minuta czekania to kolejna minuta strony błędu dla twoich odwiedzających

Zalogowany administrator idzie prosto na podpisany URL Recovery Mode - bez podróży maila w obie strony
Dalej dowodzisz, że to ty: bramka ponownego logowania core zostaje na miejscu
Zepsuta wtyczka zostaje spauzowana przez własny handler core przy następnym requeście
Biały ekran zamienia się w prawdziwą stronę błędu zamiast pustej odpowiedzi

Ten sam cel tak czy siak. Drop-in tylko usuwa najwolniejszy, najmniej niezawodny krok ze środka.

Co robią drop-iny fatal error recovery

Dwa drop-iny wdrażają się do wp-content, gdy WP Multitool się aktywuje, i zostają tam, dopóki nie deaktywujesz wtyczki. Nie ma przełącznika ani nic do konfigurowania - strona nie może stracić odzyskiwania po crashu, bo ktoś wyłączył ustawienie.

Plik	Co robi
`fatal-error-handler.php`	Nadpisuje handler błędów fatalnych core. Gdy zalogowany administrator trafi na fatal wtyczki albo motywu, buduje podpisany URL Recovery Mode core na miejscu i wysyła cię do bramki logowania - całkiem omijając maila
`php-error.php`	Renderuje sam błąd. Fatal, który kiedyś kończył się pustym body, teraz produkuje prawdziwą stronę „critical error" WordPressa, więc zawsze dostajesz widoczną odpowiedź

Po ponownym wpisaniu hasła następny crash przechodzi przez własny handler core, który pauzuje winne rozszerzenie. Ta pauza to to, co przywraca stronę - mój drop-in usuwa czekanie między crashem a linkiem odzyskiwania. URL to podpisany URL core; nic z niego nie wycieka do twoich odwiedzających.

Czego nie zrobi - przeczytaj, zanim zaczniesz na tym polegać

Wylogowani odwiedzający widzą tę samą stronę błędu tak czy siak. Dla nich strona leży, dopóki zepsute rozszerzenie nie zostanie spauzowane. Danie obcym linku odzyskiwania to danie im twojego panelu admina, więc dostaje go tylko zalogowany admin.
Tylko fatale wtyczek i motywów. Crasha wewnątrz core WordPressa, drop-inu albo zepsutego wp-config.php Recovery Mode nie może spauzować, więc dostajesz zwykłą stronę błędu.
Bez multisite. Na instalacji sieciowej drop-in ustępuje i core obsługuje crash domyślną drogą.
To nie backup. Spauzowanie zepsutej wtyczki nic nie przywraca - jeśli crash zepsuł dane, potrzebujesz backupu hostingu albo prawdziwego.
Nie zapobiega crashowi. Zły kod dalej leci i dalej pada. Wracasz szybciej, z winowajcą już nazwanym.
Martwa baza albo awaria hostingu jest poniżej tej warstwy. WordPress umiera, zanim handler się załaduje, więc nie ma czego przechwycić.

Zepsułeś sam wp-config.php?

Złe dane bazy albo zła edycja zabija WordPressa, zanim załaduje się jakikolwiek handler. Na ten wypadek Config Manager (Pro) ma komendę ratunkową WP-CLI, która przywraca backup wp-config bez uruchamiania WordPressa w ogóle - działa przy całkowicie nieosiągalnej bazie.

Z powrotem w środku? Teraz zobacz, co się naprawdę zepsuło

Recovery Mode nazywa rozszerzenie, które spauzował. Błąd, który zabił stronę, jest w debug.log - jeśli masz włączone WP_DEBUG_LOG - a ruchliwa strona potrafi pisać setki niemal identycznych linii na request, więc linia fatalu siedzi pod stosem powtórek.

Debug Log Guard (Pro) czyta log bez ładowania go. Grupuje powtórki do tabeli - wiadomość, licznik, wtyczka albo motyw źródłowy, pierwsze i ostatnie wystąpienie - i streamuje tail, więc wielogigabajtowy log otwiera się w sekundy zamiast zawiesić ci edytor. Linia, która zwaliła stronę, wypływa na górę, już przypisana do źródła.

W środku i chcesz dowód, co się zepsuło? Debug Log Guard zamienia log w pogrupowaną tabelę z nazwanym winowajcą.

Pro od $79/rok →

FAQ: strona WordPress leży

Czemu moja strona WordPress mówi „There has been a critical error on this website"?

Fatal PHP - prawie zawsze we wtyczce albo motywie - zatrzymał request. WordPress złapał go w handlerze shutdown i wydrukował ten komunikat zamiast białej strony. Twoje pliki i baza są nietknięte; jedno rozszerzenie się wywaliło i zabrało stronę ze sobą.

Jak wrócić do wp-admin, gdy strona leży?

WordPress wysyła link Recovery Mode na adres admina strony - klikasz, logujesz się jeszcze raz, a zepsuta wtyczka zostaje spauzowana. Z drop-inami WP Multitool zalogowany administrator dostaje się prosto na ten podpisany URL Recovery Mode przy fatalu, więc nie ma maila, na którego trzeba czekać.

Mail z Recovery Mode od WordPressa nigdy nie przyszedł - i co teraz?

Sprawdź spam, potem sprawdź, jaki adres siedzi w Ustawienia → Ogólne - często to skrzynka, której nikt nie czyta, a niektórzy hosterzy spowalniają albo blokują wp_mail() całkiem. Drop-in fatal error recovery buduje podpisany URL na miejscu dla zalogowanego admina zamiast go wysyłać, więc flow nie może utknąć na mailu.

Czy moja strona przepadła na dobre? Zhakowano mnie?

Prawie nigdy. Critical error po aktualizacji, podbiciu wersji PHP albo edycji pliku to jedno złe rozszerzenie, nie hack i nie utrata danych. Recovery Mode pauzuje winowajcę i strona wraca; twój content, pliki i baza są nietknięte.

Czy drop-in odzyskiwania naprawia błąd?

Nie - wpuszcza cię do Recovery Mode szybciej, a zepsute rozszerzenie zostaje spauzowane przez własny handler core. Wtyczka, która się wywaliła, dalej potrzebuje aktualizacji, wymiany albo bug reportu do autora. Drop-in kupuje ci dostęp i nazwę, nie patch.

Czy fatal error recovery działa na multisite?

Nie. Na instalacji sieciowej drop-in ustępuje, a WordPress obsługuje crash domyślną drogą - mailem odzyskiwania na adres admina. Instalacje pojedynczych stron dostają bezpośrednie przekierowanie.

A co z białym ekranem w ogóle bez komunikatu błędu?

To White Screen of Death - fatal, który odpala, zanim WordPress zdąży wyrenderować stronę błędu. Drop-in php-error.php WP Multitool pilnuje, żeby crash i tak wyprodukował prawdziwą stronę „critical error", więc zawsze widzisz coś zamiast pustej odpowiedzi.