Co zrobić w pierwszych 10 minutach, gdy strona pokazuje błąd krytyczny?
W pierwszych minutach nie naprawiaj niczego. Zabezpiecz obecny stan i zbierz informacje, bo każda zmiana wykonana na oślep zaciera ślad po przyczynie. Kolejność, która realnie skraca naprawę, wygląda tak:
Zapisz dokładną godzinę awarii. Będzie potrzebna do filtrowania logów serwera, gdzie wpisów bywa kilkaset na minutę.
Sprawdź stronę w trybie prywatnym przeglądarki. Czasem widzisz zbuforowaną wersję błędu, choć witryna już działa poprawnie.
Ustal zasięg awarii. Sprawdź osobno stronę główną, dowolną podstronę i adres /wp-admin. Jeśli front działa, a kokpit nie, przyczyna leży zwykle w kodzie ładowanym tylko w panelu.
Zrób kopię bieżącego stanu plików i bazy. Nawet uszkodzona witryna zawiera dane nowsze niż Twój ostatni backup.
Sprawdź skrzynkę administratora. Wiadomość od WordPressa potrafi wskazać nazwę wtyczki i plik, w którym wystąpił błąd.
Przypomnij sobie, co zmieniło się przed awarią. Aktualizacja wtyczki, zmiana wersji PHP, wklejony snippet, migracja.
Punkt czwarty bywa pomijany i to on najczęściej kosztuje najwięcej. Jeżeli naprawę zaczniesz od przywrócenia backupu sprzed trzech dni, stracisz zamówienia, komentarze i wiadomości z formularzy z tego okresu, a przyczyna awarii i tak pozostanie nieznana.
Zanim cokolwiek wyłączę, kopiuję wp-config.php i plik .htaccess na dysk lokalny pod inną nazwą. To dwa pliki, w których jedna literówka blokuje całą witrynę, a ich odtworzenie z pamięci przy działającym SSL i niestandardowych przekierowaniach potrafi zająć więcej czasu niż sama naprawa.
Co dokładnie oznacza komunikat „w witrynie wystąpił błąd krytyczny”?
To komunikat wbudowanego mechanizmu ochrony przed błędami krytycznymi, który trafił do rdzenia w WordPressie 5.2. Zgodnie z dokumentacją deweloperską na make.wordpress.org system przechwytuje fatal error PHP, zatrzymuje renderowanie strony i zamiast surowej treści błędu pokazuje odwiedzającym neutralny ekran. Dzięki temu nikt postronny nie zobaczy ścieżek do plików ani fragmentów kodu.
Warto rozróżnić dwa objawy, które użytkownicy nazywają tak samo. Komunikat o błędzie krytycznym oznacza, że WordPress zdążył się załadować i przejął kontrolę nad błędem. Biały ekran śmierci bez żadnego tekstu oznacza zwykle, że awaria nastąpiła wcześniej, na przykład w wp-config.php, albo że obsługa błędów została wyłączona stałą WP_DISABLE_FATAL_ERROR_HANDLER. To rozróżnienie zawęża poszukiwania, zanim jeszcze zajrzysz do logów.
Dla SEO istotny jest kod odpowiedzi, a nie sam napis. Strona z błędem krytycznym zwraca zwykle status 500. Dokumentacja Google Search Central dotycząca błędów serwera wskazuje, że krótkie awarie nie powodują trwałych konsekwencji, natomiast utrzymujące się odpowiedzi 5xx prowadzą do ograniczania indeksowania i usuwania adresów z wyników. Innymi słowy: liczy się czas naprawy, nie jednorazowe zdarzenie.
Jak wejść w tryb odzyskiwania WordPress bez e-maila od systemu?
Uczciwa odpowiedź brzmi: bez linku z wiadomości nie wejdziesz. Tryb odzyskiwania otwiera się wyłącznie podpisanym kluczem, który WordPress generuje i wysyła na adres administratora, a sam adres /wp-login.php?action=entered_recovery_mode bez tego klucza odmówi dostępu. To dlatego poradniki obiecujące wejście w tryb awaryjny WordPress jednym adresem URL kończą się rozczarowaniem.
Jeśli wiadomość nie dotarła, przyczyna jest zwykle jedna z czterech:
Serwer nie wysyła poczty. Funkcja wp_mail bywa zablokowana na hostingu albo wiadomość ląduje w spamie.
Adres administratora już nie istnieje. Typowe po zmianie wykonawcy strony lub likwidacji skrzynki.
Zadziałał limit wysyłki. W kodzie rdzenia WordPressa wiadomość o trybie odzyskiwania jest ograniczona czasowo, domyślnie do jednej na dobę, a ważność samego linku też jest limitowana. Przy powtarzającej się awarii drugi e-mail po prostu nie przyjdzie.
Obsługa błędów jest wyłączona. Jeżeli ktoś ustawił WP_DISABLE_FATAL_ERROR_HANDLER na true, mechanizm nie uruchomi się wcale.
Są dwa wyjścia. Pierwsze: dopisz w wp-config.php stałą RECOVERY_MODE_EMAIL ze swoim adresem, wywołaj błąd ponownie i poczekaj na wiadomość. Drugie, szybsze: pomiń tryb odzyskiwania i napraw stronę przez FTP, bo i tak sprowadza się to do wyłączenia tego samego komponentu.
Jest też niuans, który warto znać, zanim ucieszysz się z działającego panelu. Tryb odzyskiwania pauzuje wadliwe wtyczki i motywy tylko dla Twojej sesji. Dla odwiedzających witryna nadal pokazuje błąd krytyczny. To narzędzie diagnostyczne, a nie naprawa.
Jak włączyć tryb debugowania i odczytać plik debug.log?
Tryb debugowania WordPress włącza się trzema stałymi w pliku wp-config.php, dopisanymi przed komentarzem informującym o końcu edycji pliku. Na stronie produkcyjnej używaj wyłącznie tego zestawu:
define( 'WP_DEBUG', true );uruchamia raportowanie błędów.define( 'WP_DEBUG_LOG', true );zapisuje je do pliku wp-content/debug.log.define( 'WP_DEBUG_DISPLAY', false );ukrywa komunikaty przed odwiedzającymi.
Po zapisaniu pliku odśwież stronę z błędem i dopiero wtedy otwórz log. Kolejność ma znaczenie, bo plik powstaje w momencie pierwszego błędu po włączeniu zapisu.
Dwie rzeczy, o których większość poradników milczy. Po pierwsze, w WordPressie 5.2 i nowszych widok szczegółowego błędu na ekranie bywa przesłonięty przez mechanizm ochrony, więc na maszynie deweloperskiej trzeba go wyłączyć stałą WP_DISABLE_FATAL_ERROR_HANDLER, żeby zobaczyć surowy komunikat. Po drugie, plik debug.log leży w katalogu wp-content i przy typowej konfiguracji serwera bywa dostępny publicznie pod adresem. Po zakończonej diagnozie usuń go i wyłącz debugowanie, bo zawiera ścieżki serwerowe i nazwy komponentów.
Które wpisy w logu oznaczają realną awarię, a które można zignorować
Zatrzymanie strony powodują wyłącznie błędy krytyczne. Reszta wpisów to szum, który w logu potrafi istnieć od miesięcy i nie ma związku z awarią.
|
Wpis w logu |
Co oznacza |
Czy zatrzymuje stronę |
|---|---|---|
|
Fatal error |
Wywołanie nieistniejącej funkcji, klasy lub pliku |
Tak |
|
Parse error / syntax error |
Błąd składni, zwykle po ręcznej edycji kodu |
Tak |
|
Uncaught Error / Uncaught Exception |
Nieobsłużony wyjątek, częsty przy niezgodności z nową wersją PHP |
Tak |
|
Warning |
Ostrzeżenie, kod wykonuje się dalej |
Nie |
|
Notice / Deprecated |
Przestarzała funkcja lub niezdefiniowana zmienna |
Nie |
Praktyczna zasada przy czytaniu logu: szukaj ostatniego wpisu typu Fatal error ze znacznikiem czasu zgodnym z momentem awarii. Ścieżka w tym wpisie wskazuje winowajcę. Jeżeli zawiera wp-content/plugins/nazwa, masz konflikt wtyczki. Jeżeli wp-content/themes/nazwa, problem leży w motywie. Jeżeli ścieżka prowadzi do katalogu wp-includes lub wp-admin, przyczyną bywa niekompletny rdzeń, a nie dodatek.
Kiedy debug.log nic nie pokazuje i trzeba sięgnąć po logi serwera
Pusty debug.log oznacza zwykle, że awaria nastąpiła zanim WordPress zdążył wczytać własną obsługę błędów. W takiej sytuacji jedynym źródłem informacji są logi serwera, dostępne w panelu hostingu w sekcji z błędami PHP lub w katalogu logs na koncie FTP.
Typowe sytuacje, w których log WordPressa milczy:
Błąd składni w wp-config.php. Plik ładuje się jako pierwszy, więc nic nie zdąży się zapisać.
Uszkodzony .htaccess. Serwer zwraca 500 jeszcze przed uruchomieniem PHP.
Przekroczony limit pamięci lub czasu wykonania. Proces jest ubijany, a zapis do pliku nie następuje.
Brak prawa zapisu w katalogu wp-content. Log po prostu nie powstaje.
Jak sprawdzić logi serwera z sensem: filtruj po godzinie awarii i szukaj pierwszego wpisu z tej minuty, a nie ostatniego z całego dnia. Przy powtarzalnym błędzie ten sam komunikat pojawia się przy każdym wejściu na stronę, więc łatwo pomylić wpis sprzed godziny z aktualnym.
Jak wyłączyć wtyczki przez FTP, gdy kokpit jest zablokowany?
Najszybsza metoda to zmiana nazwy katalogu wp-content/plugins na przykład na plugins-off. WordPress nie znajdzie rozszerzeń i dezaktywuje je wszystkie naraz, a Twoje dane i ustawienia zostaną w bazie. Jeżeli strona wróci, masz potwierdzenie, że za awarię odpowiada jedna z wtyczek.
Dalej pracuj metodycznie. Przywróć pierwotną nazwę katalogu, zaloguj się do panelu i włączaj rozszerzenia pojedynczo, sprawdzając witrynę po każdej aktywacji. Jeżeli podejrzewasz konkretny dodatek, nie ruszaj całego katalogu, tylko zmień nazwę jednego folderu wtyczki.
Trzy rzeczy, które zaskakują przy tej metodzie:
Po przywróceniu nazwy katalogu wtyczki pozostają nieaktywne. Trzeba je włączyć ręcznie, co przy kilkudziesięciu dodatkach bywa czasochłonne.
Konflikty między wtyczkami nie zawsze ujawniają się od razu. Czasem błąd wraca dopiero po aktywacji drugiego rozszerzenia z pary, więc testuj także podstrony, koszyk i formularze.
Bez dostępu do FTP zostaje baza danych. W tabeli wp_options, w rekordzie active_plugins, wartość a:0:{} wyłącza wszystkie wtyczki. Przed zmianą skopiuj dotychczasową wartość, bo to Twoja jedyna lista aktywnych dodatków.
Nigdy nie usuwaj katalogu wtyczki zamiast zmieniać jego nazwę. Usunięcie kasuje także pliki konfiguracyjne i szablony, które niektóre rozszerzenia trzymają we własnym folderze.
Jak sprawdzić, czy winny jest motyw, a nie wtyczka?
Test jest analogiczny: zmień nazwę katalogu aktywnego motywu w wp-content/themes. WordPress przełączy się wtedy na motyw domyślny, ale tylko wtedy, gdy taki motyw jest zainstalowany na serwerze. Jeśli go nie ma, zobaczysz kolejny komunikat o błędzie i niepotrzebnie uznasz test za nieudany.
Dlatego warto trzymać na stronie jeden nieużywany motyw z rodziny Twenty, nawet jeżeli nigdy go nie włączysz. To jedyna awaryjna ścieżka powrotu do panelu, gdy szablon odmówi współpracy.
Najczęstsze źródła błędu krytycznego po stronie motywu to plik functions.php, wklejony snippet i aktualizacja szablonu wykonana bez motywu potomnego. Jeżeli zmiany wprowadzałeś ręcznie, zacznij od przywrócenia poprzedniej wersji tego pliku, bo cofnięcie zmian w WordPressie jest szybsze niż szukanie brakującego nawiasu.
Zanim przełączysz motyw, miej świadomość skutku ubocznego. Przypisania menu i rozmieszczenie widgetów są powiązane z konkretnym szablonem. Po powrocie do swojego motywu zwykle wracają, ale jeżeli w międzyczasie zapiszesz ustawienia na motywie domyślnym, część konfiguracji trzeba będzie odtworzyć.
Co zrobić, gdy przyczyną są brakujące pliki WordPress po nieudanej aktualizacji?
Brakujące pliki WordPress poznasz po tym, że ścieżka w logu prowadzi do katalogu wp-admin lub wp-includes, a wyłączenie wtyczek i motywu niczego nie zmienia. Rozwiązaniem jest nadpisanie rdzenia czystą paczką z oficjalnej strony pl.wordpress.org w tej samej wersji co instalacja.
Procedura wygląda tak: rozpakuj archiwum lokalnie, usuń z niego katalog wp-content, wgraj resztę na serwer z nadpisaniem i nie dotykaj pliku wp-config.php. Nadpisujesz wyłącznie pliki systemowe, więc treści, media i ustawienia pozostają nienaruszone.
Dwa szczegóły, które rozwiązują połowę takich przypadków. Po przerwanej aktualizacji w katalogu głównym potrafi zostać plik .maintenance, który utrzymuje tryb konserwacji i blokuje stronę nawet po naprawie plików. Wystarczy go usunąć. Jeżeli masz dostęp do SSH, polecenie wp core verify-checksums z WP-CLI porówna pliki instalacji z oficjalnymi sumami kontrolnymi i wskaże, które zostały zmodyfikowane lub których brakuje. To najszybszy sposób, by odróżnić niekompletną aktualizację od podmienionych plików.
Kiedy przyczyną jest wersja PHP, limit pamięci lub baza danych?
Gdy wyłączenie wszystkich wtyczek i zmiana motywu nic nie dają, przyczyna leży w warstwie serwera. Te trzy obszary odpowiadają za większość awarii, które pojawiają się bez żadnej zmiany w samej witrynie.
Niezgodność wersji PHP po zmianie ustawień hostingu
Objaw jest charakterystyczny: błąd krytyczny pojawia się natychmiast po przełączeniu wersji PHP w panelu, a w logu widnieje Uncaught Error albo wywołanie funkcji usuniętej w nowszej wersji języka. Starsze motywy i porzucone wtyczki korzystają z konstrukcji, które w PHP 8 przestały działać.
Według strony wymagań serwerowych w serwisie WordPress.org rekomendowana jest obecnie wersja PHP 8.1 lub nowsza. To nie znaczy, że można ją włączyć z dnia na dzień. Najpierw sprawdź, czy motyw i kluczowe wtyczki deklarują zgodność, a zmianę wykonuj etapami, tak jak opisuje poradnik o tym, jak bezpiecznie zaktualizować PHP w WordPressie. Powrót do poprzedniej wersji w panelu hostingu zajmuje minutę i jest najszybszym sposobem przywrócenia strony.
Wyczerpany limit pamięci i przekroczony czas wykonania skryptu
W logu zobaczysz wtedy komunikat o wyczerpaniu dozwolonego rozmiaru pamięci albo o przekroczeniu maksymalnego czasu wykonania. Objaw bywa wybiórczy: front działa, a awaria pojawia się przy imporcie, generowaniu miniatur lub wejściu w listę produktów.
Limit podnosisz wpisem w wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );dla całej witryny.define( 'WP_MAX_MEMORY_LIMIT', '512M' );dla operacji w panelu administracyjnym.
Pamiętaj o zależności, która często umyka. WordPress nie przebije limitu ustawionego po stronie serwera. Jeżeli hosting dopuszcza 128 MB, wpis w konfiguracji nic nie zmieni i trzeba podnieść wartość w panelu albo zgłosić to do obsługi. Rosnące zapotrzebowanie na pamięć to zwykle objaw, a nie przyczyna, więc warto sprawdzić, która wtyczka je generuje.
Uszkodzone tabele i naprawa bazy danych przez WP_ALLOW_REPAIR
Uszkodzenie tabel objawia się komunikatami o problemach z bazą, znikającymi ustawieniami albo błędem pojawiającym się tylko w części witryny. WordPress ma wbudowane narzędzie naprawcze, które uruchamia się stałą define( 'WP_ALLOW_REPAIR', true ); w wp-config.php i adresem /wp-admin/maint/repair.php.
Dwie kwestie są tu krytyczne. Ekran naprawy działa bez logowania, więc dostęp ma każdy, kto zna adres. Usuń stałą z konfiguracji natychmiast po zakończeniu operacji, a nie przy okazji kolejnych porządków. Druga sprawa: narzędzie opiera się na poleceniu naprawy tabel, które nie obsługuje silnika InnoDB, a ten jest dziś standardem. Jeżeli naprawa nie przynosi efektu, nie oznacza to, że baza jest zdrowa. Oznacza, że trzeba odtworzyć ją z kopii lub zgłosić sprawę do hostingu.
Jak odróżnić zwykły błąd krytyczny od skutku włamania na stronę?
Najprostszy sygnał ostrzegawczy to brak wyzwalacza. Jeżeli nikt nic nie aktualizował, nie zmieniał kodu ani wersji PHP, a strona nagle przestała działać, traktuj to jako potencjalny incydent bezpieczeństwa, a nie zwykłą awarię.
Przesłanki, które razem układają się w obraz włamania:
Pliki PHP w katalogu wp-content/uploads. W folderze z mediami nie ma powodu, żeby istniały skrypty.
Daty modyfikacji plików rdzenia niezgodne z datą aktualizacji. Najszybciej wychwycisz to sortowaniem po dacie w kliencie FTP.
Nowe konto z rolą administratora, którego nie zakładałeś.
Przekierowania na obce domeny widoczne tylko na urządzeniach mobilnych lub po wejściu z wyników wyszukiwania.
Zaciemniony kod z długimi ciągami base64 na początku plików motywu.
Jeżeli widzisz te objawy, zmień strategię. Usunięcie jednego pliku nie kończy sprawy, bo backdoory są z zasady rozproszone. Konieczna jest zmiana wszystkich haseł, wygenerowanie nowych kluczy zabezpieczeń w wp-config.php i pełny przegląd instalacji. Procedurę opisuje osobny materiał o tym, jak usunąć wirusa ze strony internetowej i się przed nim zabezpieczyć. Przywrócenie backupu bez tego kroku kończy się powrotem infekcji w ciągu kilku dni, bo luka, którą wykorzystano, nadal istnieje.
Kiedy przywrócić kopię zapasową, a kiedy jest to najgorszy możliwy ruch?
Kopię zapasową przywracaj wtedy, gdy strona musi działać natychmiast, a diagnoza się przeciąga. We wszystkich innych sytuacjach to decyzja, która kosztuje więcej, niż daje, bo usuwa dane powstałe po wykonaniu backupu i zaciera przyczynę awarii.
Pomocne jest rozróżnienie zakresu przywracania, o którym rzadko się pisze:
Same pliki jednej wtyczki lub motywu. Wystarczające w większości przypadków, gdy wiesz, co się zepsuło. Nie dotyka bazy, więc nie tracisz niczego.
Wszystkie pliki bez bazy danych. Dobre przy nieudanej aktualizacji rdzenia. Treści, zamówienia i konta pozostają aktualne.
Pliki razem z bazą. Ostateczność. Cofa witrynę w czasie wraz z całą jej zawartością.
W sklepie internetowym ostatni wariant oznacza utratę zamówień, płatności i rejestracji z okresu po backupie, a te dane rzadko da się odtworzyć. Zanim cokolwiek nadpiszesz, zrób kopię stanu bieżącego, nawet uszkodzonego. Jeżeli dopiero układasz ten proces, warto zacząć od zasad opisanych w materiale o tym, czym jest dobra kopia zapasowa strony internetowej. Backup, którego nigdy nie testowano przy odtwarzaniu, daje wyłącznie poczucie bezpieczeństwa.
Jakie 7 błędów pogłębia awarię zamiast ją naprawić?
Większość nieudanych napraw wygląda podobnie: użytkownik działa szybko, zmienia kilka rzeczy naraz i po godzinie nie wie już, co było przyczyną, a co skutkiem jego własnych działań. Oto błędy, które najczęściej przedłużają awarię.
- Kilka zmian jednocześnie. Przy zmianie wersji PHP, usunięciu wtyczki i nadpisaniu rdzenia naraz nie dowiesz się, co pomogło. Testuj po jednej zmianie.
- Usuwanie zamiast zmiany nazwy. Skasowany katalog zabiera ze sobą pliki konfiguracyjne dodatku. Zmiana nazwy jest odwracalna.
- Instalowanie kolejnych wtyczek naprawczych. Dokładasz kod do systemu, który już nie startuje, i zwiększasz liczbę zmiennych w równaniu.
- Przywracanie backupu bez zabezpieczenia stanu obecnego. To jedyny moment, w którym naprawdę można stracić dane przy błędzie krytycznym.
- Pozostawienie WP_DEBUG_DISPLAY na true. Odwiedzający i boty widzą ścieżki serwerowe oraz nazwy plików, co jest gotową mapą dla automatycznych skanerów.
- Edycja wp-config.php w edytorze tekstu z formatowaniem. Dodatkowy znak na początku pliku powoduje błąd wysyłania nagłówków. Używaj edytora kodu, nie procesora tekstu.
- Powtórzenie tej samej aktualizacji po naprawie. Bez sprawdzenia zgodności awaria wróci w tej samej postaci, zwykle w najmniej wygodnym momencie.
Wspólny mianownik tych pomyłek jest jeden. Każda z nich zwiększa liczbę rzeczy, które mogły pójść nie tak, zamiast ją zmniejszać. Dobra naprawa polega na eliminowaniu zmiennych, a nie na dokładaniu kolejnych.
Kiedy przestać naprawiać samodzielnie i zgłosić problem do hostingu lub specjalisty?
Granica jest prosta. Jeżeli po wyłączeniu wszystkich wtyczek, zmianie motywu i odczytaniu logów nadal nie wiesz, co się dzieje, dalsze próby zwiększają ryzyko. Zgłoszenie do hostingu jest pierwszym krokiem, bo obsługa widzi logi PHP, obciążenie serwera i limity konta, których nie zobaczysz z poziomu WordPressa.
Do hostingu zgłoś się od razu, gdy:
- Błąd pojawił się bez żadnej zmiany po Twojej stronie. Nic nie aktualizowałeś, a strona przestała działać. Przyczyna leży zwykle w konfiguracji serwera.
- Widzisz komunikaty o połączeniu z bazą danych albo kody 502 i 503. To objawy po stronie infrastruktury, nie samej witryny.
- Nie działa także FTP lub panel administracyjny konta. Problem wykracza poza WordPressa.
- Awaria dotyczy kilku stron na tym samym serwerze. Pojedyncza wtyczka nie wyłącza kilku niezależnych witryn naraz.
Do specjalisty warto zwrócić się wtedy, gdy witryna generuje sprzedaż, a diagnoza trwa dłużej niż godzinę, albo gdy w grę wchodzą naruszone pliki rdzenia. W takich sytuacjach liczy się nie tylko przywrócenie strony, ale też usunięcie przyczyny, dlatego sensowna jest naprawa stron internetowych prowadzona od razu z analizą tego, co doprowadziło do awarii.
Jest też kryterium, które warto policzyć na zimno. Jeżeli godzina przestoju kosztuje Cię więcej niż godzina pracy specjalisty, samodzielna diagnoza przestaje się opłacać już po pierwszym nieudanym podejściu.
Jakie informacje przygotować przed zgłoszeniem, żeby skrócić czas naprawy
Dobrze przygotowane zgłoszenie skraca naprawę bardziej niż jakiekolwiek narzędzie. Przygotuj komplet danych od razu, zamiast odpowiadać na pytania w kolejnych wiadomościach.
- Adres witryny i dokładna godzina pierwszego wystąpienia błędu. Logi serwera filtruje się po czasie, więc to najcenniejsza informacja w całym zgłoszeniu.
- Dosłowna treść komunikatu. Dołącz zrzut ekranu albo wpis z pliku debug.log, najlepiej z pełną ścieżką do pliku.
- Lista zmian z ostatnich 24 godzin. Aktualizacje, nowe wtyczki, zmiana wersji PHP, migracja, edycja kodu.
- Kroki, które już wykonałeś. Bez tego support powtórzy całą diagnostykę od zera i stracicie kilka godzin.
- Informacja o kopii zapasowej i dacie jej wykonania. Przesądza o tym, czy naprawa może iść szybką ścieżką.
- Dane dostępowe do FTP i panelu hostingu. Potrzebne wyłącznie wtedy, gdy zlecasz naprawę na zewnątrz.
Jedna uwaga praktyczna. Zdanie „strona nie działa” uruchamia standardową procedurę i odpowiedź z prośbą o szczegóły. Zdanie z godziną awarii, treścią błędu i listą wykonanych kroków trafia zwykle od razu do osoby, która zagląda w logi.
Jak zabezpieczyć stronę, żeby błąd krytyczny nie wrócił przy kolejnej aktualizacji?
Najskuteczniejsza ochrona to przeniesienie ryzyka poza produkcję. Środowisko stagingowe, czyli kopia witryny uruchamiana osobno, pozwala sprawdzić aktualizację wtyczek, motywu i wersji PHP bez narażania działającej strony. Większość hostingów udostępnia je jednym kliknięciem, a koszt jest nieporównywalnie niższy niż godziny przestoju.
Poza tym warto wdrożyć kilka rzeczy, które realnie zmniejszają liczbę awarii.
- Aktualizuj etapami, nie hurtem. Przy jednej aktualizacji na raz od razu wiesz, co wywołało problem. Szersze zasady opisuje poradnik o tym, jak przebiega aktualizacja stron internetowych na WordPress krok po kroku.
- Trzymaj narzędzie do cofania wersji. Wtyczka WP Rollback pozwala wrócić do poprzedniego wydania dodatku z poziomu panelu, co bywa szybsze niż przywracanie całego backupu.
- Ustaw RECOVERY_MODE_EMAIL na skrzynkę, którą faktycznie czytasz. Bez tego wiadomość z linkiem do trybu odzyskiwania trafi na adres, do którego nikt nie ma dostępu.
- Włącz monitoring dostępności. O awarii dowiesz się od narzędzia, a nie od klienta. Zasady doboru opisuje materiał o tym, na czym polega monitoring stron internetowych i kontrola uptime.
- Ogranicz liczbę wtyczek. Każde rozszerzenie to kolejny kod, który może wejść w konflikt po aktualizacji rdzenia. Usuwaj dodatki nieaktywne i dublujące funkcje.
- Trzymaj zapasowy motyw domyślny. To jedyna awaryjna ścieżka powrotu do panelu, gdy szablon przestanie działać.
- Testuj odtwarzanie kopii. Backup sprawdzony raz w roku jest wart więcej niż codzienny, którego nigdy nie przywracano.
Jeżeli strona odpowiada za sprzedaż lub kontakt z klientami, warto przenieść te czynności na stały proces zamiast wykonywać je przy okazji. Tak właśnie działa opieka nad stronami internetowymi, w której aktualizacje idą przez środowisko testowe, a kopie są weryfikowane, zanim będą potrzebne.
Automatyczne aktualizacje zostawiam włączone wyłącznie dla poprawek bezpieczeństwa rdzenia. Duże wydania wtyczek i motywu wdrażam ręcznie, po kopii zapasowej, bo to one odpowiadają za większość błędów krytycznych pojawiających się w nocy, gdy nikt nie patrzy na stronę.