Strona nie działa po aktualizacji – jak to cofnąć i naprawić

Autor: Grzegorz Wojterzak. Aktualizacja: 12 października 2026. Czas czytania: około 12 minut.

Aktualizacja to najczęstszy moment, w którym psuje się działająca strona. Nie dlatego, że aktualizacje są złe, tylko dlatego, że WordPress to układanka z kilkudziesięciu elementów od różnych autorów. Nowa wersja jednego elementu może przestać pasować do innego. Dobra wiadomość: skoro wiesz, co zmieniło się jako ostatnie, wiesz też, co cofnąć.

Co się dzieje podczas aktualizacji i gdzie może się zepsuć

Aktualizacja w WordPressie to kilka kroków wykonywanych jeden po drugim. Awaria w każdym z nich daje inny objaw, więc warto wiedzieć, na którym etapie coś poszło nie tak.

Najpierw: ustal, co dokładnie było aktualizowane

Zanim cokolwiek cofniesz, ustal winowajcę. Przy jednej ręcznej aktualizacji jest to oczywiste. Przy aktualizacjach automatycznych albo kilku naraz trzeba to sprawdzić:

• Mail od WordPressa. Po automatycznych aktualizacjach WordPress wysyła na adres administratora podsumowanie z listą zaktualizowanych wtyczek i motywów.
• Daty zmian katalogów. W wp-content/plugins/ posortuj katalogi po dacie modyfikacji. Te zmienione w dniu awarii to podejrzani.
• Log błędów. Jeśli strona pokazuje błąd krytyczny lub biały ekran, włącz WP_DEBUG_LOG i sprawdź ścieżkę w linii PHP Fatal error. Szczegóły w artykule o błędzie krytycznym WordPress.
• WP-CLI. Polecenie wp plugin list --skip-plugins --skip-themes pokaże wersje wszystkich wtyczek, nawet gdy strona nie działa.

Szybkie cofnięcie aktualizacji

Wybierz metodę zależnie od tego, co zostało zaktualizowane i jaki masz dostęp. Kolejność w tabeli to kolejność, w której je rozważam: od najmniej inwazyjnej do najbardziej.

Poprzednia wersja wtyczki lub motywu

Wtyczki z katalogu wordpress.org mają archiwum wcześniejszych wersji. Na stronie wtyczki w zakładce dla zaawansowanych (Advanced View) jest lista starszych wersji do pobrania. Pobierz ZIP z wersją, którą miałeś przed aktualizacją, i wgraj go przez FTP w miejsce bieżącego katalogu wtyczki.

Z WP-CLI wystarczy jedno polecenie. Opcja --force nadpisuje zainstalowaną wersję bez pytania:

# sprawdź, jaką wersję masz teraz
wp plugin get nazwa-wtyczki --field=version --skip-plugins --skip-themes

# zainstaluj poprzednią wersję w miejsce obecnej
wp plugin install nazwa-wtyczki --version=2.4.1 --force --skip-plugins --skip-themes

# to samo dla motywu z wordpress.org
wp theme install nazwa-motywu --version=1.8.0 --force --skip-plugins --skip-themes

Wtyczki i motywy płatne nie pochodzą z wordpress.org, więc ich starszych wersji szukaj na koncie u producenta albo w kopii zapasowej. Wtedy ZIP podajesz zamiast nazwy: wp plugin install ./wtyczka-2.4.1.zip --force.

Poprzednia wersja WordPressa

Cofnięcie rdzenia jest potrzebne rzadko, bo zwykle to wtyczka nie nadąża za nową wersją WordPressa. Jeśli jednak trzeba, WP-CLI pozwala zainstalować konkretną wersję. Bez --force odmówi zainstalowania wersji starszej od obecnej:

wp core version --skip-plugins --skip-themes
wp core update --version=6.7.2 --force --skip-plugins --skip-themes

Bez SSH pobierz paczkę z archiwum wydań na wordpress.org i wgraj przez FTP katalogi wp-admin i wp-includes oraz pliki z głównego katalogu, pomijając wp-content i wp-config-sample.php. Starsza wersja rdzenia to rozwiązanie tymczasowe. Wróć do najnowszej, gdy tylko winna wtyczka dostanie poprawkę.

Kopia zapasowa z hostingu

Większość polskich hostingów robi automatyczne kopie plików i baz danych i pozwala przywrócić je z panelu. Zanim to zrobisz, zastanów się, co stracisz: wszystko, co zmieniło się od momentu kopii. W sklepie to zamówienia, rejestracje klientów i stany magazynowe. Jeśli możesz, przywróć tylko pliki, a bazę zostaw, albo przywróć kopię do osobnego katalogu i skopiuj z niej tylko katalog jednej wtyczki.

Automatyczne cofanie w WordPressie 6.6 i nowszym

Od wersji 6.6 WordPress ma wbudowane zabezpieczenie dla automatycznych aktualizacji wtyczek. Przed aktualizacją przenosi starą wersję wtyczki do katalogu tymczasowego wp-content/upgrade-temp-backup/. Po aktualizacji aktywnej wtyczki wysyła zapytanie do własnej strony i sprawdza, czy nie zwraca ona błędu krytycznego. Jeśli zwraca, przywraca poprzednią wersję i informuje o tym w mailu do administratora.

To dobre zabezpieczenie, ale ma wyraźne granice:

• działa tylko przy aktualizacjach automatycznych, a nie po kliknięciu „Aktualizuj” w panelu,
• dotyczy wtyczek, a nie motywów i nie rdzenia (rdzeń ma własny mechanizm przy aktualizacjach automatycznych),
• wykrywa tylko błąd krytyczny PHP, a nie zepsuty wygląd, niedziałający koszyk czy błąd JavaScriptu,
• sprawdza stronę jednym zapytaniem, więc nie zauważy błędu, który pojawia się tylko na wybranej podstronie,
• nie sprawdza wtyczek nieaktywnych.

Jeśli dostałeś mail, że aktualizacja wtyczki zawierała błąd krytyczny i przywrócono poprzednią wersję, strona prawdopodobnie działa. Nie aktualizuj tej wtyczki ponownie, dopóki autor nie wyda poprawki albo dopóki nie sprawdzisz przyczyny na kopii strony.

Zawieszony tryb konserwacji

Na czas aktualizacji WordPress tworzy w głównym katalogu strony plik .maintenance. Dopóki ten plik istnieje, odwiedzający widzą komunikat, że strona jest chwilowo niedostępna z powodu zaplanowanych prac konserwacyjnych (w angielskiej wersji: „Briefly unavailable for scheduled maintenance. Check back in a minute.”). Gdy aktualizacja się przerwie, plik zostaje.

1. Usuń plik .maintenance

   Połącz się przez FTP lub otwórz menedżer plików i usuń plik .maintenance z katalogu, w którym leży wp-config.php. Nazwa zaczyna się od kropki, więc w niektórych programach FTP musisz włączyć pokazywanie plików ukrytych. WordPress i tak przestaje uznawać ten plik po 10 minutach od rozpoczęcia aktualizacji, ale niektóre cache potrafią dłużej serwować zapisany komunikat.

2. Sprawdź, czy aktualizacja się zakończyła

   Przerwana aktualizacja mogła zostawić niekompletny katalog wtyczki. Jeśli po usunięciu pliku widzisz błąd krytyczny z komunikatem Failed opening required, zainstaluj tę wtyczkę ponownie w aktualnej wersji. Zajrzyj też do wp-content/upgrade/: zostawione tam katalogi można usunąć.

3. Usuń blokadę aktualizacji rdzenia, jeśli trzeba

   Gdy przy ponownej próbie aktualizacji WordPressa widzisz informację, że inna aktualizacja jest w toku, a jesteś pewien, że nic się nie aktualizuje, usuń blokadę: wp option delete core_updater.lock. Blokada wygasa też sama po kilkunastu minutach.

WooCommerce: szablony nadpisane w motywie

WooCommerce pozwala motywom nadpisywać swoje szablony: koszyk, stronę produktu, maile. Motyw trzyma wtedy własne kopie plików w katalogu wp-content/themes/twoj-motyw/woocommerce/. Każdy szablon WooCommerce ma w nagłówku numer wersji (@version). Gdy WooCommerce zmieni szablon, a motyw ma starą kopię, mogą pojawić się braki w koszyku, zdublowane elementy, niedziałające przyciski albo błędy PHP.

1. Sprawdź raport stanu systemu

   W panelu wejdź w WooCommerce, Status. Na końcu raportu, w części dotyczącej szablonów, WooCommerce wypisuje szablony nadpisane przez motyw i zaznacza te, które są nieaktualne, podając wersję w motywie i wersję w WooCommerce. Po aktualizacji WooCommerce w panelu może też pojawić się komunikat o nieaktualnych kopiach szablonów w motywie.

2. Zaktualizuj motyw

   Jeśli używasz motywu komercyjnego, jego autor zwykle wydaje aktualizację z poprawionymi szablonami. To najprostsza droga.

3. Albo zaktualizuj kopie szablonów ręcznie

   Gdy nadpisane szablony są w motywie potomnym, który zrobiono na zamówienie, trzeba porównać każdy z nową wersją z katalogu wp-content/plugins/woocommerce/templates/ i przenieść własne zmiany do nowej wersji. Tymczasowo możesz zmienić nazwę nieaktualnego pliku w motywie: WooCommerce użyje wtedy swojego, domyślnego szablonu.

Cache i CDN po aktualizacji

Jeśli po aktualizacji strona działa, ale wygląda źle, przyciski nie reagują albo edytor jest pusty, przyczyną często są stare pliki CSS i JavaScript. Wtyczki optymalizujące łączą i minimalizują pliki, a cache serwera i CDN trzymają kopie stron. Po aktualizacji nowy kod HTML może odwoływać się do stylów, których w cache jeszcze nie ma.

• wyczyść cache we wtyczce cache lub optymalizacji (w tym pliki połączone i zminimalizowane),
• wyczyść cache w panelu hostingu, jeśli hosting ma własny cache stron,
• wyczyść cache w CDN, jeśli strona z niego korzysta,
• sprawdź stronę w oknie prywatnym przeglądarki.

Jeśli po wyczyszczeniu cache pojawia się biały ekran, przeczytaj artykuł Biały ekran WordPress.

Jak aktualizować, żeby strona nie padła

Aktualizacji nie da się uniknąć, bo nieaktualne wtyczki to najczęstsza droga włamań. Można za to sprawić, że awaria po aktualizacji będzie krótka i odwracalna. Taką procedurę stosuję przy stronach, którymi się opiekuję:

1. Zrób kopię tuż przed aktualizacją

   Nie polegaj wyłącznie na kopii nocnej z hostingu. Zrób świeżą kopię plików i bazy, najlepiej zapisaną poza serwerem. Przez WP-CLI: wp db export przed-aktualizacja.sql plus archiwum katalogu wp-content.

2. Testuj na kopii strony (staging)

   Wiele hostingów pozwala utworzyć kopię testową strony jednym kliknięciem. Jeśli Twój nie pozwala, kopię można postawić w podkatalogu lub na subdomenie. Na kopii zaktualizuj wszystko i sprawdź najważniejsze funkcje. Kopię testową zablokuj przed Google i usuń po zakończeniu.

3. Aktualizuj w kolejności i w małych grupach

   Najpierw małe wtyczki, potem duże (WooCommerce, kreatory stron, wielojęzyczność), potem motyw, na końcu rdzeń. Przy dużej zmianie wersji WooCommerce najpierw zaktualizuj jego rozszerzenia (płatności, wysyłki), jeśli ich autorzy deklarują zgodność z nową wersją.

4. Sprawdź to, co zarabia

   Po aktualizacji przejdź ścieżkę klienta: strona główna, produkt, koszyk, zamówienie, formularz kontaktowy. W oknie prywatnym, bez logowania. Wiele awarii widać tylko jako gość.

5. Obserwuj przez dobę

   Część błędów pojawia się dopiero przy zadaniach w tle, na przykład przy nocnej synchronizacji produktów albo wysyłce maili. Jeśli masz włączony log błędów zapisywany poza katalogiem publicznym, przejrzyj go następnego dnia.

Jeśli aktualizacja dotyczy wersji PHP na serwerze, a nie samego WordPressa, procedura jest podobna, ale ryzyka są inne. Opisuję je w artykule Strona nie działa po zmianie PHP.

Kiedy nie robić tego samemu

Cofnięcie jednej wtyczki to kilka minut pracy. Pomoc warto wezwać, gdy:

• aktualizacja WooCommerce lub dużej wtyczki zmieniła bazę danych i stara wersja nie działa,
• aktualizowałeś wiele elementów naraz i nie wiesz, który zawinił, a kopia jest stara,
• motyw ma dużo nadpisanych szablonów WooCommerce zrobionych na zamówienie,
• sklep nie przyjmuje zamówień i liczy się każda godzina.

Jeśli nie chcesz w ogóle zajmować się aktualizacjami, w Abonamencie Care (199 zł netto miesięcznie) robię je za Ciebie, z codzienną kopią zapasową i monitoringiem strony.

Najczęstsze pytania