Wystąpił błąd krytyczny WordPress – co zrobić krok po kroku

Autor: Grzegorz Wojterzak. Aktualizacja: 12 października 2026. Czas czytania: około 16 minut.

Ten komunikat wygląda groźnie, bo zastępuje całą stronę jednym zdaniem. W praktyce to jeden z wdzięczniejszych błędów do naprawy. WordPress od wersji 5.2 przechwytuje błędy krytyczne PHP, zamiast pokazywać pustą stronę, i w wielu przypadkach sam podpowiada, który dodatek zawinił. Trzeba tylko wiedzieć, gdzie tej podpowiedzi szukać.

Poniżej opisuję kolejność, w której sprawdzam takie awarie. Zaczynam od najszybszych i najbezpieczniejszych kroków. Każdy kolejny daje więcej informacji, ale wymaga trochę więcej dostępu do serwera.

Co oznacza komunikat „wystąpił błąd krytyczny”

Błąd krytyczny (w PHP: Fatal error) to sytuacja, w której interpreter PHP nie może wykonać dalej kodu i przerywa generowanie strony. Typowe powody: wywołanie funkcji, która nie istnieje, wyczerpanie pamięci, błąd składni w pliku albo przekazanie danych złego typu do funkcji, która w nowszym PHP już tego nie toleruje.

Zanim WordPress zamknie połączenie, jego mechanizm obsługi błędów sprawdza, co się stało, wysyła przeglądarce kod HTTP 500 i wyświetla krótki komunikat. Treść tego komunikatu zależy od tego, gdzie jesteś i czy działa tryb odzyskiwania. To ważna wskazówka, dlatego warto przyjrzeć się, który wariant widzisz.

Starsze instalacje (WordPress 5.2) pokazywały w tym miejscu zdanie o tym, że witryna ma problemy techniczne. Od wersji 5.3 komunikat mówi wprost o błędzie krytycznym. W wersjach od 5.3 do 5.6 link pod nim prowadził do poradnika o debugowaniu WordPressa, od wersji 5.7 prowadzi do strony z rozwiązywaniem typowych problemów. Jeśli widzisz wariant z linkiem do debugowania, strona działa na WordPressie sprzed kilku lat i aktualizacja będzie jednym z zadań po naprawie. Niezależnie od brzmienia mechanizm jest ten sam.

W aktualnym polskim WordPressie (sprawdzone na wersji 7.1) komunikat brzmi: „W witrynie wystąpił krytyczny błąd.”, a w panelu i na stronie logowania dochodzi zdanie o instrukcjach w skrzynce e-mail administratora.

Od czego zacząć: mapa diagnostyki

Na schemacie widać kolejność, w której przechodzę przez możliwe przyczyny. Najwięcej czasu oszczędza jedno pytanie: czy masz mail od WordPressa. Jeśli nie, wszystko opiera się na logu błędów, a log prawie zawsze wskazuje konkretny plik.

Mail do administratora i tryb odzyskiwania

W polskim WordPressie ten mechanizm nazywa się w panelu trybem awaryjnym. W poradniku używam nazwy „tryb odzyskiwania” z dokumentacji (ang. recovery mode), ale na ekranie szukaj słowa „awaryjny”.

Gdy błąd pochodzi z konkretnej wtyczki albo motywu, WordPress wysyła wiadomość na adres e-mail administracji ustawiony w Ustawienia, Ogólne (albo na adres ze stałej RECOVERY_MODE_EMAIL, jeśli ktoś ją zdefiniował w wp-config.php). W angielskiej wersji temat brzmi „[Nazwa strony] Your Site is Experiencing a Technical Issue”. W polskiej instalacji brzmi „[Nazwa strony] Twoja witryna ma problemy techniczne”, więc szukaj w skrzynce słów „problemy techniczne” oraz nazwy swojej strony.

W treści maila znajdziesz trzy rzeczy, które od razu przydają się w naprawie: nazwę wtyczki lub motywu, który spowodował błąd, szczegóły błędu z nazwą pliku i numerem linii oraz specjalny link logowania.

1. Znajdź mail, także w spamie

   WordPress wysyła go nie częściej niż raz na dobę. Jeśli awaria trwa od rana, a Ty skasowałeś pierwszą wiadomość, kolejna przyjdzie dopiero po upływie doby. Sprawdź folder spam, oferty i wszystkie skrzynki, które kiedyś mogły być wpisane jako adres administratora.

2. Kliknij link do trybu odzyskiwania

   Link prowadzi do strony logowania z parametrem action=enter_recovery_mode i jednorazowymi kluczami. Po kliknięciu WordPress ustawia w przeglądarce specjalne ciasteczko i przekierowuje Cię na adres wp-login.php?action=entered_recovery_mode. Tam logujesz się zwykłym loginem i hasłem administratora. Link jest ważny około doby. Po tym czasie nie zadziała, a nowy przyjdzie dopiero przy kolejnym wystąpieniu błędu.

3. Dezaktywuj wskazany dodatek

   W trybie odzyskiwania winna wtyczka lub motyw jest wstrzymany tylko w Twojej sesji. Panel działa, ale odwiedzający nadal widzą błąd. Wejdź w Wtyczki: przy wadliwej wtyczce zobaczysz opis błędu. Kliknij „Wyłącz”. Jeśli winny jest motyw, w Wygląd, Motywy włącz inny, najlepiej domyślny motyw WordPressa.

   

4. Wyjdź z trybu odzyskiwania i sprawdź stronę

   Na górnym pasku administracyjnym jest przycisk wyjścia z trybu odzyskiwania (w polskim WordPressie: „Wyjdź z trybu awaryjnego”). Kliknij go, a potem otwórz stronę w oknie prywatnym. Jeśli działa, masz czas na spokojne rozwiązanie problemu z wtyczką: aktualizację, cofnięcie wersji albo zamiennik.

Bez maila: włącz log błędów

Jeśli maila nie ma, przyczynę wskaże log. WordPress ma wbudowany tryb debugowania sterowany trzema stałymi (opisanymi w dokumentacji debugowania WordPressa) w pliku wp-config.php, który leży w głównym katalogu strony (zwykle public_html lub katalog nazwany jak domena).

1. Pobierz kopię pliku wp-config.php

   Połącz się przez FTP albo otwórz menedżer plików w panelu hostingu. Zanim cokolwiek zmienisz, pobierz wp-config.php na dysk. Jeden zgubiony średnik w tym pliku wyłącza całą stronę, a kopia pozwala to cofnąć w kilka sekund.

2. Ustaw stałe debugowania

   Znajdź linię define( 'WP_DEBUG', false ); i zamień ją na poniższy blok. Wszystko musi się znaleźć powyżej komentarza /* That's all, stop editing! Happy publishing. */ (w spolszczonych plikach ten komentarz bywa przetłumaczony).

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

   WP_DEBUG włącza raportowanie wszystkich błędów. WP_DEBUG_LOG zapisuje je do pliku wp-content/debug.log. WP_DEBUG_DISPLAY ustawione na false sprawia, że błędy nie pojawią się na ekranie odwiedzających. Zamiast true przy WP_DEBUG_LOG możesz podać pełną ścieżkę do pliku poza katalogiem publicznym, na przykład '/home/konto/logi/wp-debug.log'. To bezpieczniejsze, bo domyślny plik w wp-content bywa dostępny z przeglądarki.

3. Wywołaj błąd jeszcze raz

   Otwórz w przeglądarce stronę, na której pojawia się komunikat. Jeśli błąd występuje tylko przy konkretnej akcji (dodanie do koszyka, wysłanie formularza, zapis wpisu), powtórz ją. Dopiero wtedy błąd trafi do logu.

4. Otwórz wp-content/debug.log

   Pobierz plik przez FTP albo otwórz go w menedżerze plików. Przewiń na sam koniec: najnowsze wpisy są na dole. Szukaj linii zawierającej PHP Fatal error. Wpisy typu PHP Deprecated, PHP Notice czy PHP Warning zwykle nie są przyczyną awarii, choć warto je zanotować.

   Przez SSH wystarczy jedno polecenie:

   grep "PHP Fatal error" wp-content/debug.log | tail -n 5

Gdy debug.log się nie pojawia: log błędów hostingu

Jeśli błąd występuje bardzo wcześnie, zanim WordPress wczyta ustawienia debugowania, albo katalog wp-content nie ma praw zapisu, plik debug.log może w ogóle nie powstać. Wtedy szukaj logu samego serwera:

• plik error_log w katalogu strony lub w katalogu, w którym wystąpił błąd (często tak jest na hostingach z cPanelem),
• sekcja z logami w panelu hostingu, zwykle osobno log dostępu i log błędów dla każdej domeny,
• katalog z logami w katalogu domowym konta, jeśli masz dostęp przez SSH.

Nazwy menu różnią się między hostingami, dlatego jeśli nie możesz znaleźć logów, napisz do pomocy technicznej hostingu z prośbą o fragment logu błędów PHP z ostatniej godziny. Zwykle dostaniesz go szybko.

Jak czytać linię „PHP Fatal error” w logu

Linia błędu wygląda na nieczytelną, ale ma stałą budowę. Dla diagnozy liczą się trzy elementy: rodzaj błędu, nazwa funkcji lub opis problemu oraz ścieżka do pliku. Ścieżka mówi, czyj to kod.

Gdy w logu jest kilka linii, ważna jest pierwsza linia PHP Fatal error z czasem awarii. Pod nią często widać Stack trace, czyli listę wywołań, które doprowadziły do błędu. Jeśli sam błąd wskazuje plik rdzenia WordPressa, przejrzyj stack trace w poszukiwaniu pierwszej ścieżki z wp-content/plugins/ lub wp-content/themes/. Rdzeń rzadko psuje się sam. Częściej wtyczka przekazała mu złe dane.

Wyłączenie wtyczek bez dostępu do panelu

Jeśli log wskazał wtyczkę albo nie masz żadnej wskazówki, a awaria wystąpiła po zmianach we wtyczkach, wyłącz je z poziomu plików. WordPress, który nie znajdzie katalogu aktywnej wtyczki, po prostu jej nie załaduje. Ustawienia wtyczki w bazie danych zostają, więc po przywróceniu nazwy nic nie tracisz.

1. Wyłącz jedną wtyczkę wskazaną w logu

   W katalogu wp-content/plugins/ zmień nazwę katalogu winnej wtyczki, na przykład z stary-slider na stary-slider.off. Odśwież stronę. Jeśli działa, przyczyna jest potwierdzona.

2. Bez wskazówki: wyłącz wszystkie naraz

   Zmień nazwę całego katalogu plugins na plugins.off. Jeśli strona wróci (zwykle z innym wyglądem, bo brakuje funkcji wtyczek), przyczyna leży w jednej z nich. Przywróć nazwę plugins, a potem wyłączaj wtyczki pojedynczo, zaczynając od ostatnio aktualizowanych.

3. Pamiętaj o mu-plugins

   Wtyczki z katalogu wp-content/mu-plugins/ ładują się zawsze i nie widać ich na zwykłej liście. Często instaluje je hosting albo wtyczka do cache. Jeśli log wskazuje ten katalog, wyłącz pojedynczy plik, zmieniając jego rozszerzenie z .php na .php.off.

Z dostępem SSH i zainstalowanym WP-CLI zrobisz to samo szybciej. Opcje --skip-plugins i --skip-themes pozwalają uruchomić polecenie bez ładowania wtyczek i motywu, więc działa nawet wtedy, gdy strona jest całkowicie zepsuta:

# lista wtyczek z wersjami, bez ładowania ich kodu
wp plugin list --skip-plugins --skip-themes

# wyłączenie jednej wtyczki
wp plugin deactivate stary-slider --skip-plugins --skip-themes

# wyłączenie wszystkich wtyczek
wp plugin deactivate --all --skip-plugins --skip-themes

Przełączenie motywu

Jeśli ścieżka w logu prowadzi do wp-content/themes/, winny jest motyw albo motyw potomny (child theme). Najczęściej plik functions.php po ręcznej edycji lub stary motyw kupiony lata temu, który nie był aktualizowany.

• Przez WP-CLI: wp theme activate twentytwentyfive --skip-plugins --skip-themes. Nazwę domyślnego motywu, który masz zainstalowany, sprawdzisz poleceniem wp theme list --skip-plugins --skip-themes.
• Przez FTP: zmień nazwę katalogu aktywnego motywu, na przykład dodając .off. Gdy wejdziesz potem w Wygląd, Motywy, WordPress zauważy brak motywu i przełączy się na motyw domyślny, jeśli jest zainstalowany. Jeśli nie ma żadnego motywu domyślnego, wgraj go najpierw z wordpress.org.

Przełączenie motywu zmienia wygląd strony, a część ustawień, takich jak menu i widżety, trzeba będzie być może po powrocie przypisać ponownie. Dlatego traktuj to jako diagnozę, a nie rozwiązanie. Docelowo naprawiasz albo aktualizujesz swój motyw.

Limit pamięci PHP

Komunikat Allowed memory size of 134217728 bytes exhausted mówi, że skrypt próbował użyć więcej pamięci, niż pozwala ustawienie memory_limit (134217728 bajtów to 128 MB). Typowe sytuacje: duży import produktów, generowanie miniatur dużych zdjęć, rozbudowany kreator stron albo wtyczka, która wpadła w pętlę.

WordPress ma dwie stałe do sterowania pamięcią. Dodaj je w wp-config.php nad komentarzem „stop editing”:

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

WP_MEMORY_LIMIT dotyczy strony, WP_MAX_MEMORY_LIMIT zadań w panelu, na przykład obróbki obrazów. WordPress może podnieść limit tylko do wartości, na którą pozwala serwer. Jeśli hosting ustawił twardy limit, zmiana w wp-config.php nic nie da i trzeba podnieść memory_limit w ustawieniach PHP w panelu hostingu albo poprosić o to pomoc techniczną.

Wersja PHP

Duża część błędów krytycznych pojawia się dzień po tym, jak hosting podniósł wersję PHP. Funkcje takie jak create_function() czy each() zostały usunięte w PHP 8.0, a wiele sytuacji, które w PHP 7.4 kończyły się ostrzeżeniem, w PHP 8 przerywa działanie strony. Stare wtyczki i motywy, których nikt nie aktualizował, przestają wtedy działać.

Wersję PHP sprawdzisz w panelu hostingu albo w WordPressie w Narzędzia, Zdrowie witryny, Informacje, sekcja Serwer (jeśli panel działa). Szybkie obejście to tymczasowy powrót do poprzedniej wersji PHP w panelu hostingu. Docelowe rozwiązanie to aktualizacja albo wymiana dodatku. Cały proces opisuję w artykule Strona nie działa po zmianie PHP.

Uszkodzone pliki rdzenia WordPress

Rzadziej przyczyną jest sam WordPress: aktualizacja przerwana w połowie z powodu limitu czasu, brak miejsca na dysku albo ręcznie skasowany plik. W logu zobaczysz wtedy ścieżki do wp-includes/ lub wp-admin/ i komunikaty w rodzaju Failed opening required.

Przez WP-CLI sprawdzisz pliki rdzenia z sumami kontrolnymi i pobierzesz je ponownie w tej samej wersji:

wp core verify-checksums --skip-plugins --skip-themes
wp core download --version=$(wp core version --skip-plugins --skip-themes) --force --skip-content

Bez SSH pobierz z archiwum wydań WordPressa paczkę w tej samej wersji, którą masz (numer jest w pliku wp-includes/version.php), rozpakuj ją na komputerze i wgraj przez FTP tylko katalogi wp-admin i wp-includes oraz pliki z głównego katalogu z wyjątkiem wp-config-sample.php. Nie wgrywaj katalogu wp-content, bo nadpiszesz swoje motywy i wtyczki.

Jeśli pliki rdzenia zmieniły się bez Twojego udziału, a w katalogach pojawiły się obce pliki PHP, problem może nie być awarią, tylko włamaniem. Wtedy przeczytaj jak sprawdzić, czy strona została zhakowana.

Po naprawie: wyłącz debugowanie i zapobiegaj

Kiedy strona działa, posprzątaj po diagnostyce. Zostawione debugowanie to ryzyko bezpieczeństwa i źródło kolejnych problemów.

1. Przywróć ustawienia debugowania

   W wp-config.php ustaw define( 'WP_DEBUG', false ); i usuń dodane linie WP_DEBUG_LOG, WP_DEBUG_DISPLAY oraz @ini_set. Najprościej wgrać kopię pliku pobraną przed zmianami, jeśli w międzyczasie nie zmieniałeś w nim nic innego, na przykład limitu pamięci.

2. Usuń debug.log

   Plik wp-content/debug.log zawiera ścieżki serwera i szczegóły kodu. Pobierz go na dysk, jeśli chcesz go zachować, a z serwera usuń.

3. Zaktualizuj adres e-mail administratora

   W Ustawienia, Ogólne wpisz adres, który naprawdę czytasz. Zmiana wymaga potwierdzenia linkiem wysłanym na nowy adres. Dzięki temu przy następnej awarii dostaniesz mail z linkiem do trybu odzyskiwania.

4. Rozwiąż przyczynę, a nie tylko objaw

   Wyłączona wtyczka nie robi tego, do czego była potrzebna. Sprawdź, czy jest nowsza wersja zgodna z Twoim PHP, czy autor jeszcze ją rozwija, a jeśli nie, znajdź zamiennik. Jeśli awaria wystąpiła po aktualizacji, przeczytaj, jak cofnąć aktualizację i aktualizować bezpiecznie.

Kiedy nie robić tego samemu

Opisane kroki są bezpieczne, jeśli robisz kopię każdego pliku przed zmianą. Gdy jednak coś z poniższej listy dotyczy Twojej strony, rozważ zlecenie naprawy:

• sklep stoi, a każda godzina to utracone zamówienia,
• nie masz dostępu do FTP ani panelu hostingu, bo wszystko jest na koncie byłego wykonawcy (zobacz jak odzyskać dostęp do strony, hostingu i domeny),
• log wskazuje rdzeń WordPressa albo kod, którego nie rozumiesz, a stack trace ma kilkadziesiąt linii,
• winny jest motyw z dużą liczbą zmian wprowadzonych na zamówienie i jego wyłączenie rozsypuje całą stronę,
• po naprawie błąd wraca, na przykład co noc po automatycznych zadaniach.

Szersze omówienie cen i zakresu prac znajdziesz w artykule Ile kosztuje naprawa strony internetowej.

Najczęstsze pytania