Aktualizacje WordPress są niezbędne do zapewnienia bezpieczeństwa witryny internetowej, a jednocześnie stanowią jedno z największych źródeł obaw agencji internetowych. Poprosiliśmy Sébastiena Cavaillé, menedżera ds. marketingu produktów w OVHcloud, o wyjaśnienie, w jaki sposób funkcja Smart Automatic Updates została zaprojektowana, aby rozwiązać ten dylemat.
Każda agencja zarządzająca witrynami WordPress wie, jak trudno pogodzić konieczność przeprowadzania aktualizacji z brakiem czasu lub zasobów na ich wykonanie. Z jednej strony aktualizacji nie można odkładać – według najnowszego raportu rocznego firmy Patchstack, specjalizującej się w bezpieczeństwie systemu WordPress, w 2025 r. odnotowano 11 334 nowe podatności, z czego 91% we wtyczkach, 9% w motywach i zaledwie sześć w rdzeniu WordPress. Atakujący działają szybko: około połowa poważnych podatności jest wykorzystywana w ciągu 24 godzin od ich ujawnienia. Nieaktualna wtyczka jest jednym z najczęstszych punktów wejścia dla atakujących, a im dłużej zwleka się z aktualizacją, tym dłużej witryna pozostaje narażona na ataki.
Z drugiej strony każda aktualizacja wiąże się z ryzykiem: jakaś wtyczka może stać się niekompatybilna, motyw może przestać prawidłowo się wyświetlać, strona nagle zacznie zwracać błąd. Aby nie podejmować tego ryzyka w ciemno, wiele agencji sprawdza każdą witrynę ręcznie. Przy zarządzaniu dziesiątkami, a nawet setkami witryn zajmuje to bardzo dużo czasu. A gdy brakuje czasu, aktualizacje są odkładane, czasami o tygodnie, a nawet miesiące.
Aby przełamać ten impas, zespoły OVHcloud opracowały funkcję Smart Automatic Updates, dostępną w ramach usługi Managed Hosting for WordPress. Aby lepiej zrozumieć tę kwestię, porozmawialiśmy z Sébastienem, który pracował nad projektem.
Skąd wzięła się idea tego projektu?
Pomysł wyszedł bezpośrednio od naszych klientów. Na naszej platformie hostingu współdzielonego utrzymujemy około 6 milionów witryn internetowych, z których 80% działa w oparciu o WordPress. Dzięki temu otrzymujemy wiele opinii od klientów, w których regularnie powraca jedna potrzeba: użytkownicy wiedzą, że muszą aktualizować swoje witryny, ale wielu z nich doświadczyło już problemów związanych z aktualizacją i nie ma czasu na ręczne sprawdzanie każdej z witryn.
Tradycyjne aktualizacje automatyczne rozwiązują problem bezpieczeństwa, ale stwarzają inny – często dopiero telefon od klienta pozwala się dowiedzieć, że witryna przestała działać. Chcieliśmy stworzyć rozwiązanie, które najpierw przeprowadza kontrolę, a dopiero potem automatycznie wykonuje aktualizację.
Jedna historia szczególnie zapadła nam w pamięć. Pewien niezależny twórca stron internetowych prowadził jednoosobową agencję i samodzielnie zarządzał dziesiątkami witryn swoich klientów opartych na systemie WordPress. Ujawniono podatność we wtyczce używanej na wielu z tych witryn, a on po prostu nie zdążył ich wszystkich zaktualizować, zanim atakujący wykorzystał tę lukę. W krótkim czasie włamano się na 36 witryn jego klientów, które zaczęły przekierowywać odwiedzających na niebezpieczne adresy.
Usunięcie skutków ataku z witryn internetowych to jedno. Najtrudniejsza była jednak rozmowa z klientami. Każdy z tych klientów powierzył mu opiekę nad swoją witryną internetową i każdy dowiedział się, że odwiedzający jego stronę byli przekierowywani na niebezpieczne strony. Dla freelancera, którego działalność opiera się na reputacji i poleceniach, odbudowa tak nadszarpniętej wiarygodności trwa znacznie dłużej niż naprawa samych witryn.
Od tego czasu przeniósł witryny swoich klientów do usługi Managed Hosting for WordPress i powierzył nam ich aktualizowanie. Jego historia doskonale ilustruje sytuacje, którym chcieliśmy zapobiegać – nie dlatego, że popełnił jakiś błąd, ale dlatego, że nikt nie jest w stanie ręcznie aktualizować dziesiątek witryn tydzień po tygodniu.
Jak testowane są aktualizacje WordPress?
Podstawowa zasada polega na tym, aby nigdy nie testować aktualizacji bezpośrednio na witrynie produkcyjnej.
Jakie są cztery etapy testowania?
Codziennie sprawdzamy, czy dostępne są nowe aktualizacje. Następnie każda aktualizacja jest testowana w czterech etapach.
Najpierw tworzymy migawkę przedstawiającą aktualny stan witryny. Robot przeszukujący witrynę rozpoczyna od strony głównej i rekurencyjnie podąża za linkami: jeśli strona główna zawiera link do strony A, ta do strony B, a strona B do strony C, analizowana jest również strona C. Analizujemy maksymalnie 50 stron w każdej witrynie. Dla każdej strony zapisujemy kod stanu HTTP zwracany przez serwer, który wskazuje, czy strona ładuje się prawidłowo, czy zwraca błąd, a także zrzut ekranu obejmujący całą stronę w rozdzielczości 1920×1080.
Następnie tworzymy kopię witryny w odizolowanym środowisku testowym. To właśnie na tej kopii – i tylko na niej – przeprowadzamy aktualizacje systemu WordPress, motywów oraz wtyczek.
Po trzecie, analizujemy kopię witryny dokładnie tak samo jak oryginalną witrynę – sprawdzamy te same strony, kody stanu HTTP i zrzuty ekranu.
Na koniec porównujemy obie wersje. Wynik tego porównania decyduje o tym, czy aktualizacja może zostać wdrożona w środowisku produkcyjnym.
Kiedy aktualizacja jest uznawana za prawidłową?
Muszą być spełnione trzy warunki:
- Kody stanu HTTP są identyczne. Jeśli strona, która wcześniej działała prawidłowo, teraz zwraca błąd, aktualizacja zostaje zablokowana.
- Zrzuty ekranu są zgodne, z niewielką tolerancją na różnice wizualne.
- Wszystkie aktualizacje motywów i wtyczek zostały zainstalowane bez błędów.
Porównanie wizualne jest celowo bardzo rygorystyczne. Piksel uznaje się za zmieniony, jeśli wartość choćby jednej z jego składowych koloru – czerwonej, zielonej lub niebieskiej – zmieni się nawet o jedną jednostkę. Nie stosujemy żadnej tolerancji różnic kolorów. Dopuszczamy natomiast niewielki odsetek zmienionych pikseli – maksymalnie 5% na stronie. Próg ten określa więc, jaka część strony uległa zmianie, a nie jak bardzo zmienił się każdy piksel.
Przed wykonaniem każdego zrzutu ekranu odczekujemy również kilka sekund, aby animacje ładowania i podobne efekty zakończyły się.
Jak unikacie fałszywych alarmów?
Wiele witryn zawiera karuzele, animacje lub treści, które nieustannie się zmieniają. Był to jeden z najciekawszych problemów, które musieliśmy rozwiązać. Podczas pierwszych testów zaskoczyło nas, jak wiele aktualizacji było oznaczanych jako nieudane, mimo że podczas ręcznego sprawdzania witryn nie zauważaliśmy żadnych problemów. Gdy dokładniej przeanalizowaliśmy zrzuty ekranu, okazało się, że przyczyną były niemal zawsze te same elementy: karuzele obrazów na stronach głównych, które zdążyły wyświetlić kolejny obraz, liczniki odliczające czas w witrynach poświęconych wydarzeniom, widżety „Najnowsze wpisy” lub osadzone strumienie treści z mediów społecznościowych, które odświeżyły się między wykonaniem dwóch zrzutów ekranu. Same aktualizacje przebiegały prawidłowo – strony po prostu zmieniały się na bieżąco.
Rozwiązaniem okazało się wykonywanie kilku zrzutów ekranu każdej strony w kilkusekundowych odstępach. Jeśli strona zmienia się samoistnie między dwoma zrzutami ekranu, system oznacza ją jako dynamiczną i wyklucza z porównania wizualnego. Nie oznacza to jednak, że takie strony pozostają bez kontroli. Ich kody stanu HTTP są nadal porównywane, więc jeśli strona dynamiczna zacznie zwracać błąd, aktualizacja również zostanie zablokowana. Po dodaniu tego etapu liczba fałszywych alarmów znacznie spadła i znów mogliśmy polegać na wynikach porównania wizualnego.
Jaki jest zakres analizy?
Skupiliśmy się na tym, co najważniejsze – stronach, które odwiedzający rzeczywiście przeglądają. W praktyce analiza obejmuje najważniejsze elementy większości witryn: stronę główną, najważniejsze sekcje i kluczowe strony przeglądane przez odwiedzających.
Strony, do których nie można dotrzeć ze strony głównej, nawet pośrednio, nie są objęte analizą. To celowe działanie: jeśli do danej strony nie prowadzi żaden link, odwiedzający nie mogą do niej dotrzeć również podczas przeglądania witryny, więc nieudana aktualizacja tej strony nie będzie miała na nich wpływu.
Ta sama zasada dotyczy obszarów dostępnych po zalogowaniu, takich jak konta klientów czy panel administracyjny. Każda witryna obsługuje uwierzytelnianie na swój sposób, dlatego postanowiliśmy skupić się na stronach dostępnych publicznie, które możemy sprawdzać w sposób niezawodny i spójny na dużą skalę.
Nie chodzi o zastąpienie specjalistycznej wiedzy agencji, lecz o przejęcie powtarzalnych kontroli, które w przeciwnym razie musiałaby przeprowadzać ręcznie, witryna po witrynie. Dzięki temu agencja zyskuje czas na zadania, które tylko ona może wykonać.
Gdy test zakończy się powodzeniem lub niepowodzeniem
Co się dzieje, gdy weryfikacja zakończy się niepowodzeniem?
W witrynie produkcyjnej nic się nie zmienia – i właśnie o to chodzi. Jeśli choć jedno z kryteriów nie zostanie spełnione, aktualizacje nie są wdrażane. Witryna nadal działa dokładnie tak jak wcześniej.
Klient otrzymuje następnie wiadomość e-mail z wyjaśnieniem, dlaczego weryfikacja zakończyła się niepowodzeniem. Możliwe są cztery przyczyny:
- Nie udało się w pełni zaktualizować wtyczek lub motywów w witrynie testowej.
- Strona główna zwróciła błąd 4xx lub była niedostępna, co uniemożliwiło przeprowadzenie testu.
- Odpowiedzi HTTP oryginalnej witryny i jej kopii różnią się.
- Zrzuty ekranu różnią się między sobą.
Wiadomość e-mail zapewnia również dostęp do kopii witryny, w której zastosowano aktualizacje. Agencja może sprawdzić, na czym polega problem, rozwiązać go bezpośrednio w kopii witryny, a następnie, gdy wszystko działa prawidłowo, samodzielnie uruchomić aktualizację w środowisku produkcyjnym.
Od początku trzymaliśmy się jednej zasady: automatyzacja zajmuje się powtarzalnymi zadaniami, ale nigdy nie podejmuje ryzykownych decyzji w imieniu agencji. W razie wątpliwości kontrola zawsze pozostaje w rękach człowieka.
Jak zatwierdzona aktualizacja jest wdrażana w środowisku produkcyjnym?
Po pomyślnej weryfikacji aktualizacja jest wkrótce wdrażana w środowisku produkcyjnym, a klient otrzymuje powiadomienie.
Nie przewidziano automatycznego wycofywania aktualizacji, ponieważ została ona już przetestowana przed wdrożeniem w środowisku produkcyjnym. Jeśli jednak później pojawi się problem, klient może jednym kliknięciem przywrócić witrynę z kopii zapasowej w Panelu klienta OVHcloud. Kopie zapasowe są tworzone osobno dla każdej witryny, a nie dla całego pakietu hostingowego, dzięki czemu agencja może przywrócić witrynę jednego klienta bez ingerencji w pozostałe.
Czy można wykluczyć wtyczki z aktualizacji?
Nie – to świadoma decyzja. Jeśli ktoś chce wykluczyć wtyczkę z aktualizacji, zazwyczaj obawia się, że aktualizacja zakłóci działanie witryny. Naszym zadaniem jest właśnie dopilnowanie, aby do tego nie doszło.
Niektóre przypadki wymagają szczególnego podejścia i tym również się zajmujemy. Weźmy przykład WooCommerce: jeśli witryna korzysta zarówno z WooCommerce, jak i z rozszerzenia premium do WooCommerce, którego licencja wygasła, rozszerzenie to nie otrzymuje już aktualizacji. Aktualizacja samego WooCommerce mogłaby wówczas zakłócić działanie witryny, ponieważ nowsza wersja WooCommerce nie jest kompatybilna z nieaktualną wersją rozszerzenia. W takiej sytuacji nie aktualizujemy WooCommerce. Gdy funkcja Smart Automatic Updates wykryje inne podobne przypadki, również się nimi zajmujemy.
A co z wtyczkami i motywami premium?
Zasada jest prosta: jeśli w panelu administracyjnym WordPress można kliknąć przycisk „Aktualizuj” przy danej wtyczce lub motywie, przeprowadzamy aktualizację. Jeśli nie jest to możliwe, na przykład z powodu wygaśnięcia licencji, nie przeprowadzamy aktualizacji. W takim przypadku informujemy klienta w Panelu klienta OVHcloud o konieczności aktualizacji wtyczki, aby nie została ona przeoczona.
Co się zmienia dla agencji?
Wskazałbym trzy kwestie.
Po pierwsze, bezpieczeństwo. Aktualizacje nie kumulują się już z powodu braku czasu na ich sprawdzenie. Każda witryna jest regularnie aktualizowana, co skraca czas, w którym znana podatność pozostaje nieusunięta.
Po drugie, spokój ducha. Agencja nie musi już się zastanawiać, czy aktualizacja nie zakłóciła działania witryny. Aktualizacja została albo pomyślnie zweryfikowana i wdrożona, albo środowisko produkcyjne pozostało bez zmian, a agencja otrzymała dokładne wyjaśnienie przyczyny. Jeśli mimo wszystko pojawi się jakikolwiek problem, witrynę każdego klienta można przywrócić osobno jednym kliknięciem, bez wpływu na pozostałe.
Po trzecie, oszczędność czasu. Jedna z agencji powiedziała nam, że na utrzymanie witryn poświęcają aż 30% czasu pracy. Smart Automatic Updates przejmuje powtarzalne czynności kontrolne, dzięki czemu agencje mogą poświęcić więcej tego czasu na działania, które przynoszą największą wartość ich klientom.
Funkcja Smart Automatic Updates jest dostępna we wszystkich naszych pakietach Managed Hosting for WordPress, dzięki czemu każda aktualizacja systemu WordPress jest testowana przed wdrożeniem w witrynach Twoich klientów. Dowiedz się więcej o tym, jak wspieramy agencje i freelancerów w zarządzaniu ich stronami WordPress, lub przeczytaj, dlaczego zbudowaliśmy managed WordPress hosting w ten sposób.
Dokumentacja usługi Managed Hosting for WordPress zawiera bardziej szczegółowe informacje na temat konfiguracji i procesu aktualizacji.