„W witrynie wystąpił błąd krytyczny”. Jak znaleźć wtyczkę, która go wywołała?

Strona działała bez zarzutu, a po chwili zamiast oferty widać białe tło i jedno zdanie: „W witrynie wystąpił błąd krytyczny”. Nie da się wejść na podstrony, często nie da się też zalogować do panelu. Dla firmy oznacza to przerwę w przyjmowaniu zapytań i zamówień, dlatego liczy się spokojne, uporządkowane działanie.

Ten komunikat w zdecydowanej większości przypadków wywołuje jedna wtyczka albo motyw. WordPress ma kilka wbudowanych sposobów, żeby wskazać, który to element, i żeby go bezpiecznie wyłączyć bez utraty treści strony. Trzeba tylko wiedzieć, gdzie szukać.

Ta instrukcja jest napisana dla właścicieli firm i osób, które opiekują się stroną samodzielnie. Po lekturze będzie wiadomo, jak odczytać nazwę wtyczki z wiadomości od WordPressa, jak skorzystać z trybu awaryjnego, jak wyłączyć wtyczki przez serwer plików, jak czytać dziennik błędów i co zrobić z wtyczką, która zawiodła.

Po czym rozpoznać błąd krytyczny i co widzą wtedy klienci?

Osoba odwiedzająca stronę widzi krótkie zdanie „W witrynie wystąpił błąd krytyczny.” oraz odnośnik „Dowiedz się więcej o rozwiązywaniu problemów z WordPressem.”. Nic więcej. WordPress celowo nie pokazuje gościom szczegółów technicznych, bo mogłyby one ułatwić atak na stronę.

Przy próbie wejścia do panelu administracyjnego komunikat bywa dłuższy i zawiera informację, że instrukcje znajdują się w skrzynce e-mail administratora witryny. To ważna podpowiedź: WordPress w chwili awarii sam wysyła wiadomość ze wskazaniem przyczyny.

Błąd może obejmować całą stronę albo tylko jej część. Zdarza się, że strona główna działa, a komunikat pojawia się wyłącznie w koszyku, w formularzu albo w panelu. To również cenna informacja, bo zawęża poszukiwania do wtyczki, która obsługuje właśnie to miejsce.

Ten komunikat zastąpił dawny pusty, biały ekran. Jeśli na stronie nie ma żadnego zdania, tylko całkowicie pusta karta przeglądarki, postępowanie jest bardzo podobne i opisałem je osobno we wpisie o tym, jak przywrócić stronę, gdy WordPress pokazuje biały ekran.

Dlaczego WordPress pokazuje ten komunikat?

Błąd krytyczny oznacza, że kod napisany w języku PHP natrafił na przeszkodę, której nie potrafił ominąć, i przerwał pracę. WordPress przechwytuje taką sytuację i zamiast niezrozumiałego zapisu technicznego wyświetla jedno zdanie. Sam komunikat jest więc skutkiem, a przyczyny trzeba poszukać głębiej.

W praktyce przyczyn jest kilka i powtarzają się one na większości stron:

• aktualizacja wtyczki, która wprowadziła błąd albo przestała współpracować z inną wtyczką lub z motywem,
• instalacja nowej wtyczki, która nie jest zgodna z używaną wersją WordPressa albo PHP,
• zmiana wersji PHP na serwerze, po której starsza wtyczka lub motyw przestały działać,
• przerwana aktualizacja, po której na serwerze została tylko część plików wtyczki,
• wyczerpany limit pamięci, czyli sytuacja, w której strona potrzebuje więcej zasobów, niż przydziela jej serwer,
• ręczna zmiana w plikach motywu lub wklejony fragment kodu z literówką.

Każda z tych przyczyn zostawia ślad: w wiadomości e-mail, w trybie awaryjnym albo w dzienniku błędów. Kolejność sprawdzania ma znaczenie. Najpierw należy sięgnąć po to, co WordPress podaje sam, a dopiero potem przejść do pracy na plikach.

Co przygotować, zanim zacznie się cokolwiek zmieniać?

Pośpiech jest tu złym doradcą. Kilka minut przygotowania chroni przed pogorszeniem sytuacji i oszczędza późniejszego szukania haseł w trakcie awarii.

• Dostęp do skrzynki, na którą przychodzą wiadomości administratora strony. Adres ten jest zapisany w panelu, w menu „Ustawienia”, na ekranie „Ogólne”.
• Dostęp do panelu firmy hostingowej, a w nim do menedżera plików, albo dane do połączenia FTP lub SFTP.
• Aktualna kopia zapasowa plików i bazy danych. Większość firm hostingowych wykonuje kopie automatycznie i pozwala je przywrócić z panelu.
• Notatka o tym, co działo się ze stroną tuż przed awarią: jaka wtyczka została zainstalowana lub zaktualizowana, czy zmieniano motyw, czy ktoś wklejał kod.

Jeśli nie ma pewności, czy kopia istnieje i czy da się ją odtworzyć, radzę najpierw to ustalić. Sposób wykonania i sprawdzenia kopii opisałem we wpisie o tym, jak zrobić kopię zapasową WordPressa, która naprawdę działa.

Ostatnia zmiana przed awarią jest najmocniejszym tropem. Jeżeli błąd pojawił się kilka sekund po aktualizacji konkretnej wtyczki, to od niej należy zacząć, a pozostałe kroki posłużą głównie do potwierdzenia podejrzenia.

Jak odczytać nazwę wtyczki z wiadomości od WordPressa?

WordPress ma wbudowany mechanizm, który wykrywa błąd krytyczny wywołany przez wtyczkę lub motyw i wysyła o tym automatyczną wiadomość na adres administratora. To najszybsza droga do odpowiedzi, dlatego od niej zaczyna się poszukiwania.

1. Należy otworzyć skrzynkę, której adres jest ustawiony jako adres administratora witryny, i poszukać wiadomości o temacie kończącym się słowami „Twoja witryna ma problemy techniczne”. Na początku tematu, w nawiasie kwadratowym, znajduje się nazwa strony.
2. Jeśli wiadomości nie ma w odebranych, trzeba zajrzeć do folderu ze spamem oraz do zakładek, do których program pocztowy odkłada powiadomienia.
3. W treści należy odnaleźć zdanie zaczynające się od słów „WordPress wykrył błąd w używanej wtyczce:”. Po dwukropku podana jest nazwa wtyczki. Jeśli błąd wywołał motyw, zdanie brzmi „WordPress wykrył błąd w używanym motywie:”.
4. Niżej znajduje się część „Szczegóły błędu”. Zawiera ona zdanie według wzoru: błąd danego typu został spowodowany w określonej linii określonego pliku, a po nim komunikat błędu. Ten fragment warto skopiować do notatnika w całości.
5. W wiadomości jest też długi odnośnik do trybu awaryjnego. Nie należy go nikomu przesyłać, ponieważ pozwala przejść do logowania w specjalnym trybie pracy strony.

Najwięcej mówi ścieżka pliku ze szczegółów błędu. Jeśli zawiera fragment /wp-content/plugins/, to nazwa katalogu zapisana zaraz po nim jest nazwą katalogu wtyczki, która zawiodła. Fragment /wp-content/themes/ wskazuje na motyw, a /wp-content/mu-plugins/ na wtyczkę wymuszaną, o której mowa w dalszej części.

Odnośnik z wiadomości ma ograniczony czas ważności, podany w jej treści. Nie jest to powód do niepokoju: jeśli błąd wystąpi ponownie po wygaśnięciu odnośnika, WordPress wyśle nową wiadomość. Nie wysyła ich jednak jedna po drugiej, więc po pierwszej wiadomości kolejna nie pojawi się od razu.

Jak wejść w tryb awaryjny i wyłączyć wadliwą wtyczkę?

Tryb awaryjny to specjalny sposób pracy panelu, w którym WordPress wstrzymuje wtyczkę lub motyw wywołujące błąd. Wstrzymanie działa tylko w przeglądarce osoby, która weszła przez odnośnik z wiadomości. Pozostali odwiedzający nadal widzą komunikat o błędzie, dopóki przyczyna nie zostanie usunięta.

1. Należy kliknąć odnośnik do trybu awaryjnego z wiadomości od WordPressa. Otworzy się zwykły ekran logowania z informacją „Włączono Tryb awaryjny. Zaloguj się, by kontynuować.”.
2. Trzeba zalogować się na konto z uprawnieniami administratora.
3. Po zalogowaniu u góry panelu widać informację, że witryna jest w trybie awaryjnym, a na górnym pasku przycisk „Wyjdź z trybu awaryjnego”. Na razie nie należy go używać.
4. W menu po lewej stronie wybiera się „Wtyczki”, a następnie „Zainstalowane wtyczki”. Nad listą pojawia się informacja „Nie udało się załadować co najmniej jednej wtyczki.” oraz filtr „Wstrzymane”.
5. Przy wstrzymanej wtyczce widnieje opis „Wtyczka nie została załadowana poprawnie, więc wstrzymano jej ładowanie w trybie awaryjnym.”. Pod jej nazwą są dwa odnośniki: „Wyłącz” oraz „Wznów”. Należy kliknąć „Wyłącz”.
6. Jeśli wstrzymany został motyw, analogiczną informację i przycisk „Wznów” widać w menu „Wygląd”, na ekranie „Motywy”. W takiej sytuacji włącza się tam inny motyw, najlepiej jeden z domyślnych motywów WordPressa.
7. Na końcu trzeba kliknąć „Wyjdź z trybu awaryjnego” na górnym pasku i otworzyć stronę w oknie prywatnym przeglądarki, żeby zobaczyć ją tak, jak widzą ją klienci.

Przycisk „Wznów” służy do ponownego uruchomienia wtyczki po usunięciu przyczyny, na przykład po poprawieniu wklejonego kodu. Jeśli nic nie zostało naprawione, WordPress odpowie komunikatem „Nie można było wznowić działania wtyczki, ponieważ spowodowała ona błąd krytyczny.” i pozostawi ją wstrzymaną.

Wyłączenie wtyczki nie usuwa jej ustawień ani danych. Znika jedynie funkcja, za którą odpowiadała, na przykład formularz, galeria albo płatności. Trzeba to wziąć pod uwagę i sprawdzić, czego na stronie chwilowo brakuje.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: ustalę, która wtyczka lub który motyw wywołuje błąd, przywrócę działanie strony i zabezpieczę ją przed powtórką tej samej awarii.

Wiadomość nie przyszła. Jak wyłączyć wtyczki przez serwer plików?

Zdarza się, że wiadomości nie ma. Adres administratora bywa nieaktualny, serwer może nie wysyłać poczty, a czasem awaria jest tak głęboka, że WordPress nie zdąży niczego wysłać. Wtedy wtyczki wyłącza się ręcznie, przez menedżer plików w panelu hostingu albo przez program do połączeń FTP.

Zasada jest prosta: WordPress uruchamia tylko te wtyczki, których katalogi znajduje pod zapisaną nazwą. Zmiana nazwy katalogu sprawia, że wtyczka przestaje się ładować. Jej ustawienia pozostają nietknięte w bazie danych, a operację da się cofnąć w kilka sekund.

Gdy podejrzenie pada na jedną wtyczkę

Jeśli wiadomo, co było instalowane lub aktualizowane tuż przed awarią, wystarczy wyłączyć ten jeden element. To najmniej inwazyjna droga, bo pozostałe funkcje strony działają bez przerwy.

1. Należy zalogować się do panelu firmy hostingowej i otworzyć menedżer plików albo połączyć się z serwerem przez FTP.
2. Trzeba przejść do katalogu, w którym zainstalowany jest WordPress. Rozpoznaje się go po katalogach wp-admin, wp-content i wp-includes oraz po pliku wp-config.php.
3. Następnie otwiera się katalog wp-content, a w nim katalog plugins. Każda wtyczka ma tu własny katalog.
4. Katalogowi podejrzanej wtyczki zmienia się nazwę przez dopisanie końcówki, na przykład z nazwa-wtyczki na nazwa-wtyczki.hold.
5. Stronę należy odświeżyć w oknie prywatnym przeglądarki. Jeśli komunikat zniknął, przyczyna została potwierdzona.

Po takim zabiegu WordPress sam oznaczy wtyczkę jako wyłączoną przy najbliższym wejściu na ekran „Zainstalowane wtyczki”. Katalogu nie należy usuwać, dopóki nie zapadnie decyzja, co dalej z wtyczką.

Gdy nie wiadomo, która wtyczka zawiodła

W tej sytuacji dokumentacja WordPressa zaleca wyłączenie wszystkich wtyczek naraz przez zmianę nazwy całego katalogu plugins, na przykład na plugins.hold. Strona będzie wtedy działać bez żadnych dodatków, więc może wyglądać ubogo i nie mieć części funkcji. To stan przejściowy, potrzebny tylko do ustalenia przyczyny.

Po zmianie nazwy katalogu należy zalogować się do panelu i otworzyć ekran „Zainstalowane wtyczki”. WordPress wyświetli informacje, że wtyczek nie znaleziono, i oznaczy je jako wyłączone. Dopiero wtedy przywraca się katalogowi pierwotną nazwę plugins. Wtyczki wrócą na listę, ale wszystkie pozostaną wyłączone.

Jeżeli po zmianie nazwy katalogu komunikat o błędzie krytycznym nadal się wyświetla, wtyczki nie są przyczyną. Katalogowi trzeba przywrócić nazwę i przejść do sprawdzenia motywu, pamięci oraz wersji PHP, opisanych w dalszej części.

Włączanie wtyczek pojedynczo

Teraz zaczyna się właściwe szukanie. Polega ono na cierpliwym włączaniu wtyczek jedna po drugiej i sprawdzaniu strony po każdej z nich.

1. Na ekranie „Zainstalowane wtyczki” należy kliknąć „Włącz” przy pierwszej wtyczce z listy.
2. W drugiej karcie, najlepiej w oknie prywatnym, odświeża się stronę główną oraz to miejsce, w którym błąd był widoczny wcześniej, na przykład koszyk albo formularz.
3. Jeśli strona działa, włącza się kolejną wtyczkę i powtarza sprawdzenie.
4. Wtyczka, po której włączeniu wraca komunikat, jest tą szukaną. Jej nazwę należy zapisać.
5. Jeżeli po jej włączeniu panel przestał być dostępny, trzeba wrócić do menedżera plików i zmienić nazwę katalogu tej jednej wtyczki, tak jak opisano wyżej.
6. Pozostałe wtyczki włącza się do końca listy, żeby upewnić się, że błąd wywołuje tylko jedna.

Przy dużej liczbie wtyczek można przyspieszyć pracę i włączać je po kilka. Gdy błąd wróci, wiadomo, że odpowiada za niego któraś z ostatniej grupy, i tylko tę grupę sprawdza się pojedynczo. Kolejność ma znaczenie przy dodatkach zależnych od innej wtyczki: najpierw włącza się wtyczkę główną, potem jej rozszerzenia.

Bywa, że każda wtyczka z osobna działa, a błąd pojawia się dopiero przy dwóch konkretnych jednocześnie. To konflikt między nimi. Rozpoznaje się go po tym, że komunikat wraca zawsze po włączeniu drugiej z pary, niezależnie od kolejności.

Jak znaleźć przyczynę w dzienniku błędów?

Dziennik błędów to plik tekstowy, w którym WordPress zapisuje dokładną treść każdego błędu razem ze ścieżką pliku. Przydaje się wtedy, gdy wiadomość nie przyszła, gdy błąd pojawia się tylko czasami albo gdy autor wtyczki prosi o szczegóły do zgłoszenia.

Zapisywanie włącza się w pliku wp-config.php, który leży w głównym katalogu WordPressa. Przed zmianą należy pobrać kopię tego pliku na dysk. Zawiera on dane dostępu do bazy, a błąd w jego treści zatrzyma całą stronę.

1. W menedżerze plików należy otworzyć plik wp-config.php do edycji.
2. Trzeba sprawdzić, czy w pliku nie ma już wiersza z nazwą WP_DEBUG. Jeśli jest, zmienia się w nim wartość, zamiast dopisywać drugi taki sam wiersz.
3. Przed wierszem zawierającym słowa „That’s all, stop editing!” wkleja się trzy wiersze podane poniżej.
4. Plik należy zapisać i odświeżyć w przeglądarce tę podstronę, na której pojawia się błąd. Dzięki temu błąd zostanie zapisany.
5. W katalogu wp-content pojawi się plik debug.log. Otwiera się go w menedżerze plików i przewija na sam koniec, do najnowszych wpisów.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Pierwszy wiersz włącza tryb diagnostyczny, drugi zapisywanie błędów do pliku, a trzeci ukrywa je przed odwiedzającymi. Trzeci wiersz jest ważny: bez niego szczegóły techniczne, w tym ścieżki na serwerze, mogłyby wyświetlić się klientom. Wartości true i false wpisuje się bez cudzysłowów.

Jak czytać wpisy w pliku debug.log?

W dzienniku szuka się wierszy zaczynających się od słów „PHP Fatal error”. Wiersze ze słowami „Warning”, „Notice” lub „Deprecated” to ostrzeżenia. Mogą świadczyć o przestarzałym kodzie, ale strony nie zatrzymują i na tym etapie można je pominąć.

W wierszu z błędem krytycznym liczą się dwie rzeczy: ścieżka pliku i treść komunikatu. Ścieżkę czyta się tak samo jak w wiadomości od WordPressa, czyli katalog po /wp-content/plugins/ to nazwa wtyczki. Jeśli ścieżka prowadzi do katalogu wp-includes lub wp-admin, zwykle nie oznacza to usterki samego WordPressa. Wtedy trzeba przeczytać kolejne wiersze opisujące, skąd wywołano kod, i poszukać w nich pierwszej ścieżki z katalogiem wtyczki lub motywu.

Treść komunikatu podpowiada rodzaj przyczyny. Słowa „Allowed memory size” oznaczają wyczerpany limit pamięci. Zapis „Call to undefined function” albo „Class not found” zwykle świadczy o brakującym pliku, wyłączonej wtyczce głównej albo niezgodności z wersją PHP. Słowa „syntax error” wskazują na literówkę w kodzie, najczęściej po ręcznej zmianie pliku.

Po zakończeniu pracy tryb diagnostyczny trzeba wyłączyć. Dokumentacja WordPressa odradza pozostawianie go na działającej stronie. W pierwszym wierszu zmienia się true na false, a plik debug.log należy pobrać na dysk i usunąć z serwera, ponieważ bywa dostępny pod publicznym adresem.

Wtyczki wyłączone, a błąd nadal się wyświetla. Co jeszcze sprawdzić?

Jeśli strona nie wraca do działania nawet bez wtyczek, przyczyna leży w jednym z czterech miejsc. Sprawdza się je po kolei, od najczęstszego.

Motyw

Motyw również jest kodem i może zatrzymać stronę, zwłaszcza po aktualizacji albo po ręcznej zmianie w pliku functions.php. Jeśli panel działa, w menu „Wygląd”, na ekranie „Motywy”, włącza się jeden z domyślnych motywów WordPressa. Jeśli panel nie działa, w katalogu wp-content/themes zmienia się nazwę katalogu aktywnego motywu, tak samo jak przy wtyczce.

Warunek jest jeden: na serwerze musi znajdować się przynajmniej jeden domyślny motyw, na który WordPress może się przełączyć. Jeżeli wszystkie zostały kiedyś usunięte, trzeba najpierw wgrać taki motyw do katalogu themes. Strona po przełączeniu będzie wyglądać inaczej, ale to tylko test. Gdy przyczyna zostanie usunięta, wraca się do właściwego motywu.

Limit pamięci

Jeżeli w szczegółach błędu występują słowa „Allowed memory size”, strona potrzebuje więcej pamięci, niż ma do dyspozycji. Dokumentacja WordPressa wskazuje wtedy podniesienie limitu w pliku wp-config.php. Służy do tego wiersz define( 'WP_MEMORY_LIMIT', '256M' ); wklejany w tym samym miejscu co wiersze diagnostyczne.

Wartość w tym wierszu jest przykładowa. Górną granicę ustala firma hostingowa i WordPress jej nie przekroczy, dlatego gdy zmiana nie pomaga, należy zapytać obsługę hostingu o limit pamięci PHP dla konta. Trzeba też pamiętać, że podniesienie limitu często tylko odsuwa problem. Jeśli pamięć zużywa jedna źle napisana wtyczka, lepiej ją znaleźć.

Wersja PHP

Awaria tuż po zmianie wersji PHP w panelu hostingu, także automatycznej, wskazuje na niezgodność starszej wtyczki lub motywu z nową wersją. Najszybszym ratunkiem jest przywrócenie poprzedniej wersji PHP w panelu hostingu. Następnie aktualizuje się wszystkie wtyczki i motyw, a dopiero potem ponawia zmianę. Pozostawanie na wycofanej wersji PHP na stałe nie jest dobrym rozwiązaniem ze względów bezpieczeństwa.

Wtyczki wymuszane, zamienniki i pliki WordPressa

W katalogu wp-content może istnieć katalog mu-plugins. Znajdują się w nim wtyczki wymuszane, które działają zawsze i których nie da się wyłączyć z panelu. Często dodaje je firma hostingowa albo wtyczka do pamięci podręcznej. W panelu widać je na ekranie „Zainstalowane wtyczki” pod filtrem „Wymuszane”. Obok nich bywają zamienniki, czyli pojedyncze pliki w katalogu wp-content, takie jak object-cache.php lub advanced-cache.php.

Jeśli ścieżka w dzienniku wskazuje na któryś z tych plików, zmienia się mu nazwę tak samo jak katalogowi wtyczki. Radzę robić to pojedynczo i po każdej zmianie sprawdzać stronę. Gdy plik pochodzi od firmy hostingowej, lepiej najpierw zapytać jej obsługę.

Jeżeli żadna z tych dróg nie pomaga, a błąd pojawił się po przerwanej aktualizacji samego WordPressa, dokumentacja zaleca ponowne wgranie katalogów wp-admin i wp-includes ze świeżej paczki instalacyjnej. Katalogu wp-content ani pliku wp-config.php nie wolno przy tym nadpisywać, bo zawierają treści i ustawienia strony. Nagłe błędy w wielu nieznanych plikach naraz mogą też świadczyć o włamaniu. Wtedy przydatny będzie plan działania przy zainfekowanej stronie na WordPressie.

Co zrobić z wtyczką, która wywołała błąd?

Wyłączenie wtyczki przywraca stronę, ale nie kończy sprawy. Funkcja, za którą wtyczka odpowiadała, jest zwykle potrzebna. Do wyboru są cztery drogi i warto rozważyć je w tej kolejności.

Pierwsza to aktualizacja. Jeśli autor wypuścił już poprawioną wersję, na ekranie „Zainstalowane wtyczki” pod opisem widać informację o dostępnej aktualizacji. Wtyczkę aktualizuje się, gdy jest wyłączona, a potem włącza i sprawdza stronę.

Druga to powrót do poprzedniej wersji, jeśli błąd przyszedł razem z aktualizacją. Najbezpieczniej odtworzyć katalog tej jednej wtyczki z kopii zapasowej sprzed awarii. Wtyczki płatne zwykle udostępniają starsze wersje na koncie klienta u producenta. Na czas oczekiwania na poprawkę należy wyłączyć automatyczne aktualizacje tej wtyczki, żeby wadliwa wersja nie wróciła sama.

Trzecia to zgłoszenie błędu autorowi. Wtyczki z oficjalnego katalogu WordPressa mają forum pomocy, a wtyczki płatne własny system zgłoszeń. Dobre zgłoszenie zawiera konkretne dane, dlatego można posłużyć się gotowym wzorem:

Po aktualizacji wtyczki do wersji [numer] strona wyświetla komunikat „W witrynie wystąpił błąd krytyczny”. Wersja WordPressa: [numer]. Wersja PHP: [numer]. Aktywny motyw: [nazwa]. Treść błędu z dziennika: [wklejony wiersz zaczynający się od PHP Fatal error]. Błąd ustępuje po wyłączeniu wtyczki. Proszę o informację, czy planowana jest poprawka.

Numery wersji można odczytać w panelu, w menu „Narzędzia”, na ekranie „Stan witryny”, w zakładce „Informacja”. Przed wklejeniem treści błędu na publiczne forum należy usunąć z niej początek ścieżki z nazwą konta na serwerze i zostawić część od /wp-content/.

Czwarta droga to wymiana wtyczki na inną. Warto po nią sięgnąć, gdy wtyczka od dawna nie jest rozwijana, autor nie odpowiada albo awaria powtarza się po kolejnych aktualizacjach. Przed wymianą trzeba sprawdzić, czy nowe rozwiązanie pozwala przenieść dotychczasowe dane.

Po czym poznać, że naprawa się udała, i jakich błędów unikać?

Znikający komunikat to dopiero połowa potwierdzenia. Stronę ogląda się w oknie prywatnym przeglądarki, bez zalogowania, bo tryb awaryjny i pamięć podręczna potrafią pokazać administratorowi inny obraz niż klientom.

• Strona główna, podstrona oferty i podstrona kontaktowa otwierają się bez komunikatu.
• Formularz kontaktowy wysyła wiadomość, a w sklepie da się dodać produkt do koszyka i przejść do zamówienia.
• Logowanie do panelu działa zwykłą drogą, bez odnośnika do trybu awaryjnego.
• Na ekranie „Zainstalowane wtyczki” nie ma już filtra „Wstrzymane”.
• Przy wyłączonym trybie diagnostycznym w katalogu wp-content nie pojawia się nowy plik debug.log.
• Pamięć podręczna strony i serwera została wyczyszczona, jeśli strona z niej korzysta.

Najczęstszy błąd przy naprawie to usunięcie katalogu wtyczki zamiast zmiany jego nazwy. Zmianę nazwy cofa się w kilka sekund, a usunięcia plików już nie. Drugi błąd to przywracanie całej strony z kopii jako pierwszy odruch. Kopia cofa także zamówienia, zgłoszenia i treści dodane po jej wykonaniu, dlatego traktuję ją jako ostateczność.

Nie należy też zmieniać kilku rzeczy jednocześnie. Jeśli w tym samym momencie wyłączy się wtyczki, zmieni motyw i podniesie limit pamięci, strona może wrócić, ale nie będzie wiadomo, co pomogło. Jedna zmiana, jedno sprawdzenie i krótka notatka pozwalają dojść do przyczyny najszybciej.

Ostrożności wymaga plik wp-config.php. Edytuje się go wyłącznie po pobraniu kopii, a obok wklejanych wierszy niczego się nie zmienia. Odradzam też wklejanie do plików strony kodu znalezionego w sieci bez zrozumienia, co robi, oraz instalowanie wtyczek pobranych spoza oficjalnego katalogu i stron producentów. Takie pliki bywają zmodyfikowane w sposób groźny dla strony i jej klientów.

Na przyszłość najlepszą ochroną jest kolejność działań przy aktualizacjach: najpierw kopia, potem aktualizacja jednej wtyczki, sprawdzenie strony i dopiero kolejna. Przy stronach, które zarabiają, radzę testować większe aktualizacje na kopii roboczej strony, którą wiele firm hostingowych pozwala utworzyć z panelu.

Najczęstsze pytania

Czy wyłączenie wtyczki przez zmianę nazwy katalogu usuwa jej ustawienia?

Nie. Ustawienia i dane wtyczki są zapisane w bazie danych, a zmiana nazwy katalogu dotyczy wyłącznie plików. Po przywróceniu nazwy i ponownym włączeniu wtyczka wraca z dotychczasową konfiguracją. Dane znikają dopiero wtedy, gdy wtyczka zostanie usunięta z panelu i jej autor przewidział usuwanie danych przy odinstalowaniu.

Na jaki adres WordPress wysyła wiadomość z odnośnikiem do trybu awaryjnego?

Na adres administratora witryny, ustawiony w panelu w menu „Ustawienia”, na ekranie „Ogólne”. Jeśli stronę wykonywała zewnętrzna firma, w tym polu często pozostaje jej adres i wiadomość trafia do niej. Po usunięciu awarii warto wpisać tam adres, do którego właściciel firmy ma stały dostęp. Zmiana wymaga potwierdzenia przez kliknięcie odnośnika wysłanego na nowy adres.

Odnośnik do trybu awaryjnego wygasł. Co teraz?

Nowy odnośnik zostanie wysłany, gdy błąd wystąpi ponownie po upływie ważności poprzedniego. WordPress ogranicza częstotliwość tych wiadomości, więc może to chwilę potrwać. Nie trzeba na nią czekać: wtyczkę da się w tym czasie wyłączyć przez menedżer plików, zmieniając nazwę jej katalogu.

Czy błąd krytyczny szkodzi pozycjom strony w Google?

Krótka przerwa zwykle nie zostawia trwałych śladów, ponieważ wyszukiwarka odwiedza stronę ponownie i odczytuje ją po naprawie. Kłopot zaczyna się, gdy awaria trwa długo albo często wraca, bo robot wielokrotnie trafia na błąd zamiast treści. Z tego powodu nie należy odkładać naprawy, a po jej zakończeniu dobrze jest sprawdzić w Google Search Console, czy najważniejsze podstrony są dostępne.

Komunikat pojawia się tylko na jednej podstronie. Czy to nadal wina wtyczki?

Najczęściej tak. Błąd ograniczony do jednego miejsca wskazuje na wtyczkę lub fragment motywu, który działa właśnie tam, na przykład blok formularza, moduł rezerwacji albo element kreatora stron. W takiej sytuacji najlepiej sprawdza się dziennik błędów: po włączeniu zapisywania odświeża się tę jedną podstronę i czyta ostatni wpis.

Czy do znalezienia przyczyny potrzebna jest dodatkowa wtyczka diagnostyczna?

Nie jest konieczna. Wiadomość od WordPressa, tryb awaryjny, zmiana nazw katalogów i dziennik błędów wystarczają w większości przypadków, a wszystkie te narzędzia są wbudowane. Wtyczki diagnostyczne ułatwiają pracę na działającej stronie, ale przy błędzie krytycznym zwykle nie da się ich nawet zainstalować, bo panel jest niedostępny.

Co oznacza komunikat o błędzie połączenia z bazą danych zamiast błędu krytycznego?

To inna awaria o innych przyczynach. Dotyczy ona danych dostępu do bazy albo pracy serwera bazy danych, a nie kodu wtyczki, więc wyłączanie wtyczek zwykle nic nie zmienia. Sposób postępowania opisałem we wpisie o tym, skąd bierze się błąd podczas nawiązywania połączenia z bazą danych.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Nie każdy chce zaglądać do plików na serwerze, zwłaszcza gdy strona nie działa, a klienci dzwonią z pytaniem, co się stało. To zrozumiałe. Mogę zająć się tym od początku do końca: ustalę, która wtyczka lub który motyw wywołuje błąd, przywrócę działanie strony, sprawdzę formularze i zamówienia, a potem dopilnuję poprawki, wymiany wadliwego elementu i porządku w aktualizacjach, żeby awaria nie wróciła.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz krótki opis tego, co działo się przed awarią. Resztę wyjaśnię prostym językiem i powiem, co zostało zrobione.