Problemy po aktualizacji WordPress – rollback i naprawa 2026

Kiedy aktualizacja pójdzie nie tak, objawy bywają różne, ale ograniczają się do sześciu głównych scenariuszy. Rozpoznanie, który z nich Cię dotyczy, to pierwszy krok do szybkiej naprawy.

Sześć najczęstszych problemów po aktualizacji:

1. Biały ekran śmierci (WSOD) – wchodzisz na stronę, wyświetla się pusta biała plansza, żadnego komunikatu. Zazwyczaj oznacza fatal error w PHP. Szczegółowo opisałem to zjawisko w poradniku biały ekran WordPress – WSOD krok po kroku.
2. HTTP Error 500 – serwer zwraca komunikat "Internal Server Error". Najczęstsza przyczyna to uszkodzony plik .htaccess, konflikt wtyczek albo wyczerpany limit pamięci PHP.
3. Błąd krytyczny – "Na tej stronie wystąpił błąd krytyczny" – WordPress od wersji 5.2 łapie fatal errory i wyświetla friendly komunikat plus wysyła maila z linkiem do trybu odzyskiwania (recovery mode). Sprawdź skrzynkę admina.
4. Brak stylów / strona bez CSS – strona ładuje się, ale wygląda jak goły HTML z lat 90. Zwykle to konflikt z cache (Cloudflare, wtyczka cache) albo problem z ładowaniem zasobów po zmianie wersji.
5. Nie mogę się zalogować do /wp-admin – login przechodzi, ale zamiast dashboardu dostajesz biały ekran albo pętlę przekierowań. Klasycznie konflikt wtyczki bezpieczeństwa lub cache sesji.
6. Strona działa, ale część funkcji zniknęła – np. slider nie działa, WooCommerce nie pokazuje koszyka, formularz kontaktowy przestał wysyłać maile. Sygnał, że konkretna wtyczka jest niekompatybilna z nową wersją.

W każdym z tych przypadków fundament naprawy wygląda tak samo: zidentyfikuj co aktualizowałeś ostatnio, sprawdź logi i metodycznie wyłącz podejrzane komponenty.

Zanim zaczniesz grzebać w plikach, odpowiedz sobie na trzy pytania. Odpowiedzi zaoszczędzą Ci godziny błądzenia.

Pytanie 1: Co konkretnie aktualizowałeś?

• Tylko core WordPress (np. z 6.4 na 6.5)? → winowajcą najpewniej jest wtyczka lub motyw, które nie są jeszcze zgodne.
• Jedną wtyczkę? → idź od razu do sekcji o rollback wtyczki.
• Wszystko naraz (core + wtyczki + motyw)? → najgorszy scenariusz, wróć do backupu albo zacznij od wyłączania wtyczek.
• Wersję PHP na serwerze? → sprawdź, czy nowe PHP nie wywala deprecated functions w starych wtyczkach.

Pytanie 2: Czy masz dostęp do /wp-admin?

Jeżeli tak, debug jest prosty – włącz Query Monitor, wejdź w narzędzia i sprawdź komunikaty. Jeżeli nie, musisz działać przez FTP/SFTP albo panel hostingu (File Manager, phpMyAdmin).

Pytanie 3: Czy masz backup sprzed aktualizacji?

Jeżeli tak, i strona jest produkcyjna z klientami czekającymi na zakupy – nie eksperymentuj, przywróć backup i zrób drugie podejście na staging. Jeżeli nie, trzeba naprawiać w locie – czytaj dalej.

Kolejność debugowania, która działa w 9 na 10 przypadków:

1. Włącz WP_DEBUG w wp-config.php
2. Sprawdź /wp-content/debug.log i logi serwera (error_log w public_html)
3. Wyłącz wszystkie wtyczki przez FTP (zmiana nazwy folderu)
4. Jeśli strona wróciła – włączaj wtyczki pojedynczo
5. Znajdź winowajcę i zrób rollback tej konkretnej wtyczki
6. Jeśli wyłączenie wtyczek nie pomaga – zmień motyw na domyślny Twenty Twenty-Four
7. Jeśli to też nie działa – problem jest w core, rób rollback WordPressa

Trzymaj się tej kolejności zamiast losowo klikać – oszczędzi Ci nerwów. Jeśli Twoja strona padła całkowicie, zajrzyj też do osobnego poradnika WordPress padł po aktualizacji – rollback i naprawa, który opisuje scenariusze krytyczne.

Biały ekran niemal zawsze oznacza fatal error w PHP, który WordPress połyka bez wyświetlania komunikatu. Twoim zadaniem jest zmusić go do gadania.

Krok 1: Włącz WP_DEBUG

Zaloguj się na FTP (FileZilla, WinSCP albo File Manager w panelu hostingu) i otwórz plik `wp-config.php` w głównym katalogu WordPressa. Znajdź linię `define('WP_DEBUG', false);` albo dodaj przed komentarzem `/* That's all, stop editing! */` następujący blok:

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

Co to robi: włącza tryb debug, zapisuje błędy do pliku `/wp-content/debug.log`, ale nie wyświetla ich odwiedzającym (bezpieczeństwo na produkcji).

Krok 2: Odśwież stronę i przeczytaj log

Wejdź na stronę, żeby wygenerować błąd, potem otwórz `/wp-content/debug.log`. Szukaj linii zaczynających się od `PHP Fatal error`. Najczęstsze komunikaty:

• `Call to undefined function` – wtyczka wywołuje funkcję, której już nie ma w nowej wersji WordPressa.
• `Cannot redeclare function` – dwie wtyczki definiują tę samą funkcję, konflikt.
• `Allowed memory size of X bytes exhausted` – zabrakło RAM-u, dodaj `define('WP_MEMORY_LIMIT', '512M');` do wp-config.
• `Class not found` – brakuje pliku biblioteki, możliwe, że aktualizacja core usunęła stare API.

Krok 3: Sprawdź logi serwera

WordPressowy debug.log łapie tylko część błędów. Serwer Apache/Nginx ma własne logi, zwykle pod ścieżką `/home/{user}/logs/` albo dostępne w panelu hostingu (Błędy, Error Log). Na CyberFolks znajdziesz je w zakładce Statystyki → Dziennik błędów. Poradnik rozszerzony: biały ekran WordPress – WSOD krok po kroku.

Krok 4: Wyłącz WP_DEBUG po naprawie

Na produkcji debug powinien być wyłączony. Zostaw go włączonego tylko na staging albo lokalnie.

Gdy /wp-admin nie działa, musisz wyłączyć wtyczki bez klikania w dashboardzie. Są dwa bezpieczne sposoby.

Metoda 1: Zmiana nazwy folderu przez FTP (najszybsza)

1. Połącz się FTP-em do WordPressa.
2. Przejdź do `/wp-content/`.
3. Zmień nazwę folderu `plugins` na `plugins_off`.
4. Odśwież stronę. Jeśli zadziałała, winowajcą była któraś wtyczka.
5. Zmień nazwę z powrotem na `plugins` – wszystkie wtyczki są teraz wyłączone w bazie.
6. Zaloguj się do /wp-admin → Wtyczki. Włączaj je pojedynczo, odświeżając stronę po każdej. Ta, która rozwali serwis, to winowajca.

Metoda 2: Wyłącz konkretną wtyczkę przez phpMyAdmin

Gdy wiesz lub podejrzewasz, która wtyczka winna:

1. Zaloguj się do phpMyAdmin w panelu hostingu.
2. Otwórz tabelę `wp_options` (prefiks może być inny).
3. Znajdź wiersz `option_name = active_plugins`.
4. Kliknij Edytuj – zobaczysz serializowaną tablicę PHP z listą aktywnych wtyczek.
5. Zamiast edytować (łatwo zepsuć serializację), po prostu usuń cały wiersz – WordPress potraktuje to jak brak aktywnych wtyczek.
6. Wejdź do /wp-admin → Wtyczki i włączaj jedną po drugiej.

Metoda 3: WP-CLI (dla hostingów z SSH)

Jeśli masz SSH (CyberFolks, LH, Zenbox), to najszybsze:

wp plugin list --status=active
wp plugin deactivate --all
wp plugin activate advanced-custom-fields  # po jednej

Typowi winowajcy konfliktów:

Jeśli strona po wyłączeniu wszystkich wtyczek wciąż nie działa, problem leży w motywie albo core. Szczegółowy scenariusz naprawy omawiam w poradniku WordPress padł po aktualizacji – rollback i naprawa.

Znalazłeś winną wtyczkę. Teraz musisz cofnąć ją do wersji sprzed aktualizacji. Są trzy drogi.

Sposób 1: Wtyczka WP Rollback (najprostsza)

1. Zainstaluj wtyczkę WP Rollback z repozytorium WordPress.org (darmowa, aktywnie rozwijana).
2. Po aktywacji przy każdej wtyczce z oficjalnego repo zobaczysz przycisk "Rollback" obok "Deaktywuj".
3. Kliknij Rollback → wybierz poprzednią stabilną wersję → potwierdź.
4. WP Rollback automatycznie ściągnie starszą wersję z SVN WordPress.org i podmieni pliki.

Ograniczenie: działa tylko dla wtyczek z oficjalnego repozytorium. Dla premium (Elementor Pro, ACF Pro, WooCommerce rozszerzenia z woocommerce.com) musisz użyć metody ręcznej.

Sposób 2: Ręczny rollback z WordPress.org

1. Wejdź na stronę wtyczki na WordPress.org, np. `https://wordpress.org/plugins/nazwa-wtyczki/`.
2. W prawej kolumnie kliknij "Advanced View".
3. Na dole znajdziesz sekcję "Previous versions" z listą.
4. Wybierz wersję sprzed problemu, pobierz ZIP.
5. Przez FTP wejdź do `/wp-content/plugins/`, usuń folder wtyczki.
6. Rozpakuj pobrany ZIP i wgraj folder na serwer.
7. W /wp-admin → Wtyczki kliknij Aktywuj.

Sposób 3: Rollback wtyczki premium

Większość wtyczek premium (Elementor Pro, WP Rocket, Yoast Premium) ma w panelu konta u producenta listę poprzednich wersji. Zaloguj się, pobierz starszy ZIP, wgraj ręcznie przez FTP. Niektóre mają też licencje per-site z możliwością instalacji starszej wersji przez zip upload w /wp-admin.

Praktyczna wskazówka: Po udanym rollbacku zablokuj automatyczne aktualizacje tej konkretnej wtyczki do czasu, aż deweloper wyda fix. W /wp-admin → Wtyczki kliknij "Wyłącz automatyczne aktualizacje". Inaczej za tydzień znów będziesz gasił ten sam pożar. Po rollbacku warto też przeskanować witrynę pod kątem malware – szczegóły w WordPress zhakowany – malware i naprawa.

Zdarza się, że winowajcą jest sam core. Cofnięcie głównej wersji WordPressa brzmi groźnie, ale jest relatywnie proste, o ile masz dostęp do bazy.

Metoda 1: WP-CLI (jednolinijkowiec)

Na hostingu z SSH:

wp core update --version=6.4.3 --force --allow-root
wp core update-db --allow-root

Flaga `--force` mówi WP-CLI: "tak, wiem, że to downgrade, rób to". Polecenie pobierze starszą wersję i podmieni wszystkie pliki core.

Metoda 2: Ręcznie przez FTP

1. Pobierz starszą wersję z `https://wordpress.org/download/releases/`.
2. Rozpakuj ZIP lokalnie.
3. Połącz się FTP-em do WordPressa.
4. Usuń z serwera dwa foldery: `/wp-admin/` i `/wp-includes/`.
5. Wgraj te same foldery z pobranego ZIP-a (plus pliki w root poza `wp-config.php` i folderem `/wp-content/`).
6. Zaloguj się do /wp-admin – WordPress poprosi o zaktualizowanie bazy danych (w dół). Kliknij przycisk.

Co zostawić nietknięte:

• `/wp-content/` (wtyczki, motywy, uploads) – tego nie ruszaj.
• `wp-config.php` – konfiguracja.
• `.htaccess` – przepisywanie URL.

Uwaga o bazie danych: Core'owe updaty często modyfikują strukturę tabel (nowe kolumny, indeksy). Downgrade zwykle działa, bo nowe kolumny po prostu zostają niewykorzystane, ale jeśli aktualizacja była majora (np. 6.x → 7.x kiedyś w przyszłości), to bez backupu bazy możesz mieć problem. Dlatego punkt 7 tego poradnika istnieje.

Tryb odzyskiwania (Recovery Mode):

WordPress od wersji 5.2 wysyła na maila admina link do tak zwanego recovery mode, gdy wykryje fatal error. Sprawdź skrzynkę – link prowadzi do specjalnego trybu /wp-admin, gdzie możesz wyłączyć wtyczkę lub motyw, nawet gdy normalnie strona pada. To najszybsza droga, jeśli masz dostęp do maila.

Statystycznie 70% katastrof po aktualizacji wynika nie z samej aktualizacji, ale z faktu, że nikt nie zrobił backupu i nie ma do czego wrócić. Backup to nie paranoja, tylko higiena.

Co musi zawierać pełny backup WordPressa:

1. Pliki – cały katalog `/home/{user}/htdocs/{domena}/` (WordPress + wp-content z motywami, wtyczkami, uploadami).
2. Baza danych – eksport SQL z phpMyAdmin albo `mysqldump`.
3. Plik konfiguracyjny – `wp-config.php` (jest w katalogu WordPressa, ale warto mieć na osobnym backupie bo zawiera hasło do bazy).

Jeden bez drugiego to połowiczny backup. Treść posta jest w bazie, a zdjęcie do niego na dysku – musisz mieć jedno i drugie.

Popularne wtyczki backupowe – porównanie:

Backup poziomu serwera (najpewniejszy):

Większość dobrych hostingów (CyberFolks, LH, Zenbox) robi codziennie backup automatyczny na osobnej infrastrukturze. Sprawdź w panelu – przywrócenie to często jeden klik i 2 minuty oczekiwania. Jeśli Twój hosting nie ma backupów w standardzie albo kosztują extra, to pierwszy powód do zmiany hostingu.

Manualny backup przed każdą aktualizacją (procedura na 3 minuty):

1. Panel hostingu → File Manager → spakuj `/htdocs/{domena}/` do ZIP.
2. Panel hostingu → phpMyAdmin → wybierz bazę → Eksportuj → Quick → SQL → Wykonaj.
3. Pobierz oba pliki na dysk lokalny albo do chmury.
4. Dopiero teraz klikaj Aktualizuj w /wp-admin.

Trzy minuty pracy vs trzy godziny naprawiania – kalkulacja jest oczywista. Jeśli budujesz nową stronę od zera, warto od razu wdrożyć backup i staging – usługę strony internetowe WordPress zawsze startujemy z tą higieną.

Najczęstsze pytanie klientów brzmi: "Aktualizowałem WordPress pół roku temu i wszystko było OK, teraz ta sama akcja zabiła stronę. Co się zmieniło?" Odpowiedź: bardzo wiele.

Cztery najczęstsze przyczyny "zepsutej" aktualizacji, która kiedyś działała:

1. Nowsza wersja PHP na serwerze

Hostingi co kilka miesięcy podnoszą domyślną wersję PHP. Z 7.4 na 8.0, potem 8.1, teraz (2026) standardem jest 8.2 lub 8.3. Każde duże bump PHP wyrzuca deprecated functions. Wtyczka, która rok temu pięknie działała na PHP 7.4, dzisiaj na PHP 8.2 rzuca fatal errorem przy aktualizacji. Sprawdź aktualne PHP w panelu hostingu – jeśli niedawno się zmieniło, to najprawdopodobniej winowajca.

2. Porzucona wtyczka (abandoned plugin)

Wtyczki z WordPress.org bez updatu 12+ miesięcy to czerwona lampka. Deweloper odszedł, API się zmieniło, a wtyczka dalej siedzi w Twoim WordPressie. Sprawdzaj na każdej wtyczce komunikat typu "This plugin has not been tested with the latest 3 major releases of WordPress". Czas ją zastąpić albo usunąć.

3. Konflikt nowych API WordPress

Core zmienia API z wersji na wersję. Od WP 6.2 mamy Block Editor iterations, od 6.4 modyfikacje w HTML API, od 6.5 nowości w Interactivity API. Stare wtyczki, które nadpisywały hooki w niestandardowy sposób, po każdej takiej zmianie łamią się.

4. Cumulative effect – długo nieaktualizowana strona

Jeśli ostatnio aktualizowałeś rok temu i robisz skok z WP 6.3 na 6.5, to łączysz dwa major updaty naraz. Zwiększa się szansa na konflikt. Lepiej aktualizować małymi porcjami co miesiąc niż raz na rok tona zmian.

Jak sprawdzić kompatybilność PHP z wtyczkami:

Zainstaluj wtyczkę "PHP Compatibility Checker" od WP Engine (darmowa). Przeskanuje Ci cały motyw i wtyczki pod kątem wybranej wersji PHP. Raport pokaże, co się wywali, zanim się wywali.

Jeśli podejrzewasz zhakowanie strony, które zbiegło się z aktualizacją (czasem malware wywołuje errory po update), przeczytaj też poradnik WordPress zhakowany – malware i naprawa.

Aktualizowanie produkcji bez testu to jak operacja bez znieczulenia – technicznie możliwe, ale bardzo bolesne. Staging environment to kopia Twojej strony na wydzielonej subdomenie (np. staging.twojadomena.pl), na której testujesz zmiany przed puszczeniem na live.

Dwa modele staging:

Model 1: Staging wbudowany w hosting (najłatwiejszy)

Hostingi klasy premium – CyberFolks, LH.pl, Zenbox – oferują jeden klik "utwórz staging". System klonuje produkcję na subdomenę, daje Ci dashboard do przełączania zmian między staging a live. Workflow:

1. Klonujesz produkcję na staging (1 klik, 2 minuty).
2. Robisz na staging wszystkie aktualizacje (core, wtyczki, motyw).
3. Testujesz kluczowe funkcje: formularz, zakup, logowanie, kasa WooCommerce.
4. Jeśli działa, klikasz "Push to production" albo ręcznie powtarzasz te same aktualizacje na live (wiesz już, że są bezpieczne).

Model 2: WP Staging plugin (dla hostingów bez wbudowanego staging)

Darmowa wtyczka WP Staging tworzy klon WordPressa w podkatalogu (np. /twojadomena.pl/staging/). Pro wersja umożliwia staging na osobnej bazie. Działa, ale ma ograniczenia: staging i live dzielą ten sam hosting, więc jeśli błąd skorumpuje bazę na staging, może przelać się na live.

Checklist testów na staging przed push do live:

• [ ] Strona główna ładuje się bez błędów konsoli JS
• [ ] Menu i subpages działają
• [ ] Formularz kontaktowy wysyła maila testowego
• [ ] Dla WooCommerce: dodanie do koszyka, checkout, złożenie zamówienia testowego
• [ ] Panel admina ładuje się i edycja postów działa
• [ ] Media uploader przyjmuje obrazki
• [ ] Cache jest wyczyszczony i style ładują się poprawnie
• [ ] Mobilny widok działa (Chrome DevTools → responsive mode)
• [ ] Logi (debug.log i error_log serwera) są czyste

Koszt staging – realne liczby:

Sensowny hosting z wbudowanym staging startuje od 20-40 zł/miesiąc. Naprawa profesjonalna padniętej strony po nieudanej aktualizacji to zwykle 300-800 zł jednorazowo (więcej o tym w analizie ile kosztuje naprawa WordPressa, jeśli masz taki artykuł). ROI staging payuje się przy pierwszej oszczędzonej katastrofie.

Nie każdy problem opłaca się naprawiać samodzielnie. Są sytuacje, w których próba DIY pogarsza stan i podnosi koszt profesjonalnej naprawy.

Pięć sytuacji, w których dzwoń po wsparcie zamiast kombinować:

1. Uszkodzenie bazy danych (database corruption)

Objawy: błędy typu "Error establishing a database connection" mimo poprawnego wp-config.php, komunikaty "Table 'wp_posts' is marked as crashed", znikające fragmenty tabel. Próby naprawy bez znajomości MySQL mogą dobić bazę. Potrzebujesz kogoś, kto zrobi `REPAIR TABLE`, sprawdzi integralność i – jeśli trzeba – przywróci z binlogów.

2. Zhakowanie zbieżne z aktualizacją

Jeśli po aktualizacji widzisz dziwne pliki w /wp-content/, niechciane przekierowania, podejrzane konta admina albo alert Google Safe Browsing – to nie jest zwykły konflikt. Malware mógł siedzieć na stronie od dawna i aktualizacja go odsłoniła. DIY tutaj oznacza walkę z duchami. Zobacz poradnik WordPress zhakowany – jak wyczyścić malware, ale wiedz, że pełny clean-up zwykle wymaga specjalisty.

3. Brak dostępu do FTP, SSH ani panelu hostingu

Jeśli zgubiłeś dane dostępowe, a hosting nie odpowiada szybko, a strona tymczasem jest offline z klientami dzwoniącymi – to sytuacja kryzysowa. Ekspert ma często relacje z hostingami i wie, jak skrócić drogę weryfikacji.

4. Skomplikowana instalacja WooCommerce z integracjami

Sklep z 10 tysiącami produktów, integracją z Baselinker, Allegro, systemami płatności i kurierami – to setki punktów, które mogą się zepsuć. DIY tutaj grozi godzinami przestoju i utratą zamówień. Lepiej zapłacić za godzinę pracy specjalisty niż stracić dzień sprzedaży.

5. Strona jest Twoim głównym źródłem leadów

Każda godzina offline = utracone zapytania. Jeśli zarabiasz na niej 10k+ miesięcznie, kilkaset złotych za szybką interwencję to inwestycja, a nie wydatek.

Nasza oferta – szybka interwencja WordPress

W KC Mobile robimy interwencyjne naprawy WordPressa w ciągu kilku godzin od zgłoszenia. Zaczynamy od bezpłatnej diagnozy przez telefon, potem robimy backup i pracujemy na środowisku testowym, żeby nie pogorszyć sytuacji. Jeżeli Twoja strona właśnie padła po aktualizacji i nie wiesz, co robić – zadzwoń pod +48 604 939 140 albo napisz przez formularz kontaktowy. Zajmujemy się też budową nowych stron od zera – zobacz ofertę strony internetowe WordPress, jeśli Twoja obecna strona jest tak przestarzała, że łatanie nie ma sensu. Szczegóły kontaktu znajdziesz na /kontakt/.

Warto też wspomnieć, że część aktualizacji wywala stronę nie z powodu core'a, tylko wolnego ładowania obrazków po zmianach w silniku media. Jeśli masz problem z WebP po aktualizacji, zajrzyj do poradnika najlepsze wtyczki do WebP.

Wiele z tych problemów można rozwiązać samodzielnie – ale gdy brakuje czasu, narzędzi lub utknąłeś na etapie diagnozy, warto zlecić pracę zespołowi który robi to codziennie. W KC Mobile zajmujemy się tym od lat.

Zobacz powiązane usługi i materiały:

• wdrożenie WordPress
• strona na WordPressie
• najlepszy hosting WordPress
• PHP memory limit WordPress
• biały ekran śmierci (WSOD)

Jeśli opis w tym wpisie nie dotyczy dokładnie Twojej sytuacji, napisz do nas – odpowiadamy w ciągu 24 godzin roboczych.