Debugowanie WordPressa: logi, błędy i bezpieczna diagnoza

Debugowanie WordPressa zacznij od informacji, co dokładnie przestało działać. Zapisz adres, godzinę ze strefą czasową, konto lub rolę użytkownika i kroki odtworzenia. Sprawdź, czy problem dotyczy całej witryny, pojedynczej podstrony, panelu czy zadania wykonywanego w tle. Nie uruchamiaj od razu serii przypadkowych zmian limitów i dodatków.

Zachowaj aktualną kopię plików i bazy oraz dostępne logi. Kopia wykonana po awarii nie zastępuje wcześniejszego sprawnego stanu, ale może zachować nowe dane i materiał diagnostyczny. Przy sklepie ustal, czy nadal napływają zamówienia. Odtwarzanie starej bazy bez tej wiedzy może usunąć poprawnie przyjęte zakupy.

Porównaj moment wystąpienia błędu z ostatnimi wdrożeniami. Zmiana PHP, konfiguracji serwera i aktualizacja wtyczki są osobnymi hipotezami. Jeśli planujesz kolejną zmianę wersji, korzystaj z procedury aktualizacji WordPressa. Najpierw spróbuj odtworzyć problem na kopii; produkcyjna awaria nie jest dobrym miejscem do eksperymentów bez planu cofnięcia.

Dokumentacja debugowania WordPressa opisuje WP_DEBUG, zapis logu i wyłączenie wyświetlania komunikatów. Narzędzia te są przeznaczone przede wszystkim do pracy lokalnej i na stagingu. Log może zawierać dane wrażliwe, dlatego wybierz ścieżkę poza katalogiem publicznym i ogranicz dostęp do pliku.

Poniższy fragment jest przykładem do dostosowania, a nie gotową ścieżką dla każdego hostingu. Dodaj lub zmień istniejące definicje w wp-config.php przed uruchomieniem WordPressa; nie definiuj tej samej stałej drugi raz.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/sciezka-prywatna/logi/wordpress-debug.log');
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Katalog musi istnieć i pozwalać procesowi PHP na zapis. Po konfiguracji odtwórz objaw i potwierdź powstanie właściwego wpisu. Samo ustawienie WP_DEBUG_LOG nie wystarczy przy wyłączonym WP_DEBUG. Jeżeli diagnoza wymaga krótkiego logowania na produkcji, ustal zakres, czas oraz osobę kontrolującą plik. Nie publikuj błędów odwiedzającym i nie pozostawiaj rozbudowanej diagnostyki bez nadzoru.

Po odtworzeniu błędu znajdź wpis z odpowiadającym mu czasem. Zapisz typ komunikatu, ścieżkę i numer linii oraz otaczający kontekst. Nazwa wtyczki w stosie wywołań jest tropem, nie automatycznym wskazaniem winnego. Kod może otrzymać błędne dane od innego komponentu albo wywołać funkcję niedostępną w bieżącym środowisku.

Brak pliku może oznaczać nieprawidłową ścieżkę, brak uprawnień, wyłączone logowanie albo błąd przed uruchomieniem WordPressa. Sprawdź konfigurację i logi PHP lub hostingu. Nie uznawaj witryny za wolną od błędów tylko dlatego, że nie powstał debug.log. Ustal również strefę czasową logów, zanim połączysz wpis z próbą użytkownika.

Biały ekran opisuje wygląd odpowiedzi, a 500 jest statusem HTTP. Mogą wynikać z tej samej awarii PHP albo konfiguracji serwera. Nie rozdzielaj ich na sztywno na błąd WordPressa i błąd niezależnej infrastruktury. Sprawdź kod odpowiedzi, treść oraz logi z chwili próby.

Jeżeli WordPress nie zdążył uruchomić własnego logowania, potrzebne będą logi PHP, serwera lub procesu obsługującego żądanie. Poproś hosting o właściwy zakres czasu i adres. Nie zmieniaj w ciemno .htaccess: nie każdy serwer z niego korzysta, a plik może zawierać ważne reguły dostępu i przekierowania.

Przy komunikacie o wyczerpaniu pamięci sprawdź operację i faktyczne limity środowiska. WP_MEMORY_LIMIT nie omija ograniczeń hostingu. Podniesienie liczby może pomóc w uzasadnionym przypadku, ale nie naprawia pętli ani niekontrolowanego zużycia zasobów. Zapisz stan przed i po próbie oraz zweryfikuj wykonanie zadania. Jeżeli błąd pojawia się tylko pod obciążeniem, potrzebujesz danych o zasobach i żądaniach, nie samego zrzutu białej strony.

Na stagingu zachowaj możliwie podobną wersję PHP, konfigurację i dane potrzebne do odtworzenia. Wyłącz produkcyjne płatności, wysyłki i pomiar. Potem zmieniaj jeden element lub uzasadnioną grupę zależności, zapisując wynik tego samego scenariusza. Jeśli problem dotyczy formularza, użyj diagnostyki jego etapów, zamiast sprawdzać jedynie stronę główną.

Metoda połowienia może przyspieszyć poszukiwania, gdy błąd jest odtwarzalny i zależności na to pozwalają. Nie gwarantuje określonej liczby prób. Dwa dodatki mogą powodować problem dopiero razem, a wyłączenie modułu nadrzędnego może uruchomić nowy błąd w rozszerzeniu. Wtedy prosty podział na jednego winnego prowadzi do fałszywego wniosku.

Podejrzaną kombinację potwierdź ponownie: przywróć stan wywołujący objaw, zastosuj poprawkę i powtórz test. Motyw zmieniaj na rzeczywiście zainstalowany, zgodny wariant przez właściwy mechanizm WordPressa. Przemianowanie folderu na nazwę domyślnego motywu nie jest poprawną instalacją ani przełączeniem jego kodu.

Stan witryny pomaga zebrać informacje o środowisku, a Query Monitor udostępnia dane diagnostyczne dotyczące między innymi zapytań, błędów i żądań HTTP. Narzędzie nie wykonuje za Ciebie analizy przyczyny. Najdłuższe zapytanie w jednym widoku nie musi wyjaśniać awarii występującej w zadaniu wykonywanym w tle.

Health Check & Troubleshooting udostępnia tryb rozwiązywania problemów dla bieżącej sesji użytkownika. Nie należy mylić tej funkcji dodatku z automatyczną dostępnością identycznego trybu w każdej instalacji. Izolacja widoku sesji również nie oznacza, że każda czynność przestaje zapisywać dane lub komunikować się z zewnętrzną usługą.

Dobieraj narzędzie do pytania i ogranicz czas jego działania. Rozbudowane śledzenie zapytań zwiększa narzut, a logi mogą rosnąć. W sklepie sprawdź również logi używanej integracji, jeśli problem dotyczy płatności lub zamówień. Wyniki przekazuj w ograniczonym zakresie, bez pełnych baz, haseł i danych klientów. Wsparcie dla WordPressa powinno zaczynać się od tych samych zasad porządkowania dowodów.

Jeśli dostępny jest Recovery Mode, sprawdź informacje o błędzie i możliwość wejścia do panelu. Nie zakładaj, że wiadomość odzyskiwania zawsze dotrze. Gdy panel pozostaje niedostępny, wykorzystaj kontrolowany dostęp do hostingu i wykonawcę znającego instalację. Wyłączenie wskazanego komponentu może pomóc odzyskać dostęp, ale wymaga sprawdzenia wpływu na sklep i zależne funkcje.

Nie kasuj katalogów ani nie importuj starej bazy tylko po to, by zobaczyć, czy strona wstanie. Przywrócenie powinno obejmować spójny stan kodu i danych, z ochroną nowych zamówień. Zachowaj materiał diagnostyczny przed działaniem, które mogłoby go usunąć.

Po naprawie powtórz scenariusz oraz funkcje zależne, wyłącz zbędną diagnostykę i zabezpiecz potrzebne logi zgodnie z ustaloną retencją. Sprawdź brak publicznego dostępu do plików. Zapisz przyczynę, zmianę i wynik testu. Jeśli potrzebujesz naprawy WordPressa, prześlij opis objawu z czasem i zanonimizowanym komunikatem. Zakres późniejszych kontroli można objąć pakietem godzinowym; warunki SLA ustala się indywidualnie.

Jeśli liczba błędów rośnie po każdej zmianie, tańsza od kolejnych napraw bywa nowa strona firmowa na WordPressie.