Co zrobić gdy WordPress działał, ale przestał? Podstawy debugowania

Pozwólcie, że napiszę tu krótki poradnik jakie powinny być pierwsze kroki gdy WordPress w jakikolwiek sposób przestaje Wam działać. Początkujący użytkownicy WordPressa bowiem gdy widzą, że na przykład po aktualizacji WordPressa nie da się czegoś zrobić, idą na różne fora, zadają pytania i w odpowiedzi dostają niemal zawsze ten sam zestaw pytań i próśb o uzupełnienie opisu swojego problemu.

Skróćmy to. Oto rzeczy, które musisz niemal zawsze zrobić zanim ktoś bardziej zaawansowany będzie mógł ci pomóc (a być może już w czasie tych kroków sam rozwiążesz problem).

Wyłącz wszystkie wtyczki i ustaw domyślny motyw (jeden z motywów „twenty-cośtam”). I zobacz czy strona zacznie działać. Jeśli zacznie, zacznij stopniowo włączać wtyczki i motyw i patrz kiedy strona się wysypie. Gdy wysypie się po jednej z wtyczek, znajdziesz w ten sposób winowajcę. Pisząc na forum, wspomnij o tym.

Jeśli Twoja strona jest tak mocno wysypana, że nie możesz dostać się do Kokpitu by wyłączyć wtyczki i motyw, zmień nazwy katalogów tych wtyczek i Twojego motywu (możesz to zrobić na przykład logując się przez ftp na swój serwer). WordPress sam je wtedy wyłączy.

Jeśli wyłączenie wtyczek i motywu nie pomogło, oznacza to, że błąd jest gdzieś w samym WordPressie. Zaktualizuj WordPressa ponownie, bo być może podczas aktualizacji nie wgrały się wszystkie pliki. To oczywiście porada w przypadku gdy „wysypanie się” zdarzyło się po aktualizacji.

Niestety ponowna aktualizacja WordPressa nie jest tak prosta jak kliknięcie guziczka w Kokpicie, będziesz musiał(a) zrobić ją ręcznie, ponownie przez FTP. Dokładna instrukcja jest tutaj. Nie jest to trudne, ale faktycznie za pierwszym razem może się takie wydawać.

Wracając do etapu wyłączania wtyczek, gdy włączając je ponownie udało ci się namierzyć winowajcę i chcesz o tym napisać na jakimś forum oczekując pomocy (najlepiej pisz na oficjalnym forum wsparcia danej wtyczki, bo autor będzie musiał koniec końców naprawić ten błąd) warto zrobić mały wstęp do debugowania. Wstęp, bo nie będzie to samo debugowanie, które raczej wykracza poza zdolności zwykłego użytkownika strony, ale pozwoli Ci zebrać dane, które przekażesz autorowi i szybciej zorientuje się on co się stało, powie Ci jak to obejść i na koniec wyda zaktualizowaną wersję wtyczki/motywu już bez tego błędu.

Jeśli Twój błąd nie powoduje całkowitego „zniknięcia” strony – na przykład widzisz edytor wpisów, ale któryś przycisk przestał działać – sprawdź jakie błędy pojawiają się w konsoli przeglądarki. W tym celu kliknij prawy przyciskiem myszy gdzieś w oknie przeglądarki i wybierz „Zbadaj element”, a w oknie które się otworzy przełącz się na zakładkę „Konsola”. Być może będziesz musiał(a) odświeżyć stronę i wykonać ponownie niedziałającą akcję by zobaczyć informację o błędzie.

Jeśli strona nie działa w ogóle lub w konsoli nie widać błędów, włącz debugowanie w WordPressie. W tym celu w pliku wp-config.php odnajdź linijkę z opcją WP_DEBUG i zmienić wartość z false na true. Przeładuj stronę i zobacz co pojawia się na ekranie. Jeśli nic się nie pojawia (komunikat o błędzie PHP może być przesłonięty przez jakiś element strony lub pojawiać się w odpowiedzi wysłanej AJAXem), skonfiguruj ten plik tak by wszelkie błędy były logowane do pliku. Tu jest instrukcja jak to zrobić, a sam plik utworzy się w katalogu /wp-content.

Jeśli nadal jest biały ekran lub widzisz informację o błędzie zaczynającą się od 5xx (np Error 503 Service Unavailable) sprawdź logi serwera. Gdzie ich szukać dowiesz się albo od supportu twojej firmy hostingowej, ale zanim zapytasz, zajrzyj do panelu administracyjnego twojego serwera (najpewniej używany jest cPanel). Tak jeden z guzików pozwala wyświetlić informacje o błędach. Podpowiedź: najnowsze błędy są na dole tego pliku. Możesz też skasować całą zawartość pliku i odswieżyć stronę. Pojawią się w nim tylko błędy powstałe akurat podczas ponownego ładowania strony po odświeżeniu.

Jeśli serwer masz zainstalowany lokalnie, spróbuj wygooglać gdzie jest Twój plik z błędami, na każdym systemie a nawet jego wersji będzie to nieco inne miejsce. W Ubuntu będzie to /var/log/apache2/error.log ale googlając „{nazwa systemu} {nazwa serwera} error log” znajdziesz Twoją lokalizację.

To właściwie koniec debugowania dla początkujących. Zakładam, że przeczytanie komunikatu błędu i zrozumienie go Cie przerasta, ale nie ma w tym nic złego. Pisany jest raczej językiem zrozumiałym dla programistów. Teraz zgłoś błąd na forum odpowiedniej wtyczki, motywu czy WordPressa (w zależności do pierwszy etap wykazał jako źródło błędu) i opisując:

• napisz na czym dokładnie polega błąd. Nie pisz „nie mogę dodać zdjęcia”, bo to informacja zbyt ogólna. Może ona oznaczać, że nie możesz wejść do Kokpitu by dodać zdjęcie, nie możesz uruchomić edytora w Kokpicie, nie możesz kliknąć przycisku dodawania zdjęcia, możesz kliknąć, ale po wybraniu pliku nic się nie dzieje i tak dalej. Najlepiej opisz krok po kroku co próbujesz zrobić i czym się to kończy, a czym wg Ciebie powinno.
• Napisz jaka wtyczka lub motyw powodują błąd i podaj numer używanej wersji
• Napisz wynik wszystkich sprawdzań błędów: w konsoli przeglądarki, wynik z włączonym WP_DEBUG i co zawierają logi serwera.

Następnie przywróć felerną wtyczkę lub motyw do poprzedniej wersji (zastępując odpowiedni katalog rozpakowanym katalogiem starszej wersji). Możesz też przywrócić całą stronę z kopii zapasowej, ale na pewno zgłoś błąd autorowi. Bez zgłoszenia nie zostanie on naprawiony i zostaniesz przy starszej wersji a zaniechanie aktualizacji prędzej czy później skończy się atakiem na Twoją stronę i jej utratą. Pisałem o tym tutaj.

Jeśli wszystko powyższe Cię przerasta lub poddasz się na jakimś etapie, zawsze możesz odpłatnie uzyskać pomoc dodając zlecenie na WPzlecenia.pl. Dla bywalców tamtej strony takie sprawdzanie i dalsze rozwiązywanie problemów to codzienność.

Może jeszcze na koniec uzupełnienie: to co wyżej opisałem według wielu (w tym także i mnie) nie jest de facto debugowaniem. Fachowo takie poszukiwanie przyczyn błędu nazywa się troubleshooting, a debugowanie właściwie zaczyna się już po tych etapach gdy uruchamiamy debuggera JS lub PHP. Jednak wiele osób powyższe nazywa właśnie debugowaniem, stąd też to słowo w tytule wpisu.

Update: opublikowałem kolejny wpis, w którym wyjaśniam kolejne kroki jak znaleźć konkretne miejsce w kodzie, gdzie powstał błąd.