Aktualizacje WordPressa to nie jedna kategoria, a traktowanie ich jako jednej jest powodem, dla którego utrzymanie albo się pomija, albo staje się źródłem regularnych awarii. Poprawki bezpieczeństwa, wydania poprawkowe rdzenia, wydania główne, aktualizacje wtyczek i motywów mają różną pilność i różne ryzyko. Działająca polityka odpowiada na każdą z nich osobno, wprowadza je w kolejności, którą kontrolujesz, i pozwala każdą z nich cofnąć. Ten artykuł opisuje taką politykę oraz te jej elementy, które zwykle się pomija.
Jakie są rodzaje aktualizacji i jak pilna jest każda z nich?
Pięć kategorii, a rozróżnienie między nimi stanowi całą odpowiedź.
| Rodzaj aktualizacji | Kiedy się ukazuje | Wdrożyć w ciągu | Testy przed wdrożeniem |
|---|---|---|---|
| Poprawka bezpieczeństwa rdzenia | Po usunięciu podatności | 24 godzin | Szybki test na środowisku testowym albo akceptacja automatycznej aktualizacji |
| Poprawka bezpieczeństwa wtyczki lub motywu | Po usunięciu podatności | 24–48 godzin | Test proporcjonalny do tego, czego wtyczka dotyka |
| Wydanie poprawkowe rdzenia | W miarę potrzeb, kilka razy w roku | Tygodnia | Podstawowa weryfikacja funkcjonalna |
| Aktualizacje funkcjonalne wtyczek i motywów | Na bieżąco | Zaplanowanego okna, zwykle miesięcznego | Test na środowisku testowym, weryfikacja funkcji, których dotyczą |
| Wydanie główne rdzenia | Około trzy razy w roku | 2–6 tygodni | Pełny test regresji na środowisku testowym |
Dwie uwagi do tej tabeli, bo w obu oryginał się mylił.
Wydania poprawkowe rdzenia nie mają harmonogramu miesięcznego. Ukazują się wtedy, gdy jest co naprawić, co może oznaczać dwa razy w ciągu dwóch tygodni albo przerwę na kilka miesięcy. Wydania główne historycznie ukazywały się średnio trzy razy w roku, przy czym 2025 rok miał zredukowany harmonogram, zanim projekt wrócił do trzech wydań w 2026. Planuj według wzorca, nie według daty.
Poprawka bezpieczeństwa wdrożona w 24 godziny to co innego niż poprawka wdrożona na ślepo. Na serwisie o prostej konfiguracji automatyczna aktualizacja jest właściwą odpowiedzią, a test formalnością. Na platformie z integracjami płatniczymi i własnym kodem szybki test na środowisku testowym kosztuje godzinę i jest jej wart. Szybkość i testowanie nie stoją w sprzeczności. Test ma być po prostu proporcjonalny.
Co warto zautomatyzować?
WordPress domyślnie stosuje automatyczne aktualizacje poprawkowe rdzenia, a od wersji 5.5 pozwala włączyć automatyczne aktualizacje pojedynczych wtyczek i motywów. To, czy warto, jest oceną zasięgu potencjalnej szkody.
Rozsądne do automatyzacji: wydania poprawkowe rdzenia oraz wtyczki powszechnie używane, aktywnie rozwijane i niedotykające niczego krytycznego. Jeżeli awaria wtyczki oznacza problem kosmetyczny, automatyzacja oszczędza więcej, niż ryzykuje.
Nie automatyzuj: niczego w ścieżce płatności i zamówienia, niczego odpowiadającego za uwierzytelnianie i kontrolę dostępu, niczego, co rozszerzaliście własnym kodem, kreatorów stron i wtyczek formularzy z historią psucia układów, oraz każdego wydania głównego rdzenia bez wyjątku.
Nigdy nie automatyzuj tam, gdzie nikt nie patrzy. Automatyczne aktualizacje są bezpieczne wyłącznie wtedy, gdy coś zauważy, że serwis przestał działać. Monitoring dostępności i transakcji jest tym, co czyni automatyzację obronną. Bez niego automatyzacja oznacza, że o awarii dowiesz się od klienta.
Jak wdrażać aktualizacje bez psucia serwisu?
Kolejność ma mniejsze znaczenie niż dyscyplina. Cztery zasady pokrywają większość sytuacji.
Najpierw kopia zapasowa, ze sprawdzonym odtworzeniem. Kopia, której nigdy nie odtwarzaliście, jest założeniem. Weryfikuj ścieżkę odtworzenia na środowisku testowym przynajmniej raz na kwartał.
Testuj na aktualnej kopii produkcji. Nie na środowisku testowym sprzed roku. Większość konfliktów ujawnia się dopiero przy prawdziwych danych, prawdziwej objętości treści i prawdziwym zestawie wtyczek.
Przy realnym ryzyku zmieniaj jedną rzecz naraz. Aktualizacja czternastu wtyczek jednym kliknięciem jest w porządku na stronie wizytówce. Na platformie z integracjami oznacza, że po awarii masz czternastu podejrzanych.
Zgodność sprawdzaj przed wydaniem głównym, nie po nim. Przed przejściem na nową wersję główną potwierdź, że kluczowe wtyczki ją obsługują. To właśnie tutaj stara rada o aktualizowaniu rdzenia w pierwszej kolejności sprawia kłopot: nowy rdzeń wchodzi, wtyczka nie nadążyła, a coś, co działało wczoraj, przestaje działać.
Po każdej aktualizacji zweryfikuj to, co zarabia. Zamówienie, formularze, wyszukiwarkę, logowanie, szablony obsługujące największy ruch. Automatyczne testy są lepsze niż lista kontrolna, a lista kontrolna jest znacznie lepsza niż nic.
Co zrobić z wtyczkami, których nikt już nie rozwija?
To część pomijana w większości poradników o utrzymaniu, a wyrządzająca więcej szkód niż spóźnione aktualizacje.
Wtyczka nieaktualizowana od dwóch lat nie jest stabilna. Jest porzucona, a gdy znajdzie się w niej podatność, poprawka nie nadejdzie. To samo dotyczy wtyczek, których autor przestał odpowiadać, oraz wtyczek komercyjnych z wygasłą licencją, które przez to w ogóle nie otrzymują aktualizacji.
Przeglądaj listę wtyczek dwa razy w roku i podziel ją na trzy grupy. Aktywnie rozwijane i nadal potrzebne. Aktywnie rozwijane, ale już niepotrzebne, które należy usunąć, a nie dezaktywować, bo nieaktywny kod nadal leży na serwerze. Oraz porzucone, które wymagają planu zastąpienia z konkretną datą.
Ta ostatnia grupa to miejsce, gdzie jest praca i gdzie odkłada się ją w nieskończoność, bo wymiana działającej wtyczki źle wygląda na liście priorytetów. Jest jednak wyraźnie tańsza niż ta sama wymiana w trybie awaryjnym.
Co jeszcze wymaga aktualizacji?
Trzy rzeczy spoza ekranu aktualizacji, o których się zapomina.
PHP. Praca na niewspieranej wersji oznacza brak poprawek bezpieczeństwa na poziomie języka, a z czasem blokuje też aktualizacje WordPressa i wtyczek. Aktualizacje PHP planuj świadomie, testuj na środowisku testowym i traktuj z taką samą ostrożnością jak wydanie główne rdzenia.
Serwer bazy danych i reszta stosu. Zwykle odpowiedzialność hostingu, ale tylko wtedy, gdy ktoś to potwierdził.
Zależności we własnym kodzie. Własne motywy i wtyczki pociągają za sobą biblioteki. Biblioteki mają podatności. Zarządzane zależności z plikiem blokady i okresowym audytem zamieniają tę niewiadomą w zadanie.
Co się stanie, jeśli tego nie robić?
Ryzyko nie jest abstrakcyjne i koncentruje się w konkretnym miejscu.
Liczba podatności w ekosystemie WordPressa idzie rocznie w tysiące i rośnie, przy czym zdecydowana większość dotyczy wtyczek i motywów, nie rdzenia. Atakujący automatycznie skanują sieć w poszukiwaniu znanych podatnych wersji. Okno między publicznym ujawnieniem a pierwszymi próbami wykorzystania mierzy się często w dniach.
Drugi koszt narasta. Odłożone aktualizacje nie zostają tej samej wielkości. Serwis pozostawiony na rok nie potrzebuje jednego cyklu aktualizacji, tylko projektu migracyjnego, bo zmiany trzeba wprowadzać sekwencyjnie, konflikty rozplątywać, a część wtyczek zdąży się zmienić albo zniknąć.
Trzeci koszt zauważa się ostatni. Aktualizacje niosą poprawki wydajności i zgodności, więc zaniedbana platforma staje się wolniejsza względem konkurencji, choć nic widocznie nie przestaje działać.
Kiedy nie aktualizować?
Świadome okna zamrożenia są elementem dojrzałej polityki, nie jej brakiem.
Zamroź aktualizacje niezwiązane z bezpieczeństwem wokół szczytów sprzedażowych: Black Friday, kampanie sezonowe, okresy rekrutacji, premiery produktów. W tym czasie na produkcję nie trafia nic poza poprawkami bezpieczeństwa, a te przechodzą wcześniej porządny test.
Zamroź, gdy nie ma kto naprawić ewentualnego problemu. Aktualizacje w piątek po południu przed długim weekendem to sposób, w jaki drobne usterki stają się trzydniowymi awariami.
Zamroź na czas migracji albo dużego projektu, żeby zmiany z dwóch źródeł nie schodziły się w jednym miejscu.
Rzecz w tym, żeby zamrożenie było ogłoszone, miało datę zakończenia i kończyło się cyklem nadrabiania. Zamrożenie bezterminowe nie jest polityką, tylko zaniedbaniem nazwanym ładniej.
Kto to robi w praktyce?
Zarządzanie aktualizacjami częściej zawodzi z przyczyn organizacyjnych niż technicznych. Nie jest niczyim zadaniem, więc dzieje się wtedy, gdy ktoś sobie przypomni, czyli zwykle po awarii.
Niezależnie od przyjętego rozwiązania trzy rzeczy muszą mieć przypisane nazwiska: kto prowadzi cykl aktualizacji, kto weryfikuje serwis po nich i kogo się wzywa, gdy coś przestaje działać poza godzinami pracy.
Nasza usługa Growth & Care jest zbudowana wokół tego układu. Comiesięczny cykl obejmujący wtyczki, motywy i rozszerzenia, weryfikacja kluczowych sekcji po każdej aktualizacji i usuwanie błędów przez nią spowodowanych, a pod spodem codzienne kopie zapasowe i monitoring. Zgłoszenia idą przez service desk z testami jakości przed publikacją na produkcji, a czasy reakcji wynikają z uzgodnionego SLA, nie z tego, kto akurat ma wolne. To celowo mniej efektowne, niż brzmi, i o to chodzi.
FAQ
Jak często należy aktualizować WordPressa?
Poprawki bezpieczeństwa w ciągu 24 do 48 godzin. Wydania poprawkowe rdzenia w ciągu tygodnia. Aktualizacje funkcjonalne wtyczek i motywów w zaplanowanym oknie, dla większości serwisów miesięcznym. Wydania główne po dwóch do sześciu tygodni, po potwierdzeniu zgodności na środowisku testowym.
Czy włączać aktualizacje automatyczne?
Dla wydań poprawkowych rdzenia tak. Dla wtyczek wybiórczo: automatyzuj te o niskim ryzyku, a kontrolę ręczną zachowaj nad wszystkim, co dotyka płatności, uwierzytelniania i własnego kodu. Automatyzacja jest bezpieczna tylko wtedy, gdy monitoring powie Ci, że coś przestało działać.
Najpierw wtyczki czy najpierw rdzeń?
Nie ma uniwersalnej kolejności. Liczy się potwierdzenie, że kluczowe wtyczki obsługują nową wersję rdzenia przed wydaniem głównym, zmienianie jednej rzeczy naraz przy wysokiej stawce i utrzymanie ścieżki cofnięcia. Zakładanie sztywnej kolejności prowadzi do sytuacji, w której wtyczka nie działa na wersji, którą właśnie zainstalowałeś.
Czy można pominąć wersję główną?
Można, ale aktualizacja i tak kiedyś nastąpi, a każda pominięta wersja powiększa skok i utrudnia testowanie. Pozostawanie jedną wersję główną w tyle jest rozsądne. Pozostawanie czterema to już projekt.
Co zrobić z wtyczką, która nie jest już rozwijana?
Traktować jako zobowiązanie bezpieczeństwa z terminem wymiany, nie jako stabilny komponent. Porzucony kod nie dostaje poprawek, więc znaleziona w nim podatność pozostaje otwarta bezterminowo. Wymiana, gdy wszystko działa, kosztuje znacznie mniej niż wymiana w trakcie incydentu.
Ile czasu zajmuje porządny cykl aktualizacji?
Przy prostym serwisie poniżej godziny miesięcznie. Przy platformie z integracjami, własnym kodem i realnym procesem testowym kilka godzin miesięcznie, plus dodatkowy czas na wydania główne. Zmienną jest liczba rzeczy do zweryfikowania po aktualizacji, nie liczba przycisków do kliknięcia.
Aktualizacje ciągle się przesuwają, bo nie są niczyim zadaniem? To dokładnie ta luka, którą wypełnia Growth & Care. → Porozmawiajmy
