Strona nie działa po aktualizacji. Co zrobić w pierwszych dwudziestu minutach

Kliknąłeś „aktualizuj", odświeżyłeś stronę i zamiast oferty zobaczyłeś biały ekran albo komunikat o błędzie krytycznym. Zanim zaczniesz klikać na oślep, warto wiedzieć jedno: WordPress ma wbudowany tryb ratunkowy, o którym prawie nikt nie wie, a część awarii po aktualizacji naprawia się usunięciem jednego pliku. Ten tekst jest o pierwszych dwudziestu minutach.

Zacznij od tego, co widzisz na ekranie

Komunikat nie jest ozdobą. Każdy wskazuje inną warstwę, a to od razu odsiewa połowę możliwych przyczyn.

Dwa ostatnie wiersze różnią się od reszty. Przy 502 i 504 problem leży zwykle po stronie serwera, a nie Twojej strony, więc pierwszym krokiem jest kontakt z hostingiem zamiast grzebania we wtyczkach.

Tryb odzyskiwania, czyli mail, którego nikt nie czyta

To najbardziej niedoceniana funkcja WordPressa. Gdy strona wywraca się na błędzie krytycznym, system sam rozpoznaje, która wtyczka albo który motyw za to odpowiada, wstrzymuje ją i wysyła wiadomość na adres administratora.

W tej wiadomości jest odnośnik. Kliknięcie w niego wpuszcza Cię do panelu w trybie odzyskiwania, z problematyczną wtyczką wyłączoną. Możesz wtedy spokojnie zdecydować, czy ją usunąć, cofnąć do starszej wersji, czy poszukać zamiennika.

Zanim zaczniesz cokolwiek naprawiać, sprawdź skrzynkę. Odpowiedź bywa już tam.

Haczyk jest jeden i wywraca to w praktyce najczęściej: mail idzie na adres wpisany w ustawieniach ogólnych WordPressa, a nie na ten, którego używasz na co dzień. Przy stronach robionych lata temu bywa to skrzynka byłego pracownika albo adres wykonawcy, z którym dawno nie ma kontaktu.

Zacięty tryb konserwacji

Osobny przypadek, wyjątkowo częsty i wyjątkowo łatwy do naprawienia. Strona pokazuje komunikat o zaplanowanej konserwacji i prośbę, żeby sprawdzić za minutę. Mija godzina, mija dzień, komunikat wisi dalej.

Mechanizm jest prosty. Na czas aktualizacji WordPress tworzy w katalogu głównym plik o nazwie .maintenance i po zakończeniu go kasuje. Jeśli aktualizacja przerwie się w połowie, na przykład przez zerwane połączenie albo przekroczony czas wykonania skryptu, plik zostaje. Strona zachowuje się wtedy tak, jakby aktualizacja wciąż trwała.

Naprawa polega na usunięciu tego pliku przez menedżer plików w panelu hostingu albo przez FTP. Nazwa zaczyna się od kropki, więc bywa domyślnie ukryta i trzeba włączyć pokazywanie plików ukrytych.

Po usunięciu strona wraca od razu. Warto jednak sprawdzić, czy aktualizacja, która się przerwała, doszła do końca, bo częściowo zaktualizowana wtyczka potrafi zachowywać się dziwnie jeszcze długo potem.

Gdy nie wchodzisz nawet do panelu

Bywa, że razem ze stroną pada też zaplecze i nie da się niczego wyłączyć od środka. Wtedy zostaje droga naokoło, przez pliki.

Zmiana nazwy katalogu wp-content/plugins na dowolną inną wyłącza wszystkie wtyczki naraz. To brutalne, ale skuteczne: jeśli po tej operacji panel wstaje, wiesz już, że winna jest któraś z wtyczek. Przywracasz nazwę katalogu, wchodzisz do panelu i włączasz je pojedynczo, aż strona znowu się wywróci.

Ta metoda ma jedną pułapkę. Wyłączenie wtyczek przez zmianę nazwy katalogu bywa traktowane przez WordPressa jak dezaktywacja, więc część wtyczek po ponownym włączeniu zapomina ustawienia. Przy prostych wtyczkach to bez znaczenia, przy sklepie potrafi zaboleć.

Jeśli awaria dotyczy konkretnie Elementora, rozpisałem tamten przypadek osobno, razem z listą rzeczy, których nie wolno robić w pierwszych minutach, we wpisie o naprawie strony po aktualizacji Elementora.

Gdzie leży dziennik błędów

Biały ekran nic nie mówi, ale serwer wie dokładnie, co się stało. Trzeba tylko wiedzieć, gdzie zajrzeć.

Pierwsze miejsce to panel hostingu. Prawie każdy dostawca udostępnia dzienniki błędów, zwykle w sekcji o statystykach albo o logach. Ostatnie wpisy z godziny awarii wskazują plik i linijkę, w której proces się wywrócił, a nazwa pliku zawiera zwykle nazwę winnej wtyczki.

Drugie miejsce to własny dziennik WordPressa, który trzeba wcześniej włączyć w pliku wp-config.php. Po włączeniu zapisu błędy trafiają do pliku w katalogu wp-content. To rozwiązanie na przyszłość, a nie na teraz, bo w trakcie awarii rzadko chce się grzebać w konfiguracji.

Kiedy przestać grzebać samemu

Nie ma nagrody za samodzielność, a przy stronie firmowej każda godzina przestoju kosztuje realnie. Cztery sytuacje, w których lepiej odpuścić.

Nie masz kopii zapasowej. Bez niej każdy ruch jest jednokierunkowy. Pierwszą rzeczą, jaką robi się przy takiej naprawie, jest zabezpieczenie stanu obecnego, żeby dało się wrócić. O tym, dlaczego kopia u hostingodawcy nie zastępuje własnej, pisałem przy prostym backupie strony.

Padł sklep. Przy koszyku i płatnościach eksperymenty kosztują zamówienia, a błąd w bazie potrafi pomieszać dane klientów.

Minęła godzina bez postępu. Po godzinie klikania zwykle nie jesteś bliżej rozwiązania, tylko dalej od stanu wyjściowego.

Widzisz błąd bazy danych. To jedyna kategoria z tej listy, przy której nieudana próba naprawy potrafi trwale uszkodzić treść.

Co przygotować, zanim poprosisz o pomoc

Tu jest rzecz, o której warto wiedzieć zawczasu. Naprawy awaryjne rozlicza się za rozpoczętą godzinę, więc czas zużyty na zbieranie dostępów liczy się tak samo jak czas naprawy. Kwadrans przygotowania potrafi zmieścić całą sprawę w jednej pozycji zamiast w dwóch.

Ile to trwa i od czego zależy

Rozrzut jest spory i zależy głównie od tego, w której warstwie siedzi problem.

Zacięty tryb konserwacji albo pojedyncza wtyczka rozpoznana z dziennika to zwykle kwadrans. Awaria wymagająca przejścia wtyczek pojedynczo zabiera więcej, bo po każdym włączeniu trzeba stronę sprawdzić. Problemy z bazą danych albo z niezgodnością wersji PHP ciągną się najdłużej, bo naprawa wymaga wcześniejszego zabezpieczenia danych.

Drugi czynnik to dostępy. Naprawa, przy której trzeba czekać na hasła od trzech różnych osób, trwa dłużej od samej naprawy. Stąd lista wyżej.

Częste pytania