W witrynie wystąpił błąd krytyczny. Jak żyć?

Czy przydarzył Ci się kiedyś błąd krytyczny w WordPressie? Wystarczy, że zapomnisz średnika w kodzie PHP i problem gotowy. Kłopot może się też pojawić po aktualizacji PHP do wersji 8, ponieważ ta wersja PHP jest znacznie bardziej restrykcyjna niż poprzednie i to, co kiedyś było tylko ostrzeżeniem, teraz może spowodować błąd krytyczny.

Włączenie trybu debugowania

Komunikat na ekranie nie mówi zbyt wiele: „W witrynie wystąpił błąd krytyczny”. Jeśli chcesz się dowiedzieć, co konkretnie spowodowało problem, włącz tryb debugowania.

Uwaga: jeśli mimo błędu krytycznego jesteś w stanie zalogować się do panelu administratora, możesz do debugowania użyć wtyczki WP Debugging. Więcej informacji znajdziesz tu: WP Debugging: jest i wtyczka do debugowania! Ten sposób jest dobry dla osób, które nie czują się pewnie, edytując pliki WordPressa.

Zaloguj się do strony przez FTP lub menedżera plików w cPanel i znajdź plik wp-config.php. Znajduje się on w katalogu głównym Twojej strony:

Dodaj do tego pliku następujące linijki:

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

Ważne: powyższy kod musi być umieszczony przed linią /* That's all, stop editing! Happy publishing. */. Umieszczenie go za tą linią nie będzie miało efektu.

Teraz, gdy ponownie wejdziesz na swoją stronę i zobaczysz komunikat o błędzie krytycznym, błąd zostanie zapisany do pliku /wp-content/debug.log. Przykładowy plik debug.log będzie wyglądał tak:

[12-May-2022 15:04:17 UTC] PHP Fatal error:  Uncaught TypeError: implode(): Argument #2 ($array) must be of type ?array, string given in /app/wp-content/themes/astra-child/functions.php:28

W tym przypadku powodem błędu było nieprawidłowe użycie funkcji implode w pliku themes/astra-child/functions.php. W PHP 7.4 kod jeszcze działał, ale w wersji 8.0 już powoduje błąd krytyczny, bo zmieniła się kolejność parametrów w tej funkcji.

Co dalej?

Jeśli błąd tkwi we wtyczce, wyłącz ją, a następnie daj znać autorom wtyczki o problemie. Być może problem będzie naprawiony w następnej wersji.

Jak wyłączyć wtyczkę bez dostępu do kokpitu

Jeśli błąd jest na tyle krytyczny, że nie możesz się zalogować do kokpitu, zmień nazwę folderu wtyczki. Zaloguj się do strony przez FTP lub menedżer plików cPanel i przejdź do katalogu public_html/wp-content/plugins. Znajdź katalog wtyczki i zmień mu nazwę.

Jak zgłosić problem autorom wtyczki

Jeśli wtyczka jest darmowa, daj znać jej autorom na stronie wordpress.org. Wyszukaj swoją wtyczkę i przejdź do sekcji „Wsparcie”:

Jeśli wtyczka jest płatna, wystaw tzw. support ticket. Można to zrobić np. poprzez formularz kontaktowy na stronie wtyczki. Pamiętaj, że wsparcie techniczne jest w cenie wtyczki i po prostu ci się należy. Jeśli obawiasz się pisania po angielsku, opisz problem po polsku i skorzystaj z Google Translate do przetłumaczenia mejla.

Wyłączenie trybu debugowania

Gdy problem zostanie naprawiony lub zgłoszony, wyłącz tryb debugowania. To ważne, bo plik debug.log jest dostępny publicznie, dla każdego. Zastąp poprzedni kod następującym:

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

Następnie usuń plik debug.log.

Logowanie do innego pliku

Błędy mogą być logowane do pliku o innej nazwie. Można też zmienić jego lokalizację, żeby trudniej było go podejrzeć obcym.

Zamiast:

define( 'WP_DEBUG_LOG', true );

wklej do pliku wp-config.php coś takiego:

define( 'WP_DEBUG_LOG', '/home/panimarta/domains/panimarta.pl/public_html/bledy-wp.log' );

/home/panimarta/domains/panimarta.pl/public_html/bledy-wp.log to ścieżka bezwzględna na serwerze. Od teraz błędy będą logowane do pliku bledy-wp.log.

---

Jeśli mimo tego wpisu błąd krytyczny nadal spędza ci sen z powiek, daj mi znać, pomogę. Napisz do mnie mejla lub wypełnij formularz na stronie Kontakt. Razem poradzimy sobie z tym problemem w try miga 🙂