WordPress – Błędy krytyczne

WordPress jest jednym z najpopularniejszych systemów CMS, ale jak każde oprogramowanie, bywa podatny różnego rodzaju awarie, błędy i niestabilne działanie. Jednym dosyć często występujących błędów jest Błąd krytyczny  (z ang. Criticalal Error), który może zostać wywołany z wielu różnych powodów, a jego naprawa, w zależności od przyczyny może wymagać różnych umiejętności oraz czasu.

W tym poradniku zostanie omówione:

1. Najczęstsze przyczyny powodujące Błąd krytyczny
2. Kolejność postępowania w razie awarii strony
3. Narzędzie wspomagające debugowanie
4. Fast fix – Błędy i rozwiązania
5. Dobre praktyki na przyszłość
6. FAQ – pytania i odpowiedzi

Mini słownik pojęć:

• CMS  (z ang. Content Management System) —  systemy służące do tworzenia i zarządzania treścią.
• Core WordPress —  pliki źródłowe systemu wymagane do uruchomienia podstawowej aplikacji WordPress.
• Wtyczki (z ang. plugins) — moduły rozszerzające działanie podstawowej aplikacji WordPress o dodatkowe funkcjonalności.
• Motywy (ang. themes) — moduły odpowiadające za widok aplikacji, umożliwiające zarządzanie wyglądem i układem modułów w aplikacji WordPress.
• WP-CLI — dedykowany zestaw narzędzi dla systemu WordPress, polecenia uruchamiane z poziomu SSH, umożliwiają pełne sterowanie aplikacją WordPress z poziomu konsoli. 
• tryb debugowania — moduł w systemie WordPress umożliwiający wyświetlanie i zapis do plików logów wskazujących błędy w aplikacji. Sam proces debugowania, polega na wyszukiwaniu i rozwiązywaniu błędów w kodzie, strukturze programu, systemu.

1. Przyczyny błądów krytyczny WordPress

Jak już wcześniej wspominane Błąd krytyczny witryny wynikać może z wielu aspektów. Do najczęstszych przyczyn zaliczamy:

• Brak kompatybilności PHP z modułami CMS WordPress, wtyczek, motywów.
• Brak kompatybilności między wersjami CMS WordPress, wtyczek, motywów.
• Niepoprawne ustawienia PHP względem CMS WordPress, wtyczek, motywów.
• Uszkodzenia w plikach lub braki plików systemowych CMS.
• Infekcje na koncie w tym również uszkodzenia plików systemowych CMS.
• Błędne konfiguracje pliku .htaccess.
• Brak monitorowania strony i pozostawienie jej „samej sobie”.

Ważne: Błędy krytyczne witryny nie są błędami stricte serwerowymi. Komunikacja o błędach pochodzi bezpośrednio od samego systemu CMS WordPress, informując o problemach z działaniem skryptów wewnątrz systemu. Błędy te powiązane mogą być z niepoprawną konfiguracją wersji lub parametrów PHP, za którą odpowiada Klient, za pośrednictwem panelu administracyjnego. Zarządzanie skryptami systemów CMS utrzymywanych na serwerze również leży po stronie Klienta. 

2. Kolejność postępowania w razie awarii

Poniżej przedstawimy kilka kroków jakie klient może podjąć w pełni samodzielnie, jeżeli na stronie pojawi się komunikat o błędzie krytycznym:

1. Nie panikuj — stres może okazać się największym problemem w całej sytuacji. Każdy problem da się rozwiązać, posiadając odpowiednią wiedzę, narzędzia i czas.
2. Dodatkowa kopia zapasowa — Przed podjęciem działań naprawczych zalecamy wykonanie dodatkowej kopii zapasowej. Zaloguj się do panelu Direct admin i wykonaj kopię zapasową plików i bazy zgodnie z poradnikiem: Installatron – kopie zapasowe . W razie konieczności dostępne też są kopie serwerowe.
3. Dostęp do plików strony — Do plików strony możemy dostać się z poziomu: Manager plików, konta FTP, konta SSH w tym WP-CLI. Do bazy danych możemy się dostać z poziomu phpmyadmin – dane do logowania znajdują się w pliku wp-config.php.
4. Włącz debugowanie — uruchom tryb debugowanie zgodnie z instrukcją: Jak zdebugować WordPress lub w sekcji 3.1 Narzędzia wspomagające debugowanie. 
5. Odczytaj komunikaty o błędach — w zależności jaką wybierzesz opcję debugowania komunikaty mogą się pojawić jednocześnie w pliku wp-content/debug.log oraz na ekranie monitora. Zapisz (np. do notatnika) komunikaty o błędach.
6. Określ przyczynę problemu — spróbuj wyszukać w internecie podobnych fraz występujących we wskazanych wcześniej logach błędów. Niekiedy komunikaty wskazują wprost na przyczynę problemu, niekiedy jednak sprawa może być bardziej złożona i wymagać dodatkowego researchu.
7. Spróbuj podjąć działania naprawcze — jeżeli udało Ci się już wstępnie zdiagnozować przyczynę pora na jej usunięcie (poniżej w sekcji 4. Fast Fix – Błędy i rozwiązania, podaliśmy kilka przykładów działań jakie można podjąć w określonych przypadkach).
8. Przywróć kopię plików — jeżeli podjęte działania naprawcze nie przyniosły skutku lub nie jesteś w stanie określić przyczyny problemu, zalecamy skorzystać z kopii zapasowej. Kopię serwerową plików można przywrócić zgodnie z poradnikiem: Jak przywrócić kopie plików. Jeżeli była wcześniej utworzona kopia z poziomu Moje aplikacje, można ją przywrócić zgodnie z poradnikiem: Installatron – kopie zapasowe.
9. Przywróć kopię bazy danych — jeżeli problemy dalej występują wymagane będzie również przywrócenie bazy danych. Kopię bazy danych można przywrócić zgodnie z poradnikiem: Jak przywrócić kopię bazy danych. Ważne: przywrócenie kopii zapasowej bazy spowoduje nadpisanie poprzedniej zawartości bazy w tym np. utratę zamówień.

Z poziomu wsparcia technicznego możemy pomóc w:

• Wskazaniu jak zmienić wersję i ustawienia PHP dla domeny.
• Włączeniu trybu debugowania.
• Przywróceniu kopii zapasowej plików i bazy.
• Jeżeli znana jest przyczyna problemu, prostych operacjach takich jak włącznie/ wyłącznie wtyczki, przełączenie motywu.
• Uruchomieniu skanowania antywirusowego.

Jeżeli wskazane działania nie przyniosą efektu, skontaktować należy się z administratorem witryny (webmasterem), który dokona analizy problemu i podejmie dalsze kroki w celu usunięcia usterki.

3. Narzędzia wspomagające debugowanie

Zarówno z poziomu serwera, jak i CMS WordPress dostępnych jest kilka narzędzi umożliwiających debugowanie i rozwiązywanie problemów związanych z tym systemem.

Funckja debug mode

Opcja wbudowana dla CMS WordPress, umożliwia wywołanie funkcje analizy, wyświetlania i logowania błędów systemowych. Kolejno dostępne opcje:

• WP_DEBUG – włącz/ wyłącz tryb debugowania
• WP_DEBUG_LOG – włącz/ wyłącz zapis logów do pliku.
• WP_DEBUG_DISPLAY – włącz/ wyłącz wyświetlanie logów błędów na ekranie
• SCRIPT_DEBUG – opcja dla developerów dla debugowania plików źródłowych css js.

Poniższy wpis należy skopiować do wpliku wp-config.php przed:
/* That’s all, stop editing! Happy blogging. */

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );

// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 0 );

// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
define( 'SCRIPT_DEBUG', true );

Tip: Jeżeli plik debug.log jest dosyć obszerny, gdyż agregował dane z dłuższego czasu, wystarczy zmienić jego nazwę, aby zachować poprzednie logi i wygenerować nowy plik, z nowymi danymi o błędach.

WP-CLI

Jest to dedykowany command line dla systemu CMS WordPress. Posiada masę poleceń do zarządzania całym CMS WordPress. W kontekście debugowania aplikacji można sprawdzić, wersję Core WordPress oraz innych modułów, czy dane pluginy lub motywy zgłaszają błędy w konsoli, lub możemy aktywować, dezaktywować określone moduły lub funkcje, co pozwoli nam na awaryjne dostanie się np. do zaplecza strony. Oto kilka przydatnych poleceń podczas debugowania:

//sprawdzenie wersji wp-cli z wywołaniem w okreśonej wersji PHP (jeżeli w konsoli pojawiają się błędy krytyczne)
/usr/local/bin/php81 /usr/local/bin/wp --info

//ustawienie opcji debugowania wp-config.php
wp config set --raw WP_DEBUG true && wp config set --raw WP_DEBUG_LOG true && wp config set --raw WP_DEBUG_DISPLAY false

//odpytanie wersji Core WordPress
wp core version

//wywołanie listy wszystkich pluginów wraz wersjami 
wp plugin list

//deaktywacja wszystkich pluginów (zamiast zmian nazw katalogów)
wp plugin deactivate --all --skip-themes --skip-plugins

//reinstalacja zmiana wersji pluginu
wp plugin install litespeed-cache --version=6.1 --force

//wywołanie listy wszystkich motywów wraz wersjami
wp theme list

//zmiana aktywnego motywu na domyślny
wp theme activate theme_name --skip-themes --skip-plugins

Error.log + .htaccess (DirectAdmin)

Zazwyczaj sam tryb debugowania WordPress wystarcza aby uruchomić wyświetlanie potrzebnych informacji. Celem dodatkowej dniagnozy możemy posiłkować się error.log, który z oznaczoną opcją logowania błędów PHP, dostarczy dodatkowych informacji o problemach ze stroną. Włączenie logowania błędów PHP możemy wykonać na dwa sposoby z poziomu Direct admin/ PHP – ustawienia globalne/ Opcje/ log_errors lub .htaccess wybranej strony.

Przykładowe flagi PHP umieszczamy na samej górze pliku .htaccess:

#Podstawowe flagi
php_flag display_startup_errors on
php_flag display_errors on
php_flag html_errors on
php_flag  log_errors on

#Dodatkowe opcje logowania błędów, zmiana katalogu logow
php_value error_reporting 32767
php_value error_log /home/USER/php_err.log

4. Fast Fix (Błędy i rozwiązania)

W tej sekcji przyjrzymy się, jak w kilku nieskomplikowanych krokach można rozwiązać na pozór skomplikowany problem. Jest to zbiór czynności, jakie możemy podjąć przed przywróceniem kopii zapasowej. Podane przykłady błędów i objawów mogą obejmować większy zakres problemów niż same błędy krytyczne. Często jednak “w parze” z pozostałymi problemami wewnątrz systemu CMS WordPress.

# BEGIN WordPress

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

5. Porady od _Folksów!

• Czytaj dokumentacje, znaj swój system — Bycie na bieżąco ze zmianami, jakie wchodzą jednakowo dla WordPress oraz powiązanych z nim modułów pomoże w uniknięciu lub diagnozie problemu. Dodatkowa znajomość działania systemu, włączania trybu debugowania czy rozumienia komunikatów o błędach ułatwi znacznie prace z systemem i reakcję w razie awarii. Im więcej wiemy tym spokojniej śpimy.
• Aktualizuj z głową — pilnuj zawsze aktualizacji i nie pozostawiaj je przypadkowi. Sprawdzaj z dokumentacją czy wersje PHP oraz wersje modułów są ze sobą zgodne.
• Wykonuj dodatkowe kopie zapasowe — Lepiej mieć o 10 kopii za dużo niż o jedną za mało, dlatego zawsze zalecamy aby Klienci posiadali ręczne kopie: poprzez FTP i phpmyadmin, SSH, ręczne kopie Installatron. Dodatkowo kopie Installatron jest bardzo łatwo przywrócić co znacznie skraca czas naprawy problemu.
• Dbaj o bezpieczeństwo strony — Mimo dostępnych zabezpieczeń z poziomu serwera (WAF, mod_security, WAF systemowym ochrony antyDDos, monitoring zapytań do serwera), dalej po stronie klienta leży odpowiednie zabezpieczenie witryny na różnych poziomach.
• Korzystaj z ogólnodostępnej wiedzy — bardzo wiele problemów powiela się na całym świecie a sam WordPress jest najczęściej wybieranym systemem CMS, co sprawia, że baza wiedzy jest olbrzymia (zarówno dokumentacja jak i informacje od innych developerów i użytkowników).
• Rozwijaj się — świat idzie cały czas na przód, chcąc więc utrzymywać samodzielnie strony Internetowe z wykorzystaniem CMS, musimy mieć na uwadze, że wymagać to będzie poświecenia czasu, zaangażowania i rozwoju, celem utrzymania prawidłowego i stabilnego działania naszych witryn.

6. FAQ — Pytania i odpowiedzi