Co zrobić gdy funkcjonująca już od dłuższego czasu strona nagle przestaje działać? Co gdy zamiast naszego serwisu w przeglądarce pojawia się tylko biała, pusta strona (zwana czasem White Screen of Death)? Co gdy nie możemy nawet zalogować się do panelu administracyjnego WordPressa? Czy nasza strona została bezpowrotnie utracona i jedynym sposobem na przywrócenie jej do życia jest skorzystanie z kopii bezpieczeństwa? Zanim wpadniemy w panikę wykonajmy kilka prostych czynności, które w znacznej części przypadków powinny doprowadzić nasz serwis do stanu używalności.
Nic nie dzieje się samo
Na wstępie ustalmy jedno: strona nie psuje się sama i nie przestaje działać sama z siebie. Przypomnijmy sobie jakie czynności wykonywaliśmy ostatnio w naszym serwisie. Czy instalowaliśmy lub aktualizowaliśmy jakieś wtyczki? Czy wykonywaliśmy jakieś zmiany w plikach motywu? Czy zmienialiśmy konfigurację serwera? A może zrobiła to nasza firma hostingowa (a e-mail z informacją gdzieś nam się zapodział)? Wszystkie, nawet z pozoru nieistotne, działania mogą być potencjalnie związane z awarią.
Tryb debug
Na samym wstępie powinniśmy włączyć w WordPressie tryb debug. W tym trybie WordPress wyświetla wszystkie komunikaty o błędach, ostrzeżenia i informacje. (domyślnie są one ukryte przez wzgląd na bezpieczeństwo). Aby to zrobić musimy zalogować się do naszego serwera przez FTP i odszukać plik wp-config.php. Otwórzmy go, znajdźmy następującą linię:
define('WP_DEBUG', false);
i zamieńmy ją na:
define('WP_DEBUG', true);
Jeśli w naszym pliku nie ma tej linii, po prostu dodajmy ją – na przykład za definicją zmiennej $table_prefix.
Po zapisaniu zmian w pliku wp-config.php możemy ponownie spróbować otworzyć naszą stronę – w większości przypadków zobaczymy jakiś komunikat o błędzie.
Informacje o błędach możemy również znaleźć w logu serwera. Najczęściej dostęp do niego możemy uzyskać z poziomu panelu administracyjnego usług hsotingowych, często również można go znaleźć w katalogu głównym strony (plik error_log). W razie problemów ze zlokalizowaniem logów najlepiej poprosić o pomoc firmę hostingową utrzymującą nasz serwer.
Najczęstsze przyczyny problemów
Trudno opisać wszystkie możliwe przyczyny problemów z działaniem WordPressa, ale na pewno można wymienić kilka występujących najczęściej.
Zainfekowana strona
Samo zainfekowanie strony nie powinno jej zepsuć – nie to jest bowiem celem złośliwych skryptów. Może jednak zdarzyć się sytuacja, w której błędy w kodzie spowodują, że nasz serwis przestanie działać. Kilka porad na temat radzenia sobie z zainfekowaną stroną można znaleźć w tekście Moja strona została zainfekowana – co robić?.
Błąd we wtyczce
Niestety, ponieważ aktualizacje wtyczek nie przechodzą żadnej weryfikacji, zdarza się (rzadko, ale jednak), że wkradnie się do nich jakiś błąd. Pół biedy gdy powoduje on wyświetlanie komunikatów lub nieprawidłowe działanie rozszerzenia. Gorzej gdy unieruchomi on całą naszą stronę.
Jeśli błąd we wtyczce wystąpi na etapie jej aktywacji, WordPress automatycznie dezaktywuje problematyczne rozszerzenie. Tak się jednak nie stanie gdy problem wystąpi później.
Felerną wtyczkę bardzo łatwo zidentyfikować na podstawie komunikatów o błędach. Jeśli problemem jest jedno z rozszerzeń, komunikat będzie wyglądał na przykład tak:
Parse error: syntax error, unexpected T_STRING in /home/domena/wp-content/plugins/nazwa-wtyczki/wtyczka.php
Nas interesuje pogrubiony fragment. Mówi on nam o którą wtyczkę chodzi – w tym wypadku jest to rozszerzenie znajdujące się w katalogu plugins/nazwa-wtyczki. Jeśli nie wiemy jak naprawić błąd, najprościej po prostu dezaktywować wtyczkę. W tym celu należy połączyć się z serwerem za pomocą FTP, przejść do katalogu wp-content/plugins i zmienić nazwę katalogu nazwa-wtyczki na jakąkolwiek inną, co spowoduje dezaktywację rozszerzenia.
Błąd w motywie
Jeśli błąd występuje w motywie, to komunikat będzie wyglądał na przykład tak:
Parse error: syntax error, unexpected T_STRING in /home/domena/wp-content/themes/nazwa-motywu/index.php
Jeśli chcemy dezaktywować problematyczny motyw, schemat działania wygląda dokładnie tak samo jak w przypadku wtyczek: należy zmienić nazwę katalogu wp-content/themes/nazwa-motywu na inną.
Zbyt mała ilość dostępnej pamięci
Problem ten występuje często na tanich serwerach współdzielonych, gdy zainstalujemy zbyt dużo wtyczek lub gdy używany przez nas motyw jest naprawdę rozbudowany. Komunikat o przekroczonej maksymalnej ilości dostępnej pamięci wygląda mniej więcej tak:
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 64 bytes)
Najprostszym (ale niestety nie zawsze skutecznym) sposobem na zwiększenie limitu dostępnej pamięci jest dodanie następującej linijki do pliku wp-config.php:
define('WP_MEMORY_LIMIT', '64M');
Gdy ten sposób nie zadziała, można spróbować zwiększyć limit za pomocą pliku .htaccess (znajduje się w katalogu głównym WordPressa). Wystarczy dodać do niego (na przykład na samym początku) taką linię:
php_value memory_limit 64M
Jeśli i ten sposób nie da oczekiwanego skutku, to nie pozostaje nam nic innego jak skontaktować się z firmą hostingową utrzymującą nasz serwer i poprosić o zwiększenie limitu pamięci.
Uszkodzone tabele w bazie danych
Jedną z najczęstszych przyczyn problemów z połączeniem z bazą danych (poza błędnymi danymi logowania oraz niedziałającym serwerem) są uszkodzone tabele. Problem ten objawia się w dość dziwny sposób – uszkodzone tabele są oznaczane jako będące w użyciu lub zablokowane. Najczęściej przyczyną jest nagłe i nieprawidłowe wyłączenie serwera bazy danych (na przykład w skutek awarii) lub brak miejsce na dysku (w tym również przekroczenie limitu wielkości bazy danych). Uszkodzone tabele na szczęście bardzo łatwo naprawić (w większości przypadków bez utraty danych) za pomocą funkcji REPAIR. Jeśli mamy dostęp do jakiegoś menedżera baz danych (na przykład phpMyAdmina), to w zakładce SQL wystarczy wykonać zapytanie:
REPAIR TABLE nazwa_tabeli
Warto wiedzieć, że WordPress posiada wbudowaną funkcję automatycznego naprawiania tabel. Aby ją włączyć należy do pliku wp-config.php dodać następującą linię:
define('WP_ALLOW_REPAIR', true);
a następnie otworzyć stronę http://nasza-domena.pl/wp-admin/maint/repair.php i postępować zgodnie z instrukcjami. Po zakończeniu operacji należy usunąć dodaną linię z pliku konfiguracyjnego.
Spacje na początku pliku .php
Ten rodzaj błędów jest jednym z trudniejszych do zlokalizowania, szczególnie dla mniej zaawansowanych użytkowników. Objawia się on komunikatem, który wyglądać może na przykład tak:
Warning: Cannot modify header information – headers already sent by (output started at /home/domena/public_html/wp-config.php:2) in /home/domena/public_html/wp-includes/pluggable.php on line 877
W tym komunikacie interesuje nas plik o pogrubionej nazwie – w nim należy szukać przyczyn problemu. Najczęściej winna jest pusta linia lub spacja przed znacznikiem otwarcia kodu PHP (<?php). W tym konkretnym przypadku problematyczny fragment (numer linii znajduje się po dwukropku) wygląda tak:
<?php /** * The base configurations of the WordPress.
a powinien on wyglądać tak (bez spacji przed <?php):
<?php /** * The base configurations of the WordPress.
Przyczyna problemu nie musi leżeć na początku pliku – taki kod również spowoduje wystąpienie opisywanego błędu:
<?php // jakiś kod PHP ?> <?php // ciąg dalszy kodu PHP
Nieprawidłowe uprawnienia katalogów lub plików
Niektóre serwery domyślnie blokują żądania, które odnoszą się do katalogów lub plików posiadających nieprawidłowe (mało restrykcyjne) uprawnienia. Jest to sytuacja stosunkowo rzadka, co nie zmienia faktu, że z przyczyn związanych z bezpieczeństwem warto dbać o prawidłowe uprawnienia. Uprawnienia katalogów i plików można sprawdzić i zmienić za pomocą dowolnego klienta FTP. W skrócie – wszystkie katalogi powinny mieć uprawnienia 755 (lub 750), a pliki 644 (lub 640). Plikowi wp-config.php można ustawić nieco bardziej restrykcyjne uprawnienia 600.
Nic nie pomogło – co dalej?
Jeśli nasze działania nie przyniosły oczekiwanego skutku, to zawsze zostaje najbardziej radykalne rozwiązanie – przywrócenie plików i bazy danych naszej strony z kopii bezpieczeństwa.
Masz taką kopię, prawda?