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

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

Cel lekcji: Po tej lekcji będą Państwo potrafili uporządkować wtyczki oraz samodzielnie wykryć i rozwiązać konflikt lub biały ekran.

Kluczowe pojęcia: wyłączenie a usunięcie, nieaktywny kod, błąd krytyczny, tryb naprawy (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 wyrzucenie

W sekcji Wtyczki można wyłączyć (dezaktywować) lub usunąć wtyczkę. Różnica:

• Wyłączenie: WordPress przestaje ładować wtyczkę. Jednak pliki pozostają w katalogu wp-content/plugins/ i często nadal można je wywołać bezpośrednio przez serwer WWW. Jeśli w pojedynczym pliku PHP tej wtyczki znajduje się luka bezpieczeństwa, nadal tam jest. Włamywacze skanują pod kątem znanych podatnych plików, nie pod kątem aktywnych wtyczek.
• Usunięcie: pliki znikają. Niektóre wtyczki przy usuwaniu porządkują również swoje ustawienia i tabele w bazie danych; inne pozostawiają je bez zmian.

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

Porządkowanie: stały przegląd

Raz na kwartał (lekcja 9.4) proszę przejrzeć swoje wtyczki. Dla każdej wtyczki:

1. Do czego służy? Jeśli Państwo nie pamiętają, proszę to sprawdzić. Często okazuje się, że wtyczka została zainstalowana kiedyś do jednej rzeczy i nigdy nie usunięta.
2. Czy jest jeszcze używana? Wtyczka do slajdów, podczas gdy nigdzie nie ma slajdera, wtyczka do formularzy, podczas gdy strona kontaktowa korzysta z innego formularza.
3. Czy można się bez niej obejść? Czy WordPress, motyw lub inna wtyczka potrafi już to zrobić (lekcja 5.3)?
4. Czy jest jeszcze utrzymywana? Ostatnia aktualizacja, czy nadal jest w katalogu wtyczek?

Porządkowanie proszę wykonać najpierw w środowisku testowym (staging) (lekcja 8.3) lub przynajmniej wykonać kopię zapasową, i usuwać po jednej wtyczce naraz, aby wiedzieć, co poszło nie tak, jeśli coś pójdzie nie tak. Proszę zwrócić uwagę na shortcody: jeśli usuną Państwo wtyczkę, która dostarczała [formulier id="2"], ten tekst pozostanie potem dosłownie na stronie.

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

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

W witrynie wystąpił błąd krytyczny.

lub całkowicie biały ekran. Oznacza to, że PHP zatrzymał się z błędem krytycznym (fatal error), zanim powstała strona (lekcja 1.2). Zwykle jest to spowodowane przez wtyczkę lub motyw, który nie współdziała z czymś innym: inną wtyczką, nową wersją WordPressa lub wersją PHP.

Od wersji WordPress 5.2 WordPress wykonuje wtedy dwie rzeczy:

• wysyła e-mail na adres administratora z informacją, która wtyczka lub motyw spowodowały błąd, oraz specjalny link;
• dzięki temu linkowi logują się Państwo w trybie naprawy (recovery mode): panel administracyjny wtedy działa, z tymczasowo wyłączoną wtyczką, która spowodowała błąd, dzięki czemu można ją zaktualizować, zastąpić lub usunąć.

Dlatego tak ważne jest, aby adres administratora był czytany przez Państwa (lekcja 2.2).

Samodzielne szukanie: kroki

Nie przyszedł e-mail albo tryb naprawy nie działa? Oto jak znaleźć problem samodzielnie.

1. Proszę sprawdzić log błędów

Błąd niemal zawsze znajduje się w logu błędów serwera WWW lub PHP. W DirectAdmin znajdą go Państwo w dziennikach zdarzeń (logach) swojej domeny. Należy szukać wiersza z PHP Fatal error i godziną swojej próby:

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

Ścieżka wskazuje, kto jest winowajcą: tutaj wtyczka w katalogu oude-slider. Reszta wiersza wskazuje dlaczego (tutaj: funkcja usunięta w PHP 8, lekcja 8.4).

2. Proszę włączyć log debugowania (nie komunikat na ekranie)

Jeśli w logu błędów nie ma nic przydatnego, proszę umieścić w pliku wp-config.php (nad komentarzem „stop met bewerken”):

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. Proszę nigdy nie zostawiać tego włączonego dłużej niż to konieczne: plik debug.log znajduje się w katalogu udostępnianym przez serwer WWW, a osoba znająca jego adres może go odczytać. Znajdują się tam ścieżki, czasem nazwy użytkowników i inne informacje, które pomagają włamywaczowi. Proszę po zakończeniu poszukiwań ponownie wyłączyć tę opcję i usunąć plik debug.log. Można też zlecić WordPressowi zapisywanie pliku logu poza katalogiem dostępnym przez www, podając ścieżkę w WP_DEBUG_LOG (na przykład '/home/gebruiker/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 dostępu do panelu administracyjnego

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

wp-content/plugins/oude-slider   wordt   wp-content/plugins/oude-slider-uit

WordPress nie znajdzie wtedy wtyczki i ją wyłączy. Jeśli nie wiedzą Państwo, która to wtyczka, proszę zmienić nazwę całego katalogu plugins na plugins-uit: wszystkie wtyczki zostaną wyłączone. Jeśli strona wtedy działa, proszę utworzyć nowy, pusty katalog plugins, przywracać wtyczki jedna po drugiej i po każdej sprawdzać, czy błąd powraca. Dla motywu obowiązuje to samo: proszę zmienić nazwę katalogu aktywnego motywu, a WordPress przełączy się na motyw domyślny, jeśli taki jeszcze tam jest (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ę częściowo. Wtedy często chodzi o konflikt między dwiema wtyczkami lub między wtyczką a motywem. Przydatna jest do tego oficjalna wtyczka Health Check & Troubleshooting: w trybie rozwiązywania problemów wyłącza ona wszystkie wtyczki i przełącza na motyw domyślny, ale tylko dla Państwa sesji, podczas gdy odwiedzający nadal widzą normalną stronę. Następnie włączają je Państwo jedną po drugiej, aż problem powróci.

Proszę 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 stronę: nieaktualną wersję PHP, wtyczki i motywy, które nie są aktywne, brakujące rozszerzenia PHP, niedziałające REST API, zaległe zaplanowane zadania. Na karcie Informacje znajdują się wszystkie dane Państwa instalacji (wersje, ścieżki, ustawienia PHP). Tę kartę można skopiować i wysłać, prosząc o pomoc. Proszę sprawdzać ją po każdej większej zmianie.

Podsumowanie

• Wyłączenie pozostawia pliki na miejscu; proszę usuwać wtyczki i motywy, z których Państwo nie korzystają.
• Proszę porządkować wtyczki co kwartał, po jednej naraz, z kopią zapasową lub w środowisku testowym.
• Przy błędzie krytycznym WordPress wysyła e-mail z linkiem do trybu naprawy.
• Log błędów lub debug.log wskazuje ścieżkę winowajcy; po zakończeniu poszukiwań proszę ponownie wyłączyć debugowanie, ponieważ inaczej debug.log jest publicznie dostępny.
• Bez dostępu do panelu administracyjnego wyłączają Państwo wtyczkę, zmieniając nazwę jej katalogu; konflikty szukają Państwo za pomocą trybu rozwiązywania problemów.

Quiz

Zadanie

Zadanie A5.4: Czy Państwa log debugowania nie jest publicznie dostępny? Proszę podać adres swojej strony i udowodnić za pomocą kodu podanego w zadaniu, że jest to Państwa własna strona (rekord TXT lub mały plik). Program sprawdzi adres /wp-content/debug.log: dobrze, jeśli ten plik nie istnieje lub dostęp jest odmówiony (404 lub 403). Jeśli program otrzyma plik w odpowiedzi, wynik jest czerwony. Dodatkowo program policzy, ile różnych katalogów wtyczek pojawia się w kodzie HTML Państwa strony głównej (tylko informacyjnie).

Zadanie D5.4: Uporządkowanie listy wtyczek. Proszę sporządzić listę wszystkich swoich wtyczek (aktywnych i nieaktywnych): nazwa, do czego służy, czy nadal jest potrzebna (tak/nie), alternatywa bez wtyczki. Proszę usunąć (po wykonaniu kopii zapasowej lub w środowisku testowym) wtyczki, które nie są już potrzebne, po jednej naraz, i po każdym usunięciu sprawdzić, czy strona nadal działa. Proszę podać, ile wtyczek Państwo mieli i ile pozostało, oraz zanotować, czy pozostały jakieś shortcody, które trzeba było uporządkować.

Więcej informacji

Poniższe artykuły opisują kroki w panelach WebOké; w innych panelach działają one 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 WordPress)
• 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, w języku angielskim): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/