WordPress padł po aktualizacji – rollback i naprawa w 2026

Pierwszy odruch po awarii to panika i klikanie przycisków. Zły pomysł. Każdy rollback trzeba dopasować do tego, co konkretnie się zepsuło – inaczej naprawisz core, a problem siedzi w motywie. Zacznij od trzech pytań.

Co kliknąłeś jako ostatnie? Jeśli robiłeś update ręcznie, wiesz dokładnie co. Jeśli WordPress zaktualizował coś sam (auto-updates są domyślnie włączone od 5.5), zajrzyj do `wp-content/upgrade/` – tam leżą ślady operacji. Sprawdź też zakładkę Kokpit > Aktualizacje w panelu admina, o ile panel w ogóle działa. Jeśli nie działa – zaloguj się przez FTP i przeczytaj `wp-content/debug.log` (jeśli WP_DEBUG_LOG był włączony).

Co widzi użytkownik? Biały ekran śmierci (WSOD) oznacza fatal error w PHP – najczęściej konflikt wtyczki z nową wersją core albo brak funkcji w starszym PHP. Błąd 500 to częściej problem z `.htaccess` lub limitem pamięci. Błąd bazy danych (Error establishing database connection) to znak, że coś wywaliło się przy upgrade MySQL/MariaDB lub migracji tabel. Panel admina działa, ale frontend nie – problem z motywem lub plikiem `functions.php`.

Kiedy ostatni raz robiłeś backup? Jeśli backup jest sprzed 24 godzin – odetchnij. Jeśli nie masz żadnego backupu – nadal można cofnąć większość zmian (wtyczki, motywy, core da się pobrać ręcznie), ale kopia danych z bazy to ratunek ostatniej instancji. Sprawdź UpdraftPlus, BackWPup, kopię hostingu. CyberFolks, LH.pl i Zenbox trzymają codzienne snapshoty 7–14 dni wstecz. Nie zaczynaj naprawiać, jeśli nie wiesz, dokąd wrócić. Ten sam problem opisaliśmy przy okazji diagnozy w artykule WordPress wolno się ładuje – diagnoza i naprawa.

Aktualizacja wersji głównej (6.4 na 6.5) zdarza się rzadko, ale kiedy popsuje, skala jest duża: panel nie odpowiada, frontend pokazuje WSOD, a API REST zwraca 500. Najczęstsza przyczyna to niekompatybilność wtyczek z nowym buildem albo błąd w migracji bazy (nowe wersje potrafią modyfikować strukturę tabel).

Rollback przez WP-CLI to najszybsza droga, o ile masz dostęp SSH do serwera. Komendy:

cd /home/user/htdocs/twojadomena.pl
wp core update --version=6.4.3 --force --allow-root
wp core update-db --allow-root

Flaga `--force` zmusza WP do downgrade (domyślnie blokuje cofanie wersji). Po operacji wp-cli uruchomi migracje tabel w drugą stronę – to normalne, nie przerywaj. Cały proces zajmuje 30–60 sekund.

Rollback przez FTP robisz, gdy nie masz SSH. Pobierz starszą wersję z wordpress.org/download/releases, rozpakuj na dysku i przez FTP zastąp foldery `wp-admin/` i `wp-includes/` oraz pliki w katalogu głównym (oprócz `wp-config.php` i `wp-content/`). Nie nadpisuj `wp-content/` – tam masz swoje wtyczki, motywy i uploady. Po przesłaniu wejdź na `twojadomena.pl/wp-admin/` – WordPress wykryje, że struktura jest starsza i poprosi o migrację bazy wstecz. Zgódź się.

Jeśli panel admina dalej nie działa, zajrzyj do `wp-config.php` i tymczasowo dodaj:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Odśwież stronę, potem otwórz `wp-content/debug.log`. Pierwsza linia z Fatal error powie ci, która wtyczka lub motyw wykłada się na nowym core. Wyłączysz ją przez FTP (zmień nazwę folderu w `wp-content/plugins/` z `nazwa-wtyczki` na `nazwa-wtyczki.disabled`) i panel wróci. Jeśli widzisz błąd 500 zamiast WSOD, zajrzyj też do Błąd 500 w WordPress – jak naprawić.

To zdecydowanie najczęstszy scenariusz. Updates wtyczek wychodzą co tydzień, jakość kodu jest różna, a kompatybilność z innymi wtyczkami jest trudna do przewidzenia. Jak poznać, że to właśnie wtyczka? Po aktualizacji jednej konkretnej pozycji (widzisz na liście Kokpit > Aktualizacje) zaczął się problem, albo strona działa, ale jedna sekcja wariuje (koszyk WooCommerce, formularz kontaktowy, slider).

Metoda 1 – WP Rollback plugin. Zainstaluj darmową wtyczkę WP Rollback. Po aktywacji na liście wtyczek (Wtyczki > Zainstalowane) pojawi się nowy link Rollback przy każdej pozycji z katalogu wordpress.org. Kliknij, wybierz wersję (WP Rollback pobiera je bezpośrednio z SVN wordpress.org) i potwierdź. Operacja zajmuje 20 sekund. Działa dla wtyczek i motywów z katalogu oficjalnego, dla premium trzeba ręcznie.

Metoda 2 – ręczny downgrade przez FTP. Działa dla wtyczek premium (Advanced Custom Fields Pro, WP Rocket, Yoast Premium). Pobierz starszą wersję z panelu producenta (większość trzyma archiwum pod My Account > Downloads), rozpakuj ZIP, przez FTP wejdź do `wp-content/plugins/`, zmień nazwę aktualnego folderu wtyczki na `nazwa.disabled` (zachowaj na wszelki wypadek) i wgraj rozpakowaną starą wersję. Wejdź w panel, aktywuj wtyczkę. Jeśli pytała o aktualizację bazy – czasem trzeba uruchomić starszy schemat, sprawdź dokumentację wtyczki.

Metoda 3 – wyłączenie wtyczki przez bazę danych. Jeśli panel padł z powodu tej wtyczki (WSOD), nie wejdziesz nawet na listę wtyczek. Idź do phpMyAdmin, tabela `wp_options`, rekord `active_plugins`, edytuj pole `option_value`. Jest to serializowana tablica PHP z listą wtyczek. Zmień na pustą tablicę: `a:0:{}`. Wszystkie wtyczki zostaną wyłączone, panel wróci. Potem aktywuj wtyczki pojedynczo – znajdziesz winowajcę.

Metoda 4 – WP-CLI. Jeden kawałek kodu i masz downgrade konkretnej wtyczki do wybranej wersji:

wp plugin install contact-form-7 --version=5.8.6 --force --allow-root
wp plugin activate contact-form-7 --allow-root

Jeśli często aktualizujesz wtyczki, warto też zerknąć na wpis Aktualizacja WordPress – bezpieczny przewodnik – opisujemy tam pełną procedurę update, która minimalizuje ryzyko takich sytuacji.

Update motywu to ryzyko szczególne, bo motywy często modyfikują `functions.php` i wprowadzają zmiany w hookach – jeden błąd składniowy i cała strona pokazuje WSOD. Dodatkowo, jeśli robiłeś customizację motywu bezpośrednio (zamiast child theme), update go nadpisze i stracisz zmiany.

Rollback motywu przez FTP to najprostsza metoda. Jeśli masz backup (UpdraftPlus, BackWPup, snapshot hostingu), wypakuj folder `wp-content/themes/nazwa-motywu/` z backupu i przez FTP zastąp obecną wersję. Jeśli nie masz backupu, a motyw pochodzi z katalogu wordpress.org, pobierz starszą wersję z sekcji Development > Previous versions albo skorzystaj z WP Rollback plugin.

Awaryjne przełączenie na domyślny motyw. Jeśli strona jest niewidoczna (błąd 500 z powodu motywu) i nie możesz wejść w panel, przez FTP zmień nazwę folderu aktualnego motywu w `wp-content/themes/` (np. z `mojmotyw` na `mojmotyw.broken`). WordPress wykryje brak aktywnego motywu i automatycznie przełączy się na Twenty Twenty-Four (lub inny dostępny). Frontend odżyje – brzydki, ale żywy. Wtedy przez panel spokojnie cofnij motyw albo napraw błąd.

Downgrade motywu przez WP-CLI:

wp theme install astra --version=4.6.0 --force --allow-root
wp theme activate astra --allow-root

Ważne: jeśli customizowałeś motyw ręcznie (edycja `functions.php` lub plików szablonów), rollback to dla ciebie ostrzeżenie – następnym razem zrób child theme. Inaczej każdy update nadpisuje twoją pracę. Child theme to katalog w `wp-content/themes/` z minimalnym `style.css` (deklaracja rodzica) i `functions.php` – wszystkie zmiany robisz tam, update rodzica ich nie rusza. Jeśli nie masz doświadczenia w pracy z PHP i WordPressem, zrobienie dobrego child theme to zadanie dla developera, ale opłaca się raz na zawsze.

Hostingi regularnie podbijają wersję PHP – CyberFolks, LH.pl i Zenbox co pół roku informują mailem o migracji na nowszą wersję. Zwykle to dobrze (PHP 8.3 jest o 20–30 procent szybszy niż 8.1), ale jeśli masz starą wtyczkę lub motyw używający funkcji usuniętych w nowym PHP, strona się wywala. Typowe objawy: błąd 500, komunikat Undefined function w logach, albo biały ekran po zmianie wersji w panelu hostingu.

Downgrade PHP w panelu hostingu. Każdy większy polski hosting pozwala wrócić do poprzedniej wersji PHP jednym kliknięciem:

• CyberFolks (polecamy, ref link) – panel klienta > Hosting > Ustawienia PHP > wybierz wersję z listy (7.4, 8.0, 8.1, 8.2, 8.3). Zmiana natychmiastowa.
• LH.pl – panel > Usługi > twoja usługa > Wersja PHP.
• Zenbox – panel > Strony > wybierz domenę > PHP Version.
• cPanel (starsze hostingi) – MultiPHP Manager.

Po downgrade sprawdź, czy strona wróciła. Jeśli tak – masz czas na aktualizację problematycznych wtyczek, a dopiero potem ponowny upgrade PHP.

Jak sprawdzić kompatybilność wtyczek z nowym PHP przed update. Zainstaluj darmową wtyczkę PHP Compatibility Checker od WP Engine. Skanuje wszystkie wtyczki i motywy pod kątem zgodności z wybraną wersją PHP, wskazuje konkretne pliki i linie z problemem. Uruchamiasz skan przed upgrade PHP – dzięki temu wiesz, co wymaga wymiany. Nie zastępuje testowania na stagingu, ale filtruje 80 procent problemów.

Jeśli hosting nie pozwala na downgrade (rzadkie, ale zdarza się na tanich shared), jedyna opcja to ręczne usunięcie niekompatybilnej wtyczki przez FTP i szukanie zamiennika albo update'u od autora. Warto przy okazji pomyśleć o migracji na lepszy hosting. Zły hosting objawia się zwykle nie tylko brakiem downgrade PHP, ale też wolnym czasem odpowiedzi i brakiem wsparcia. NIGDY nie polecamy nazwa.pl ani home.pl – CyberFolks jest o klasę lepszy za podobne pieniądze.

Rzadziej spotykany, ale paskudny scenariusz. Hosting migruje z MySQL 5.7 na 8.0 albo z MariaDB 10.3 na 10.6, a niektóre kolumny w tabelach WordPressa zmieniają zachowanie (collation, typy tekstowe, strict mode). Strona pokazuje Error establishing database connection albo One or more database tables are unavailable.

Przywrócenie z backupu przez UpdraftPlus. Jeśli masz zainstalowanego UpdraftPlus (darmowy, rekomendowany), przejdź do Ustawienia > UpdraftPlus Backups > zakładka Existing backups. Wybierz backup sprzed awarii i kliknij Restore, zaznacz Database, potwierdź. Plugin pobiera plik SQL z Dropboxa, Google Drive lub S3, gdzie wcześniej był wysyłany, i przywraca tabele. Czas: 2–10 minut dla małych stron, 30 minut dla sklepów.

Przywrócenie z backupu hostingu. CyberFolks, LH.pl i Zenbox trzymają dzienne snapshoty baz 7–14 dni wstecz. W panelu klienta: Bazy danych > wybierz bazę > Przywróć > wybierz datę. Uwaga – operacja nadpisze aktualną bazę, więc utracisz dane z ostatnich godzin (zamówienia, komentarze, nowe posty). Zawsze pobierz aktualny backup zanim zaczniesz przywracanie – choćby po to, żeby móc wrócić, gdyby coś poszło nie tak.

Ręczna naprawa tabel przez phpMyAdmin. Jeśli problem jest lokalny (jedna tabela się rozsypała, nie cała baza), wejdź w phpMyAdmin, wybierz bazę, zaznacz wszystkie tabele, z listy na dole Repair table, wykonaj. MySQL próbuje naprawić strukturę i dane. Nie zawsze działa, ale warto sprawdzić przed pełnym restore.

WP-CLI do naprawy bazy:

wp db repair --allow-root
wp db check --allow-root
wp db optimize --allow-root

Wp-cli używa wewnętrznych mechanizmów WordPressa i MySQL do sprawdzenia integralności. Komenda `check` nie modyfikuje niczego, `repair` próbuje naprawić. Jeśli po tym dalej nie działa – tylko backup. Dlatego codzienny backup bazy to absolutna podstawa – opisaliśmy to szerzej w sekcji profilaktyki niżej.

WordPress od wersji 5.5 ma domyślnie włączone automatyczne aktualizacje wtyczek i motywów (tych, które sam zaznaczyłeś). Plus automatyczne minor updates core (z 6.4.1 na 6.4.2). W teorii wygodne – w praktyce czasami rano siadasz do komputera, a strona od 3:47 nie działa, bo auto-update wywrócił wtyczkę.

Jak zidentyfikować co się samo zaktualizowało. Zaloguj się do panelu admina. Kokpit > Aktualizacje – historia operacji pokaże datę i wersję. Jeśli panel nie działa, przez FTP otwórz `wp-content/debug.log` (jeśli miałeś włączony) albo `wp-content/upgrade/` – znajdziesz tam tymczasowe foldery z operacji. Sprawdź też e-mail – WordPress wysyła powiadomienie o auto-update'ach na adres administratora.

Szybkie wyłączenie auto-update na przyszłość – dodaj do `wp-config.php`:

// Wylaczenie auto-update core
define('AUTOMATIC_UPDATER_DISABLED', true);

// Wylaczenie auto-update core minor
define('WP_AUTO_UPDATE_CORE', false);

Wtyczki i motywy wyłączysz w panelu: Wtyczki > Zainstalowane > przy każdej kliknij Disable auto-updates. Albo przez WP-CLI hurtowo:

wp plugin auto-updates disable --all --allow-root
wp theme auto-updates disable --all --allow-root

Nie wyłączaj auto-update'ów w pełni – minor updates core zawierają poprawki bezpieczeństwa i blokowanie ich to zaproszenie do włamania. Złoty środek: auto-update core minor włączony, wtyczki i motywy manualne (robisz review raz w tygodniu na stagingu).

Rollback samej operacji robisz tak samo, jak w scenariuszach 1–3 – najpierw ustal, co się zaktualizowało, potem cofnij odpowiednią metodą. Różnica jest taka, że auto-update często zaskakuje cię w nocy, więc koszt jest wyższy – strona może nie działać 6–10 godzin zanim się obudzisz. Dlatego monitoring uptime (Uptime Robot) jest kluczowy – alert o awarii dostajesz w 2 minuty, nie rano po kawie.

Kiedy już wiesz, co się zaktualizowało, zamiast chaotycznie klikać, trzymaj się sprawdzonej procedury. Oto workflow, który stosujemy u klientów – od momentu telefonu strona nie działa do potwierdzenia wróciło.

Krok 1 – zabezpiecz obecny stan (2 minuty). Nawet jeśli strona jest popsuta, obecna baza danych może zawierać nowe zamówienia, komentarze, dane użytkowników. Zanim zaczniesz cokolwiek cofać, zrób szybki backup: `wp db export backup-awaria.sql --allow-root` albo przez phpMyAdmin > Export > Custom > Save as file. Odpakuj na dysk jako polisę.

Krok 2 – włącz tryb konserwacji (30 sekund). Stwórz pusty plik `.maintenance` w katalogu głównym WordPressa z zawartością: ``. Strona pokaże się jako Trwa krótkotrwała konserwacja – zero ruchu, zero zamówień podczas naprawy. Po skończeniu usuwasz plik.

Krok 3 – zdiagnozuj przyczynę (3 minuty). Sprawdź logi: `wp-content/debug.log`, logi serwera (`/home/user/logs/error.log`), panel hostingu > logi PHP. Pierwsza linia z Fatal error albo Call to undefined function pokaże ci winowajcę. Jeśli nie ma debug.log, włącz go w `wp-config.php` (patrz Scenariusz 1).

Krok 4 – wykonaj rollback (2–5 minut). W zależności od diagnozy wybierz metodę z jednego ze scenariuszy powyżej. Zasada: najmniej inwazyjna metoda najpierw (wyłączenie wtyczki przed downgrade core).

Krok 5 – przetestuj (3 minuty). Wyłącz tryb konserwacji. Otwórz stronę główną, jedną podstronę, stronę kontaktu, panel admina. Na sklepie: dodaj produkt do koszyka, przejdź do kasy, wypełnij dane testowe. Sprawdź, czy e-maile wychodzą (WordPress > Komentarz testowy).

Krok 6 – zbadaj przyczynę i zaplanuj trwałe rozwiązanie (5 minut dokumentacji). Rollback to tylko plaster. Teraz musisz ustalić: czemu to pękło? Stary motyw? Niekompatybilna wtyczka? Zbyt ambitny update? Zapisz wniosek i dodaj do checklisty nie aktualizuj automatycznie dla tej konkretnej pozycji. Zgłoś błąd autorowi wtyczki – następna wersja może to naprawić. Po tygodniu spróbuj update ponownie, tym razem na stagingu.

Rollback ratuje, ale lepiej nie musieć go używać. Oto pięć nawyków, które minimalizują ryzyko awarii przy następnej aktualizacji.

Środowisko staging. Najlepsze hostingi (CyberFolks, LH.pl, Zenbox, Cloudways) oferują one-click staging – kopię twojej strony na subdomenie typu `staging.twojadomena.pl`. Aktualizacje robisz najpierw tam: klikasz update, klikasz kilka stron, sprawdzasz kasę sklepu, dopiero potem pushujesz zmiany na produkcję. Koszt: 0 zł (u większości dobrych hostingów w cenie), czas: dodatkowe 15 minut przed każdym update. Opłaca się pierwszego dnia, kiedy wykryjesz zepsutą wtyczkę na stagingu zamiast na produkcji w porze obiadu.

Codzienny backup do zewnętrznej lokalizacji. UpdraftPlus (darmowy) plus Dropbox lub Google Drive to standard. Konfiguracja: Ustawienia > UpdraftPlus > Schedule backup: Daily (files) plus Daily (database). Retain: 14 dni. Destination: Dropbox. Efekt: zawsze masz 14 ostatnich snapshotów na zewnątrz, jeden klik do restore. Backup na serwerze nie wystarczy – jeśli padnie dysk, tracisz wszystko.

Selektywne updates zamiast Update all. Przycisk Update all w panelu jest pokusą, ale to droga do katastrofy. Aktualizuj po jednej wtyczce na raz, z przerwą 30 sekund między nimi i testem podstawowej funkcjonalności. Jeśli coś pęknie – wiesz dokładnie, która wtyczka. Update all działa, ale debugging zajmuje godzinę zamiast 2 minut.

Review changelog przed update'em. Większość dobrych wtyczek publikuje changelog na stronie wordpress.org (zakładka Development > Changelog). Jeśli widzisz Major rewrite, Database structure changed, Breaking change – odczekaj tydzień, przeczytaj raporty innych użytkowników, sprawdź forum wtyczki. Drobne bugfixy możesz aktualizować od razu.

Monitoring uptime. Uptime Robot lub StatusCake (darmowe) wysyłają ci SMS lub e-mail, gdy strona padnie – nawet w środku nocy, nawet jeśli auto-update wywrócił stronę. Zamiast dowiedzieć się od klienta, że kasa nie działa od 6 godzin, masz alert w 2 minuty po awarii. Można wrócić z łóżka i zrobić rollback, zanim ruch na stronie spadnie do zera.

Większość scenariuszy opisanych wyżej ogarniesz samodzielnie w 15 minut, o ile masz podstawową znajomość FTP, panelu hostingu i `wp-config.php`. Ale są sytuacje, kiedy warto zadzwonić po pomoc – bo ryzyko pogorszenia sytuacji przewyższa koszt godziny pracy developera.

Sklep WooCommerce z ruchem powyżej 50 zamówień dziennie. Każda godzina przestoju to utracone zamówienia i wkurzeni klienci. Jeśli nie jesteś pewien, co robisz, i strona padła po aktualizacji, zadzwoń od razu, zamiast eksperymentować. Koszt godziny pracy (200–400 zł) jest nieporównywalny ze stratami ze sprzedaży przy dłuższej awarii.

Strona korporacyjna z formularzami kontaktowymi prowadzącymi do CRM. Jeśli po update kontakt z klientami nie dociera, tracisz leady warte tysiące złotych dziennie. Zadzwoń natychmiast – nie próbuj własnymi siłami.

Nie masz żadnego backupu. Jeśli robisz rollback na ślepo, bez kopii bazy i plików, każda pomyłka jest nieodwracalna. Usuniesz wrong folder, nadpiszesz coś ważnego i koniec. W takiej sytuacji lepiej zostawić stronę popsutą i zadzwonić po specjalistę, który zrobi backup przed operacją.

Błędy, których nie rozumiesz. Jeśli w `debug.log` widzisz coś w stylu Cannot unserialize object albo Deprecated: Required parameter follows optional, a nie wiesz, co to znaczy, nie próbuj edytować kodu PHP. Jeden zły znak i strona pada na dobre.

Hosting współdzielony z uprawnieniami tylko do FTP. Jeśli nie masz SSH i phpMyAdmina, a problem jest w bazie, trudno będzie naprawić bez pomocy supportu hostingu albo osoby z większym dostępem. Zadzwoń do nas przez formularz kontaktowy – zrobimy rollback, backup i staging, dostaniesz raport z opisem co było nie tak i jak tego uniknąć następnym razem. Jeśli potrzebujesz długofalowej opieki nad WordPressem (updates, backupy, monitoring), zerknij na ofertę WordPress i strony internetowe. Dla pełnej weryfikacji stanu twojej strony (nie tylko po awarii) zamów audyt cyfrowy – pokażemy wszystkie słabe punkty zanim wyłożą cię na kolana.