Przejdź do treści
Podobają Ci się nasze treści?
Sięgnij po unikalną wiedzę prosto od developerów i marketingowców. Zapisz się do newslettera.
CAPTCHA
Dziękujemy za zapisanie się do newslettera!
Aby otrzymywać najświeższe, branżowe informacje, potwierdź subskrypcję w mailu, który od nas dostałeś.
PS. Nawet tak ważne wiadomości lubią czasem pomylić folder, dlatego upewnij się, że mail nie trafił do SPAMU
Otwórz swoją skrzynkę e-mail

Jak naprawić błędy krytyczne w WordPressie?

Kategoria: 
Opublikowane: 
Czas czytania
: 10 min

„W witrynie wystąpił błąd krytyczny” – tego komunikatu żaden administrator WP nie chce zobaczyć, a jednak pojawia się dość często, zwłaszcza na stronach z dużą liczbą wtyczek. Na szczęście wyjście z tej sytuacji jest łatwiejsze, niż może się zdawać. Poniżej wyjaśniamy krok po kroku, jak to zrobić.

Sposoby naprawiania błędów krytycznych w WP

Błąd krytyczny w WordPressie: jak przywrócić stronę do działania i zapobiec awariom w przyszłości?

WordPress – wystąpienie błędu krytycznego

Taka informacja pojawi się na stronie, jeśli w plikach witryny znajdzie się skrypt, którego PHP nie jest w stanie obsłużyć i z tego powodu zatrzyma wykonywanie kodu. Na tym, w dużym skrócie, polega błąd krytyczny WordPressa. W takiej sytuacji zarówno Ty, jak i użytkownicy nie będziecie mogli wejść na stronę, dopóki problem nie zostanie rozwiązany – dlatego trzeba działać jak najszybciej.

Jak samodzielnie naprawić błąd krytyczny w WordPressie?

Zaczynamy od uzyskania dostępu do plików strony na serwerze. Są trzy ścieżki dostępu.

Ścieżka dostępu

Jak z niej skorzystać?

Panel hostingu

Każdy hostingodawca oferuje interfejs, za pomocą którego możesz przeglądać i edytować pliki strony w menedżerze bez żadnych dodatkowych narzędzi. Najczęściej będzie to cPanel lub Plesk, oba są równie łatwe w użyciu.

FTP

Dostęp do plików możesz uzyskać za pośrednictwem FileZilli lub innego klienta FTP. Oczywiście musisz znać dane dostępowe do serwera (host, login, hasło oraz port).

SSH

Jeśli na serwerze włączony jest protokół SSH, wtedy można edytować pliki również za pomocą wiersza poleceń WP-CLI. To opcja dla doświadczonych administratorów.

  1. Włączenie trybu debugowania (WP_DEBUG) i lokalizacja błędu

    Gdy masz już dostęp do plików strony, trzeba znaleźć przyczynę błędu. Najłatwiej to zrobić włączając tryb debugowania WordPressa. Domyślnie jest on wyłączony – dla bezpieczeństwa, żeby nie ujawniać za dużo informacji o „zapleczu” witryny.

    Aby go uruchomić:

    • otwórz plik wp-config.php, który znajduje się w głównym katalogu instalacji WordPressa;
    • znajdź linijkę:

    define( 'WP_DEBUG', false );

    • zastąp ją wpisem:
    define( 'WP_DEBUG', true ); 
    define( 'WP_DEBUG_LOG', true ); 
    define( 'WP_DEBUG_DISPLAY', false );
    

    Bardzo ważne, aby wpis wyglądał dokładnie tak, jak wyżej!

    WP\_DEBUG\_LOG zapisuje błędy do pliku /wp-content/debug.log na serwerze, do którego tylko Ty masz dostęp. Natomiast jeśli ustawiłbyś na true również WP\_DEBUG\_DISPLAY, wtedy dokładna informacja o błędzie pojawiłaby się… w komunikacie na stronie, więc każdy mógłby ją przeczytać.

    Po zapisaniu pliku wejdź na stronę, odśwież ją, a następnie otwórz plik wp-content/debug.log – znajdziesz tam wpisy w formacie:

    PHP Fatal error: [opis błędu] in /wp-content/plugins/[nazwa wtyczki]/plik.php on line 42

    Mamy tu informację, na jakim pliku i w której konkretnie linijce zatrzymał się proces wykonywania kodu strony. To tam leży problem.

  2. Bezpieczne wyłączenie wadliwej wtyczki

    Jeżeli wpis w logach wskazuje na którąś z zainstalowanych wtyczek, wykonaj następujące kroki.

    1. Wejdź do katalogu wp-content, a następnie do folderu plugins.
    2. Znajdź podfolder wskazanej wtyczki i zmień jego nazwę na inną – wystarczy nawet dodać jedną literę, wtedy WP nie będzie mógł jej znaleźć i potraktuje ją tak, jakby była nieaktywna.
    3. Odśwież stronę. Jeśli komunikat o błędzie krytycznym znikł, to znaczy, że za błędem PHP w WordPressie faktycznie stał wadliwy plugin.

    Co, jeśli po wyłączeniu wtyczki strona nadal nie zadziała? Wtedy wróć do debug.log i sprawdź, jaki tym razem pojawia się błąd. Na stronach z dużą liczbą zainstalowanych pluginów czasem dochodzi do konfliktów między nimi. Być może trzeba sprawdzić kilka wtyczek.

    Dalej opcje są trzy:

    • jeśli dostępna jest aktualizacja pluginu – koniecznie ją zainstaluj, bo twórcy mogli już naprawić błąd;
    • jeśli nie – możliwe, że będzie trzeba całkowicie usunąć wtyczkę i znaleźć dla niej alternatywę;
    • jeżeli Twoja strona nie może normalnie funkcjonować bez tego konkretnego pluginu – warto skontaktować się z jego twórcami i przedstawić błąd wraz z logami.
  3. Wykluczenie błędu motywu i uszkodzonego pliku functions.php

    Może również okazać się, że problem leży gdzieś indziej niż we wtyczkach, na przykład w pliku functions.php. To jeden z ważniejszych plików w całej instalacji WordPressa, bo pozwala dodawać niestandardowe funkcje PHP i zmieniać w ten sposób zachowanie witryny. Sęk w tym, że wystarczy jedna literówka, aby pojawił się błąd krytyczny.

    Ważne jest to, że plik functions.php jest powiązany z motywem strony i uruchamia się razem z nim; dlatego jeśli chcesz sprawdzić, czy to on jest źródłem problemu, wystarczy, że zmienisz motyw.

    1. Otwórz phpMyAdmin w panelu hostingu.
    2. Przejdź do bazy danych swojej strony.
    3. W tabeli wp_options znajdź dwa wpisy: template oraz stylesheet, a następnie zmień ich wartość na nazwę najnowszego domyślnego motywu WordPressa.
    4. Odśwież stronę i sprawdź, czy błąd zniknął.

    Jeśli masz dostęp przez SSH, możesz zrobić to samo (ale szybciej) przez WP-CLI przy użyciu komendy:

    wp theme activate twentytwentyfive

    Strona znów działa? To znaczy, że niemal na pewno trzeba przyjrzeć się bliżej functions.php – plik możesz pobrać przez FTP z folderu wp-content/themes/[nazwa motywu]. Przejrzyj go przede wszystkim pod kątem ostatnio wprowadzonych zmian – poszukaj literówek, brakujących średników, niezamkniętych nawiasów itp.

  4. Zwiększenie limitu pamięci

    Jest jeszcze inna opcja. PHP, wykonując skrypty WordPressa, operuje w ramach określonego limitu pamięci RAM. Jeśli jakaś operacja go przekroczy, serwer także zatrzyma wykonywanie skryptu. W debug.log wygląda to tak:

    PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

    134217728 bajtów to dokładnie 128 MB – na wielu hostingach współdzielonych tyle właśnie wynosi limit. Można go jednak zwiększyć:

    • dodając w pliku wp-config.php linijkę:
    define( 'WP_MEMORY_LIMIT', '256M' );
    • edytując plik php.ini i zmieniając wartość linii (jeśli plik nie jest widoczny w katalogu głównym, należy szukać ustawień w panelu hostingu):
    memory_limit = 128M;
    • lub dodając do pliku .htaccess linię:
    php_value memory_limit 256M

    WordPress pozwala ustawić limit wyższy niż ten zdefiniowany w konfiguracji PHP tylko wtedy, gdy umożliwia to również hostingodawca. Jeżeli faktycznie Twoja witryna potrzebuje większej ilości pamięci RAM, być może trzeba będzie pomyśleć o migracji na serwer z bardziej elastyczną konfiguracją PHP? Z drugiej strony, dla większości serwisów 128 lub 256 MB powinno w zupełności wystarczyć, więc konieczność zwiększenia limitu RAM-u może świadczyć po prostu o słabej optymalizacji witryny.

Kopia zapasowa (backup) vs profesjonalny rollback w e-commerce

Powyższe kroki powinny pomóc, tyle że przejście przez nie może zająć dużo czasu. A wiadomo, że dla właścicieli e-sklepów czy stron o naprawdę dużym ruchu każda minuta downtime’u oznacza straty.

Kilka lat temu firma konsultingowa PwC – w ramach badania Future of CX – spytała 15 tysięcy klientów e-commerce z całego świata o to, jak zachowują się, gdy trafiają na stronie sklepu na błędy uniemożliwiające im zakupy. Aż 1/3 ankietowanych przyznała, że są skłonni nigdy już nie wrócić do sklepu po jednej takiej „wpadce”, a 59% – po dwóch lub trzech.

Aby nie ryzykować, najłatwiej byłoby przywrócić kopię zapasową WordPressa sprzed awarii. Tylko że od momentu wykonania ostatniego backupu do pojawienia się błędu może minąć kilka-kilkanaście godzin, w zależności od częstotliwości generowania kopii zapasowych. Co z zamówieniami, które trafiły do bazy danych w tym czasie? Trzeba byłoby je odtwarzać ręcznie, dlatego lepszym rozwiązaniem będzie:

  • znaleźć jak najszybciej źródło błędu,
  • a potem wykonać rollback, czyli cofnąć wyłącznie tę zmianę, która spowodowała błąd, nie ruszając w ogóle bazy danych.

Możesz to zrobić na przykład przy pomocy wtyczki WP Rollback, która pozwala jednym kliknięciem przywrócić dowolny plugin lub motyw do wcześniejszej wersji.

Zaawansowana diagnostyka: narzędzia stosowane w środowiskach enterprise

Wszystko jednak zależy od tego, czy uda Ci się szybko zidentyfikować przyczynę.

Debugging WordPressa z WP_DEBUG to jedna opcja, ale dobrze mieć też do dyspozycji bardziej zaawansowane narzędzia diagnostyczne. Standardem w społeczności WP stał się Query Monitor – darmowa, open source’owa wtyczka, wykorzystywana nawet przy największych projektach. Plugin w czasie rzeczywistym monitoruje zapytania do bazy danych oraz skrypty wykonywane na stronie, zapisuje wszystkie błędy 404 WordPressa, a nawet śledzi zależności między innymi wtyczkami. Jeśli błąd krytyczny wynika na przykład z konfliktu między dwoma pluginami, co dzieje się bardzo często, to z Query Monitor wychwycisz to o wiele szybciej.

Główne przyczyny błędów krytycznych

Na szczęście – i warto to podkreślić – błędy krytyczne WP w większości przypadków mają te same, dobrze znane źródła. Czyli:

WordPress – najczęstsze powody błędów krytycznych
  • konflikty między wtyczkami – najczęściej dochodzi do nich wtedy, gdy dwa pluginy próbują zdefiniować tę samą funkcję PHP lub gdy aktualizacja jednego zmienia sposób działania fragmentu kodu, od którego zależy inny. Ryzyko, rzecz jasna, rośnie wraz z liczbą zainstalowanych wtyczek;
  • źle przeprowadzona aktualizacja motywu WordPressa, pluginu lub core’u – jeśli update zostanie przerwany z powodu timeoutu PHP lub chwilowego braku połączenia, część plików pozostanie w starej wersji, a część w nowej. Przy próbie uruchomienia strony WordPress będzie próbował wykonać kod, który zakłada istnienie funkcji lub klas, których jeszcze nie ma – i zatrzyma się z błędem krytycznym;
  • błędy w pliku functions.php po ręcznej edycji kodu – częsty problem na stronach, na których kilka osób (nie tylko administrator!) ma dostęp do edytora plików w panelu WordPressa;
  • niski limit pamięci RAM na serwerze – problem dotyczy głównie, tak jak wspomnieliśmy, tanich serwerów współdzielonych albo słabo zoptymalizowanych, przeciążonych wtyczkami stron;
  • uszkodzona baza danych – na przykład w wyniku nieudanej migracji lub błędu po aktualizacji WordPressa, która zmieniła strukturę tabel;
  • niekompatybilna wersja PHP – jeśli hosting korzysta ze starszego wydania PHP, niż wymagają tego core WordPressa oraz zainstalowane wtyczki, może on po prostu nie być w stanie obsłużyć niektórych funkcji wprowadzonych w nowszych wersjach języka.

Od doraźnych napraw do stabilnej infrastruktury: kiedy warto rozważyć audyt technologiczny?

Błąd krytyczny może pojawić się nawet na dobrze zarządzanej stronie. Wystarczy, że dwie wtyczki wejdą ze sobą w konflikt po aktualizacji, czego z reguły nie da się przewidzieć.

Natomiast jeśli takie „incydenty” mają miejsce regularnie (choćby kilka razy w roku) jest to sygnał, że ich źródło prawdopodobnie kryje się głębiej w środowisku witryny. Wtedy warto zastanowić się nad audytem technicznym, który możemy przeprowadzić w Smartbees. Skontaktuj się z nami – podpowiemy, co robić dalej, aby rozwiązać problemy WordPressa i Twojej strony.

Czy błąd krytyczny w WordPressie oznacza, że strona została zhakowana?

Nie, to dwa różne problemy. Hakerom atakującym stronę zazwyczaj zależy na tym, żeby witryna działała normalnie, podczas gdy w tle działa złośliwy kod. Błąd krytyczny by im to uniemożliwił.

Dlaczego WordPress wyrzucił błąd od razu po aktualizacji wtyczki?

Po aktualizacji pluginów WordPressa wtyczki czasem wchodzą ze sobą w konflikty, jeśli update zmienił sposób działania współdzielonych przez nie funkcji. Może być również tak, że nowa wersja pluginu jest niekompatybilna z aktualną wersją PHP na Twoim serwerze albo że pobieranie paczki aktualizacji nie przebiegło poprawnie i część plików jest uszkodzona.

Czy błąd HTTP 500 (Internal Server Error) to to samo co błąd krytyczny WordPressa?

Nie do końca. Błąd 500 w WordPressie oznacza tylko tyle, że problem z witryną leży po stronie serwera. Przyczyną równie dobrze może być błąd PHP, ale też źle skonfigurowany plik .htaccess albo przekroczenie limitu czasu wykonywania skryptu.

Jak wyłączyć wszystkie wtyczki w WordPress bez dostępu do panelu administratora?

To bardzo proste. Wystarczy wejść przez klienta FTP do plików strony na serwerze, znaleźć katalog wp-content i zmienić nazwę folderu plugins na inną – na przykład na plugins.disabled. Wtedy WordPress automatycznie potraktuje wszystkie wtyczki jako nieaktywne.

Czy przywrócenie niższej wersji PHP naprawi błąd krytyczny?

Tylko w jednym, bardzo konkretnym przypadku: jeśli błąd pojawił się bezpośrednio po aktualizacji PHP na serwerze i wynika z niekompatybilności jednej z wtyczek lub motywu strony z nową wersją języka.

Oceń wpis
0

Dziękujemy za ocenę postu!

Mamy więcej darmowych treści. Nie rezygnuj z nich!
Technologie, SEO, marketing - newsletter z poradami, które od razu możesz wdrożyć! Prosto na Twoją skrzynkę. Za darmo i bez spam
CAPTCHA