Aktualizacje WordPress robię w ramach opieki technicznej według stałego harmonogramu: najpierw pełna kopia zapasowa, potem aktualizacja na kopii testowej strony (stagingu), testy, porównanie zrzutów ekranu sprzed zmiany i po niej, a dopiero wtedy publikacja na produkcji w ustalonym oknie. Nie instaluję automatycznie każdej nowej wersji. Krytyczne poprawki bezpieczeństwa idą poza kolejką, ale też przez staging.
Ta strona opisuje, jak często co aktualizuję, jak wygląda jedna runda aktualizacji, co robię, gdy po aktualizacji coś przestaje działać, i jak wyglądają aktualizacje w sklepie z integracjami, na page builderze i w systemach spoza WordPressa. Cała usługa opieki, z kopiami zapasowymi i monitoringiem, jest opisana na stronie utrzymanie stron WordPress.
Jak często aktualizuję WordPressa
Harmonogram w opiece nad jedną stroną. Dla sklepu okna ustalam osobno.
Co tydzień
- Drobne poprawki i wydania bezpieczeństwa rdzenia, wtyczek i motywów
- Aktualizacja przez WP-CLI na klonie stagingowym
- Testy najważniejszych ścieżek i porównanie zrzutów ekranu
- Publikacja na produkcji w ustalonym oknie
Co miesiąc
- Przegląd dużych wersji wtyczek i ich list zmian
- Decyzja: aktualizować teraz albo wstrzymać wersję
- Przegląd kont administratorów
- Pomiar Core Web Vitals po zmianach
Co kwartał i co pół roku
- Kwartalnie: przegląd listy wtyczek i usunięcie porzuconych
- Co pół roku: przegląd bezpieczeństwa, czyli integralność plików, konta administratorów, uprawnienia i wystawione endpointy
- Co pół roku: porównanie stagingu z produkcją
- Przejście na nowszą wersję PHP: według planu, gdy wtyczki i motyw są gotowe
Aktualizacja WordPress poza harmonogramem: poprawki bezpieczeństwa
Krytyczna poprawka bezpieczeństwa nie czeka na cotygodniowy cykl. Idzie pierwsza, osobno, ale tą samą drogą: kopia, staging, test, publikacja. Dokładne okno na takie poprawki zapisuję w wycenie, bo zależy od tego, jaki czas reakcji obejmuje twój plan.
Źródło informacji o lukach to bazy podatności, między innymi Patchstack i WPScan. Gdy w bazie pojawia się luka we wtyczce, którą masz na stronie, sprawdzam, czy jest już poprawiona wersja i czy luka dotyczy twojej konfiguracji.
Zespół bezpieczeństwa WordPressa to ponad 50 zaufanych ekspertów, w tym główni deweloperzy i badacze bezpieczeństwa. Według tej samej strony oficjalnie wspierana jest tylko najnowsza wersja WordPressa, a poprawki do starszych gałęzi zespół przenosi grzecznościowo. Strona zatrzymana kilka wersji wstecz może więc zostać bez poprawki.
Jak przebiega jedna runda aktualizacji
Ta sama kolejność dla rdzenia, wtyczek, motywów i PHP. Zmienia się tylko zakres testów.
Pełna kopia zapasowa
Przed jakąkolwiek zmianą robię pełną kopię bazy danych i plików. Kopia jest punktem powrotu, jeśli coś pójdzie źle na produkcji.
Aktualizacja na stagingu
Aktualizacje trafiają najpierw na klon strony, przez WP-CLI. Duże wersje wtyczek idą dopiero po przeczytaniu listy zmian.
Testy na klonie
Sprawdzam najważniejsze ścieżki strony: formularze, logowanie, w sklepie koszyk i płatność. Gdy test nie przechodzi, zmiana nie idzie dalej.
Porównanie zrzutów ekranu
Robię zrzuty ekranu wybranych podstron przed aktualizacją i po niej i porównuję je. Przesunięty układ, zniknięty przycisk albo inny font widać tu, zanim zobaczy je odwiedzający.
Publikacja w oknie serwisowym
Zmiana trafia na produkcję w ustalonym oknie, ze snapshotem i gotowym planem powrotu.
Obserwacja po publikacji
Przez 24 godziny po publikacji prowadzę wzmożony monitoring pod kątem efektów ubocznych. Monitoring dostępności sprawdza stronę co 1 do 5 minut.
Wpis do raportu
Aktualizacje, wykryte regresje i ewentualne wycofania trafiają do raportu miesięcznego.
Przykład z tego roku: WP Rocket 3.23.2.2 poszedł na klon, zanim zaktualizowałem stronę do WordPressa 7.1. Opis błędu i obejścia jest we wpisie WP Rocket, fatal WordPress 7.1 i Cloudflare.php.
Porównanie zrzutów ekranu po aktualizacji
Test funkcjonalny sprawdza, czy formularz się wysyła, a koszyk przyjmuje produkt. Nie zauważy, że po aktualizacji motywu nagłówek zasłania menu na telefonie albo że page builder zmienił odstępy w sekcji z cennikiem. Dlatego po każdej aktualizacji porównuję zrzuty ekranu wybranych podstron sprzed zmiany i po niej. Listę podstron do porównania ustalam na starcie opieki: strona główna, najważniejsze podstrony usług, formularz, a w sklepie karta produktu, koszyk i zamówienie.
Gdy porównanie pokazuje różnicę, sprawdzam, czy wynika z zaplanowanej zmiany. Jeśli nie, aktualizacja zostaje na stagingu, a ja szukam przyczyny. Na produkcję idzie dopiero wersja, która wygląda tak samo albo różni się w sposób, o którym wiesz.
Aktualizacja PHP w opiece
Przejście na nowszą wersję PHP jest częścią opieki, bez osobnej wyceny. Planuję je z wyprzedzeniem, bo zależy od trzech rzeczy: czy hosting oferuje nowszą wersję, czy wszystkie wtyczki i motyw ją obsługują i czy własny kod strony nie korzysta z funkcji, które w nowszym PHP zniknęły. Najpierw uruchamiam klon strony na nowszym PHP, potem przechodzę testy i porównanie zrzutów ekranu, a dopiero potem zmieniam wersję na produkcji, w ustalonym oknie.
WordPress zaleca PHP 8.3 lub nowszy, MariaDB 10.11 albo MySQL 8.0 i obsługę HTTPS. Według usługi sprawdzania wersji WordPress.org minimalna wersja PHP dla bieżącego WordPressa to 7.4. Przejście na nowsze PHP łączę z przeglądem listy wtyczek, bo wtyczka bez aktualizacji od dawna jest pierwszym kandydatem do błędu na nowszej wersji.
Co psuje się po aktualizacji i co wtedy robię
Najczęstsze objawy po aktualizacji rdzenia, wtyczki, motywu lub PHP.
- Objaw: Błąd krytyczny albo biały ekran po aktualizacji wtyczki
- Co robięWracam do stanu sprzed zmiany ze snapshotu. Przyczynę szukam na klonie, a poprawioną wersję publikuję w kolejnym oknie.
- Objaw: Podstrona wygląda inaczej niż przed aktualizacją
- Co robięPorównanie zrzutów ekranu zatrzymuje taką zmianę na stagingu. Jeśli różnica przeszła na produkcję, wycofuję aktualizację i poprawiam styl albo wstrzymuję wersję.
- Objaw: Koszyk lub płatność w sklepie przestaje działać
- Co robięNie publikuję zmiany, która nie przeszła testu koszyka. Jeśli błąd wyszedł dopiero na produkcji, wycofuję aktualizację i wracam do stagingu.
- Objaw: Zamówienia przestają trafiać do ERP albo programu księgowego
- Co robięSprawdzam na stagingu wymianę danych między sklepem a drugim systemem i wstrzymuję wersję łącznika, dopóki dane nie przechodzą poprawnie.
- Objaw: Nowa wersja wtyczki wymaga zmian w kodzie motywu
- Co robięWstrzymuję wersję i opisuję, co trzeba przebudować. Przebudowa jest poza opieką i dostaje osobną wycenę.
- Objaw: Autor przestał rozwijać wtyczkę
- Co robięPrzy kwartalnym przeglądzie listy wtyczek proponuję zamiennik albo usunięcie.
- Objaw: Wtyczka wymaga nowszej wersji PHP niż ta na serwerze
- Co robięPlanuję przejście na nowsze PHP i testuję je na stagingu. To część opieki.
- Objaw: Strona zmieniła się w nocy bez niczyjej decyzji
- Co robięSprawdzam, które automatyczne aktualizacje są włączone, i ustawiam je tak, żeby elementy krytyczne szły przez staging.
Aktualizacje w sklepie z integracjami: ERP, KSeF, płatności
W sklepie WooCommerce aktualizacja dotyczy nie tylko samego sklepu. Bramka płatności, wtyczka kurierska, łącznik z ERP i wtyczka do faktur mają własnych autorów i własny rytm wydań, a każda z nich rozmawia z systemem poza twoim serwerem. Po aktualizacji takiego łącznika sprawdzam na stagingu, czy dane dalej przechodzą w obie strony: zamówienie trafia do ERP, stan magazynowy wraca do sklepu, faktura powstaje.
Faktury w KSeF to dobry przykład. WooCommerce sam faktur nie wystawia, więc robi to wtyczka albo integracja z programem księgowym, co opisuję we wpisie KSeF w WooCommerce. Aktualizacja takiej wtyczki idzie przez staging jak każda inna, ale test obejmuje też wystawienie faktury w środowisku testowym. Architekturę połączeń sklepu z innymi systemami opisuję w przewodnikach integracja WooCommerce z ERP i WordPress API-first.
Bramki płatności testuję scenariuszem koszyk, dane, dostawa, płatność, bez składania prawdziwego zamówienia. Sklep, w którym to ma się dziać stale, a nie tylko po aktualizacji, prowadzę w Store Reliability Plan. W tym planie rytm aktualizacji zależy od poziomu: od comiesięcznych aktualizacji przez staging, przez aktualizacje co dwa tygodnie, po cotygodniowe okno aktualizacji.
Typowy scenariusz: sklep z bramką płatności i łącznikiem do programu księgowego
Typowy sklep, z którym przychodzą właściciele, ma bramkę płatności, wtyczkę kurierską, wtyczkę do faktur połączoną z programem księgowym i kilkanaście innych wtyczek. W jednym tygodniu aktualizację mogą dostać jednocześnie WooCommerce i bramka płatności. W takim tygodniu aktualizuję je osobno: najpierw WooCommerce, test koszyka i faktury, potem bramkę, znowu test. Gdy coś pójdzie źle, od razu wiadomo, która zmiana to spowodowała.
Aktualizacje na page builderze
Strony zbudowane na Elementorze, Divi czy WPBakery mają dodatkową warstwę, którą trzeba aktualizować: sam builder, jego dodatki i często osobny motyw. Builder zapisuje układ strony we własnym formacie, więc jego aktualizacja potrafi zmienić wygląd wielu podstron naraz. Różnice między builderami opisuję we wpisie Gutenberg, Elementor, Divi i WPBakery.
Typowa strona firmowa z 30 wtyczkami i page builderem dostaje w większości tygodni kilka aktualizacji. Na takiej stronie porównanie zrzutów ekranu robi najwięcej pracy, bo test funkcjonalny przejdzie, nawet gdy sekcja na stronie głównej się rozjedzie.
Aktualizować samemu czy zlecić
Odpowiedź zależy od tego, co psuje się na twojej stronie, gdy aktualizacja się nie uda.
Masz prostą stronę z kilkoma wtyczkami, działającą kopią zapasową i czas, żeby po aktualizacji przejrzeć stronę.
Możesz aktualizować sam. Zrób kopię przed każdą aktualizacją i włącz automatyczne drobne aktualizacje rdzenia.
Strona stoi na page builderze i ma kilkadziesiąt wtyczek.
Aktualizacje przez staging z porównaniem zrzutów ekranu, w opiece nad stroną firmową.
Prowadzisz sklep z płatnościami, ERP albo fakturami w KSeF.
Aktualizacje z testem koszyka i wymiany danych, w Store Reliability Plan albo w opiece nad sklepem.
Strona jest kilka wersji WordPressa albo PHP za aktualną.
Zacznij od audytu startowego w opiece. Plan dojścia do aktualnych wersji jest jego wynikiem.
Aktualizacja już zepsuła stronę, a nie masz umowy opieki.
Automatyczne aktualizacje WordPress a aktualizacje w opiece
WordPress potrafi aktualizować się sam. Według dokumentacji dla administratorów istniejące instalacje domyślnie dostają automatycznie drobne aktualizacje rdzenia, a nowe instalacje od wersji 5.6 dostają zarówno drobne, jak i duże. Zachowanie zmienia stała WP_AUTO_UPDATE_CORE w pliku wp-config.php: wartość 'minor' zostawia tylko drobne aktualizacje, wartość true włącza wszystkie.
Wtyczki i motywy działają inaczej. Od WordPressa 5.5 administrator włącza automatyczne aktualizacje osobno dla każdej wtyczki i każdego motywu. Według tej samej strony WordPress uruchamia je dwa razy dziennie i opiera się przy tym na zadaniach WP-Cron.
Automatyczna aktualizacja instaluje nową wersję bez kopii i bez testu na stagingu. Dla drobnych poprawek rdzenia to akceptowalne ryzyko. Dla sklepu, wtyczki płatności albo wtyczki, od której zależy formularz zamówienia, jest za duże. Dlatego w opiece zostawiam automat tam, gdzie zmiana jest mała, a elementy krytyczne prowadzę ręcznie przez staging.
Strona po roku bez aktualizacji: jak ją doprowadzam do porządku
Typowy scenariusz na start opieki: strona firmowa, której nikt nie aktualizował od roku, z kilkudziesięcioma wtyczkami, starszą wersją PHP i jedną kopią zapasową sprzed kilku miesięcy. Na takiej stronie nie aktualizuję wszystkiego naraz, bo przy błędzie nie da się ustalić, która zmiana go spowodowała.
Zaczynam od audytu startowego, który jest wliczony w pierwszy miesiąc: lista wtyczek z wersjami, sprawdzenie, które z nich autor jeszcze rozwija, wersja PHP i to, czy istniejąca kopia daje się odtworzyć. Potem robię świeżą pełną kopię i klon stagingowy. Na klonie aktualizuję w partiach: najpierw rdzeń, potem wtyczki od najprostszych do tych, od których zależy formularz albo sklep, na końcu motyw. Po każdej partii testy i porównanie zrzutów ekranu. Porzucone wtyczki dostają zamiennik albo wypadają. Przejście na nowsze PHP planuję jako osobny krok, gdy wszystkie wtyczki są już aktualne.
Dopiero gdy klon przechodzi wszystkie testy, przenoszę zmiany na produkcję w ustalonym oknie. Od tej chwili strona wchodzi w zwykły, cotygodniowy rytm. Gdy po drodze wyjdzie element, który wymaga nowego kodu, opisuję go i wyceniam osobno.
Aktualizacje w sieci Multisite
W sieci WordPress Multisite wtyczki i motywy są instalowane raz dla całej sieci, więc ich aktualizacja dotyczy wszystkich witryn naraz. Każda witryna może jednak używać wtyczki inaczej: jedna ma na niej formularz zamówienia, druga tylko baner. Dlatego na stagingu sieci testuję najważniejsze ścieżki na każdej witrynie, która z danej wtyczki korzysta, a porównanie zrzutów ekranu obejmuje podstrony z kilku witryn. Sieć Multisite wyceniam indywidualnie, w zależności od liczby witryn i wymagań.
Duża wersja WordPressa: jak ją wprowadzam
Duża wersja rdzenia, taka jak WordPress 7.1, zmienia więcej niż wersja poprawkowa i częściej ujawnia niezgodności we wtyczkach. Według usługi sprawdzania wersji WordPress.org bieżąca wersja to 7.1.3 (stan na 28 października 2026). Dużej wersji nie wprowadzam w dniu wydania. Najpierw sprawdzam na stagingu, czy wtyczki i motyw działają z nową wersją, porównuję zrzuty ekranu i czytam listy zmian wtyczek, które jeszcze nie zadeklarowały zgodności. Na produkcję duża wersja idzie w ustalonym oknie, gdy klon przechodzi testy.
Na takim klonie wyszedł błąd WP Rocket 3.23.2.2 z WordPressem 7.1, opisany wyżej. Gdy jedna wtyczka blokuje dużą wersję, zostawiam stronę na poprzedniej gałęzi, dopóki autor nie wyda poprawki albo nie znajdę obejścia, i zapisuję to w raporcie.
Co z aktualizacji trafia do raportu
Każda runda aktualizacji zostawia ślad w raporcie miesięcznym: co zostało zaktualizowane, jakie regresje wyszły na stagingu, które wersje wstrzymałem i dlaczego, czy któraś zmiana została wycofana z produkcji. Dzięki temu po awarii wiadomo, co i kiedy zmieniło się na stronie, a przy zmianie dostawcy opieki masz historię, którą możesz przekazać dalej.
Zmiany we własnym kodzie przy aktualizacjach
Czasem aktualizacja wymaga drobnej poprawki we własnym kodzie strony: w motywie potomnym, we wtyczce napisanej dla firmy albo w funkcji, która przestała działać na nowszym PHP. Każdą taką zmianę trzymam w systemie kontroli wersji, więc wiadomo, co, kiedy i dlaczego zostało zmienione, i da się ją cofnąć. Kod sprawdzam pod kątem WordPress Coding Standards narzędziem PHP_CodeSniffer z regułami WPCS, a analiza statyczna PHPStan wyłapuje błędy typów i wywołania funkcji, których nowsze PHP już nie ma. Przed publikacją przeglądam własną zmianę jeszcze raz, osobno od pisania. Większa przebudowa nadal jest poza opieką i dostaje osobną wycenę.
Aktualizacje Drupal, TYPO3, Laravel i Symfony
Ten sam schemat (kopia, staging, testy, okno, plan powrotu) stosuję w systemach spoza WordPressa. Różnią się narzędzia i rytm wydań.
Drupal aktualizuję w powtarzalnym procesie opartym na Composerze i wdrożeniach przez Drush. Drupal 7 nie ma wsparcia bezpieczeństwa od 5 stycznia 2025, a Drupal 10 traci je 9 grudnia 2026. Co to oznacza dla serwisu na Drupalu 10, opisuję we wpisie Drupal 10 koniec wsparcia.
W TYPO3 najważniejsze są przejścia między wersjami LTS. Bezpłatne wsparcie dla TYPO3 12.4 skończyło się 30 kwietnia 2026, więc serwis na tej wersji potrzebuje planu przejścia na 13 albo 14 LTS.
W aplikacji Laravel wersje poprawkowe wychodzą nawet co tydzień, a każda wersja główna ma dwa lata poprawek bezpieczeństwa. Poprawki trafiają na produkcję w ciągu kilku dni, razem z aktualizacją zależności Composera i przebiegiem composer audit, zawsze najpierw na serwerze testowym. W Symfony wersja 6.4 dostaje poprawki błędów do listopada 2026 i poprawki bezpieczeństwa do listopada 2027, dlatego wiele projektów zaczyna się od planu przejścia na 7.4.
Czego nie obejmują aktualizacje w opiece
W opiece aktualizuję rdzeń, wtyczki, motywy i wersję PHP. Poza opieką jest przebudowa elementu, który po aktualizacji wymaga nowego kodu, duże zmiany w motywie lub architekturze strony, budowa nowych integracji oraz przejście na inny system, na przykład migracja do Next.js lub Astro. Taka praca dostaje osobną wycenę i zaczyna się po jej potwierdzeniu. Ile kosztuje sama opieka, opisuję na stronie opieka WordPress cena.
Jeśli strona już nie działa po nieudanej aktualizacji, a nie masz umowy opieki, zacznij od naprawy WordPress. Jeśli po aktualizacji pojawiły się obce pliki, przekierowania albo ostrzeżenie Google, przejdź do strony usuwanie wirusów WordPress.
Następny krok: wyślij adres strony i listę wtyczek, które uważasz za krytyczne. Odpowiem, jak ułożę dla nich harmonogram aktualizacji i ile będzie kosztować opieka.
