Komunikat „Wystąpił krytyczny błąd na Twojej stronie” wygląda groźnie, ale zazwyczaj oznacza konkretny błąd PHP, który można namierzyć. Zamiast wyłączać losowo pół WordPressa, wolę najpierw zdobyć informację, który plik, wtyczka albo fragment kodu rzeczywiście spowodował awarię.
W praktyce przyczyną często okazuje się konflikt wtyczek, nieudana aktualizacja, niekompatybilny motyw, własny kod w functions.php, brak pamięci PHP albo zmiana wersji PHP na hostingu.
Krytyczny błąd zwykle oznacza fatalny błąd PHP.
Najpierw sprawdzam wiadomość Recovery Mode wysłaną na e-mail administratora.
Na publicznej stronie zapisuję błędy do pliku zamiast pokazywać je użytkownikom.
Log błędów najczęściej znajdziesz w wp-content/debug.log.
Jeżeli panel nie działa, wadliwą wtyczkę można wyłączyć przez FTP.
Po diagnozie wyłączam debugowanie i ponownie testuję stronę.
Co oznacza krytyczny błąd w WordPressie?
WordPress pokazuje ogólny komunikat zamiast szczegółowego błędu PHP, ponieważ wyświetlanie pełnych informacji technicznych użytkownikom nie jest dobrym rozwiązaniem na stronie produkcyjnej.
Dla mnie najważniejsze jest dotarcie do prawdziwej treści błędu. To właśnie tam często znajduje się nazwa konkretnej wtyczki, ścieżka do pliku i numer linii, na której PHP przerwało wykonywanie strony.
Najpierw sprawdź e-mail administratora WordPress
WordPress posiada tryb odzyskiwania. Przy części błędów wysyła na adres administratora wiadomość zawierającą informacje o awarii oraz specjalny link umożliwiający zalogowanie się w Recovery Mode.
Jeżeli wiadomości nie ma w skrzynce głównej, sprawdzam również spam. Brak e-maila nie oznacza jednak, że błędu nie da się zdiagnozować – wtedy przechodzę bezpośrednio do logów.
Jak włączyć WP_DEBUG i zapisywanie błędów?
Przed edycją wp-config.php robię kopię pliku. Następnie przed linią kończącą edycję konfiguracji WordPressa dodaję:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Dzięki temu WordPress może zapisywać komunikaty diagnostyczne do pliku, ale nie musi wyświetlać technicznych błędów osobom odwiedzającym stronę.
Gdzie znaleźć debug.log?
Standardowo szukam go tutaj:
/wp-content/debug.log
Po odtworzeniu błędu otwieram plik i szukam przede wszystkim wpisów zawierających Fatal error, Uncaught albo nazwę konkretnej wtyczki lub motywu.
Przykład komunikatu
PHP Fatal error: Uncaught TypeError...
in /wp-content/plugins/nazwa-wtyczki/includes/file.php on line 245Taki log daje już konkretny punkt zaczepienia. Zamiast zgadywać, wiem, że problem pojawił się podczas wykonywania kodu określonego rozszerzenia.
Co zrobić, jeśli błąd powoduje wtyczka?
Jeżeli mam dostęp do panelu, mogę ją po prostu dezaktywować. Jeśli /wp-admin/ również pokazuje krytyczny błąd, korzystam z FTP albo menedżera plików hostingu.
/wp-content/plugins/nazwa-wtyczki/zmieniam np. na:
/wp-content/plugins/nazwa-wtyczki-disabled/Jeżeli strona zaczyna działać, mam bardzo mocny sygnał, że problem jest związany właśnie z tym rozszerzeniem.
A jeśli winny jest motyw?
Podobnie analizuję katalog aktywnego motywu. Problem może pojawić się po aktualizacji, zmianach w motywie potomnym albo wklejeniu własnego kodu.
Jeżeli błąd zaczął się dokładnie po edycji functions.php, w pierwszej kolejności cofam tę zmianę.
Sprawdź wersję PHP
Starsza wtyczka może przestać działać po przełączeniu hostingu na nowsze PHP. Z kolei bardzo stare PHP może powodować problemy z aktualnym WordPressem lub rozszerzeniami.
Nie zmieniam wersji PHP tylko po to, żeby „zobaczyć, czy pomoże”. Najpierw sprawdzam log i wymagania wykorzystywanego oprogramowania.
Czy problemem może być limit pamięci?
Tak. Jeżeli w logu pojawia się komunikat:
Allowed memory size ... bytes exhaustedproblemem jest brak dostępnej pamięci dla wykonywanego procesu PHP. Samo zwiększenie limitu nie zawsze rozwiązuje jednak przyczynę.
Moja kolejność diagnozy krytycznego błędu
- Sprawdzam wiadomość Recovery Mode.
- Robię kopię plików i bazy.
- Włączam logowanie błędów bez wyświetlania ich użytkownikom.
- Odtwarzam problem i analizuję
debug.log. - Sprawdzam wskazaną wtyczkę, motyw albo własny kod.
- Weryfikuję wersję PHP i dostępne zasoby.
- Naprawiam właściwą przyczynę, a nie sam komunikat.
- Wyłączam debugowanie i ponownie testuję stronę.
Jeżeli nie chcesz ingerować samodzielnie w pliki strony, możesz skorzystać z mojego wsparcia technicznego WordPress i WooCommerce .
Nie musisz naprawiać krytycznego błędu metodą prób i błędów
Podeślij mi adres strony i informację, co wydarzyło się przed awarią. Mogę sprawdzić logi, wtyczki, motyw, PHP i przywrócić prawidłowe działanie WordPressa.
Krytyczny błąd WordPress – najczęstsze pytania
Co najczęściej powoduje krytyczny błąd WordPress?
Najczęściej szukam problemu w wtyczkach, motywie, własnym kodzie, wersji PHP, limitach pamięci albo nieudanej aktualizacji.
Gdzie znajduje się plik debug.log?
Przy standardowej konfiguracji WP_DEBUG_LOG plik znajduje się w katalogu wp-content/debug.log.
Czy można włączyć debugowanie bez pokazywania błędów klientom?
Tak. Włączam WP_DEBUG i WP_DEBUG_LOG, a WP_DEBUG_DISPLAY ustawiam na false. Dzięki temu błędy mogą trafiać do logu zamiast na ekran użytkownika.
Jak wyłączyć wtyczkę bez dostępu do wp-admin?
Można połączyć się przez FTP lub użyć menedżera plików hostingu i tymczasowo zmienić nazwę katalogu danej wtyczki.
Czy po naprawie zostawić WP_DEBUG włączony?
Na publicznej stronie nie zostawiam debugowania włączonego bez potrzeby. Po zakończeniu diagnozy przywracam standardową konfigurację.
Kamil Sudoł – freelancer WordPress & SEO. Od 2015 roku tworzę i rozwijam strony internetowe oraz sklepy WooCommerce, a także zajmuję się SEO i widocznością firm w Google. Na blogu publikuję praktyczne materiały dotyczące WordPressa, SEO, UX i marketingu internetowego.
