W witrynie wystąpił błąd krytyczny – co ten komunikat znaczy i jak go usunąć

Ten komunikat oznacza, że PHP napotkał błąd krytyczny podczas budowania strony, a WordPress przechwycił go, zanim zamienił się w pusty biały ekran. Błąd jest prawdziwy, konkretny i zapisany — WordPress po prostu nie chce go wypisać w przeglądarce, bo ślad stosu na publicznej stronie ujawnia ścieżki do plików i kod każdemu, kto ją odwiedzi.

Dlatego naprawa nigdy nie polega na zgadywaniu. Polega na tym, żeby przeczytać faktyczny błąd, a potem zrobić to, co z niego wynika.

Co się tak naprawdę dzieje

Od WordPressa 5.2 w rdzeniu działa mechanizm obsługi błędów krytycznych. Kiedy PHP umiera w trakcie żądania, mechanizm wkracza do akcji, zastępuje wynik awarii uprzejmym ogólnikiem i — jeśli uda mu się ustalić, która wtyczka albo który szablon zawinił — próbuje wysłać administratorowi e-mail z linkiem do trybu odzyskiwania.

Właśnie dlatego widzisz to zamiast dawnego białego ekranu śmierci. To postęp, ale oznacza też, że informacje diagnostyczne są domyślnie ukryte. Komunikat występuje w dwóch wariantach:

Co widzisz	Gdzie	Co ci to mówi
„W witrynie wystąpił błąd krytyczny.”	Front, bez zalogowania	Wystąpił błąd krytyczny, żadnych szczegółów
To samo plus „Dowiedz się więcej o rozwiązywaniu problemów w WordPressie”	Front lub wp-admin	Ten sam błąd, WordPress podsuwa ci stronę z podręcznika
„…Sprawdź skrzynkę odbiorczą administratora witryny, aby uzyskać instrukcje.”	Front	Mechanizm uznał, że wysłał e-mail z trybem odzyskiwania

Trzeci wariant jest tym przydatnym. Znaczy, że WordPress przypisał awarię konkretnej wtyczce lub szablonowi i próbował podać ci drogę do środka.

Krok 1: sprawdź e-mail z trybem odzyskiwania

WordPress wysyła link odzyskiwania na adres e-mail administratora witryny — ten z Ustawienia → Ogólne — który często nie jest adresem, którym się logujesz. Zajrzyj do tej skrzynki i do spamu.

W wiadomości jest długi link kończący się mniej więcej na ?action=enter_recovery_mode. Otwarcie go loguje cię do wp-admin w trybie odzyskiwania, gdzie problematyczna wtyczka lub szablon są wstrzymane i oznaczone czerwonym komunikatem na górze. Stamtąd możesz je normalnie wyłączyć.

Dwa uczciwe zastrzeżenia. Po pierwsze, e-mail generuje ten sam proces PHP, który przed chwilą padł, na serwerze, który może w ogóle nie mieć działającej poczty — brak dostarczenia jest częsty i nic nie mówi o samym błędzie. Po drugie, link odzyskiwania wygasa (domyślnie mniej więcej po dobie), więc stara wiadomość w skrzynce może już nie działać; wywołaj świeżą awarię, przeładowując stronę, i poczekaj na nową.

Jeśli chcesz, żeby e-mail trafiał tam, gdzie faktycznie zaglądasz, ustaw adres wprost w wp-config.php:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Krok 2: przeczytaj prawdziwy błąd

To ten krok, który zamienia zepsutą stronę w pięciominutową naprawę. Dodaj te linie do wp-config.php, powyżej linii mówiącej, żeby przestać edytować:

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

WP_DEBUG_DISPLAY ustawione na false ma znaczenie — trzyma błąd z dala od przeglądarki, a mimo to zapisuje go na dysk, więc podczas diagnozy nie pokazujesz odwiedzającym ścieżek serwera.

Przeładuj zepsutą stronę raz, a potem otwórz wp-content/debug.log. Ostatni wpis będzie wyglądał mniej więcej tak:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

Ścieżka do pliku to odpowiedź. Jeśli wskazuje na wp-content/plugins/, winna jest ta wtyczka. Jeśli na wp-content/themes/ — to szablon, bardzo często coś świeżo wklejonego do functions.php.

Jeśli debug.log się nie pojawia, katalog może nie być zapisywalny albo wtyczka bezpieczeństwa przeniosła logowanie gdzie indziej. Wróć wtedy do dziennika błędów PHP na hostingu — większość paneli ma sekcję „Dziennik błędów” lub „Logi”, a ten sam błąd krytyczny będzie tam ze znacznikiem czasu.

Wklej wpis do dekodera dziennika błędów WordPressa, żeby przetłumaczyć formułki PHP na to, co znaczą w praktyce, i dowiedzieć się, do którego pliku zajrzeć najpierw.

Usuń te linie debugowania, kiedy skończysz. Zostawienie włączonego WP_DEBUG na produkcji zapycha dysk, a jeśli WP_DEBUG_DISPLAY kiedyś wróci na true, publicznie wypisuje ścieżki serwera.

Krok 3: wróć do wp-admin

Jeśli wp-admin też nie działa i żaden e-mail odzyskiwania nie przyszedł, wyłącz wszystkie wtyczki na poziomie plików. Połącz się przez SFTP (albo menedżer plików hostingu) i zmień nazwę jednego folderu:

mv wp-content/plugins wp-content/plugins-off

WordPress nie znajduje wtyczek, więc dezaktywuje je wszystkie i dostęp do panelu prawie zawsze wraca. Następnie:

1. Przywróć folderowi nazwę plugins. Wszystko zostaje wyłączone — WordPress zapisał je jako nieaktywne.
2. Włączaj wtyczki pojedynczo, ładując front po każdej z nich.
3. Ta, przy której błąd wraca, to twój winowajca.

Jeśli strona nadal jest zepsuta przy wszystkich wtyczkach wyłączonych, podejrzanym jest szablon. Zmień nazwę folderu aktywnego szablonu w wp-content/themes/, a WordPress przełączy się na domyślny motyw, o ile jakiś jest zainstalowany.

Trzy przyczyny, które warto znać

Aktualizacja wtyczki albo szablonu z błędem krytycznym. Zdecydowanie najczęstsza. Dziennik podaje plik wprost. Cofnij tę jedną wtyczkę do poprzedniej wersji albo zostaw ją wyłączoną i wyślij autorowi linię z dziennika.

Niezgodność wersji PHP. Hostingi podnoszą PHP według własnego harmonogramu, czasem bez wyraźnego uprzedzenia. Kod pisany pod starsze PHP potrafi się w ogóle przestać parsować na nowszej wersji. Sygnał rozpoznawczy: nic nie zmieniałeś, a wszystko padło naraz. Cofnięcie PHP o jedną wersję pomocniczą w panelu hostingu to poprawna diagnostyka — ale traktuj to jako kupowanie czasu, nie naprawę. Stare wersje PHP przestają dostawać poprawki bezpieczeństwa.

Wyczerpanie pamięci. Dziennik mówi „Allowed memory size of X bytes exhausted”. Podniesienie limitu w wp-config.php jest rozsądne:

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

Bądź szczery co do tego, co to robi: usuwa sufit, ale nie naprawia tego, co zjadło 256 MB przy renderowaniu jednej strony. Jeśli limit trzeba podnosić w kółko, prawdziwym problemem jest coś innego — zwykle import, kreator stron albo źle napisane zapytanie.

Rady, które możesz spokojnie zignorować

„Po prostu zwiększ limit pamięci.” Ma sens tylko wtedy, gdy dziennik faktycznie mówi o wyczerpaniu pamięci. W przeciwnym razie nic nie zmienia i przykrywa fakt, że nigdy nie przeczytałeś błędu.

„Zainstaluj rdzeń WordPressa od nowa.” Pliki rdzenia rzadko są przyczyną, a ich podmiana zjada czas, który mógłbyś poświęcić na przeczytanie jednej linii dziennika.

„Wyłącz mechanizm obsługi błędów krytycznych.” Istnieje stała, która go wyłącza, a efekt jest taki, że surowy błąd wypisuje się na twojej publicznej stronie zamiast zostać przechwycony. To ujawnia odwiedzającym ścieżki plików. Użyj WP_DEBUG_LOG z wyłączonym WP_DEBUG_DISPLAY — te same informacje, zero ekspozycji.

„Wyczyść pamięć podręczną.” Błąd krytyczny występuje w PHP, zanim wtyczka cache zdąży cokolwiek podać. Jeśli serwowana jest zapisana w cache kopia strony z błędem, czyszczenie pomaga po usunięciu przyczyny — nigdy zamiast niego.

Nadal nie działa?

Jeśli dziennik wskazuje na plik rdzenia, a nie na coś w wp-content, bardziej prawdopodobne jest, że wcześniej załadowana wtyczka zepsuła stan, na którym rdzeń polega, niż że rdzeń jest uszkodzony. Wyłącz wszystko zmianą nazwy folderu, potwierdź, że strona ładuje się czysto, a potem wprowadzaj wtyczki po jednej — ta ostatnia włączona przed powrotem błędu to ta, którą trzeba zgłosić, z dołączoną linią z dziennika.