Aktualizacja WordPressa bez ryzyka – procedura, którą stosuję u klientów

Najczęstszy powód, dla którego strony WordPress stoją na starych wersjach, brzmi: „ostatnio po aktualizacji coś się zepsuło”. To prawda, aktualizacje potrafią zepsuć stronę. Nieaktualizowana strona psuje się jednak na pewno – tylko później i drożej, bo przez włamanie. Różnica polega na procedurze. Poniżej ta, według której aktualizuję strony pod stałą opieką.

Przed aktualizacją

1. Kopia zapasowa całej strony – pliki i baza danych, zapisana poza serwerem. Nie „kopia z wczoraj z hostingu”, tylko wykonana teraz, przed zmianami. Bez tego kroku nie ma aktualizacji.
2. Lista zmian – dla większych aktualizacji (rdzeń, WooCommerce, motyw, wtyczka formularzy) czytam informacje o wydaniu. Szukam dwóch rzeczy: wymaganej wersji PHP i słów „breaking change” albo „migracja bazy”.
3. Sprawdzenie zgodności – czy wtyczka jest testowana z bieżącą wersją WordPressa i czy hosting ma wersję PHP, której wymaga.
4. Punkt odniesienia – otwieram stronę główną, jedną podstronę usług, formularz i (w sklepie) koszyk z płatnością.

Kolejność aktualizacji

Nigdy wszystko naraz. Gdy aktualizujesz dwadzieścia wtyczek jednym kliknięciem, a strona przestaje działać, nie wiesz, która to zrobiła.

1. Wtyczki – po jednej, od najmniej istotnych. Po każdej odświeżenie strony. Wtyczki krytyczne (WooCommerce, formularze, kreator stron, wtyczka SEO) na końcu, każda osobno.
2. Motyw – tylko jeśli używasz motywu potomnego albo motywu bez własnych modyfikacji. Zmiany wpisane bezpośrednio w pliki motywu nadrzędnego znikają przy aktualizacji; jeśli tak jest u Ciebie, najpierw trzeba je przenieść.
3. Rdzeń WordPressa – na końcu, gdy wtyczki są już zgodne z nową wersją.
4. PHP na hostingu – to osobne zadanie, nie element cotygodniowych aktualizacji. Zmiana wersji PHP potrafi ujawnić błędy w starszych wtyczkach, więc przy serwisie z kilkudziesięcioma wtyczkami każdą trzeba sprawdzić na nowej wersji; takie wdrożenie z reguły wyceniam i rozliczam osobno.

Po aktualizacji

Sprawdzam to samo, co przed: strona główna, podstrona, w sklepie ścieżka od produktu do podsumowania zamówienia. Formularza nie testuję po każdej aktualizacji – robię to wtedy, gdy aktualizowana była wtyczka formularzy: wysyłam testową wiadomość i sprawdzam, czy dotarła na skrzynkę. Do tego dziennik błędów PHP na hostingu – ostrzeżenia, które nie psują strony dziś, psują ją przy następnej aktualizacji. Czyszczę pamięć podręczną: wtyczki cache, serwera i Cloudflare, jeśli jest. Bez tego widzisz starą wersję i myślisz, że nic się nie zmieniło.

Gdy coś się zepsuje

Zasada: najpierw przywrócić działanie, potem szukać przyczyny.

• Biały ekran albo błąd krytyczny – WordPress wysyła na adres administratora link do trybu odzyskiwania, w którym można wyłączyć wtyczkę, która spowodowała błąd. Jeśli mail nie dotarł, wtyczkę wyłącza się przez FTP, zmieniając nazwę jej katalogu.
• Zmiana wyglądu albo układu – zwykle motyw albo kreator stron. Cofam tę jedną aktualizację (poprzednia wersja wtyczki jest w repozytorium WordPressa) i zgłaszam błąd autorowi.
• Problem z bazą danych po aktualizacji sklepu – przywracam kopię sprzed aktualizacji, a aktualizację powtarzam na kopii testowej, żeby zobaczyć, co się dzieje, bez ryzyka dla zamówień.

Dlatego kopia z punktu pierwszego nie jest formalnością – to jedyny sposób, żeby po nieudanej aktualizacji wrócić do stanu sprzed pięciu minut.

Sklepy i większe serwisy: najpierw kopia testowa

Przy sklepie WooCommerce aktualizacje robię najpierw na kopii testowej: identycznej instalacji na subdomenie, z ostatnią kopią bazy. Tam widać konflikty między wtyczkami płatności, dostaw i motywu, zanim zobaczą je klienci. Dopiero po sprawdzeniu ścieżki zakupowej powtarzam procedurę na sklepie właściwym – najlepiej rano w dzień roboczy, kiedy w razie problemu jest komu reagować. Tak wygląda to w pakietach opieki nad sklepami.

Automatyczne aktualizacje

Na stronach pod moją opieką żadna wtyczka nie aktualizuje się automatycznie. Muszę mieć kontrolę nad stanem technicznym serwisu – nie mogę zgadywać, co i kiedy przestało działać po aktualizacji, która uruchomiła się sama. Każdą zmianę wersji wykonuję ręcznie, po kopii zapasowej i ze sprawdzeniem strony, według procedury opisanej wyżej. Wyjątkiem są mniejsze wydania rdzenia WordPressa (wersje poprawkowe, np. 6.8.1 → 6.8.2): te pozostają włączone, bo zawierają poprawki bezpieczeństwa i błędów, bez nowych funkcji.

Jak często

Raz w tygodniu przegląd i aktualizacje wtyczek. O podatnościach informuje mnie Patchstack, z którym zintegrowany jest każdy serwis pod moją opieką; wtyczki ze znalezionymi podatnościami aktualizuję w ciągu 24 godzin, jeżeli autor udostępnił poprawkę. Raz na kwartał przegląd nieużywanych wtyczek. Strona, na której od pół roku nikt nie kliknął „aktualizuj”, jest dla automatów skanujących sieć zaproszeniem – piszę o tym w tekście o bezpieczeństwie WordPressa dla początkujących.