„Błąd krytyczny” w WordPressie to zwykle fatalny błąd PHP, który zatrzymuje działanie strony — najczęściej z powodu problemów z wtyczką, motywem, wersją PHP, plikami lub bazą danych.
Aby szybko znaleźć przyczynę i przywrócić stronę, włącz tryb debugowania, przeanalizuj plik debug.log, a następnie krok po kroku wykluczaj wtyczki, motyw, plik .htaccess, niezgodną wersję PHP, uszkodzone pliki i błędy w bazie danych.
Co oznacza komunikat „W witrynie wystąpił błąd krytyczny”?
- Co oznacza komunikat „W witrynie wystąpił błąd krytyczny”?
- Krok 1 – włącz tryb debugowania i zbierz informacje
- Krok 2 – wyłączenie wtyczek (najczęstsza przyczyna)
- Krok 3 – sprawdzenie motywu (szablonu)
- Krok 4 – plik .htaccess i ustawienia permalinków
- Krok 5 – sprawdzenie wersji PHP i limitu pamięci
- Krok 6 – naprawa plików WordPressa (rdzenia)
- Krok 7 – naprawa i diagnostyka bazy danych
- Krok 8 – aktualizacje, bezpieczeństwo i skan w poszukiwaniu malware
- Jak postępować w różnych sytuacjach – dwa scenariusze
- Kiedy skontaktować się z hostingiem lub specjalistą?
- Jak zapobiegać błędom krytycznym w przyszłości?
Od kilku wersji WordPress zamiast „białej strony śmierci” wyświetla komunikat w stylu: „W witrynie wystąpił błąd krytyczny” lub „There has been a critical error on this website”. To sygnał, że wystąpił fatal error — błąd, którego PHP nie potrafi obsłużyć i przerywa wykonanie skryptu.
Najczęstsze przyczyny tego komunikatu to:
- Błędna lub zaktualizowana wtyczka – powoduje konflikt z inną wtyczką, motywem lub wersją PHP;
- Motyw (szablon) – zawiera błędny kod lub jest niekompatybilny z aktualnym WordPressem;
- Niekompatybilna wersja PHP – zbyt stara lub zbyt nowa względem używanych wtyczek/motywu;
- Zbyt niski limit pamięci PHP – brak zasobów wywołuje krytyczne błędy podczas ładowania strony;
- Uszkodzone pliki WordPressa – np. po przerwanej aktualizacji lub błędnym nadpisaniu plików;
- Problemy z bazą danych – uszkodzone tabele, nieprawidłowe dane logowania lub błędna struktura;
- Plik
.htaccess– zmodyfikowany lub uszkodzony, powodujący błędy konfiguracji serwera; - Złośliwe oprogramowanie (malware) – nieautoryzowana ingerencja w pliki strony.
Zanim zaczniesz cokolwiek zmieniać, wykonaj kopię zapasową plików i bazy danych. Nawet jeśli strona nie działa, backup pozwoli cofnąć ewentualne nieudane naprawy.
Krok 1 – włącz tryb debugowania i zbierz informacje
Najważniejsze na starcie to poznać dokładny komunikat błędu. Umożliwia to tryb debugowania i log błędów.
Modyfikacja pliku wp-config.php
Wykonaj poniższe czynności przez FTP lub menedżera plików w panelu hostingu:
- Połącz się z serwerem i wejdź do katalogu głównego WordPressa, gdzie znajduje się plik
wp-config.php. - Otwórz
wp-config.phpdo edycji. - Znajdź linijkę (jeśli istnieje):
define('WP_DEBUG', false);
- Zmień ją (lub dodaj, jeśli jej nie ma) na:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Dzięki temu WordPress zapisze błędy do pliku logów, ale nie pokaże ich odwiedzającym.
- Zapisz plik i odśwież stronę, aby ponownie wywołać błąd i zapisać go w logu.
Odczyt pliku debug.log
Po włączeniu debugowania wykonaj te kroki:
- przejdź do katalogu
wp-contentna serwerze, - znajdź plik
debug.log(zazwyczaj WordPress tworzy go sam; jeśli nie ma — utwórz go ręcznie), - otwórz
debug.logi odszukaj ostatnie wpisy — wskazują plik, funkcję lub wtyczkę powodującą błąd.
W logu zazwyczaj zobaczysz:
- ścieżkę do pliku, w którym wystąpił błąd (np.
wp-content/plugins/nazwa-wtyczki/...), - numer linii,
- rodzaj błędu (np.
Fatal error: Uncaught Error,Call to undefined function,Allowed memory size exhausted).
Na tej podstawie z dużym prawdopodobieństwem wskażesz winowajcę — wtyczkę, motyw, własny fragment kodu lub ustawienie PHP. Kolejny krok to tymczasowe wyłączenie problematycznego elementu i dalsza analiza.
Krok 2 – wyłączenie wtyczek (najczęstsza przyczyna)
Wtyczki najczęściej powodują błędy krytyczne — zwłaszcza po aktualizacjach lub instalacji nowych dodatków.
Wyłączenie wszystkich wtyczek przez FTP
Gdy nie możesz zalogować się do panelu WordPress, zrób tak:
- Połącz się z serwerem przez FTP / SFTP lub menedżer plików hostingu.
- Przejdź do katalogu:
/wp-content/plugins
- Aby zbiorczo wyłączyć wszystkie wtyczki, zmień nazwę całego folderu
plugins, np. na:
plugins-dezaktywowane
WordPress przy ładowaniu strony nie znajdzie katalogu i potraktuje wszystkie wtyczki jako wyłączone.
- Odśwież stronę.
Jeśli błąd krytyczny zniknął, przyczyną była któraś z wtyczek.
Jeśli komunikat nadal się pojawia, problem leży gdzie indziej (motyw, baza, pliki, PHP).
Znalezienie konkretnej wtyczki powodującej błąd
Jeśli po wyłączeniu wszystkich wtyczek strona działa, przeprowadź selekcję:
- Przywróć nazwę folderu
pluginsdo oryginalnej. - Wyłączaj wtyczki stopniowo, zmieniając nazwy folderów poszczególnych wtyczek:
- wejdź do
wp-content/plugins/, - wybierz podejrzaną wtyczkę (np. ostatnio instalowaną lub aktualizowaną),
- zmień nazwę jej folderu, np. z
elementornaelementor-dezaktywowany.
- Po każdej zmianie nazwy odśwież stronę i sprawdź, czy błąd zniknął.
- Gdy po dezaktywacji konkretnej wtyczki strona działa poprawnie — znalazłeś winowajcę.
Co dalej z problematyczną wtyczką:
- Aktualizacja – sprawdź, czy dostępna jest nowsza wersja naprawiająca problem;
- Kompatybilność – zweryfikuj zgodność z Twoją wersją WordPressa i PHP (zwłaszcza po ich aktualizacji);
- Zgłoszenie błędu autorowi – opisz problem i dołącz fragmenty z
debug.log; - Changelog – przeczytaj dziennik zmian pod kątem znanych konfliktów lub poprawek;
- Alternatywa – tymczasowo użyj wtyczki o podobnej funkcjonalności;
- Wtyczka autorska – skorzystaj z pomocy programisty w dostosowaniu kodu do aktualnego WordPressa/PHP.
Krok 3 – sprawdzenie motywu (szablonu)
Jeśli log błędów wskazuje katalog wp-content/themes/, albo wyłączenie wszystkich wtyczek nie pomaga, następnym podejrzanym jest motyw.
Tymczasowe przełączenie na motyw domyślny
Gdy nie możesz wejść do panelu administratora:
- Połącz się z serwerem przez FTP / menedżer plików.
- Wejdź do katalogu:
/wp-content/themes
- Odnajdź folder aktualnie aktywnego motywu (nazwę poznasz z wcześniejszych ustawień lub logów błędów).
- Zmień nazwę tego folderu, np. dodając znak
_na początku:
_nazwa-motywu
Po zmianie nazwy WordPress nie odnajdzie motywu i spróbuje automatycznie przełączyć się na domyślny motyw (np. z serii Twenty Twenty‑xx), o ile jest zainstalowany.
Jeśli strona działa po przełączeniu — problem wynikał z motywu (konflikt, niekompatybilność lub błąd w plikach).
Naprawa lub wymiana motywu
Wykonaj następujące działania:
- Wgraj świeżą kopię motywu domyślnego z repozytorium WordPress, rozpakuj lokalnie i nadpisz pliki na serwerze;
- Aktualizacja motywu premium – sprawdź, czy dostępna jest wersja kompatybilna z bieżącym WordPressem i PHP;
- Informacje od autora – zweryfikuj, czy nie zgłoszono znanego błędu w najnowszej wersji;
- Motyw autorski – skontaktuj się z twórcą/programistą, by poprawić linie kodu wskazane w logach.
Krok 4 – plik .htaccess i ustawienia permalinków
Zmodyfikowany lub uszkodzony plik .htaccess potrafi wywołać liczne błędy — w tym te skutkujące błędem krytycznym.
Przywrócenie domyślnego .htaccess
- Połącz się przez FTP / menedżer plików.
- W katalogu głównym WordPressa znajdź plik:
.htaccess
- Dla bezpieczeństwa zrób kopię, np. zmieniając nazwę na
.htaccess-backup. - Utwórz nowy plik
.htaccessz domyślną zawartością WordPressa dla standardowych permalinków, np.:
# Domyślny .htaccess WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
- Zapisz plik i odśwież stronę. Jeśli błąd ustąpi, problem wynikał z poprzedniej konfiguracji
.htaccess.
Po odzyskaniu dostępu do panelu zapisz ponownie Bezpośrednie odnośniki (Permalinks), aby WordPress sam wygenerował poprawny .htaccess.
Krok 5 – sprawdzenie wersji PHP i limitu pamięci
Nieprawidłowa wersja PHP lub zbyt niski limit pamięci często powodują krytyczne błędy — zwłaszcza przy rozbudowanych motywach, page builderach i WooCommerce.
Wersja PHP na serwerze
W panelu hostingu (np. dhosting) zwykle możesz sprawdzić aktualną wersję PHP i zmienić ją na wyższą lub niższą — zgodnie z wymaganiami WordPressa oraz wtyczek.
Zweryfikuj zgodność: używana wersja PHP powinna być wspierana przez Twój WordPress i wtyczki; jeśli po zmianie wersji błąd krytyczny znika, przyczyną była niekompatybilność.
Zwiększenie limitu pamięci WordPressa
Komunikaty typu Allowed memory size exhausted oznaczają, że brakuje pamięci dla skryptów PHP.
Możesz zwiększyć limit w wp-config.php:
- Otwórz
wp-config.php. - Dodaj (lub zmień) linijkę:
define('WP_MEMORY_LIMIT', '256M');
WordPress spróbuje użyć większej ilości pamięci (np. 256 MB). Upewnij się, że limit pamięci po stronie serwera pozwala na taki rozmiar — w przeciwnym razie wpis w wp-config.php nie zadziała.
Krok 6 – naprawa plików WordPressa (rdzenia)
Gdy logi wskazują na pliki w rdzeniu WordPressa (wp-admin, wp-includes) lub podejrzewasz uszkodzenie plików po nieudanej aktualizacji, rozważ ponowne wgranie „czystych” plików WordPressa.
Bezpieczne przeinstalowanie rdzenia WordPressa
- Pobierz najnowszą wersję WordPressa z oficjalnego źródła i rozpakuj ją lokalnie.
- Za pomocą FTP prześlij na serwer wszystkie pliki z paczki, z wyłączeniem katalogu
wp-contentoraz plikuwp-config.php(aby nie nadpisywać motywów, wtyczek, uploadów i konfiguracji). - Zgódź się na nadpisanie istniejących plików rdzenia.
- Po zakończeniu wgrywania odśwież stronę — jeśli błąd był spowodowany uszkodzonym plikiem rdzenia, powinien zniknąć.
To bezpieczna metoda: nie ingeruje w treści i ustawienia, a naprawia jedynie „silnik” WordPressa.
Krok 7 – naprawa i diagnostyka bazy danych
WordPress intensywnie korzysta z bazy — jeśli jest uszkodzona lub dane uwierzytelniające są błędne, mogą pojawiać się błędy krytyczne.
Automatyczna naprawa bazy z poziomu WordPressa
WordPress ma wbudowane narzędzie do naprawy bazy danych, które uruchomisz przez wp-config.php:
- Otwórz plik
wp-config.php. - Dodaj linijkę:
define('WP_ALLOW_REPAIR', true);
- Zapisz plik.
- W przeglądarce wejdź pod adres:
/wp-admin/maint/repair.php
(podstaw swoją domenę przed ścieżką; logowanie nie jest wymagane).
- Uruchom naprawę bazy (opcjonalnie także optymalizację tabel).
- Po zakończeniu usuń dodaną linijkę
WP_ALLOW_REPAIRzwp-config.php— pozostawienie jej publicznie udostępnia narzędzie naprawy.
Sprawdzenie integralności bazy w phpMyAdmin
Dodatkowo wykonaj te działania:
- zaloguj się do phpMyAdmin z panelu hostingu,
- sprawdź tabele (opcje w stylu „Sprawdź”, „Napraw”),
- zidentyfikuj i napraw ewentualne błędy struktury tabel.
Narzędzia phpMyAdmin potrafią usunąć drobne błędy, które prowadzą do krytycznych problemów podczas działania strony.
Weryfikacja danych uwierzytelniających bazy
W niektórych konfiguracjach ustawienia połączenia z bazą możesz mieć osobno — upewnij się, że są poprawne:
- przejdź do sekcji ustawień bazy (w panelu lub konfiguracji),
- sprawdź poprawność nazwy bazy danych, użytkownika, hasła i hosta,
- popraw ewentualne błędy i zapisz zmiany.
Błędne dane dostępowe uniemożliwiają połączenie z bazą, co może skutkować błędami krytycznymi lub komunikatami o błędzie połączenia.
Krok 8 – aktualizacje, bezpieczeństwo i skan w poszukiwaniu malware
Po przywróceniu działania strony sprawdź, czy przyczyną nie były nieaktualne komponenty lub złośliwy kod.
Aktualizacja WordPressa, wtyczek i motywów
Nieaktualne, niewspierane wersje to częste źródło problemów i luk bezpieczeństwa. Warto:
- Rdzeń WordPressa – zaktualizować do najnowszej stabilnej wersji;
- Wtyczki i motywy – zaktualizować wszystkie po sprawdzeniu kompatybilności;
- Usuwanie nieużywanych – pozbywać się dodatków, których nie używasz, by zmniejszyć ryzyko konfliktów i ataków.
Skanowanie strony pod kątem złośliwego oprogramowania
Przy nawracających błędach lub podejrzanych wpisach w logach wykonaj skan w poszukiwaniu malware. Możesz użyć wtyczek bezpieczeństwa (skanerów plików i sygnatur) oraz narzędzi hostingodawcy (często oferują skan antywirusowy plików strony).
Jeśli pliki okażą się zainfekowane, wykonaj:
- usunięcie nieautoryzowanych plików,
- przywrócenie strony z czystej kopii zapasowej,
- zabezpieczenie dostępu (zmiana haseł, kluczy, włączenie 2FA).
Jak postępować w różnych sytuacjach – dwa scenariusze
W praktyce błędy krytyczne występują w dwóch wariantach: brak dostępu zarówno do frontu, jak i panelu; front nie działa, ale panel admina działa (lub odwrotnie).
Gdy nie masz dostępu do panelu admina
Wszystkie działania wykonujesz z poziomu FTP lub panelu hostingu:
- włączasz debugowanie przez edycję
wp-config.php, - czytasz
debug.logwwp-content, - wyłączasz wtyczki, zmieniając nazwę folderu
pluginslub pojedynczych wtyczek, - wyłączasz motyw, zmieniając nazwę jego folderu w
wp-content/themes, - naprawiasz
.htaccess, wersję PHP, pamięć i pliki WordPressa, - uruchamiasz naprawę bazy przez
WP_ALLOW_REPAIR.
Gdy masz dostęp do panelu admina
Jeśli panel działa, a front pokazuje błąd krytyczny, będzie łatwiej:
- możesz wyłączać i włączać wtyczki w sekcji „Wtyczki”, by znaleźć problematyczną,
- możesz zmienić motyw na domyślny w „Wygląd”,
- możesz przeinstalować WordPress w „Aktualizacje”.
Mimo to włącz WP_DEBUG i WP_DEBUG_LOG, aby mieć dokładny zapis błędów w debug.log.
Kiedy skontaktować się z hostingiem lub specjalistą?
Jeśli po wykonaniu powyższych kroków błąd krytyczny nadal się pojawia lub logi wskazują problemy z serwerem, których nie możesz samodzielnie rozwiązać, skontaktuj się z dostawcą hostingu albo zewnętrznym specjalistą od WordPressa.
W takim przypadku warto:
- przesłać hostingodawcy fragmenty z
debug.logi dziennika błędów serwera, - poprosić o weryfikację limitów zasobów, ustawień PHP i logów serwera (np.
error_log), - w razie potrzeby poprosić o przywrócenie kopii zapasowej z określonej daty.
Jeśli problem wynika z niestandardowego kodu (autorska wtyczka lub motyw), konieczna może być pomoc programisty, który poprawi wskazane w logach fragmenty.
Jak zapobiegać błędom krytycznym w przyszłości?
Błędom krytycznym można w dużej mierze zapobiegać, stosując kilka sprawdzonych praktyk:
- Regularne kopie zapasowe – wykonuj backup plików i bazy przed większymi aktualizacjami oraz instalacją nowych dodatków;
- Aktualizowanie WordPressa, wtyczek i motywów – utrzymuj najnowsze stabilne wersje i śledź kompatybilność z PHP;
- Unikanie nadmiaru wtyczek – im więcej dodatków, tym większe ryzyko konfliktów i błędów;
- Testy na środowisku staging – sprawdzaj zmiany przed wdrożeniem na stronę produkcyjną;
- Monitorowanie logów błędów – okresowo kontroluj
debug.logi logi serwera, by wychwycić problemy zawczasu; - Bezpieczeństwo – silne hasła, aktualne wtyczki bezpieczeństwa, ograniczenia dostępu do panelu i 2FA.
Stosowanie tych zasad znacząco zmniejsza ryzyko wystąpienia błędu krytycznego i przyspiesza diagnostykę w razie problemów.