WordPress przestał działać po aktualizacji – co robić krok po kroku

Kliknąłeś „Aktualizuj” i strona zniknęła. Objaw bywa różny: biały ekran, komunikat „Na tej witrynie wystąpił błąd krytyczny”, panel, do którego nie da się wejść, rozjechany układ albo – wariant najbardziej podstępny – strona, która wygląda normalnie, tylko formularz przestał wysyłać, a koszyk nie przechodzi do kasy.

Awaria po aktualizacji ma jedną zaletę, której nie mają inne: znasz przyczynę. Coś się zmieniło i wiesz, o której. To zawęża listę podejrzanych z całego WordPressa do kilku pozycji, a większość napraw sprowadza się do cofnięcia jednej zmiany – o ile cofasz właściwą rzecz i we właściwej kolejności.

Ten poradnik prowadzi przez to od strony zdarzenia, nie kodu błędu: od pierwszych piętnastu minut, przez cofnięcie wtyczki, motywu i rdzenia, po decyzję, której nikt nie opisuje – kiedy przestać naprawiać i przywrócić kopię.

Wykonaj po kolei. Po każdym kroku odśwież stronę w oknie prywatnym – zwykłe odświeżenie potrafi pokazać wersję z cache.

1. Przestań aktualizować. Kolejna aktualizacja „na wszelki wypadek” dokłada zmiennych do równania, którego nie rozwiązałeś.
2. Zapisz, co i o której zaktualizowałeś. Pulpit → Aktualizacje, historia w panelu hostingu, e-maile o automatycznych aktualizacjach. To lista podejrzanych.
3. Zrób kopię TERAZ – stanu uszkodzonego. Nie po to, żeby do niej wracać, tylko żeby nie stracić zamówień i wiadomości z ostatnich godzin, gdy później przywrócisz starszą.
4. Sprawdź skrzynkę administratora – adres z Ustawienia → Ogólne, razem ze spamem. WordPress mógł wysłać wiadomość z nazwą winnej wtyczki i linkiem do trybu odzyskiwania.
5. Sprawdź, czy działa panel (/wp-admin/). To pytanie dzieli dalszą drogę na dwie różne.
6. Zajrzyj, czy w katalogu głównym nie został plik .maintenance. Zostaje po przerwanej aktualizacji i sam nie znika. Usuń go.
7. Wyłącz jedną podejrzaną wtyczkę, nie wszystkie naraz – przez panel albo zmieniając nazwę katalogu w wp-content/plugins na nazwa-wtyczki_off.
8. Wyczyść cache – wtyczki, cache serwera i CDN. Strona bywa już naprawiona i dalej pokazuje uszkodzoną kopię.
9. Jeśli strona wróciła – nie zostawiaj wtyczki wyłączonej. Cofnij ją do poprzedniej wersji, żeby jej funkcja dalej działała.
10. Jeśli po 15 minutach nie wiesz więcej niż na starcie – przejdź do decyzji „przywrócić kopię czy naprawiać”.

Zanim cokolwiek cofniesz, nazwij objaw – trzy scenariusze prowadzą do trzech różnych pierwszych kroków.

Trzeci scenariusz jest najdroższy, choć wygląda najłagodniej: strona odpowiada, monitoring milczy, a przez tydzień nikt nie zauważa, że kasa odrzuca płatności albo że formularz po wysłaniu pokazuje potwierdzenie, a wiadomość nigdzie nie dociera. Ten drugi objaw nie istnieje, dopóki ktoś nie zadzwoni o e-mail sprzed pięciu dni.

Sprawdź też zasięg: awaria widoczna wyłącznie u Ciebie to zwykle cache przeglądarki lub CDN. A jeśli widzisz konkretnie kod 500 albo „Internal Server Error”, pełną ścieżkę diagnostyczną – od .htaccess, przez logi, po limity hostingu – rozpisaliśmy w poradniku o błędzie 500 w WordPressie - https://nestero.pl/blog/poradniki/formularz-wordpress-nie-wysyla/.

Od wersji 5.2 WordPress sam wskazuje winowajcę. Gdy wtyczka lub motyw wywoła błąd krytyczny, system wysyła na adres administratora wiadomość „Na Twojej witrynie wystąpił błąd krytyczny”. W środku jest nazwa winowajcy, ścieżka do pliku, numer linii i – najważniejsze – link logujący do panelu w trybie odzyskiwania, z tą wtyczką tymczasowo wstrzymaną. Zamiast zgadywać przez FTP, dostajesz nazwę i wejście do panelu.

Trzy rzeczy, przez które bywa bezużyteczny:

• Adres jest nieaktualny. Wiadomość idzie na adres z Ustawienia → Ogólne, nie na adres Twojego konta. Po przejęciu strony od poprzedniego wykonawcy bardzo często stoi tam jego skrzynka albo admin@ domeny, której nikt nie odbiera.
• Strona nie wysyła maili. Bez skonfigurowanego SMTP wiadomość może nie wyjść albo wpaść do spamu.
• Błąd nie pochodzi z wtyczki ani motywu. Niekompletne pliki rdzenia, zmiana wersji PHP czy uszkodzony .htaccess nie wywołają tego maila.

Link ma ograniczoną ważność, a WordPress nie wysyła powiadomienia o tym samym błędzie częściej niż raz na dobę – jeśli mail przyszedł wczoraj i został zignorowany, drugiego dziś może nie być. W trybie odzyskiwania przejdź do Wtyczki, zobacz, która pozycja jest wstrzymana, i zdecyduj: cofnąć wersję czy wyłączyć na stałe.

Wyłączenie to nie to samo co cofnięcie. Wyłączona wtyczka płatności znaczy sklep bez płatności, wyłączona wtyczka formularza – stronę bez formularza. Wyłączenie potwierdza diagnozę; naprawą jest powrót do działającej wersji.

Najprostsza droga, o ile masz panel, a wtyczka pochodzi z repozytorium wordpress.org. Wtyczki typu WP Rollback dokładają przy każdej pozycji odnośnik „Rollback” z listą wersji – działa jak zwykły aktualizator, tylko w drugą stronę, i obejmuje też motywy.

1. Wejdź na wordpress.org/plugins/<nazwa-wtyczki>/, otwórz Advanced View i w sekcji Previous Versions pobierz plik ZIP poprzedniej wersji.
2. Przez FTP zmień nazwę katalogu bieżącej wersji w wp-content/plugins na nazwa-wtyczki_off – przestanie się ładować, a pliki zostaną.
3. Rozpakuj ZIP i wgraj katalog pod oryginalną nazwą, bez sufiksu. Nazwa katalogu jest tożsamością wtyczki – po zmianie WordPress uzna ją za nieaktywną.
4. Odśwież stronę, potem panel. Jeśli wstały oba, usuń katalog _off.

Z motywami procedura jest identyczna, tylko w wp-content/themes. Przy dostępie do SSH robi to WP-CLI:

Płatnych rozszerzeń nie ma na wordpress.org, więc „Previous Versions” odpada – starsze wersje pobiera się z konta u producenta. Gdy licencja wygasła, konto przestaje wydawać pliki i nie pobierzesz nawet wersji, za którą zapłaciłeś. Dlatego ZIP każdej płatnej wtyczki trzymaj u siebie, z numerem wersji w nazwie.

Cofnięcie jest tymczasowe: stara wersja przestaje dostawać poprawki bezpieczeństwa. Po ugaszeniu pożaru zostaje decyzja – poczekać na poprawkę autora czy zastąpić wtyczkę czymś utrzymywanym. Ta, przy której nikt nie odpowiada na zgłoszenia od pół roku, jest kandydatem na kolejną awarię.

Rdzeń psuje strony rzadziej niż wtyczki – częściej winna jest wtyczka niezgodna z jego nową wersją. Zanim zaczniesz cofać, wyłącz wtyczki i sprawdź, czy strona wraca. Jeśli wraca, cofanie rdzenia niczego nie naprawi.

Dopiero gdy strona nie działa również z wyłączonymi wtyczkami i domyślnym motywem, przyczyną bywa sam rdzeń – najczęściej przerwana aktualizacja: utracone połączenie, limit czasu PHP albo brak miejsca na dysku zostawiają niekompletne pliki w wp-admin i wp-includes.

Przy ręcznym wgrywaniu plików rdzenia obowiązują dwie zasady: nie wgrywasz katalogu wp-content (tam są wtyczki, motywy i media) i nie nadpisujesz wp-config.php ani .htaccess. Gdy panel działa, tę samą operację wygodniej wykonać wtyczką typu WP Downgrade: podajesz numer wersji i klikasz „Zainstaluj ponownie” w Kokpit → Aktualizacje.

Po cofnięciu rdzenia WordPress zaproponuje aktualizację przy najbliższej okazji. Kontrolę daje wp-config.php:

To ustawienie tymczasowe. Strona bez aktualizacji rdzenia przestaje dostawać poprawki bezpieczeństwa, a to zamienia problem z dostępnością w problem z włamaniem.

Najdroższy błąd po nieudanej aktualizacji to nie zła naprawa, tylko naprawianie zbyt długo. Dwie godziny szukania winowajcy w sklepie, który nie sprzedaje, kosztują więcej niż kwadrans na odtworzenie kopii.

Sedno decyzji: kopia zapasowa to pliki plus baza danych, a te dwie części cofa się osobno i z innymi konsekwencjami:

• Same pliki – przywracasz wp-content albo tylko katalog jednej wtyczki, bazy nie ruszasz. Cofa kod, zostawia zamówienia, wpisy i wiadomości z ostatnich godzin. Działa, dopóki nowa wersja nie zmieniła struktury danych.
• Pliki i baza – pełny powrót do stanu z chwili wykonania kopii. Cofa też wszystko, co powstało po niej: zamówienia, komentarze, zapisy do newslettera, zmiany treści.

Zanim uruchomisz przywracanie, zrób kopię stanu uszkodzonego. Jeśli odtwarzanie zawiedzie, masz punkt wyjścia – a jeśli się uda i zniknie okno danych, z tamtej kopii wyjmiesz zamówienia z tego okresu.

Po przywróceniu sprawdź cztery rzeczy: wersję PHP, adresy w Ustawienia → Ogólne, odnośniki (Ustawienia → Bezpośrednie odnośniki, zapisz bez zmian) i komunikat o oczekującej aktualizacji bazy danych.

Objaw bywa identyczny, a droga naprawy zupełnie inna – tabela porządkuje to, co wrzuca się do jednego worka „aktualizacja”.

Dwie pozycje są pułapkami, bo nie wyglądają na aktualizację.

Zmiana wersji PHP przez hosting to aktualizacja, której nie zrobiłeś. Dostawcy podnoszą wersje w ramach porządków bezpieczeństwa, czasem tylko z zapowiedzią mailową, którą łatwo przeoczyć. Objaw jest identyczny jak po aktualizacji wtyczki, bo padnie właśnie ta, która używa funkcji usuniętej w nowszym PHP. Diagnoza jest inna: patrzysz w panel hostingu i datę zmiany, nie w katalog wtyczek. Cofnięcie wersji PHP jest natychmiastowe i odwracalne – najtańsza próba, jaką możesz wykonać, o ile to dla Ciebie zawieszenie broni, nie rozwiązanie.

Aktualizacja motywu różni się jednym szczegółem: jeśli ktoś zmodyfikował pliki motywu zamiast założyć motyw potomny, aktualizacja nadpisała te zmiany i cofnięcie wersji ich nie przywróci – wracają tylko z kopii. Stąd strona, która po cofnięciu „działa, ale wygląda inaczej niż przedtem”.

W sklepie rzadko pada wszystko. Częściej strona główna i lista produktów wyglądają normalnie, a przestaje działać jeden element ścieżki zakupowej – dlatego monitoring strony głównej tego nie wykrywa. Po każdej aktualizacji przejdź tę listę:

1. Złóż testowe zamówienie do końca, z płatnością – całą drogę, a nie tylko dodanie do koszyka.
2. Sprawdź komunikat o aktualizacji bazy danych. WooCommerce po części aktualizacji prosi o jej uruchomienie. Do tego czasu sklep pracuje w stanie pośrednim: część danych w starym formacie, część w nowym.
3. Sprawdź zgodność z HPOS (nowym magazynem zamówień). WooCommerce pokazuje listę wtyczek zadeklarowanych jako niezgodne – po aktualizacji rozszerzenia potrafi się tam pojawić pozycja, której wcześniej nie było. Sklepy założone od października 2023 mają HPOS domyślnie, starsze tylko po ręcznym przełączeniu.
4. Sprawdź maile o zamówieniach – i te do klienta, i te do sklepu. Wysyłka potrafi paść cicho, a objaw wygląda jak brak zamówień.
5. Sprawdź integracje i kolejkę zadań: czy zamówienia spływają do BaseLinkera, czy faktury wystawiają się w Fakturowni, czy w Action Schedulerze (WooCommerce → Stan → Zaplanowane zadania) nie zalega kolejka blokująca maile i synchronizacje.
6. Przejrzyj zamówienia z okna awarii. Szukasz statusów „oczekujące na płatność” przy transakcjach opłaconych według panelu bramki.

Decyzja o przywróceniu kopii wygląda w sklepie inaczej: odtworzenie bazy kasuje zamówienia złożone po jej wykonaniu. Pełne przywrócenie wchodzi w grę tylko z kopią sprzed kilku godzin – albo wcale, a naprawą jest cofnięcie samych plików. Jeśli objawy sięgają ścieżki zakupowej głębiej niż sama aktualizacja, kolejne miejsca do sprawdzenia zebraliśmy w tekście o tym, dlaczego sklep przestaje przyjmować zamówienia (https://nestero.pl/blog/e-commerce/woocommerce-nie-przyjmuje-zamowien/).

Prawie każda awaria po aktualizacji ma to samo źródło: zmiana weszła prosto na produkcję, bez sprawdzenia. Zapobieganie nie polega na rzadszym aktualizowaniu – od tego robi się gorzej – tylko na innej procedurze.

1. Kopia bezpośrednio przed aktualizacją, nie „wczorajsza z hostingu”. I raz na jakiś czas test, czy da się z niej odtworzyć stronę. Kopia, której nikt nigdy nie odtworzył, jest deklaracją, nie zabezpieczeniem.
2. Aktualizuj na kopii testowej. Wiele hostingów tworzy staging jednym kliknięciem: klonujesz stronę, aktualizujesz klon, sprawdzasz, dopiero potem powtarzasz na produkcji.
3. Miej spisaną listę ścieżek do sprawdzenia – tę samą za każdym razem: strona główna, podstrona z buildera, formularz wysłany naprawdę, logowanie, wyszukiwarka, a w sklepie pełna ścieżka koszyk → kasa → płatność.
4. Aktualizuj pojedynczo, nie hurtem. Kolejność: rdzeń, wtyczki krytyczne (WooCommerce, płatności, dostawa), reszta, motyw na końcu. Przy „aktualizuj wszystko” na trzydziestu pozycjach szukanie winowajcy trwa dłużej niż cała aktualizacja.
5. Nie aktualizuj w piątek po południu ani w dniu startu kampanii – chodzi o to, kto jest pod telefonem przez najbliższe trzy godziny.
6. Trzymaj ZIP-y płatnych wtyczek i motywów z numerem wersji w nazwie – to jedyna kopia dostępna po wygaśnięciu licencji.
7. Prowadź dziennik zmian: data, co, z jakiej wersji na jaką, kto. Przy awarii pierwsze pytanie brzmi „co się zmieniło” i warto znać odpowiedź w trzydzieści sekund.
8. Automatyczne aktualizacje włączaj świadomie. Wersje pomocnicze rdzenia zostaw. Automatyczne aktualizacje wtyczek mają sens tam, gdzie stoi za nimi staging i monitoring – inaczej pierwszą informacją o awarii jest telefon od klienta.

To praca cykliczna – kilka godzin miesięcznie, których zwykle nikt w firmie nie ma w kalendarzu. Dokładnie to obejmuje stała opieka techniczna nad stroną: aktualizacje wchodzą najpierw na kopię, a przed nimi i po nich stoi backup oraz monitoring.

Większość awarii po aktualizacji usuwa się według powyższej listy w kilkanaście do kilkudziesięciu minut. Są jednak sytuacje, w których samodzielne próby kosztują więcej niż pomoc:

• Sklep nie przyjmuje zamówień, a od awarii minęła godzina. Każda kolejna godzina eksperymentów ma cenę, którą policzysz z własnych statystyk.
• Nie masz dostępu do FTP ani do panelu hostingu. Wtedy pierwszym zadaniem jest odzyskanie dostępów, nie naprawa – a to procedura dłuższa niż sama awaria.
• Cofnąłeś wersję i nic się nie zmieniło. Sygnał, że aktualizacja ruszyła bazę albo że winowajców jest dwóch. Dalsze cofanie na oślep pogłębia rozjazd między kodem a danymi.
• Nie masz kopii sprzed aktualizacji albo nie wiesz, czy da się z niej odtworzyć stronę – bez punktu powrotu każda kolejna zmiana jest nieodwracalna.
• Widzisz w plikach coś, czego nie wgrywałeś – nieznane pliki PHP, przekierowania na obce domeny, wtyczki, których nikt nie instalował. Aktualizacja mogła nie być przyczyną, tylko momentem, w którym problem wyszedł na wierzch..
• Awaria wraca po każdej aktualizacji. To nie awaria, tylko dług techniczny: stare wtyczki, motyw z przeróbkami w plikach, PHP na granicy wsparcia.

W takich przypadkach najszybsza droga to telefon: +48 575 067 607. Awarię wyłączającą stronę lub sprzedaż bierzemy poza kolejnością – najpierw przywracamy działanie, potem ustalamy przyczynę.

Awaria po aktualizacji różni się od innych tym, że znasz jej przyczynę od pierwszej minuty. Kolejność jest zawsze ta sama: nazwij objaw, sprawdź skrzynkę administratora i tryb odzyskiwania, cofnij jedną zmianę zamiast wyłączać wszystko, a gdy po godzinie nie wiesz więcej niż na starcie – przywróć kopię i wróć do diagnozy na klonie, nie na żywej stronie. Sam rollback to środek doraźny; naprawą jest decyzja, co zrobić z wtyczką, która przestała pasować do Twojego środowiska.

Jeśli strona albo sklep stoi teraz, zadzwoń: +48 575 067 607. Możesz też napisać przez formularz kontaktowy – przywrócimy działanie i powiemy, co dokładnie się stało. A jeśli wolisz, żeby aktualizacje przestały być Twoim ryzykiem, pakiety opieki technicznej zaczynają się od 349 zł netto miesięcznie i obejmują testowanie zmian na kopii, codzienny backup oraz monitoring, który zauważa awarię przed Twoimi klientami.

Źródła:

• Fatal Error Recovery Mode in 5.2 – Make WordPress Core: https://make.wordpress.org/core/2019/04/16/fatal-error-recovery-mode-in-5-2/
• Debugging in WordPress – dokumentacja WordPress: https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
• Updating WordPress – dokumentacja WordPress: https://developer.wordpress.org/advanced-administration/upgrade/upgrading/
• Releases – WordPress.org (archiwum wersji): https://wordpress.org/download/releases/
• wp plugin install – dokumentacja WP-CLI: https://developer.wordpress.org/cli/commands/plugin/install/
• High-Performance Order Storage – dokumentacja WooCommerce: https://woocommerce.com/document/high-performance-order-storage/
• Supported Versions – PHP.net: https://www.php.net/supported-versions.php