Mniej znaczy więcej: porządkowanie wtyczek i rozwiązywanie konfliktów

Moduł 5: Motywy i wtyczki · Czas czytania: 9 minut

Cel lekcji: Po tej lekcji potrafią Państwo uporządkować wtyczki oraz samodzielnie znaleźć i rozwiązać konflikt lub białą stronę.

Kluczowe pojęcia: wyłączenie a usunięcie, nieaktywny kod, błąd krytyczny, tryb odzyskiwania (recovery mode), Stan witryny, tryb rozwiązywania problemów, zmiana nazwy katalogu wtyczki, WP_DEBUG, WP_DEBUG_LOG, debug.log, log błędów

Wyłączenie to nie usunięcie

W sekcji Wtyczki mogą Państwo wtyczkę wyłączyć lub usunąć. Różnica:

• Wyłącz: WordPress przestaje ładować wtyczkę. Jej pliki pozostają jednak w katalogu wp-content/plugins/ i często nadal można je wywołać bezpośrednio przez serwer WWW. Jeśli w osobnym pliku PHP tej wtyczki jest luka, ta luka nadal istnieje. Włamywacze skanują w poszukiwaniu znanych podatnych plików, a nie aktywnych wtyczek.
• Usuń: pliki znikają. Niektóre wtyczki podczas usuwania sprzątają też swoje ustawienia i tabele w bazie danych, inne je pozostawiają.

Jeśli nie korzystają już Państwo z wtyczki, prosimy ją usunąć. Wyłączenie jest tylko rozwiązaniem tymczasowym (na czas szukania problemu). To samo dotyczy motywów (lekcja 2.4).

Porządki: stały przegląd

Raz na kwartał (lekcja 9.4) prosimy przejrzeć swoje wtyczki. Przy każdej wtyczce:

1. Do czego służy? Jeśli Państwo nie pamiętają, warto to sprawdzić. Często okazuje się, że wtyczkę zainstalowano kiedyś w jednym celu i nigdy jej nie usunięto.
2. Czy jest jeszcze używana? Na przykład wtyczka slidera, choć nigdzie nie ma slidera, albo wtyczka formularzy, choć strona kontaktowa korzysta z innego formularza.
3. Czy można się bez niej obejść? Czy WordPress, motyw lub inna wtyczka już to potrafią (lekcja 5.3)?
4. Czy jest nadal rozwijana? Kiedy była ostatnio aktualizowana, czy nadal jest w katalogu wtyczek?

Porządki prosimy najpierw przeprowadzić w środowisku testowym (staging) (lekcja 8.3) lub przynajmniej wykonać kopię zapasową, a wtyczki usuwać pojedynczo, aby w razie problemu wiedzieć, co go spowodowało. Uwaga na shortcode'y: jeśli usuną Państwo wtyczkę, która obsługiwała [formularz id="2"], ten tekst pojawi się potem dosłownie na stronie.

Gdy coś pójdzie nie tak: błąd krytyczny

Po aktualizacji, instalacji nowej wtyczki lub aktualizacji PHP nagle widzą Państwo:

Na stronie wystąpił błąd krytyczny.

albo zupełnie białą stronę. Oznacza to, że PHP zatrzymał się z błędem krytycznym (fatal error), zanim powstała strona (lekcja 1.2). Najczęściej przyczyną jest wtyczka lub motyw, który nie współpracuje z czymś innym: z inną wtyczką, nową wersją WordPressa lub wersją PHP.

Od wersji WordPress 5.2 WordPress robi wtedy dwie rzeczy:

• wysyła e-mail na adres administratora z informacją, która wtyczka lub który motyw spowodował błąd, oraz ze specjalnym linkiem;
• za pomocą tego linku logują się Państwo w trybie odzyskiwania (recovery mode): panel administracyjny działa wtedy, a wtyczka, która spowodowała błąd, jest tymczasowo wyłączona, dzięki czemu mogą ją Państwo zaktualizować, zastąpić lub usunąć.

Dlatego tak ważny jest adres administratora, który Państwo faktycznie czytają (lekcja 2.2).

Samodzielne szukanie: kolejne kroki

Nie przyszedł e-mail albo tryb odzyskiwania nie działa? Oto jak samodzielnie znaleźć przyczynę.

1. Proszę zajrzeć do logu błędów

Błąd prawie zawsze znajduje się w logu błędów serwera WWW lub PHP. W DirectAdmin znajdą go Państwo w logach swojej domeny. Szukają Państwo wiersza z PHP Fatal error i godziną swojej próby:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /home/uzytkownik/domains/example.com/public_html/wp-content/plugins/stary-slider/slider.php:42

Ścieżka wskazuje winowajcę: w tym przypadku wtyczkę w katalogu stary-slider. Reszta wiersza mówi, dlaczego (tutaj: funkcja, którą usunięto w PHP 8, lekcja 8.4).

2. Proszę włączyć log debugowania (nie wyświetlanie błędów na ekranie)

Jeśli w logu błędów nie ma nic przydatnego, prosimy dodać w pliku wp-config.php (powyżej komentarza „To wszystko, zakończ edycję!”):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WordPress zapisuje wtedy wszystkie błędy do pliku wp-content/debug.log, nie pokazując ich odwiedzającym. Prosimy nigdy nie zostawiać tego włączonego dłużej, niż to konieczne: debug.log znajduje się w katalogu udostępnianym przez serwer WWW i każdy, kto zna adres, może go przeczytać. Są w nim ścieżki, czasem nazwy użytkowników i inne informacje pomocne dla włamywacza. Po zakończeniu szukania prosimy wyłączyć debugowanie i usunąć debug.log. Można też polecić WordPressowi zapisywanie logu poza katalogiem WWW, podając ścieżkę przy WP_DEBUG_LOG (na przykład '/home/uzytkownik/logs/wp-debug.log', jeśli dostawca hostingu na to pozwala). W lekcji 7.4 sprawdzą Państwo, czy debug.log nie jest publicznie dostępny.

3. Wyłączenie wtyczki bez panelu administracyjnego

Jeśli nie mogą Państwo wejść do panelu administracyjnego, prosimy wyłączyć podejrzaną wtyczkę, zmieniając nazwę jej katalogu w Menedżerze Plików lub przez SFTP:

wp-content/plugins/stary-slider   zmienić na   wp-content/plugins/stary-slider-wylaczony

WordPress nie znajduje wtedy wtyczki i ją wyłącza. Jeśli nie wiedzą Państwo, która to wtyczka, prosimy zmienić nazwę całego katalogu plugins na plugins-wylaczone: wszystkie wtyczki zostaną wyłączone. Jeśli strona wtedy działa, prosimy utworzyć nowy, pusty katalog plugins, przenosić do niego wtyczki pojedynczo i po każdej sprawdzać, czy błąd wraca. To samo dotyczy motywu: po zmianie nazwy katalogu aktywnego motywu WordPress przełączy się na motyw domyślny, o ile jest on jeszcze zainstalowany (lekcja 2.4).

4. Konflikty bez błędu krytycznego

Nie każdy problem jest błędem krytycznym. Czasem nie działa tylko jedna funkcja: przycisk nic nie robi, formularz się nie wysyła, edytor ładuje się do połowy. Wtedy często jest to konflikt między dwiema wtyczkami albo między wtyczką a motywem. Przydaje się tu oficjalna wtyczka Health Check & Troubleshooting: w trybie rozwiązywania problemów wyłącza ona wszystkie wtyczki i przełącza na motyw domyślny wyłącznie w Państwa sesji, podczas gdy odwiedzający widzą normalną stronę. Następnie włączają Państwo wtyczki pojedynczo, aż problem powróci.

Warto też zajrzeć do konsoli przeglądarki (F12): błędy JavaScript często wskazują plik, a tym samym wtyczkę.

Stan witryny

W sekcji Narzędzia > Stan witryny WordPress sam sprawdza Państwa stronę: przestarzałą wersję PHP, nieaktywne wtyczki i motywy, brakujące rozszerzenia PHP, niedziałające REST API, zaległe zaplanowane zadania. Na karcie Informacje znajdują się wszystkie dane instalacji (wersje, ścieżki, ustawienia PHP). Zawartość tej karty można skopiować i dołączyć do prośby o pomoc. Warto tu zajrzeć po każdej większej zmianie.

Podsumowanie

• Wyłączenie pozostawia pliki na serwerze; prosimy usuwać wtyczki i motywy, z których Państwo nie korzystają.
• Porządki raz na kwartał, po jednej wtyczce, z kopią zapasową lub w środowisku testowym (staging).
• Przy błędzie krytycznym WordPress wysyła e-mail z linkiem do trybu odzyskiwania.
• Log błędów lub debug.log podaje ścieżkę winowajcy; po zakończeniu szukania prosimy wyłączyć debugowanie, bo w przeciwnym razie debug.log jest publicznie dostępny.
• Bez panelu administracyjnego wyłączają Państwo wtyczkę, zmieniając nazwę jej katalogu; konflikty wyszukuje się w trybie rozwiązywania problemów.

Quiz

Zadanie

Zadanie A5.4: Czy Państwa log debugowania nie jest publicznie dostępny? Prosimy wpisać adres swojej strony i za pomocą kodu podanego w zadaniu udowodnić, że to Państwa strona (rekord TXT lub mały plik). Program wywołuje /wp-content/debug.log: wynik jest dobry, jeśli plik nie istnieje lub dostęp jest zablokowany (404 lub 403). Jeśli program otrzyma plik, wynik jest czerwony. Dodatkowo program liczy, ile różnych katalogów wtyczek pojawia się w kodzie HTML Państwa strony głównej (wyłącznie informacyjnie).

Zadanie D5.4: Uporządkowanie listy wtyczek. Prosimy sporządzić listę wszystkich swoich wtyczek (aktywnych i nieaktywnych): nazwa, do czego służy, czy jest jeszcze potrzebna (tak/nie), alternatywa bez wtyczki. Wtyczki, które nie są już potrzebne, prosimy usuwać (po wykonaniu kopii zapasowej lub w środowisku testowym (staging)) pojedynczo i po każdym usunięciu sprawdzać, czy strona nadal działa. Prosimy wpisać, ile wtyczek było na początku i ile zostało, oraz zanotować, czy pozostały shortcode'y, które trzeba było usunąć.

Dalsza lektura

Te artykuły opisują kroki w panelach WebOké; w innych panelach wygląda to podobnie.

• Instrukcja DirectAdmin 18.1: Moja strona jest biała lub wyświetla błąd 500
• Błąd 500 lub „krytyczny błąd” na Państwa stronie internetowej (również po aktualizacji WordPressa)
• Instrukcja DirectAdmin 14.6: Błędy po aktualizacji PHP i znajdowanie logu błędów
• Instrukcja DirectAdmin 17.2: Podsumowanie witryny i logi: log błędów i log dostępu
• Jak debugować PHP bez zmiany php.ini?
• Debugowanie w WordPressie (developer.wordpress.org, po angielsku): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
• Wybór, ocena i porządkowanie wtyczek WordPress