Jak bezpiecznie zaktualizować WordPressa bez psucia strony (i dlaczego robimy backup przed każdą aktualizacją)

Bezpieczna aktualizacja WordPressa to zawsze ta sama kolejność: pełny backup bazy i plików, test na kopii, dopiero potem aktualizacja na działającej stronie. Pomiń pierwszy krok, a jedna aktualizacja wtyczki może zakończyć się białym ekranem i telefonem od klienta o ósmej rano. Dlatego u nas backup przed każdą aktualizacją to nie opcja, tylko standardowa procedura.

Dlaczego aktualizacje WordPressa bywają niebezpieczne

WordPress sam w sobie jest stabilny, ale strona firmowa to zwykle nie tylko rdzeń CMS-a. To dziesiątki wtyczek, motyw z własnymi modyfikacjami, integracje z systemem księgowym czy kalkulatorem cen, czasem stary kod pisany "na szybko" kilka lat temu. Każdy z tych elementów ma swój cykl życia i swoje wymagania co do wersji PHP oraz wersji samego WordPressa. Kiedy aktualizujesz jeden składnik, reszta układanki niekoniecznie jest na to gotowa.

Najczęstsze przyczyny "wysypanej" strony po aktualizacji, które widzimy w praktyce, to konflikt wtyczki z nową wersją rdzenia, motyw korzystający z funkcji oznaczonych jako przestarzałe (deprecated), które w końcu zostały usunięte, oraz aktualizacja PHP do wersji, z którą stary kod po prostu nie działa. Do tego dochodzi ryzyko samej operacji: przerwane połączenie w trakcie update'u, wyczerpany limit czasu wykonania skryptu albo brak miejsca na dysku potrafią zostawić instalację w stanie połowicznym, gdzie część plików jest już nowa, a część stara.

Problem w tym, że właściciel firmowej strony rzadko wie, które z tych ryzyk go dotyczą. Nie ma powodu, żeby znał różnicę między PHP 7.4 a 8.2 albo wiedział, że jego wtyczka do rezerwacji terminów nie była aktualizowana od trzech lat. To jest dokładnie ta wiedza, którą powinien dostarczać hosting z opieką, a nie sam klient metodą prób i błędów na własnej, działającej stronie.

Backup przed każdą aktualizacją, dlaczego to niepodważalna zasada

W planie Biznes i Pro każda zarządzana aktualizacja, WordPressa, wtyczek, motywu, PHP czy bibliotek, jest poprzedzona osobnym backupem oznaczonym jako "przed aktualizacją" (pre-update). To coś innego niż standardowy backup dobowy. Backup dobowy chroni przed utratą danych w skali dnia, ale jeśli aktualizacja zepsuje stronę o 14:32, a najbliższy backup dobowy powstał o 3:00 w nocy, tracisz kilkanaście godzin pracy, zamówień w sklepie albo zgłoszeń z formularza kontaktowego.

Backup przed aktualizacją powstaje dosłownie kilka minut przed wprowadzeniem zmiany i obejmuje bazę danych oraz pliki instalacji. Dzięki temu, jeśli coś pójdzie nie tak, przywracamy stronę do stanu sprzed operacji w ciągu minut, a nie godzin, i nie tracimy ani jednego zamówienia czy wpisu z formularza złożonego tuż przed aktualizacją. Każde takie zdarzenie, backup, aktualizacja, ewentualny przywrót, trafia do dziennika zdarzeń (audit log), więc dokładnie wiadomo, co, kiedy i dlaczego zostało zrobione na koncie klienta.

To jest właśnie ta różnica między "hostingiem, który tylko trzyma pliki" a hostingiem, który bierze odpowiedzialność za to, żeby strona firmowa działała. Duzi hostingodawcy w Polsce w cenie abonamentu robią zwykle backup dobowy albo tygodniowy i na tym kończy się ich udział w temacie aktualizacji, resztę zostawiają właścicielowi strony. My traktujemy backup przed zmianą jako element samej procedury aktualizacji, nie jako osobną, płatną usługę.

Krok po kroku: jak aktualizujemy WordPressa u naszych klientów

Poniżej dokładna procedura, którą stosujemy w ramach zarządzanych aktualizacji w planie Biznes i Pro. To nie jest teoria z poradnika, tylko realny checklist używany na kontach klientów.

• Krok 1, backup przed zmianą. Tworzymy pełną kopię bazy danych i plików, zapisujemy ją z możliwością przywrócenia (w zależności od planu do 14 lub 28 dni wstecz).
• Krok 2, sprawdzenie zgodności. Weryfikujemy wersję PHP, listę aktywnych wtyczek i motyw pod kątem znanych konfliktów z nową wersją WordPressa lub aktualizowanej wtyczki. Sprawdzamy też, czy wtyczka jest wciąż wspierana przez autora, bo porzucone wtyczki to jedno z głównych źródeł luk bezpieczeństwa.
• Krok 3, aktualizacja na środowisku testowym (staging). W planie Pro robimy to najpierw na osobnej kopii strony (staging), żeby zobaczyć efekt bez ryzyka dla działającej witryny. W planie Biznes stosujemy skróconą wersję tego kroku, testując kluczowe strony i formularze zaraz po aktualizacji.
• Krok 4, aktualizacja na produkcji. Aktualizujemy w kolejności: najpierw wtyczki i motyw, na końcu rdzeń WordPressa oraz PHP, jeśli to konieczne. Taka kolejność zmniejsza ryzyko, że dwie zmiany naraz utrudnią diagnozę problemu.
• Krok 5, weryfikacja po aktualizacji. Sprawdzamy stronę główną, formularz kontaktowy, proces zakupu w sklepie (jeśli występuje), panel logowania i szybkość ładowania. Dopiero po tej weryfikacji uznajemy aktualizację za zakończoną.
• Krok 6, wpis w dzienniku zdarzeń. Każda operacja jest logowana, backup przed zmianą, zakres aktualizacji, wynik weryfikacji, żeby klient mógł w każdej chwili zobaczyć historię zmian na swoim koncie.

Cała procedura jest zaprojektowana pod filozofię "co kto chce", czyli elastyczne podejście do drobnych prac na życzenie klienta. Jeśli klient prosi o coś nietypowego, na przykład aktualizację tylko wybranej wtyczki przed ważnym wydarzeniem branżowym, robimy dokładnie to, zamiast trzymać się sztywnego harmonogramu.

Co robimy, gdy aktualizacja jednak coś zepsuje

Nawet przy najlepszej procedurze zdarza się, że aktualizacja wtyczki ujawni błąd, którego nie dało się przewidzieć, bo autor wtyczki sam popełnił błąd w swoim kodzie. W takiej sytuacji różnica między hostingiem z opieką a hostingiem "zrób to sam" jest największa. U nas wygląda to tak: wykrywamy problem (najczęściej zanim zgłosi go klient, dzięki monitoringowi), przywracamy backup sprzed aktualizacji w ciągu kilku minut, analizujemy przyczynę i albo instalujemy poprawioną wersję wtyczki, albo wdrażamy obejście, albo wracamy do poprzedniej, stabilnej wersji do czasu, aż autor wtyczki wyda łatkę.

Klient w tym czasie nie zostaje sam z komunikatem błędu i telefonem do anonimowego działu wsparcia. Zgłoszenie w kanale "Czego potrzebujesz?" trafia do realnej osoby, która zna historię jego konta, wie, jaką aktualizację właśnie wykonaliśmy, i nie musi zaczynać rozmowy od zera. To jest sedno różnicy względem home.pl czy nazwa.pl, gdzie problem trzeba opisać od podstaw w formularzu, a potem czekać w kolejce na odpowiedź skryptową.

Jak często aktualizować i co zrobić z wtyczkami "end of life"

Rekomendujemy aktualizacje bezpieczeństwa (security releases) WordPressa niemal natychmiast po ich wydaniu, zwykle w ciągu 24 do 48 godzin, bo to właśnie te aktualizacje najczęściej łatają luki już aktywnie wykorzystywane przez boty skanujące internet. Aktualizacje funkcjonalne (nowe wersje major) wdrażamy z rozwagą, po sprawdzeniu zgodności z zainstalowanymi wtyczkami, zwykle w ciągu jednego, dwóch tygodni od premiery.

Osobny temat to wtyczki, które przestały być rozwijane przez autora, tak zwane porzucone wtyczki (abandonware). Jeśli wtyczka nie miała aktualizacji od dwóch, trzech lat, a jednocześnie WordPress regularnie łata luki bezpieczeństwa w swoim rdzeniu, taka wtyczka staje się najsłabszym ogniwem całej instalacji. W ramach opieki nad kontem rekomendujemy klientowi zamiennik o podobnej funkcji i pomagamy w migracji ustawień, zamiast czekać, aż stanie się ona furtką dla ataku. Więcej o tym, jak wygląda usuwanie skutków takiego ataku, piszemy w osobnym artykule o usuwaniu malware i hardeningu.

Checklist: co sprawdzić po każdej aktualizacji

Niezależnie od tego, czy aktualizację robi u Ciebie firma hostingowa, czy robisz ją samodzielnie, warto mieć krótką listę kontrolną, którą przechodzi się zaraz po zmianie. My stosujemy ją jako ostatni, obowiązkowy punkt każdej procedury:

• Strona główna ładuje się poprawnie i bez błędów w konsoli przeglądarki.
• Formularz kontaktowy wysyła wiadomość i trafia ona na właściwy adres e-mail.
• Proces zakupu (jeśli to sklep) działa od dodania produktu do koszyka aż po stronę potwierdzenia płatności.
• Panel logowania klienta i panel administracyjny WordPressa działają bez błędu 500 czy białego ekranu.
• Czas ładowania strony nie wzrósł zauważalnie względem stanu sprzed aktualizacji.
• Certyfikat SSL nadal jest aktywny i przeglądarka nie zgłasza ostrzeżenia o niezaufanym połączeniu.

Ten sam checklist stosujemy niezależnie od wielkości strony, bo doświadczenie pokazuje, że to właśnie drobne, pozornie nieistotne elementy (formularz, proces zakupu) najczęściej przestają działać po aktualizacji wtyczki, a nie sama strona główna.

Jak to wygląda w zależności od typu strony

Wizytówka firmowa z kilkoma podstronami to zwykle najprostszy przypadek, ryzyko koncentruje się głównie na formularzu kontaktowym i ewentualnym kalkulatorze albo mapie dojazdu osadzonej jako wtyczka. Sklep WooCommerce to zupełnie inna skala ryzyka, aktualizacja WooCommerce, bramki płatności albo wtyczki do integracji z kurierem musi być przetestowana szczególnie dokładnie, bo błąd w procesie zamówienia oznacza bezpośrednią stratę finansową, nie tylko niedogodność. Dlatego przy sklepach internetowych w planie Pro rekomendujemy środowisko staging jako standard, a nie opcję.

Strona kancelarii albo gabinetu, gdzie kluczowy jest formularz umawiania wizyt lub kontaktu z klientem objętym tajemnicą zawodową, wymaga z kolei szczególnej uwagi przy aktualizacji wtyczek związanych z ochroną danych i szyfrowaniem formularzy. W każdym z tych scenariuszy procedura backupu przed aktualizacją jest identyczna, różni się tylko zakres testów po jej wykonaniu.

Ile to kosztuje i co się dzieje, gdy nikt tego nie robi

Koszt zarządzanych aktualizacji nie jest osobną pozycją na fakturze, jest wliczony w abonament planu Biznes (79 zł netto miesięcznie) i Pro (179 zł netto miesięcznie). To zwykle mniej niż jednorazowa wizyta freelancera wezwanego awaryjnie, gdy strona już przestała działać po nieudanej, samodzielnej aktualizacji. Koszt braku takiej opieki bywa dużo wyższy: utracone zamówienia w czasie przestoju, godziny spędzone na szukaniu freelancera dostępnego "na już", a czasem konieczność odtwarzania danych z przypadkowego, tygodniowego backupu, bo nikt nie pomyślał o kopii sprzed samej aktualizacji.

Co to oznacza dla Twojej firmy

Jeśli prowadzisz firmę i strona internetowa nie jest Twoim głównym zajęciem, ostatnią rzeczą, jakiej potrzebujesz, jest samodzielne żonglowanie wersjami PHP, wtyczek i rdzenia WordPressa w wolnej chwili między spotkaniami. Dokładnie po to powstał zarządzany hosting WordPress dla firm: zarządzane aktualizacje z backupem przed każdą zmianą, zabezpieczenie strony WordPress i bezpłatna migracja z obecnego hostingu są wliczone w cenę planu Biznes, bez dopłat za "dodatkowe" wsparcie. Pełne stawki znajdziesz w cenniku.

Szukasz hostingu dla firm, w którym ktoś naprawdę zajmuje się aktualizacjami za Ciebie, a nie tylko odpowiada na pytania w czacie? Zobacz, jak wygląda to w praktyce dla różnych typów stron na stronie zastosowania, od wizytówki, przez sklep WooCommerce, po stronę kancelarii z podwyższonymi wymaganiami RODO.