Logi błędów WordPress: gdzie znaleźć treść błędu i co znaczą komunikaty
Logi błędów WordPress to pliki, w których serwer, WordPress i wtyczki zapisują treść błędów: komunikat, plik i linię. Szukaj ich w trzech miejscach: w pliku debug.log w katalogu wp-content (po włączeniu zapisu w wp-config.php), w panelu hostingu i w WooCommerce → Status → Logi. Bez nich naprawa błędu to zgadywanie.
Autor: Zespół TellMyShop. Poradnik dla właścicieli stron WordPress i sklepów WooCommerce: przyczyna, ręczna naprawa i to samo w rozmowie z czatem.
Aktualizacja: · 5 min czytania
Trzy miejsca, w których szukać
Każde z tych miejsc zapisuje coś innego. Sprawdzaj je w tej kolejności, od najłatwiejszego.
| Miejsce | Co tam trafia | Jak się dostać | Kto zwykle ma dostęp |
|---|---|---|---|
| WooCommerce → Status → Logi, plik fatal-errors | błędy krytyczne PHP z plikiem i linią | kokpit, jeśli działa | ty |
| debug.log w wp-content | błędy, ostrzeżenia i komunikaty WordPressa i wtyczek | menedżer plików hostingu albo FTP, po włączeniu zapisu | ty albo opiekun strony |
| Log błędów PHP na serwerze | błędy PHP, także gdy WordPress w ogóle nie wstaje | panel hostingu | hosting, czasem ty |
Sklep na WooCommerce ma przewagę: dziennik fatal-errors działa bez grzebania w plikach. WooCommerce sam radzi zacząć od niego, co opisuje dokumentacja WooCommerce o szukaniu logów błędów PHP.
Jak włączyć debug.log krok po kroku
Zapis do debug.log włącza się w pliku wp-config.php. To plik z hasłem do bazy, więc pracuj na kopii i ostrożnie. Jeśli nie czujesz się pewnie, poproś o to hosting albo opiekuna strony.
- Zrób kopię pliku wp-config.php w menedżerze plików hostingu.
- Otwórz wp-config.php do edycji i znajdź linię z WP_DEBUG.
- Ustaw WP_DEBUG na true, dodaj WP_DEBUG_LOG na true i WP_DEBUG_DISPLAY na false.
- Zapisz plik i powtórz to, co wywołuje błąd, na przykład otwórz stronę albo dodaj produkt do koszyka.
- Otwórz wp-content/debug.log i przeczytaj ostatnie linie.
- Gdy skończysz, ustaw WP_DEBUG z powrotem na false.
Wszystkie stałe i ich działanie opisuje podręcznik WordPress o debugowaniu. Krótkie wyjaśnienie samego pliku ma słowniczek GreenGeeks o WP Debug Log.
Plik debug.log leży w katalogu, do którego bywa dostęp z przeglądarki. Nie zostawiaj zapisu włączonego na stałe bez potrzeby albo poproś hosting o zablokowanie dostępu do tego pliku.
Jak czytać wpis w logu
Każdy wpis ma podobną budowę: data i godzina, poziom błędu, komunikat, a na końcu ścieżka do pliku i numer linii. Najważniejsza jest ścieżka. Jeśli zawiera wp-content/plugins/nazwa-wtyczki, winna jest ta wtyczka. Jeśli wp-content/themes/nazwa-motywu, winny jest motyw.
Poziomy od najgroźniejszego:
- Fatal error: kod się zatrzymał, strona albo jej część nie działa.
- Warning: coś poszło nie tak, ale strona działa dalej.
- Notice i Deprecated: uwagi dla programisty, zwykle bez wpływu na odwiedzających.
Słowniczek: pięć częstych komunikatów
Allowed memory size of … bytes exhausted. Skończyła się pamięć przydzielona PHP. Bywa winna jedna ciężka wtyczka albo za niski limit na hostingu. Limit pamięci podnosi hosting albo opiekun strony.
Call to undefined function … Kod woła funkcję, której nie ma. Częsta przyczyna to wtyczka zależna od innej wtyczki, która jest wyłączona, albo motyw po aktualizacji niezgodny z wtyczką.
Maximum execution time of … seconds exceeded. Skrypt działał dłużej, niż pozwala serwer. Zdarza się przy imporcie, dużej kopii zapasowej albo wolnym połączeniu z zewnętrzną usługą.
Uncaught Error: Class … not found. Brakuje części kodu wtyczki, na przykład po nieudanej aktualizacji. Pomaga ponowna instalacja tej samej wersji wtyczki.
Cannot modify header information - headers already sent. Coś wysłało tekst do przeglądarki za wcześnie. Bardzo często to pusta linia albo spacja na końcu pliku functions.php po ręcznej edycji.
Wartości w komunikatach zmieniają się w zależności od strony, dlatego zamiast nich jest wielokropek. Jeśli log pokazuje błąd krytyczny, a strona nie działa, przejdź do poradnika błąd krytyczny WordPress. Przy białym ekranie albo kodzie 500 zajrzyj do tekstu o błędzie 500 w WordPress.
Co wysłać hostingowi albo developerowi
Dobrze opisane zgłoszenie oszczędza wymiany kilku wiadomości. Podaj w nim:
- dokładny komunikat z logu, skopiowany, a nie przepisany z pamięci, razem ze ścieżką do pliku i numerem linii,
- datę i godzinę pierwszego wystąpienia oraz informację, czy błąd się powtarza,
- co zmieniło się tuż wcześniej: aktualizacja wtyczki, motywu, WordPressa albo wersji PHP,
- na której stronie i przy jakiej czynności błąd się pojawia, na przykład przy dodaniu do koszyka,
- wersję WordPressa i PHP z ekranu Narzędzia → Zdrowie witryny → Informacje.
Przed wysłaniem usuń z fragmentu adresy e-mail i inne dane klientów.
Jak czat czyta logi za ciebie
Wtyczka TellMyShop dla WordPress i WooCommerce czyta dzienniki błędów już w darmowej wersji TellMyShop Free. Twój czat (Claude albo ChatGPT) dostaje błędy PHP, WordPressa i WooCommerce z ostatnich dni, zgrupowane: ten sam komunikat to jeden wiersz z liczbą wystąpień i datą ostatniego. Przy każdym wskazuje wtyczkę albo motyw, z którego pochodzi, i tłumaczy komunikat prostymi słowami. E-maile, telefony i adresy IP w logach są maskowane.
Ty: Od wczoraj koszyk czasem się nie ładuje. Zajrzyj do logów.
Twój czat: W ostatnich dwóch dniach jest jeden błąd krytyczny, powtórzony kilkanaście razy:
Allowed memory size exhausted, plik we wtyczce do kalkulacji wysyłki.
Pojawia się tylko przy otwieraniu koszyka. Wtyczka ma od wczoraj nową wersję.
Proponuję: zgłosić błąd autorowi albo wrócić do poprzedniej wersji wtyczki. Limit pamięci to sprawa dla hostingu.
Wynik w tej rozmowie jest przykładowy. Czat czyta to, co jest zapisane. Jeśli zapis do debug.log jest wyłączony, w logach WordPressa nic nie będzie. Włączyć go czat nie może: plik wp-config.php jest dla wtyczki zablokowany zawsze, w każdej wersji. To robisz ty, hosting albo opiekun strony.
Samo czytanie logów, kondycji witryny i listy wtyczek wystarczy do diagnozy i jest za darmo. Gdy przyczyną jest wtyczka, w TellMyShop Pro czat może ją wyłączyć albo zaktualizować po włączeniu przełącznika Wtyczki na 24 godziny, zawsze z podglądem i po twojej zgodzie. Darmową wersję pobierzesz ze strony TellMyShop Free, opis Pro jest na stronie TellMyShop dla WordPress i WooCommerce, a różnice w cenniku.
Pytania i odpowiedzi
Gdzie jest plik debug.log w WordPress?
Domyślnie w katalogu wp-content, ale tylko wtedy, gdy w wp-config.php włączone są WP_DEBUG i WP_DEBUG_LOG. Plik powstaje przy pierwszym błędzie po włączeniu zapisu. Jeśli go nie ma, zapis jest wyłączony albo od włączenia nie było błędów.
Czy włączenie WP_DEBUG pokaże błędy klientom?
Może, jeśli zostawisz wyświetlanie błędów włączone. Na działającej stronie ustawia się zapis do pliku z wyłączonym wyświetlaniem, czyli WP_DEBUG_DISPLAY na false. Wtedy błędy trafiają tylko do debug.log.
Czy ostrzeżenia Deprecated trzeba naprawiać od razu?
Zwykle nie. Mówią, że wtyczka albo motyw używa funkcji, która w przyszłości zniknie z PHP lub WordPressa. Strona działa, ale przed zmianą wersji PHP warto zgłosić je autorowi wtyczki albo poszukać aktualizacji.
Czy log błędów może zawierać dane klientów?
Tak, czasem trafiają tam adresy e-mail, adresy IP albo fragmenty zapytań. Dlatego nie wysyłaj całego pliku na forum i nie zostawiaj zapisu włączonego bez potrzeby. Wtyczka TellMyShop przy odczycie maskuje e-maile, telefony i adresy IP.
Kto ma dostęp do logów serwera?
Hosting. Logi błędów PHP serwera są zwykle w panelu hostingu, w sekcji ze statystykami albo logami. Jeśli ich tam nie widzisz, poproś pomoc techniczną o fragment z godziną, o której pojawił się błąd.
WordPress jest znakiem towarowym WordPress Foundation. WooCommerce jest znakiem towarowym Automattic Inc. Claude jest znakiem towarowym Anthropic PBC. ChatGPT i OpenAI są znakami towarowymi OpenAI. TellMyShop nie jest powiązany z tymi firmami.