„Es gab einen kritischen Fehler auf dieser Website“ – krytyczny błąd WordPressa i jak go naprawić

W skrócie: „Es gab einen kritischen Fehler auf dieser Website“ (w wolnym tłumaczeniu: „Na tej stronie wystąpił błąd krytyczny“) to komunikat, który WordPress wyświetla, gdy PHP zatrzyma się na błędzie typu Fatal Error. Prawie zawsze winna jest wtyczka, motyw albo nowa wersja PHP u hostingodawcy, rzadziej brak pamięci. Dokładną przyczynę znajdą Państwo w e-mailu z trybem odzyskiwania (Recovery Mode) albo w pliku wp-content/debug.log. Jeśli panel administracyjny nie działa, wtyczki można wyłączyć przez FTP, zmieniając nazwy ich folderów.

Komunikat wygląda niewinnie: jedno zdanie na białym tle i link do pomocy WordPressa. Dla klientów strona jednak przestaje istnieć, często razem z panelem /wp-admin. Dobra wiadomość: w zdecydowanej większości przypadków żadne dane nie giną. Strony, wpisy i zamówienia leżą nietknięte w bazie danych. Zepsuty jest tylko kod PHP, który je wyświetla.

Na stronach z niemieckim interfejsem zobaczą Państwo właśnie wersję niemiecką. Na instalacji z polskim językiem pojawia się ten sam komunikat po polsku. Przyczyny i rozwiązanie są identyczne.

Co oznacza ten komunikat

WordPress jest napisany w PHP. Gdy PHP trafi na błąd, po którym nie może kontynuować pracy – tzw. Fatal Error – przerywa generowanie strony. Kiedyś odwiedzający widzieli wtedy pustą białą stronę albo techniczny komunikat ze ścieżkami do plików. Od wersji 5.2 WordPress przechwytuje takie błędy i pokazuje zamiast nich neutralną informację o błędzie krytycznym.

Ten komunikat mówi więc tylko tyle: „PHP przestało działać“. W którym pliku i w której linii – to jest zapisane gdzie indziej. I to trzeba ustalić w pierwszej kolejności. Zgadywanie zajmuje więcej czasu niż sprawdzenie.

Najczęstsze przyczyny

1. Wtyczka lub motyw po aktualizacji

W mojej praktyce to zdecydowanie najczęstszy przypadek. Wtyczka zaktualizowała się automatycznie albo ktoś kliknął „Aktualisieren“ i nowa wersja gryzie się z inną wtyczką, z motywem albo z wersją WordPressa. Typowy przykład: page builder z dodatkiem Pro, które nie zostały zaktualizowane jednocześnie, a dodatek wymaga nowszej wersji wtyczki podstawowej.

2. Nowa wersja PHP na hostingu

Hostingodawcy przełączają stare wersje PHP, bo przestały dostawać poprawki bezpieczeństwa. PHP 7.4 nie ma wsparcia od 28.11.2022, PHP 8.0 od 26.11.2023, a PHP 8.1 od 31.12.2025. Starszy kod wtyczek i motywów często nie działa na nowym PHP. Klasyka to funkcje create_function() i each(), usunięte w PHP 8.0. Jeśli wczoraj wszystko działało, a Państwo niczego nie zmieniali, to mocna wskazówka, że chodzi właśnie o to.

3. Za mało pamięci

Gdy skrypt potrzebuje więcej pamięci, niż pozwala serwer, kończy się błędem „Allowed memory size of … bytes exhausted“. WordPress też pokazuje go jako błąd krytyczny. Zdarza się to przy wgrywaniu dużych zdjęć, przy importach i w sklepach z dużą liczbą produktów.

4. Własne zmiany w kodzie

Fragment kodu wklejony do functions.php, brakujący średnik, plik wgrany tylko w połowie po przerwanym transferze FTP. To również kończy się błędem krytycznym – zwykle zaraz po zapisaniu zmian.

Krok 1: sprawdzić e-mail z trybem odzyskiwania

Od wersji 5.2 WordPress przy błędzie krytycznym wysyła e-mail na adres administratora. Zazwyczaj znajdą w nim Państwo:

• nazwę wtyczki lub motywu, w którym wystąpił błąd,
• treść błędu z nazwą pliku i numerem linii,
• specjalny link do logowania w trybie odzyskiwania (Recovery Mode).

Ten link otwiera zabezpieczoną sesję, w której wadliwa wtyczka jest wstrzymana. Można ją wtedy wyłączyć, zaktualizować albo usunąć. Dla zwykłych odwiedzających strona pozostaje niedostępna, dopóki problem nie zostanie naprawiony.

Proszę zajrzeć też do folderu spam. E-mail trafia na adres z „Einstellungen → Allgemein“ (Ustawienia → Ogólne). Często jest to jeszcze adres dawnej agencji albo skrzynka, której nikt nie czyta. Link działa poza tym tylko przez ograniczony czas.

Krok 2: włączyć WP_DEBUG i debug.log

Jeśli e-mail nie przyszedł, trzeba włączyć dziennik błędów WordPressa. Przez FTP albo menedżer plików w panelu hostingu proszę otworzyć plik wp-config.php w katalogu głównym. Linię z WP_DEBUG zastępujemy tym:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Te linie muszą stać powyżej require_once ABSPATH . 'wp-settings.php';. Potem wystarczy raz otworzyć niedziałającą stronę. WordPress zapisze błędy w pliku wp-content/debug.log. Najważniejsza jest linia z PHP Fatal error, na przykład:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /www/htdocs/.../wp-content/plugins/stary-slider/inc/widget.php:42

Ścieżka wskazuje winowajcę. Tutaj to wtyczka w folderze stary-slider. Jeśli w ścieżce jest wp-content/themes/…, problem leży w motywie. Jeśli błąd wskazuje na wp-includes, wyzwalaczem i tak bywa wtyczka – wtedy warto przeczytać kolejne linie pod spodem (tzw. stack trace).

Ustawienie WP_DEBUG_DISPLAY na false sprawia, że odwiedzający nie widzą komunikatów błędów. To ważne, bo zdradzają one ścieżki i szczegóły serwera. Po naprawie proszę ustawić WP_DEBUG z powrotem na false i usunąć debug.log. Plik leży w publicznie dostępnym folderze wp-content i bez tego da się go pobrać z zewnątrz.

Krok 3: wyłączyć wtyczki przez FTP

Gdy panel nie działa, wtyczki wyłącza się bezpośrednio na serwerze. WordPress ładuje wtyczkę tylko wtedy, gdy istnieje jej folder. Wystarczy zmienić jego nazwę.

1. Proszę połączyć się przez FTP, np. programem FileZilla, albo otworzyć menedżer plików w panelu hostingu.
2. Przejść do wp-content/plugins/.
3. Jeśli wiadomo z e-maila lub z debug.log, która to wtyczka, zmienić nazwę tylko jej folderu, np. elementor-pro na elementor-pro_off.
4. Jeśli nie wiadomo, zmienić nazwę całego folderu plugins na plugins_off. Wtedy wyłączone są wszystkie wtyczki.
5. Odświeżyć stronę. Jeśli działa, winna była wtyczka.

Po zmianie nazwy całego folderu trzeba potem przywrócić nazwę plugins. WordPress traktuje wtyczki wtedy jako wyłączone. Proszę włączać je w panelu pojedynczo i po każdej odświeżać stronę. Przy wadliwej wtyczce błąd wróci – tę jedną wyłączamy ponownie przez FTP.

Z motywem jest tak samo: zmiana nazwy folderu w wp-content/themes/. WordPress przełączy się wtedy na zainstalowany motyw domyślny, np. „Twenty Twenty-Four“. Strona będzie wyglądać inaczej, ale panel znów zadziała. Jeśli żaden motyw domyślny nie jest zainstalowany, wystarczy wgrać go przez FTP.

Krok 4: usunąć właściwą przyczynę

Wyłączona wtyczka to rozwiązanie awaryjne, a nie naprawa. Często zależą od niej formularze, funkcje sklepu albo wygląd strony. Dalej postępujemy zależnie od przyczyny:

• Wadliwa aktualizacja wtyczki: poszukać poprawki od producenta albo wgrać poprzednią wersję.
• Nowe PHP: zaktualizować wtyczkę lub motyw. Jeśli aktualizacji już nie ma – wymienić wtyczkę albo dostosować kod. Cofnięcie wersji PHP na hostingu tylko odsuwa problem w czasie.
• Pamięć: sprawdzić limit, ale też wyjaśnić, dlaczego skrypt potrzebuje tyle pamięci.
• Własny kod: przywrócić zmieniony plik z kopii zapasowej albo poprawić błąd we wskazanej linii.

Czego lepiej nie robić

• Instalować WordPressa od nowa. Rzadko pomaga, bo przyczyna prawie zawsze tkwi we wtyczkach albo w motywie.
• Przywracać kopię zapasową w ciemno. W sklepie przepadną wszystkie zamówienia od dnia kopii. A jeśli hosting zmienił wersję PHP, błąd wróci od razu.
• Usuwać folderów zamiast zmieniać nazwy. Zmianę nazwy cofa się jednym kliknięciem, usunięcia nie.
• Zostawiać WP_DEBUG_DISPLAY na true. Wtedy każdy odwiedzający widzi ścieżki na serwerze.
• Eksperymentować na żywej stronie. Jeśli to tylko możliwe, aktualizacje lepiej najpierw sprawdzić na kopii.

Kiedy warto poprosić o pomoc

Robi się trudniej, gdy debug.log wskazuje błąd w motywie albo we wtyczce pisanej na zamówienie. Wtedy trzeba zmienić kod, a to powinien zrobić ktoś, kto czyta PHP. Podobnie, gdy błąd nie znika mimo wyłączenia wszystkich wtyczek, gdy chodzi o sklep i każda godzina przestoju kosztuje, albo gdy na serwerze pojawiły się pliki, których Państwo nie znają. Za błędem może wtedy stać włamanie.

Profesjonalna pomoc

Jeśli utknęli Państwo w miejscu, chętnie przejrzę stronę. Szukam przyczyny w logach, usuwam ją w kodzie zamiast tylko obchodzić i sprawdzam potem, czy formularze, sklep i panel znów działają. Naprawa WordPressa kosztuje od 290 € netto. Jeśli błąd siedzi we własnym kodzie PHP albo pojawił się po zmianie wersji PHP, właściwa będzie naprawa błędów PHP: analiza 150 € netto, naprawa od 290 € netto.