Aktualizacja WordPressa bez psucia strony

Regularnie aktualizuję strony Klientów na WordPressie i WooCommerce. Poniżej opisuję, w jakiej kolejności to robię, co sprawdzam po każdym kroku i co zrobić, gdy coś jednak pójdzie źle. Przy każdej radzie piszę, skąd się wzięła, bo większość z nich to wnioski z sytuacji, które raz już kogoś zaskoczyły.

Czy aktualizacja WordPressa jest bezpieczna?

Sama aktualizacja to rutynowa operacja i zwykle przechodzi bez śladu. Kłopot zaczyna się wtedy, gdy strona ma kilkadziesiąt wtyczek od różnych autorów, motyw przerabiany latami i własny kod, którego nikt nie sprawdzał na nowej wersji. Wtedy jedna zmiana potrafi wyłączyć funkcję, której nie widać na pierwszy rzut oka. Strona się wyświetla i niby działa, a po trzech dniach dostajesz od kupującego maila: „Dlaczego nie mogę kupić produktu? Na ostatnim kroku zamówienia wyskakuje błąd”. Nie muszę chyba tłumaczyć, jak niekomfortowa jest taka sytuacja dla właściciela sklepu, jego kupujących i wykonawcy.

Bezpieczeństwo aktualizacji nie zależy więc od samego przycisku, tylko od tego, co jest wokół niego. Czy masz kopię, z której naprawdę da się odtworzyć stronę. Czy pierwsza próba odbywa się na kopii roboczej, a nie na wersji, którą oglądają odwiedzający. I czy po aktualizacji ktoś sprawdza coś więcej niż to, że strona główna się otwiera.

Nieaktualizowanie też jest decyzją, tylko z gorszym rachunkiem. Każda poprawka bezpieczeństwa pokazuje, co było dziurawe w poprzedniej wersji. WordPress i jego wtyczki mają otwarty kod, więc różnicę między wersją przed poprawką i po niej może obejrzeć każdy, a opisy luk trafiają do publicznych baz. Atakujący, najczęściej za pomocą automatów, szukają właśnie stron, które tej poprawki jeszcze nie dostały.

Jaka jest aktualna wersja WordPressa?

W dniu pisania tego tekstu, 6 listopada 2026, najnowsze wydanie to WordPress 7.1.4 z 28 października 2026. Numer zmienia się regularnie, więc zamiast go zapamiętywać, sprawdź go w panelu, w menu Kokpit, pozycja Aktualizacje, albo na liście wydań na wordpress.org.

Warto rozróżniać dwa rodzaje wydań. Wydanie poprawkowe zmienia trzecią liczbę, na przykład z 7.1.3 na 7.1.4, i niesie poprawki błędów oraz bezpieczeństwa. Wydanie główne zmienia jedną z dwóch pierwszych liczb, na przykład z 7.0 na 7.1, i wprowadza nowe funkcje. Z mojego doświadczenia to po wydaniach głównych strony psują się częściej, bo wtyczki nie zawsze za nimi nadążają.

Dlaczego WordPress nie działa po aktualizacji?

Najczęściej winny nie jest sam WordPress, tylko kod na styku między nim a resztą strony. W mojej praktyce regularnie powtarza się pięć sytuacji.

• Wtyczka nie nadąża za nową wersją silnika albo PHP. Kończy się to komunikatem o błędzie krytycznym albo białą stroną.
• Motyw potomny korzysta z plików motywu nadrzędnego, które w nowej wersji zmieniły lokalizację albo nazwę, przez co dotychczasowy kod nie potrafi ich znaleźć. Widziałem stronę, na której po dużej aktualizacji motywu nadrzędnego zniknęły wszystkie ikony, bo zmieniła się ścieżka do zestawu ikon. Strona działała, tylko wyglądała na zepsutą.
• Wtyczka płatna z wygasłą licencją najczęściej nie dostaje aktualizacji razem z resztą i zostaje w starej wersji, która przestaje pasować do nowych sąsiadów.
• Własny kod dopisany do sklepu korzysta z funkcji, które nowa wersja WooCommerce albo wtyczki zmieniła. Taki błąd często nie jest widoczny na ekranie i wychodzi dopiero przy zamówieniu. Jeśli po aktualizacji nikt nie przejdzie całej ścieżki zamówienia, odkrywa go dopiero kupujący.
• Pamięć podręczna serwuje stare pliki stylów i skryptów obok nowego kodu. Wygląda to jak awaria, a znika po wyczyszczeniu wszystkich warstw pamięci podręcznej, także tej po stronie serwera.

Dlatego czwarty przypadek uważam za najgroźniejszy. Na pierwszy rzut oka wszystko wygląda prawidłowo. W systemie takim jak silnik rezerwacji Mundo Coworking, gdzie każda rezerwacja jest powiązana z zamówieniem WooCommerce, albo jak harmonogram dostaw w sklepie Restauracji Tobiasz, zrzut ekranu nie pokaże, że opłacone zamówienie nie trafiło tam, gdzie powinno. Przy takich stronach po aktualizacji trzeba przejść całą ścieżkę, od wyboru produktu po potwierdzenie w skrzynce.

W jakiej kolejności aktualizować wtyczki, motyw i WordPressa?

Kolejność ma znaczenie, bo gdy coś się zepsuje, chcesz wiedzieć, na którym kroku nastąpiła awaria. Tak wygląda moja procedura, którą dopracowywałem latami.

1. 01Kopia zapasowa bazy danych i plików, zanim cokolwiek ruszę.
2. 02Kopia robocza strony na serwerze deweloperskim, z aktualną bazą z produkcji i wyczyszczoną pamięcią podręczną. Stare dane w pamięci podręcznej potrafią pokazać różnice, których na prawdziwej stronie nie ma.
3. 03Zrzuty ekranu kluczowych podstron przed zmianą, w rozmiarze komputera i telefonu, oraz lista błędów z konsoli przeglądarki. Bez tego po aktualizacji nie wiadomo, czy błąd jest nowy, czy był tam od dawna. Do tego kroku i do każdego innego porównania przed i po zbudowałem własne narzędzie, którego używam na co dzień.
4. 04Lista dostępnych aktualizacji, zanim cokolwiek kliknę. Drobne wydania wtyczek idą razem, duże po jednej, żeby było wiadomo, która co zmieniła.
5. 05WordPress i aktualizacja bazy danych, o którą silnik prosi po wydaniu głównym. Potem jeszcze raz lista wtyczek, bo część aktualizacji pojawia się w panelu dopiero dla nowej wersji silnika.
6. 06Motyw na końcu, bo to on najczęściej ma przeróbki pod konkretną stronę i najtrudniej go cofnąć.
7. 07Tłumaczenia.
8. 08Porównanie zrzutów przed i po, piksel po pikselu, i przejście ścieżki, na której strona zarabia. Formularz musi dojść, zamówienie musi się złożyć, maile muszą wyjść. To samo narzędzie zestawia zrzuty przed i po i zaznacza miejsca, w których coś się zmieniło.
9. 09Dopiero wtedy ten sam zestaw aktualizacji na stronie produkcyjnej, po świeżej kopii zapasowej, z wyczyszczeniem pamięci podręcznej i ponownym sprawdzeniem najważniejszych podstron.

Po każdym kroku na kopii roboczej sprawdzam trzy rzeczy. Czy strona odpowiada, czy w logu błędów nie pojawił się nowy błąd krytyczny i czy kluczowe podstrony wyglądają tak samo jak przed zmianą.

Maile sprawdzam w MailHogu, czyli testowej skrzynce, która przechwytuje każdą wiadomość wysłaną z kopii roboczej. Dzięki temu żaden test nie trafia do prawdziwego kupującego, a ja widzę treść, adresata i załączniki dokładnie tak, jak wyszłyby z produkcji.

Porównanie zrzutów ma jedno ograniczenie. Nie widzi stanów, które pojawiają się dopiero po kliknięciu. Na moim własnym blogu rozwinięte menu na telefonie pokazywało jedną pozycję z pięciu, a zrzuty przed i po były identyczne, bo błąd siedział w obu wersjach. Dlatego rozwijane menu, koszyk i formularze klikam osobno.

Wtyczki płatne bywają osobnym przypadkiem. Licencja jest często przypisana do domeny produkcyjnej, więc na kopii roboczej taka wtyczka czasem nie chce się zaktualizować. Wtedy sprawdzam na kopii wszystko inne, a ją aktualizuję na produkcji z panelu i od razu sprawdzam to, za co odpowiada. Robię to dopiero po świeżej kopii bazy danych i plików, bo każda zmiana bezpośrednio na produkcji niesie ryzyko.

Jak przywrócić poprzednią wersję WordPressa?

Najpewniejszy sposób to odtworzenie kopii zapasowej zrobionej tuż przed aktualizacją, bazy i plików razem. Cofnięcie samych plików, gdy nowsza wersja zdążyła już zmodyfikować bazę danych, potrafi narobić więcej szkody niż pożytku.

WordPress ma też dwa wbudowane zabezpieczenia. Od wersji 6.3 nieudana ręczna aktualizacja wtyczki albo motywu sama przywraca poprzednią wersję z tymczasowej kopii. Od wersji 6.6 podobnie działa automatyczna aktualizacja wtyczki. Jeśli po niej strona zgłasza błąd krytyczny, WordPress wraca do poprzedniej wersji i wysyła administratorowi maila. Oba mechanizmy łapią jednak tylko awarię w chwili aktualizacji. Nie pomogą, gdy wtyczka zainstaluje się poprawnie, a sklep po cichu przestanie przyjmować zamówienia.

Pojedynczą wtyczkę da się cofnąć ręcznie. Od wersji 5.5 WordPress pozwala podmienić zainstalowaną wtyczkę, wgrywając jej starszą wersję jako plik ZIP, a wtyczki z katalogu wordpress.org mają poprzednie wersje do pobrania na swojej stronie, w widoku zaawansowanym.

Cofnięcie to rozwiązanie na chwilę. Stara wersja wraca razem ze swoimi lukami, więc po cofnięciu trzeba znaleźć przyczynę i wrócić do aktualizacji.

Czy włączać automatyczne aktualizacje WordPressa?

WordPress od wersji 3.7 sam instaluje wydania poprawkowe i tłumaczenia. Od wersji 5.5 automatyczne aktualizacje można włączyć osobno dla każdej wtyczki i motywu, a od wersji 5.6 nowe instalacje aktualizują się automatycznie także do wydań głównych. Starsze instalacje zachowują swoje dotychczasowe ustawienie.

Automatyczne poprawki bezpieczeństwa silnika zostawiam włączone zawsze. To małe zmiany, ryzyko błędu jest niewielkie, a zysk duży. Na samym przełączniku jednak nie poprzestaję i sprawdzam, czy aktualizacja naprawdę się wykonała. Serwer z zablokowanym zapisem plików albo z wyłączonym harmonogramem zadań potrafi ją po cichu pominąć, a przełącznik dalej wygląda na włączony.

Z wtyczkami jest inaczej. Automat włączam tam, gdzie strona jest prosta, a wtyczka mała i bez wpływu na pieniądze Klienta. W sklepie, przy płatnościach, formularzach z danymi osób i własnym kodzie wolę aktualizację sprawdzoną najpierw na kopii roboczej. Automatyczne wycofanie złapie błąd krytyczny, ale nie zamówienie, które przestało dochodzić.

Kiedy i jak zaktualizować PHP na stronie WordPress?

PHP to język, w którym działa WordPress, a jego wersję zwykle ustawia się w panelu hostingu. WordPress zaleca obecnie PHP 8.3 lub nowsze. Działa też na starszych, od 7.4 wzwyż, ale sam zastrzega, że wersje bez wsparcia mogą narazić stronę na luki. Według php.net najstarsza wspierana dziś gałąź to 8.2, z poprawkami bezpieczeństwa do 31 grudnia 2026.

Zmiana PHP to aktualizacja jak każda inna, tylko szersza, bo dotyczy wszystkich wtyczek naraz. Robię ją na kopii roboczej z włączonym zapisem ostrzeżeń i dopiero przy czystym logu przełączam wersję na produkcji. Najczęściej wysypują się tu stare wtyczki, których nikt od lat nie aktualizował.

Przy okazji warto sprawdzić, czy każda wtyczka nadal istnieje w katalogu wordpress.org. Wtyczka zamknięta w katalogu, na przykład z powodu luki, wygląda w panelu tak samo jak taka, która po prostu nie ma nowej wersji. Różnicę widać dopiero na jej stronie.

Jak zrobić kopię zapasową WordPressa przed aktualizacją?

Kopia WordPressa ma dwie części. Baza danych trzyma treści, ustawienia i zamówienia, a pliki to wtyczki, motywy i wgrane obrazy. Przed aktualizacją potrzebujesz obu, zrobionych w tym samym momencie.

Kopia niesprawdzona odtworzeniem to nadzieja, nie kopia. Innymi słowy, możesz robić kopie nawet codziennie, a w chwili awarii może się okazać, że z żadnej nie da się odtworzyć strony. Wtedy masz naprawdę duży problem. Pilnuję więc dwóch rzeczy. Kopia leży poza serwerem strony, bo awaria albo włamanie na serwer zabiera też kopie trzymane na serwerze. I co jakiś czas odtwarzam ją na próbę, bo dopiero wtedy wiadomo, że plik nie jest pusty, ucięty albo bez bazy.

Zmiany w plikach śledzę dodatkowo za pomocą Gita, systemu kontroli wersji, który pokazuje dokładnie, co, gdzie i jak zmieniło się w plikach strony. Przydaje się to także po włamaniu, bo widać, które pliki napastnik zmienił albo dodał. Git nie zastępuje jednak kopii, bo nie obejmuje bazy danych, w której złośliwy kod też potrafi się schować. Sam katalog .git musi być zamknięty dla odwiedzających, inaczej każdy mógłby pobrać z niego kod strony, dlatego blokuję do niego dostęp w konfiguracji serwera, najczęściej w pliku .htaccess, i ustawiam mu odpowiednie uprawnienia.

W sklepie dochodzi jeszcze jedna rzecz. Między kopią a aktualizacją mogą wpaść nowe zamówienia, więc przywrócenie kopii po nieudanej aktualizacji na produkcji może je skasować. To kolejny powód, żeby pierwszą próbę robić na kopii roboczej, a na produkcji tylko powtórzyć sprawdzony zestaw.

Czy aktualizacja usunie wirusa ze strony WordPress?

Nie. Aktualizacja zamyka drzwi, którymi ktoś mógł wejść, ale nie wyprasza tego, kto już jest w środku. Złośliwy kod siedzi zwykle w plikach poza wtyczkami, w bazie danych albo w dodatkowym koncie administratora, a nowa wersja wtyczki niczego z tego nie dotyka.

Sygnały, które powinny zaniepokoić, to przekierowania na obce strony, zwłaszcza tylko na telefonie albo tylko po wejściu z Google, konta administratorów, których nikt nie zakładał, pliki zmienione wtedy, gdy nikt przy stronie nie pracował, i ostrzeżenie przy adresie strony w wynikach wyszukiwania.

Usuwanie złośliwego kodu to osobna praca. Trzeba znaleźć drogę wejścia, wyczyścić pliki i bazę, zmienić hasła i klucze, a na końcu zaktualizować to, co było otwarte. Po takiej pracy nikt uczciwy nie może obiecać, że strona jest czysta na zawsze. Da się za to sprawdzić ją według procedury i ustawić monitoring, który zauważy powrót infekcji.

Profilaktyka jest tańsza i dość nudna. Nieużywane wtyczki i motywy usuwam, a nie tylko wyłączam, bo wyłączona wtyczka dalej leży na serwerze ze swoim kodem. Edytor plików w panelu wyłączam. A dostępności strony pilnuje monitoring, który postawiłem na własnym serwerze, bo widziałem stronę, która po włamaniu długo nie działała, zanim ktokolwiek to zauważył. Powiadomienie o niedostępności dłuższej niż 30 minut przychodzi na mój telefon, więc o awarii strony objętej opieką dowiaduję się sam, zwykle zanim zauważy ją Klient.

Ile kosztuje aktualizacja WordPressa?

Cena zależy mniej od liczby wtyczek, a bardziej od tego, co strona robi i co się stanie, gdy przestanie działać. Strona firmowa z formularzem to inna odpowiedzialność niż sklep z płatnościami i własnym modułem dostaw. Na koszt wpływają głównie te rzeczy:

• Liczba i rodzaj wtyczek, zwłaszcza płatnych, z licencją przypisaną do domeny.
• Zaległość. Skok o kilka wydań głównych naraz to więcej pracy niż bieżąca aktualizacja.
• Własny kod i przeróbki motywu, które trzeba sprawdzić na nowej wersji.
• Ścieżka do przetestowania, od formularza kontaktowego po pełny proces zamówienia z płatnością.
• Dostęp do kopii roboczej i do kopii zapasowych, czyli czy jest na czym bezpiecznie próbować.

Jednorazowa aktualizacja mocno zaniedbanej strony to zwykle osobna wycena, bo z góry nie wiadomo, ile zmian wyjdzie naraz. Stałą opiekę rozliczam ryczałtem miesięcznym od 250 zł netto za stronę, plus jednorazowe poukładanie na start od 500 zł netto. W tej cenie są aktualizacje sprawdzane najpierw na kopii roboczej, kopie zapasowe z próbnym odtworzeniem, monitoring i raport z każdego przeglądu. Trzy poziomy i pełny zakres opisuję na stronie opieki nad WordPressem, a jak wygląda raport po takim przeglądzie, pokazuje przykładowy raport z mojego własnego bloga.