Błąd krytyczny WordPress – jak naprawić stronę

Błąd krytyczny WordPress oznacza, że witryna napotkała problem, przez który nie może poprawnie wykonać części kodu. Strona może wyświetlać ogólny komunikat techniczny, biały ekran, błąd 500 albo przestać działać tylko w wybranym miejscu. Czasami niedostępny jest również panel administracyjny.

Taka awaria wygląda poważnie, ale zwykle nie oznacza utraty całej strony. Najczęściej powoduje ją konflikt wtyczek, błąd motywu, niezgodność z wersją PHP, nieudana aktualizacja albo wadliwa zmiana w kodzie. Kluczowe jest ustalenie źródła problemu bez wykonywania wielu przypadkowych zmian jednocześnie.

Poniżej znajdziesz uporządkowaną procedurę naprawy: od sprawdzenia komunikatu i trybu odzyskiwania, przez wyłączenie wtyczek bez dostępu do panelu, aż po analizę logów, przywrócenie kopii oraz kontakt z hostingiem lub wykonawcą strony.

Czym jest błąd krytyczny WordPress?

Błąd krytyczny w WordPressie pojawia się wtedy, gdy system napotyka poważny błąd PHP i nie może dokończyć wykonywania kodu potrzebnego do wyświetlenia strony albo panelu administracyjnego. Zamiast właściwej zawartości użytkownik może zobaczyć komunikat:

„W witrynie wystąpił błąd krytyczny”

W zależności od źródła problemu awaria może obejmować:

całą stronę internetową,
wyłącznie panel /wp-admin,
jedną podstronę lub konkretny szablon,
formularz kontaktowy,
edytor WordPress lub kreator strony,
koszyk i finalizację zamówienia,
wybraną funkcję uruchamianą przez wtyczkę.

Komunikat o błędzie krytycznym nie podaje zwykle dokładnej przyczyny osobie odwiedzającej stronę. Jest to celowe, ponieważ szczegóły błędów PHP mogłyby ujawniać nazwy katalogów, plików i używanych rozszerzeń. Więcej informacji można znaleźć w wiadomości wysłanej do administratora, logach serwera albo pliku debugowania WordPress.

Najczęstsze źródła awarii to:

niezgodna lub uszkodzona wtyczka,
konflikt pomiędzy kilkoma wtyczkami,
błąd aktywnego motywu albo motywu potomnego,
niezgodność kodu z używaną wersją PHP,
nieudana aktualizacja WordPressa, motywu lub dodatku,
błąd wprowadzony w pliku functions.php,
zbyt niski limit pamięci PHP,
uszkodzenie lub brak części plików,
problem po migracji albo zmianie hostingu,
nieautoryzowana modyfikacja kodu lub infekcja strony.

Sam komunikat nie oznacza jeszcze, że baza danych została usunięta albo treści bezpowrotnie utracone. W większości przypadków dane nadal znajdują się na serwerze, a przywrócenie działania strony wymaga odłączenia elementu powodującego błąd lub cofnięcia ostatniej zmiany.

Co zrobić, gdy WordPress wyświetla błąd krytyczny?

Najgorszym rozwiązaniem jest wykonywanie wielu zmian jednocześnie. Jeżeli od razu zaktualizujesz kolejne wtyczki, zmienisz PHP, usuniesz motyw i przywrócisz starą bazę danych, późniejsze ustalenie przyczyny będzie znacznie trudniejsze.

Naprawę warto rozpocząć od zebrania informacji.

1. Sprawdź zakres awarii

Otwórz stronę w oknie prywatnym przeglądarki i sprawdź kilka różnych adresów:

stronę główną,
zwykłą podstronę,
pojedynczy wpis blogowy,
panel /wp-admin,
formularz albo inną ważną funkcję.

Jeśli nie działa tylko jeden adres, problem może dotyczyć konkretnego szablonu, bloku, shortcode’u albo funkcji uruchamianej na tej podstronie. Jeżeli niedostępna jest cała witryna i panel administracyjny, trzeba przejść do diagnostyki przez e-mail administratora, hosting lub pliki serwera.

2. Zapisz komunikat i godzinę wystąpienia błędu

Zrób zrzut ekranu i zanotuj, kiedy problem został zauważony. Informacja o godzinie jest przydatna podczas przeglądania logów serwera. Warto również sprawdzić, czy chwilę wcześniej ktoś:

aktualizował wtyczkę,
instalował nowy dodatek,
zmieniał motyw,
edytował kod,
zmieniał wersję PHP,
przenosił stronę,
przywracał backup,
modyfikował ustawienia hostingu.

Jeżeli błąd wystąpił bezpośrednio po jednej z tych czynności, prawdopodobne źródło problemu jest już znane.

3. Sprawdź skrzynkę administratora

WordPress może wysłać wiadomość na adres przypisany do konta administratora. E-mail często zawiera nazwę wtyczki lub motywu, który spowodował błąd, oraz specjalny link prowadzący do trybu odzyskiwania.

Sprawdź również folder spam. Na starszych stronach wiadomość może trafiać na nieaktualny adres poprzedniego pracownika, wykonawcy albo skrzynkę, do której nikt już nie zagląda.

4. Nie przywracaj od razu starej kopii

Backup jest ważnym zabezpieczeniem, ale jego natychmiastowe przywrócenie nie zawsze jest najlepszym pierwszym krokiem. Jeśli przyczyną jest jedna wadliwa wtyczka, wystarczy ją wyłączyć. Przywrócenie całej bazy może natomiast usunąć nowe wpisy, zgłoszenia z formularzy lub zamówienia.

Przed większymi zmianami warto wykonać dodatkową kopię aktualnego, nawet niedziałającego stanu. Dzięki temu zachowasz najnowsze dane i pliki potrzebne do dalszej diagnozy.

Jak działa tryb odzyskiwania WordPress?

Tryb odzyskiwania WordPress, nazywany czasem trybem awaryjnym, umożliwia zalogowanie się do panelu mimo wykrycia błędu PHP. System tymczasowo wstrzymuje problematyczny element dla sesji administratora, dzięki czemu można wejść do kokpitu i podjąć działania naprawcze.

Link odzyskiwania jest indywidualny i ograniczony czasowo. Po jego otwarciu WordPress może wyświetlić informację, która wtyczka lub część motywu została zatrzymana.

Po wejściu do panelu należy:

sprawdzić powiadomienie o wykrytym błędzie,
zanotować nazwę problematycznej wtyczki albo motywu,
wyłączyć wskazany element,
sprawdzić, czy strona ponownie działa,
ustalić, czy dostępna jest poprawiona wersja,
sprawdzić zgodność dodatku z WordPressem i PHP,
nie włączać ponownie wadliwego elementu bez testu.

Tryb odzyskiwania nie usuwa źródła problemu automatycznie. Daje jedynie dostęp do panelu w warunkach, w których zwykłe logowanie może być niemożliwe. Po odzyskaniu dostępu nadal trzeba ustalić, dlaczego konkretny element powoduje błąd.

Co zrobić, gdy wiadomość z linkiem nie dociera?

Brak e-maila nie oznacza, że strony nie da się naprawić. W takim przypadku pozostają inne metody:

wyłączenie wtyczki przez FTP lub menedżer plików,
sprawdzenie logów w panelu hostingu,
zmiana wersji PHP, jeśli awaria pojawiła się po jej przełączeniu,
przywrócenie konkretnego pliku lub katalogu,
kontakt z hostingiem albo wykonawcą strony.

Po odzyskaniu panelu warto zaktualizować adres administratora i upewnić się, że WordPress prawidłowo wysyła wiadomości systemowe.

Jak wyłączyć wtyczki bez dostępu do panelu?

Konflikt wtyczek jest jedną z najczęstszych przyczyn błędu krytycznego WordPress. Problem może pojawić się po aktualizacji dodatku, instalacji nowej wtyczki albo zmianie wersji PHP.

Na problem z wtyczką wskazują między innymi:

awaria bezpośrednio po jej aktualizacji,
nazwa dodatku podana w wiadomości WordPressa,
ścieżka wp-content/plugins/ widoczna w logu,
błąd dotyczący funkcji obsługiwanej przez konkretną wtyczkę,
powrót działania strony po wyłączeniu wszystkich dodatków.

Jeżeli panel administracyjny jest dostępny, podejrzaną wtyczkę można po prostu dezaktywować. Gdy panel nie działa, potrzebny będzie dostęp do plików strony przez FTP, SFTP albo menedżer plików dostępny na hostingu.

Wyłączenie jednej podejrzanej wtyczki

Katalogi wtyczek znajdują się standardowo pod adresem:

wp-content/plugins/

Aby wyłączyć konkretną wtyczkę:

otwórz katalog wp-content/plugins/,
znajdź folder problematycznego dodatku,
zmień nazwę katalogu, dodając na końcu na przykład -off,
odśwież stronę i panel administracyjny,
sprawdź, czy komunikat zniknął.

Przykładowa zmiana:

nazwa-wtyczki
nazwa-wtyczki-off

WordPress przestanie ładować dodatek, ponieważ nie znajdzie go pod zapisaną wcześniej ścieżką. Pliki wtyczki nie zostaną usunięte.

Wyłączenie wszystkich wtyczek

Jeżeli nie wiadomo, który dodatek powoduje problem, można tymczasowo zmienić nazwę całego katalogu:

wp-content/plugins
wp-content/plugins-off

Po tej zmianie wszystkie wtyczki zostaną wyłączone. Jeżeli strona zacznie działać, przyczyną prawdopodobnie jest jeden z dodatków albo konflikt pomiędzy nimi.

Następnie należy:

przywrócić nazwę katalogu plugins,
zalogować się do panelu,
aktywować wtyczki pojedynczo,
po każdej aktywacji sprawdzać stronę,
zatrzymać test po ponownym wystąpieniu błędu.

Na stronie produkcyjnej takie działania trzeba wykonywać ostrożnie. Tymczasowe wyłączenie wszystkich wtyczek może zatrzymać formularze, system cache, przekierowania, płatności, wysyłkę wiadomości oraz inne ważne funkcje.

Diagnozowanie błędu krytycznego WordPress na komputerze

Czy motyw może powodować błąd krytyczny?

Aktywny motyw również wykonuje kod PHP, dlatego może spowodować błąd krytyczny witryny. Ryzyko jest większe w przypadku starych motywów, ręcznie modyfikowanych szablonów, wygasłej licencji albo dodatków nierozwijanych od dłuższego czasu.

Źródłem problemu może być zarówno motyw główny, jak i motyw potomny. Częstą przyczyną jest błąd w pliku functions.php, do którego został dodany własny fragment kodu.

Na problem z motywem może wskazywać:

ścieżka wp-content/themes/ w logu błędów,
awaria po aktualizacji motywu,
błąd po edycji pliku functions.php,
problem widoczny tylko na określonym typie podstrony,
awaria po aktualizacji kreatora powiązanego z motywem,
błąd po zmianie wersji PHP.

Jednym z testów jest tymczasowe przełączenie strony na domyślny motyw WordPress. Najbezpieczniej wykonać to na kopii testowej, ponieważ zmiana aktywnego motywu może całkowicie zmienić wygląd witryny.

Jeśli po przełączeniu strona zacznie działać, trzeba sprawdzić:

czy motyw ma aktualną wersję,
czy jest zgodny z używanym PHP,
czy zmodyfikowane pliki nie zawierają błędu,
czy problem nie dotyczy motywu potomnego,
czy wymagane wtyczki motywu są zgodne z jego wersją.

Nie należy od razu usuwać aktywnego motywu. Może on zawierać własne szablony, konfigurację oraz kod potrzebny do poprawnego wyświetlania strony.

Jak wersja PHP wpływa na działanie strony?

WordPress, motywy i wtyczki działają w środowisku PHP. Jeśli jeden z tych elementów wykorzystuje funkcje niedostępne w wybranej wersji języka, może pojawić się błąd krytyczny.

Typowe scenariusze to:

hosting automatycznie przełączył stronę na nowsze PHP,
właściciel zmienił PHP ręcznie w panelu serwera,
nowa wtyczka wymaga nowszego środowiska,
stary motyw nie obsługuje aktualnej wersji PHP,
strona została przeniesiona na serwer z inną konfiguracją,
niestandardowy kod korzysta z przestarzałych funkcji.

Jeżeli błąd pojawił się bezpośrednio po zmianie PHP, można tymczasowo powrócić do poprzedniej wersji i sprawdzić, czy strona zacznie działać. Nie jest to jednak rozwiązanie długoterminowe, szczególnie gdy poprzednie PHP nie jest już wspierane.

Po przywróceniu strony trzeba ustalić, który element nie jest zgodny z docelową wersją środowiska. Rozwiązaniem może być:

aktualizacja motywu,
aktualizacja wtyczki,
wymiana porzuconego dodatku,
poprawienie własnego kodu,
aktualizacja całej instalacji etapami,
wykonanie testów na środowisku stagingowym.

Więcej informacji o środowisku serwera znajdziesz w poradniku dotyczącym wyboru hostingu pod WordPress.

Jak włączyć debugowanie WordPress?

Debugowanie WordPress pomaga ustalić rzeczywiste źródło awarii. Ogólny komunikat widoczny na stronie informuje jedynie, że wystąpił problem. Log może natomiast wskazać konkretny plik, funkcję i linię kodu.

Informacje o błędach można znaleźć w:

logach PHP w panelu hostingu,
pliku error_log,
logach serwera,
pliku debugowania WordPress,
wiadomości wysłanej na adres administratora.

Aby włączyć tryb debugowania WordPress, należy edytować plik wp-config.php znajdujący się w głównym katalogu instalacji. Przed zmianą wykonaj kopię pliku.

Podstawowa konfiguracja może wyglądać następująco:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Przy takich ustawieniach szczegóły nie powinny być publicznie wyświetlane użytkownikom. Błędy są zapisywane zwykle w pliku:

wp-content/debug.log

W logu należy szukać najnowszych wpisów oraz ścieżek prowadzących do katalogów:

wp-content/plugins/
wp-content/themes/

Przykładowo ścieżka prowadząca do pliku określonej wtyczki może wskazywać, że to ona wywołuje błąd. Nie każdy wpis w logu jest jednak błędem krytycznym. Ostrzeżenia i komunikaty przestarzałych funkcji nie zawsze zatrzymują działanie strony.

Po zakończeniu diagnozy tryb debugowania należy wyłączyć:

define( 'WP_DEBUG', false );

Pozostawienie aktywnego logowania na długo może powodować szybki wzrost pliku, a publiczne wyświetlanie błędów ujawniałoby informacje techniczne o witrynie.

Kiedy przywrócić kopię zapasową?

Kopia zapasowa jest jednym z najważniejszych zabezpieczeń strony, ale jej przywrócenie powinno być przemyślane. Nie każda awaria wymaga cofnięcia całej instalacji.

Przywrócenie backupu ma sens szczególnie wtedy, gdy:

awaria pojawiła się po większej aktualizacji,
uszkodzono wiele plików,
nie da się ustalić zakresu zmian,
problem wystąpił po nieudanej migracji,
strona została zainfekowana lub nieautoryzowanie zmodyfikowana,
wtyczki i motyw nie są jedynym źródłem problemu,
istnieje sprawdzona kopia wykonana tuż przed awarią.

Przed przywróceniem sprawdź:

datę wykonania kopii,
czy obejmuje pliki oraz bazę danych,
czy została wcześniej przetestowana,
jakie dane powstały po jej wykonaniu,
czy można ją najpierw odtworzyć na stagingu,
czy hosting ma również nowszą kopię.

Jeśli problem powoduje jedna wtyczka, lepiej ją tymczasowo wyłączyć niż cofać całą witrynę. Przywrócenie starej bazy danych może usunąć najnowsze formularze, zmiany treści, konta użytkowników albo zamówienia.

Dokładny proces wykonywania i sprawdzania kopii opisuje osobny poradnik o tym, jak przygotować backup WordPress.

Naprawa błędu krytycznego WordPress na stronie internetowej

Kiedy skontaktować się z hostingiem lub wykonawcą?

Hosting i wykonawca strony odpowiadają za inne obszary. Pomoc techniczna serwera może sprawdzić infrastrukturę, logi, PHP i dostępne kopie. Wykonawca WordPressa zajmuje się natomiast kodem strony, motywem, wtyczkami oraz integracjami.

Kiedy napisać do hostingu?

Kontakt z hostingiem jest uzasadniony, gdy:

strona pokazuje błąd 500,
nie działa dostęp FTP lub panel serwera,
nie możesz sprawdzić logów,
potrzebujesz kopii przechowywanej przez hosting,
nie możesz zmienić wersji PHP,
występuje problem z limitem pamięci,
awaria pojawiła się po zmianach na serwerze,
kilka stron na tym samym koncie przestało działać,
podejrzewasz awarię infrastruktury.

W zgłoszeniu podaj adres witryny, godzinę wystąpienia problemu, treść komunikatu oraz informację o ostatnich zmianach. Poproś o sprawdzenie najnowszych błędów PHP i potwierdzenie, czy serwer działa prawidłowo.

Kiedy skontaktować się z wykonawcą?

Pomoc osoby znającej WordPress jest szczególnie potrzebna, gdy:

log wskazuje plik motywu lub wtyczki,
strona zawiera niestandardowy kod,
awaria dotyczy sklepu lub systemu rezerwacji,
nie masz pewnej kopii zapasowej,
nie wiesz, jakie zmiany można bezpiecznie cofnąć,
strona generuje zapytania i każda godzina przestoju powoduje straty,
problem powraca po ponownym włączeniu dodatku,
podejrzewasz infekcję albo zmianę plików.

Przy stałej opiece nad stroną WordPress diagnoza jest zwykle szybsza, ponieważ osoba techniczna zna używane rozszerzenia, historię zmian, konfigurację serwera i system kopii zapasowych.

Co zrobić, gdy błąd pojawił się po aktualizacji?

Jeżeli WordPress nie działa po aktualizacji, najważniejsze jest ustalenie, który element został zmieniony bezpośrednio przed awarią. Mogła to być aktualizacja:

rdzenia WordPressa,
jednej wtyczki,
kilku wtyczek jednocześnie,
aktywnego motywu,
WooCommerce,
kreatora strony,
integracji płatności lub dostawy.

Jeśli aktualizowano tylko jeden dodatek, diagnostyka jest stosunkowo prosta. Wtyczkę można wyłączyć i sprawdzić, czy witryna zacznie działać. Następnie trzeba ustalić, czy:

dostępna jest poprawiona wersja,
aktualizacja wymaga nowszego PHP,
dodatek nadal jest zgodny z WordPressem,
można bezpiecznie wrócić do poprzedniej wersji,
wtyczkę należy zastąpić innym rozwiązaniem.

Jeśli jednocześnie zaktualizowano wiele elementów, diagnoza jest trudniejsza. Trzeba analizować logi albo wyłączać dodatki etapami. To jeden z powodów, dla których bezpieczna aktualizacja WordPress powinna być wykonywana po utworzeniu kopii, najlepiej pojedynczo i z testem po każdym ważnym kroku.

Po przywróceniu działania nie należy ponownie klikać wszystkich aktualizacji bez przygotowania. Najpierw trzeba sprawdzić zgodność środowiska, wykonać backup i odtworzyć problem na kopii testowej.

Jak reagować na błąd krytyczny WooCommerce?

W sklepie internetowym błąd krytyczny wymaga szybkiej reakcji, ponieważ może zatrzymać sprzedaż. Jednocześnie nie wolno działać pochopnie, szczególnie przy przywracaniu bazy danych zawierającej zamówienia.

Najpierw sprawdź, czy działają:

strona główna sklepu,
kategorie produktów,
karty produktów,
dodawanie do koszyka,
koszyk,
checkout,
bramki płatności,
metody dostawy,
zapisywanie nowych zamówień,
wiadomości transakcyjne.

W WooCommerce awarię mogą powodować między innymi:

aktualizacja samego WooCommerce,
stare szablony sklepu zapisane w motywie,
niezgodna bramka płatności,
konflikt wtyczki dostawy,
wtyczka cache,
zewnętrzna integracja magazynowa lub księgowa,
zmiana wersji PHP,
zbyt niski limit pamięci.

Przywrócenie starszej bazy może usunąć zamówienia złożone po wykonaniu kopii. Jeżeli sklep zdążył przyjąć transakcje przed całkowitą awarią, naprawę i odtwarzanie danych najlepiej powierzyć osobie technicznej.

Jak ograniczyć ryzyko kolejnych awarii?

Nie da się całkowicie wyeliminować ryzyka błędu krytycznego, ale można znacząco zmniejszyć prawdopodobieństwo jego wystąpienia i skrócić czas potrzebny na przywrócenie witryny.

Wykonuj regularne i sprawdzane kopie

Backup powinien obejmować zarówno pliki, jak i bazę danych. Sama informacja, że „kopia jest robiona”, nie wystarcza. Trzeba również wiedzieć, gdzie jest przechowywana, jak długo pozostaje dostępna i czy można ją skutecznie odtworzyć.

Aktualizuj stronę etapami

Zamiast aktualizować jednocześnie WordPress, motyw i kilkanaście wtyczek, lepiej podzielić zmiany na etapy. Po każdej ważnej aktualizacji trzeba sprawdzić stronę, panel, formularze i inne kluczowe funkcje.

Testuj większe zmiany na stagingu

Środowisko testowe pozwala sprawdzić nowe wersje PHP, aktualizacje i zmiany kodu bez ryzyka wyłączenia publicznej witryny. Jest szczególnie ważne przy sklepach, stronach z niestandardowymi funkcjami i starszych instalacjach.

Usuwaj nieużywane wtyczki i motywy

Nieaktywne dodatki również zajmują miejsce i mogą zawierać luki bezpieczeństwa. Im więcej rozszerzeń, tym większe ryzyko konfliktów oraz trudniejsza późniejsza diagnoza.

Nie korzystaj z porzuconych dodatków

Wtyczka, która od dawna nie otrzymuje aktualizacji, może działać poprawnie do momentu zmiany WordPressa lub PHP. Później staje się częstym źródłem błędów.

Zabezpiecz wszystkie dostępy

Właściciel strony powinien posiadać aktualny dostęp do:

panelu WordPress,
hostingu,
FTP lub SFTP,
domeny,
bazy danych,
kopii zapasowych,
skrzynki administratora.

Bez tych danych nawet prosty błąd może spowodować dłuższy przestój. Warto również wdrożyć podstawowe zasady opisane w poradniku dotyczącym bezpieczeństwa WordPress.

Regularna administracja generuje koszty, ale ogranicza ryzyko długiej awarii i konieczności kosztownej naprawy zaniedbanej instalacji. Szerzej ten temat omawia artykuł o koszcie utrzymania strony internetowej.

Checklista naprawy błędu krytycznego

Gdy strona WordPress nie działa, wykonuj działania w poniższej kolejności.

Rozpoznanie problemu

Sprawdź stronę główną, podstrony i panel administracyjny.
Zapisz dokładny komunikat błędu.
Zanotuj godzinę wystąpienia awarii.
Ustal, co zmieniono bezpośrednio przed problemem.
Sprawdź e-mail administratora i folder spam.

Zabezpieczenie danych

Sprawdź dostępne kopie zapasowe.
Ustal, czy backup obejmuje pliki oraz bazę danych.
Przed większą ingerencją wykonaj kopię aktualnego stanu.
Nie przywracaj starej bazy bez sprawdzenia nowych danych.
W sklepie zweryfikuj, czy nie pojawiły się nowe zamówienia.

Wtyczki i motyw

Sprawdź, czy błąd pojawił się po aktualizacji dodatku.
Poszukaj ścieżki wp-content/plugins/ w logach.
Wyłącz podejrzaną wtyczkę przez panel albo FTP.
Jeśli to konieczne, tymczasowo wyłącz wszystkie wtyczki.
Sprawdź ścieżki prowadzące do katalogu motywu.
Zweryfikuj ostatnie zmiany w functions.php.

PHP i serwer

Sprawdź, czy zmieniano wersję PHP.
Jeśli awaria wystąpiła po zmianie, przetestuj poprzednią wersję.
Sprawdź limit pamięci PHP.
Odczytaj najnowsze logi serwera.
Zapytaj hosting o ostatnie zmiany i dostępne kopie.

Przywrócenie działania

Wyłącz element powodujący błąd.
Sprawdź stronę po każdej zmianie.
Nie aktywuj ponownie problematycznej wtyczki bez testu.
Przywracaj backup dopiero po ocenie konsekwencji.
Po naprawie sprawdź formularze, panel i kluczowe funkcje.
Wyłącz debugowanie po zakończeniu diagnozy.

Najczęściej zadawane pytania

Co oznacza komunikat „W witrynie wystąpił błąd krytyczny”?

Komunikat oznacza, że WordPress napotkał poważny błąd PHP i nie może poprawnie wykonać części kodu. Przyczyną najczęściej jest wtyczka, motyw, aktualizacja, wersja PHP albo własna modyfikacja.

Czy błąd krytyczny WordPress oznacza utratę strony?

Zwykle nie. Pliki i baza danych najczęściej nadal znajdują się na serwerze. Trzeba odnaleźć element powodujący błąd i wyłączyć go, poprawić albo przywrócić jego wcześniejszą wersję.

Czy błąd krytyczny oznacza włamanie?

Nie musi. Znacznie częściej jest skutkiem konfliktu technicznego. Infekcja również może powodować awarię, dlatego przy podejrzanych zmianach plików warto przeprowadzić kontrolę bezpieczeństwa.

Jak naprawić błąd krytyczny WordPress bez dostępu do panelu?

Można użyć linku trybu odzyskiwania, wyłączyć wtyczkę przez FTP lub menedżer plików, sprawdzić logi hostingu, cofnąć zmianę PHP albo skontaktować się z wykonawcą.

Jak wyłączyć wszystkie wtyczki bez logowania do WordPressa?

W katalogu wp-content należy tymczasowo zmienić nazwę folderu plugins. WordPress przestanie ładować wszystkie dodatki. Po sprawdzeniu strony można przywrócić nazwę katalogu i aktywować wtyczki pojedynczo.

Czy zmiana wersji PHP może naprawić stronę?

Tak, jeśli błąd pojawił się po przełączeniu PHP i wynika z niezgodności motywu albo wtyczki. Powrót do poprzedniej wersji może tymczasowo przywrócić działanie, ale później trzeba zaktualizować lub wymienić niezgodny element.

Gdzie znajduje się plik z błędami WordPress?

Po włączeniu WP_DEBUG_LOG komunikaty są zwykle zapisywane w pliku wp-content/debug.log. Hosting może również udostępniać własne logi PHP i serwera.

Czy zawsze trzeba przywracać backup?

Nie. Jeśli problem powoduje jedna wtyczka, zazwyczaj wystarczy ją wyłączyć. Backup jest potrzebny głównie przy rozległych uszkodzeniach, nieudanej migracji, infekcji albo braku możliwości cofnięcia zmian w inny sposób.

Kiedy najlepiej skontaktować się z wykonawcą strony?

Gdy strona jest ważna biznesowo, nie masz aktualnej kopii, awaria dotyczy sklepu, log wskazuje własny kod albo nie masz doświadczenia w pracy z FTP, PHP i bazą danych.

Jak uniknąć błędu krytycznego po aktualizacji?

Przed aktualizacją należy wykonać backup, sprawdzić zgodność rozszerzeń, aktualizować elementy etapami i testować stronę po każdej zmianie. Większe aktualizacje najlepiej najpierw przeprowadzić na stagingu.

Podsumowanie

Błąd krytyczny WordPress najczęściej wynika z konfliktu wtyczek, problemu z motywem, niezgodności PHP, aktualizacji albo wadliwego fragmentu kodu. Nie oznacza automatycznie utraty strony, ale wymaga uporządkowanej diagnozy.

Najpierw sprawdź zakres awarii, zapisz komunikat, ustal ostatnie zmiany i odszukaj wiadomość administratora. Jeżeli dostępny jest tryb odzyskiwania WordPress, wykorzystaj go do wejścia do panelu i wyłączenia problematycznego elementu.

Bez dostępu do panelu wtyczki można wyłączyć przez FTP lub menedżer plików. Kolejne kroki to sprawdzenie motywu, wersji PHP, logów oraz kopii zapasowej. Każdą zmianę wykonuj osobno i po każdym etapie sprawdzaj działanie strony.

Po przywróceniu witryny warto poprawić proces aktualizacji, skonfigurować regularne backupy, usunąć zbędne rozszerzenia i kontrolować zgodność PHP. Dzięki temu kolejny problem będzie łatwiejszy do wykrycia, a czas niedostępności strony znacznie krótszy.

Błąd krytyczny WordPress – co zrobić, gdy strona przestaje działać?