Jak naprawić błędy krytyczne w WordPressie?
„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ć.
Błąd krytyczny w WordPressie: jak przywrócić stronę do działania i zapobiec awariom w przyszłości?
Błąd krytyczny w WordPressie: jak przywrócić stronę do działania i zapobiec awariom w przyszłości?
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?
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. |
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.
Bezpieczne wyłączenie wadliwej wtyczki
Jeżeli wpis w logach wskazuje na którąś z zainstalowanych wtyczek, wykonaj następujące kroki.
- Wejdź do katalogu wp-content, a następnie do folderu plugins.
- 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.
- 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.
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.
- Otwórz phpMyAdmin w panelu hostingu.
- Przejdź do bazy danych swojej strony.
- W tabeli wp_options znajdź dwa wpisy: template oraz stylesheet, a następnie zmień ich wartość na nazwę najnowszego domyślnego motywu WordPressa.
- 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.
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 256MWordPress 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
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
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
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:
- 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?
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.
