Błędy WordPress - jak naprawić najczęstsze problemy

Otwórz stronę główną, problematyczny adres i panel administracyjny. Sprawdź witrynę również w prywatnym oknie przeglądarki. Jeśli błąd występuje tylko u Ciebie, zacznij od sesji przeglądarki, nie od konfiguracji serwera. Zanotuj ostatnią aktualizację, edycję pliku lub zmianę wersji PHP. Sprawdź komunikaty o awariach u dostawcy hostingu.

Przed ingerencją zachowaj obecne pliki i bazę oraz ustal datę ostatniej działającej kopii. Nie nadpisuj jej nowym backupem. Dokumentacja WordPressa zaleca przechowywanie 3-5 ostatnich kopii w różnych miejscach. Do pełnego odtworzenia typowej instalacji potrzebne są zarówno pliki, jak i baza.

Oficjalny poradnik ujmuje zasadę tak: "Back up your database regularly, and always before an upgrade". Czyli: regularnie twórz kopię bazy, zawsze przed aktualizacją (tłumaczenie własne).

Sprawdź, czy kopię można przywrócić na środowisku testowym WordPress. Staging pozwala odtworzyć usterkę bez zmieniania działającej strony. Jeśli nie masz kopii ani dostępu do plików, przerwij samodzielne zmiany i poproś hosting o pomoc.

Sam komunikat nie zawsze wskazuje przyczynę. Biały ekran może wynikać z różnych błędów, dlatego nie traktuj zwiększenia pamięci czy wyłączenia wszystkich dodatków jako obowiązkowego początku naprawy. WordPress opisuje osobno błędy PHP, połączenia z bazą i problemy hostingu.

Szczegółowe działania serwerowe opisuje poradnik błędu 500. Jeśli strona działa, lecz długo się otwiera, przejdź do diagnostyki wolnego WordPressa. To wymaga pomiarów wydajności.

Recovery Mode jest dostępny od WordPressa 5.2, zgodnie z dokumentacją tej funkcji. Przy niektórych błędach PHP pomaga odzyskać dostęp do kokpitu. Sprawdź skrzynkę administratora oraz spam. Przed otwarciem linku upewnij się, że prowadzi do Twojej witryny.

Po zalogowaniu odczytaj informację o wtyczce lub motywie, którego wykonanie zostało przerwane. Zawieszenie komponentu w tym trybie dotyczy sesji administratora: sam dostęp do panelu nie oznacza, że strona została naprawiona dla odwiedzających. Zapisz komunikat przed kolejnym działaniem.

Brak wiadomości nie wyklucza błędu krytycznego. Jeśli nie możesz wejść do kokpitu, przejdź do logów w panelu hostingu. Nie dopisuj w plikach kodu tworzącego nowe konto administratora.

W panelu hostingu znajdź log błędów PHP lub serwera. Odtwórz problem i porównaj czas żądania z czasem wpisu, uwzględniając strefę czasową. Szukaj komunikatu o przerwanym wykonaniu, nazwy komponentu i miejsca wystąpienia błędu. Samo ostrzeżenie o przestarzałej funkcji nie dowodzi, że powoduje niedostępność witryny.

Jeśli potrzebujesz diagnostyki WordPressa, przygotuj ją na stagingu. Oficjalna dokumentacja debugowania opisuje WP_DEBUG, zapis przez WP_DEBUG_LOG oraz wyłączenie wyświetlania komunikatów przez WP_DEBUG_DISPLAY=false i ustawienie PHP display_errors. Istniejących definicji nie należy dublować. Wartości logiczne true i false pozostają bez apostrofów.

Log może trafić do wp-content/debug.log lub wskazanej, zapisywalnej lokalizacji poza katalogiem publicznym. Wyłączenie wyświetlania błędów nie chroni pliku logu przed pobraniem przez przeglądarkę. Udostępniaj wyłącznie zanonimizowany fragment: bez haseł, tokenów, cookies i danych klientów. Po diagnostyce wyłącz debugowanie. Jeżeli log nie powstaje, zweryfikuj uprawnienia zapisu i log PHP z hostingiem.

Zacznij od dodatku wskazanego w komunikacie albo zmienionego bezpośrednio przed awarią. Jeśli masz panel, wyłącz ten komponent na kopii testowej i ponów czynność wywołującą błąd. Nie usuwaj wtyczki: dezaktywacja i odinstalowanie to różne operacje.

Bez dostępu do kokpitu można przez SFTP lub menedżer plików zmienić nazwę folderu podejrzanej wtyczki. Tę metodę opisuje WordPress w instrukcji Recovery Mode. Zapisz oryginalną nazwę, żeby móc ją przywrócić. Wyłączenie dodatku na produkcji może zatrzymać formularz, płatności lub inną funkcję, nawet jeśli usunie błąd strony.

Powrót działania wskazuje związek z komponentem, ale przyczyną może być jego konflikt z innym dodatkiem. Testuj po jednej zmianie. Motyw zmieniaj dopiero po przygotowaniu sprawnej alternatywy. Gdy test nie pomaga, cofnij go przed następnym, zamiast zostawiać serię nieudokumentowanych zmian.

Baza danych: porównaj jej nazwę, użytkownika i host z konfiguracją dostawcy, szczególnie po migracji. Nie publikuj zawartości wp-config.php. Host bazy nie musi mieć wartości localhost. Przy niedostępności usługi lub przekroczonym limicie poproś hosting o diagnozę. Komunikat o braku połączenia nie uzasadnia naprawiania wszystkich tabel.

Błąd 404: jeśli opublikowana treść istnieje, zapis ustawień bezpośrednich odnośników bez zmiany ich struktury może odświeżyć reguły. Nie kasuj przy tym własnych przekierowań. Dokumentacja Nginx wyjaśnia, że sam Nginx nie korzysta z .htaccess; jego reguły sprawdza administrator serwera.

Logowanie: sprawdź prywatne okno przeglądarki. Dla zapomnianego hasła użyj oficjalnej ścieżki odzyskiwania dostępu. Pętla przekierowań wymaga osobnego sprawdzenia adresów i konfiguracji HTTPS.

Konserwacja: domyślny mechanizm WordPressa uwzględnia znacznik aktualizacji sprzed mniej niż 10 minut. Nie jest to gwarantowany czas zakończenia procesu. Pozostały plik .maintenance usuwaj dopiero po potwierdzeniu, że aktualizacja się zakończyła. Inny komunikat może pochodzić z wtyczki lub cache. Dalsze przygotowanie zmian opisuje poradnik aktualizacji WordPressa.

Cofnięcie plików wtyczki i odtworzenie całej bazy to różne działania. Ustal, czy aktualizacja zmieniła także strukturę danych. Przywrócenie starszej bazy sklepu może nadpisać późniejsze zamówienia, dlatego najpierw zabezpiecz obecny stan i przygotuj plan odtworzenia. Nie kopiuj starej bazy stagingu na produkcję bez sprawdzenia nowych danych.

Po naprawie powtórz pierwotny test, sprawdź stronę główną, logowanie i kluczowe podstrony. Formularze i przepływy zakupowe testuj w przygotowanym środowisku, bez przypadkowych płatności lub wiadomości do klientów. WooCommerce zaleca sprawdzanie między innymi koszyka, checkoutu i płatności.

Na końcu wyjdź z Recovery Mode, sprawdź witrynę jako niezalogowany użytkownik i przejrzyj nowe wpisy w logu. Zapisz, co przywróciło działanie i który komponent nadal wymaga poprawki.

Przerwij samodzielne zmiany, gdy brakuje kopii, nie działa usługa bazy lub PHP, podejrzewasz włamanie albo naprawa grozi nadpisaniem zamówień. Przygotuj adres, czas awarii, komunikat, ostatnią zmianę i listę wykonanych testów. Dołącz zanonimizowany fragment logu oraz informację o kopii.

Możesz sprawdzić zakres pomocy przy WordPressie lub opisać problem przez kontakt. Taki komplet informacji pozwala rozpocząć diagnozę od ustaleń, zamiast ponownie wykonywać przypadkowe próby.

Gdy błędy wynikają z przestarzałej konstrukcji strony, rozważ przebudowę strony firmowej na WordPressie zamiast kolejnych poprawek.

• Błąd strony po przeniesieniu WordPressa: jak znaleźć przyczynę i naprawić problem
• WordPress: jak bezpiecznie zaktualizować bazę danych po aktualizacji
• Błąd 404: co oznacza i jak go naprawić na stronie?
• Wtyczki do zarządzania bazą danych WordPress: porównanie i bezpieczny wybór
• Jak skonfigurować reCAPTCHA w formularzach na stronie
• Jak stworzyć formularz zapisu do newslettera, który zdobywa subskrybentów
• Jak działają formularze popup i jak wykorzystać je na stronie
• Białe znaki na stronie - jak poprawiają czytelność i użyteczność?