WordPress · serwis
Strona przestaje działać zwykle w najgorszym momencie: w dniu wysyłki newslettera albo w środku kampanii reklamowej. Zamiast wyłączać wtyczki po kolei i sprawdzać, co pomoże, zaczynam od logów serwera – bo w nich prawie zawsze jest nazwa pliku i numer linii, który powoduje awarię. Analizę otrzymujesz zwykle tego samego dnia.
Zakres
Osiem sytuacji, które w praktyce wracają najczęściej. Jeśli Twojego objawu nie ma na liście, i tak napisz – nazwa błędu rzadko mówi cokolwiek o przyczynie.
Panel przestaje wpuszczać po aktualizacji, po zmianie ustawień wtyczki bezpieczeństwa albo po ataku na konta administratorów. Resetuję dostęp z poziomu plików i bazy danych, sprawdzam listę kont administratorów i usuwam te, które nie powinny tam istnieć.
Dwie wtyczki ładujące własną wersję tej samej biblioteki potrafią wyłączyć slider, galerię albo edytor. Odtwarzam sytuację na kopii strony, ustalam, które elementy ze sobą kolidują, i szukam rozwiązania: aktualizacji, zamiennika albo poprawki w kodzie motywu potomnego.
Formularz pokazuje „dziękujemy”, a wiadomość nie dociera. Najczęściej to poczta wysyłana funkcją PHP zamiast przez SMTP, brak rekordów SPF i DKIM albo filtr odbiorcy. Konfiguruję wysyłkę przez uwierzytelnione konto i sprawdzam dostarczalność na kilka skrzynek.
Hosting aktualizuje PHP, a strona przestaje działać, bo motyw albo wtyczka używa błędnej funkcji. Sprawdzam zgodność komponentów, poprawiam przestarzały kod w motywie potomnym i dopiero wtedy zostawiam nową wersję na produkcji.
Kłódka znika, bo część zasobów wciąż ładuje się po http – najczęściej zdjęcia z bazy danych albo skrypty wpisane na sztywno w szablonie. Porządkuję adresy w bazie danych, ustawiam przekierowania i sprawdzam, czy certyfikat odnawia się automatycznie.
Kiedy strony nie da się przywrócić w rozsądnym czasie, wracam do ostatniej sprawnej kopii zapasowej i dopiero na odzyskanej wersji szukam przyczyny. Ustawiam poprawny harmonogram wykonywania kopii zapasowych.
Błąd 500, 502 albo strona ładująca się minutę bywają problemem hostingu, nie WordPressa: za mały limit pamięci, wyczerpany limit procesów, blokada od reguł bezpieczeństwa serwera. Ustalam to na podstawie logów i przygotowuję dla Ciebie treść zgłoszenia do hostingu.
Pusta strona zamiast treści albo komunikat „wystąpił błąd krytyczny” to zwykle błąd PHP zatrzymujący wykonanie skryptu. Włączam zapis błędów po stronie serwera, czytam log i trafiam do konkretnego pliku, zamiast wyłączać wtyczki po kolei na żywej stronie.
Etapy
Trzy kroki, w tej samej kolejności za każdym razem. Najważniejszy jest pierwszy: kopia zapasowa robiona zanim ktokolwiek dotknie plików.
Opisujesz objaw i to, co zmieniało się na stronie w ostatnich dniach. Zanim wprowadzę jakąkolwiek zmianę, wykonuję kopię plików i bazy danych – również wtedy, gdy strona już nie działa.
Czytam logi błędów serwera i PHP, włączam tryb diagnostyczny, porównuję pliki rdzenia z oryginalnymi i odtwarzam problem na kopii strony. Wyłączanie wtyczek po kolei na produkcji to ostateczność, nie metoda pracy.
Usuwam przyczynę i sprawdzam całą stronę: podstrony, formularze, wyszukiwarkę, panel. Na koniec dostajesz krótkie wyjaśnienie, co się stało i co zrobić, żeby to samo nie wróciło za miesiąc – nawet jeśli nie zdecydujesz się na stałą opiekę.
Start współpracy
Im więcej z tej listy dostanę od razu, tym szybciej zrealizuję naprawę. Najczęściej brakuje dostępu do hostingu – a to właśnie tam znajdują się logi wskazujące przyczynę.
Jeśli nie możesz zalogować się do panelu, wystarczy FTP i dostęp do bazy danych. Z tego poziomu da się wyłączyć wtyczkę blokującą logowanie i wrócić do działającej strony.
Powiązane usługi
Część awarii ma szerszą przyczynę: infekcję, przeciążony serwer albo wieloletni brak aktualizacji. Wtedy sama naprawa nie wystarczy.
Czyszczenie plików i bazy danych, zdjęcie ostrzeżeń Google i zamknięcie luki, przez którą ktoś zaatakował stronę. Z raportem z wykonanych prac.
Cache, obrazy, baza danych i przegląd wtyczek – z pomiarem przed i po. Cel to Core Web Vitals, nie ładna liczba w jednym teście.
Aktualizacje, kopie zapasowe, monitoring dostępności i godziny prac na bieżące zmiany. Trzy pakiety od 200 zł netto miesięcznie.
Jeśli strona przestała działać zaraz po przeprowadzce na nowy serwer, zajrzyj do migracji. Wszystkie usługi serwisowe zebrałem na stronie serwisu WordPress.
FAQ
Odpowiedzi na to, o co klienci pytają w pierwszej wiadomości, zwykle wysyłanej w pośpiechu – o czas, koszt, ryzyko utraty danych i o to, co dzieje się po naprawie.
Typowe usterki – biały ekran, konflikt wtyczek, niedziałający formularz – zamykam w 24 do 48 godzin od otrzymania dostępów. Sama analiza zwykle zajmuje kilka godzin, więc informację o przyczynie i koszcie dostajesz tego samego dnia. Dłużej trwają sprawy, w których trzeba odtworzyć stronę z kopii albo poprawić kod motywu napisanego przez kogoś innego.
Najpierw analiza, potem cena. Sprawdzam logi i odtwarzam problem, a następnie podaję zakres, czas i koszt naprawy – dopiero po Twojej akceptacji zaczynam pracę. Nie ma sytuacji, w której poznajesz kwotę z faktury. Jeśli w trakcie okaże się, że zakres naprawy jest szerszy, zatrzymuję się i wracam z nową wyceną.
Pracę zaczynam od pełnej kopii plików i bazy danych, którą trzymam poza serwerem strony. Zmiany w kodzie wprowadzam w motywie potomnym, żeby nie zniknęły przy najbliższej aktualizacji szablonu. Jeśli naprawa wymaga ingerencji w bazę danych – na przykład podmiany adresów po zmianie domeny – robię osobny zrzut tabel, które będę modyfikował.
Tak, i to częsty scenariusz – panel bywa zablokowany przez wtyczkę bezpieczeństwa, błąd w motywie albo przejęte konto. Wystarczy dostęp FTP lub SSH i baza danych: z tego poziomu da się wyłączyć wtyczkę blokującą logowanie, przywrócić domyślny motyw i założyć nowe konto administratora. Jeśli podejrzewasz, że ktoś przejął stronę, zacznij od usunięcia infekcji, a nie od samego odzyskania hasła.
Opis objawu i adres podstrony, na której widać błąd, wraz ze zrzutami ekranu, konto administratora WordPressa, a gdy panel nie działa – dostęp FTP lub SSH, dane do panelu hostingu, żeby dotrzeć do logów błędów serwera, oraz informacja, co zmieniało się ostatnio: aktualizacja, nowa wtyczka, zmiana wersji PHP, zmiana hostingu. Im więcej z tego dostanę od razu, tym szybciej zrealizuję naprawę.
Na wykonaną naprawę daję 30 dni gwarancji: jeżeli ta sama usterka wraca w tym czasie, zajmuję się nią bez dodatkowej opłaty. Dlatego przy każdym zgłoszeniu szukam przyczyny, a nie tylko sposobu na zgaszenie objawu – opisuję ją w krótkim podsumowaniu razem z tym, co trzeba zrobić, żeby się nie powtórzyła. Nowa, inna awaria jest już osobnym zleceniem.
Dostajesz opis tego, co było zepsute i dlaczego, oraz listę rzeczy, które warto uporządkować, żeby uniknąć kolejnej awarii: wersja PHP, porzucone wtyczki, brak kopii zapasowych. Możesz zająć się nimi samodzielnie albo przejść na stałą opiekę techniczną, w której aktualizacje i kopie zapasowe pilnowane są co tydzień. Nie warunkuję naprawy podpisaniem abonamentu.
