Poradnik dotyczy samodzielnie hostowanych stron WordPress. Zmiany wymagają uprawnień i bezpiecznego wycofania. Jeśli nie znasz plików, baz danych i hostingu, uzgodnij diagnozę z dostawcą lub opiekunem strony.
Zapisz obserwacje
Zapisz URL, dokładny komunikat, pierwszy czas ze strefą i ostatnią zmianę. Porównaj stronę główną, podstronę i logowanie. Dokumentuj próby: pojedynczy nieudany odczyt nie dowodzi pełnej awarii.
Kopia i droga powrotu
Przed zmianami zachowaj w miarę możliwości pliki, bazę i starsze kopie. Sprawdź datę oraz możliwość odtworzenia. Uszkodzona lub zainfekowana kopia może być dowodem; zabezpiecz ją osobno i nie traktuj jako czystej.
Zmieniaj jedną rzecz i powtarzaj tę samą próbę. Rozległe testy wtyczek, motywów i ustawień wykonuj na stagingu. Wyłączenie to nie usunięcie: może dotknąć sklep, formularze i ochronę. Zapisz stan wyjściowy i sposób cofnięcia.
Ukierunkowana diagnoza
01
Wyodrębnij żądanie
Porównaj stronę główną, podstronę, logowanie i konkretną czynność: zapis, upload lub wysłanie. Przed ponawianiem formularza czy zamówienia sprawdź, czy przetwarzanie już zaszło.
02
Przeczytaj właściwy log
Kod 500 nie wskazuje przyczyny. Podaj URL, godzinę, strefę i identyfikator żądania. Plik PHP, pamięć i błędna reguła dają inne tropy. Brak wpisu wymaga sprawdzenia logu lub usługi pośredniej.
03
Sprawdź wtyczki, motyw i PHP
Porównaj początek z aktualizacjami, kodem i wersją PHP. Testuj podejrzany element na kopii. Większy limit pamięci nie wyjaśnia wzrostu zużycia; zbadaj przyczynę i limity.
04
Zachowaj reguły serwera
Błędne .htaccess może wpływać na Apache; sam Nginx nie czyta tego pliku. Ślepa wymiana może usunąć ochronę i przekierowania. Z hostingiem sprawdź konkretną regułę.
05
Sprawdź uprawnienia i zasoby
Właściciele, prawa plików, miejsce i PHP muszą pasować do hostingu. Masowe 777 nie jest naprawą. Po poprawce ponów żądanie i sprawdź inne procesy.
Rozważ przywrócenie
Kopia nie zastępuje ustalenia przyczyny. Sprawdź ją najpierw w izolacji. Odtworzenie może usunąć nowe zamówienia, zapytania i treści. Uzgodnij zakres; po ataku nie przenoś bieżących plików bez weryfikacji.
Sprawdź po korekcie
Sprawdź pierwotny URL, stronę główną, podstrony i logowanie. Formularze oraz sklep testuj w odpowiednim środowisku bez przypadkowych rzeczywistych zamówień. Po poprawce czyść tylko właściwą pamięć podręczną. Zapisz przyczynę i wynik.
Kiedy potrzebna jest pomoc
Przerwij zmiany, gdy przyczyna pozostaje niejasna, powrót jest niepewny lub dotknięto funkcji krytycznych. Ślady malware wymagają analizy bezpieczeństwa. Nie publikuj pełnych logów, haseł, kluczy i linków odzyskiwania.
Uzgodnij zakres i koszty →Opieka po naprawie
Rdzeń WordPress, wtyczki i motywy aktualizujemy co tydzień, aby codzienne zadania nie opóźniały potrzebnych aktualizacji. Co miesiąc, codziennie lub co godzinę: zależnie od pakietu. Kopie są przechowywane na serwerach w UE.
Naprawy i czyszczenie już zhakowanych stron są odrębnymi usługami. Płatne licencje nie są wliczone.