Aktualizacja wtyczek WordPress bez ryzyka krok po kroku

Zanim klikniesz „Aktualizuj”

Dobra aktualizacja zaczyna się przed kliknięciem. Te kroki zajmują kilka minut, a oszczędzają godziny przy awarii.

• Zrób pełną kopię plików i bazy danych, zapisaną poza serwerem strony. Kopia z wczoraj nie wystarcza, jeśli od tego czasu przyszły zamówienia albo zapytania. Szczegóły opisujemy w poradniku o kopii zapasowej WordPress.
• Sprawdź listę dostępnych aktualizacji. W WP-CLI robi to polecenie wp plugin list --update=available, które pokazuje wersję obecną i nową.
• Przeczytaj dziennik zmian (changelog). Szukaj słów „security”, „breaking change”, „requires”, informacji o zmianie minimalnej wersji PHP lub WordPressa i o migracji danych.
• Rozróżnij wersje. Zmiana z 4.2.1 na 4.2.2 to zwykle poprawka, a zmiana z 4.x na 5.0 to często przebudowa, która wymaga testu całej funkcji.
• Sprawdź wtyczki porzucone. Jeśli wtyczka od dawna nie ma aktualizacji albo została zamknięta w katalogu WordPress.org, zaplanuj jej zastąpienie, a nie czekaj na poprawkę.
• Wybierz porę małego ruchu i upewnij się, że ktoś będzie dostępny przez kolejne godziny, na wypadek gdyby problem wyszedł później.

Aktualizacja na kopii testowej (staging)

Kopia testowa to osobna instancja strony, najlepiej na tym samym serwerze albo w tej samej konfiguracji, z aktualną bazą i plikami, zablokowana przed indeksowaniem i niedostępna publicznie. Aktualizujesz najpierw tam, sprawdzasz, a dopiero potem powtarzasz na produkcji.

• Odśwież kopię testową z produkcji tuż przed aktualizacją, żeby testować na bieżących danych.
• Na kopii testowej wyłącz wysyłkę maili do klientów i połączenia z bramką płatności w trybie produkcyjnym, żeby test nie wysłał prawdziwych powiadomień ani nie pobrał pieniędzy.
• Zaktualizuj wtyczki, uruchom ewentualne aktualizacje bazy danych i przejdź przez listę testów opisaną niżej.
• Włącz zapis błędów: w pliku wp-config.php stałe WP_DEBUG i WP_DEBUG_LOG ustawione na true, a WP_DEBUG_DISPLAY na false. Ostrzeżenia i błędy trafią do pliku wp-content/debug.log, zamiast wyświetlać się odwiedzającym.

Jeśli nie masz kopii testowej, minimum to aktualizacja po jednej wtyczce na produkcji, z kopią zrobioną tuż wcześniej i sprawdzeniem strony po każdej z nich. To wolniejsze, ale od razu wiesz, która wtyczka wywołała problem.

Kolejność aktualizacji i WP-CLI

Rozsądna kolejność to najpierw drobne poprawki rdzenia WordPressa, potem wtyczki, potem motyw, a na końcu duże wersje rdzenia i PHP, każde z osobnym testem. Wtyczki aktualizuj pojedynczo albo w małych grupach, zaczynając od tych, które mają poprawki bezpieczeństwa.

WP-CLI, czyli wiersz poleceń WordPressa, bardzo ułatwia tę pracę, szczególnie przy kilku stronach.

• wp plugin update nazwa-wtyczki aktualizuje jedną wtyczkę.
• wp plugin update --all --dry-run pokazuje, co zostałoby zaktualizowane, niczego nie zmieniając.
• wp plugin install nazwa-wtyczki --version=1.2.3 --force przywraca wskazaną wersję z katalogu WordPress.org, jeśli nowa się nie sprawdzi.
• wp core update --minor aktualizuje rdzeń tylko w ramach poprawek bieżącej wersji.
• wp plugin verify-checksums --all porównuje pliki wtyczek z katalogu WordPress.org z oryginałem i pokazuje, czy ktoś je zmodyfikował.

Czy włączać automatyczne aktualizacje

WordPress od wersji 5.5 pozwala włączyć automatyczne aktualizacje dla każdej wtyczki osobno, a drobne poprawki rdzenia instaluje sam od dawna. Automatyczne aktualizacje dobrze sprawdzają się dla prostych wtyczek na prostych stronach. Dla sklepu, kreatora stron, wtyczki płatności, formularzy i wszystkiego, od czego zależy sprzedaż, bezpieczniej aktualizować świadomie: z kopią, testem i kimś, kto zobaczy efekt. Jeśli włączasz automat, połącz go z monitoringiem dostępności i codzienną kopią.

Co sprawdzić po każdej aktualizacji

Strona, która się ładuje, nie musi działać. Po aktualizacji przejdź przez stałą listę kontrolną.

• Strona główna, kilka kluczowych podstron i widok na telefonie: czy układ, menu i obrazy wyglądają jak przed zmianą.
• Formularz kontaktowy: wyślij testowe zgłoszenie i sprawdź, czy mail doszedł.
• Sklep: dodanie do koszyka, koszyk, zamówienie z testową metodą płatności, mail z potwierdzeniem, a w panelu WooCommerce zakładka Status i lista nieaktualnych szablonów.
• Logowanie do panelu i strefy klienta, jeśli jest.
• Plik debug.log i log błędów serwera: nowe ostrzeżenia to sygnał, że coś trzeba poprawić, zanim stanie się błędem.
• Zadania cykliczne (WP-Cron), na przykład wysyłka newslettera, synchronizacja z hurtownią czy generowanie plików produktowych.
• Cache: wyczyść cache strony i CDN, żeby odwiedzający nie dostali mieszanki starych i nowych plików.

Najpewniejszy sposób na wychwycenie zmian wyglądu to porównanie zrzutów ekranu przed i po aktualizacji. Test wizualny wskazuje przesunięte elementy, których łatwo nie zauważyć przy szybkim przeglądzie.

Aktualizacja motywu, rdzenia i wersji PHP

Wtyczki to tylko część układanki. Motyw, rdzeń WordPressa i wersja PHP na serwerze też wymagają aktualizacji, a każda z tych zmian ma własne ryzyka.

• Motyw. Jeśli zmieniałeś coś bezpośrednio w plikach motywu, aktualizacja nadpisze te zmiany. Właściwe miejsce na własny kod to motyw potomny (child theme) albo osobna, mała wtyczka. Motywy kupione na platformach z szablonami często aktualizują się tylko z aktywną licencją, więc sprawdź, czy ją masz.
• Rdzeń WordPressa. Drobne wersje (na przykład z 6.8.2 na 6.8.3) to głównie poprawki błędów i bezpieczeństwa. Duże wersje wprowadzają zmiany w edytorze bloków i interfejsach, z których korzystają wtyczki, więc zawsze testuj je na kopii testowej i sprawdź, czy kluczowe wtyczki deklarują zgodność.
• Wersja PHP. Starsze wersje PHP przestają dostawać poprawki bezpieczeństwa, a nowe są zwykle wyraźnie szybsze. Zmiana PHP to jednak moment, w którym wychodzą na jaw przestarzałe wtyczki i własny kod. Przełącz wersję najpierw na kopii testowej, przejrzyj log błędów i dopiero wtedy zmień ją na produkcji.
• Wtyczki premium. Pobieraj je wyłącznie z konta u producenta albo przez jego mechanizm aktualizacji. Paczka z nieoficjalnego źródła to jedna z najczęstszych dróg infekcji.

Kilka stron to kilka razy więcej pracy

Przy jednej stronie cały proces zajmuje zwykle godzinę w tygodniu. Przy kilkunastu stronach bez wspólnych narzędzi, stałej listy testów i harmonogramu aktualizacje zaczynają się odkładać, a zaległości rosną najszybciej właśnie tam, gdzie nikt nie patrzy. Wtedy warto rozważyć stałą opiekę albo przynajmniej wspólny panel, z którego widać wersje wszystkich stron naraz.

Plan wycofania

Jeśli po aktualizacji pojawia się biała strona albo komunikat o błędzie krytycznym, nie aktualizuj kolejnych rzeczy „na próbę”. Działaj po kolei.

• WordPress od wersji 5.2 ma tryb odzyskiwania: przy błędzie krytycznym wysyła na adres administratora link, który pozwala zalogować się do panelu i wyłączyć wtyczkę powodującą błąd.
• Bez dostępu do panelu wyłącz wtyczkę, zmieniając nazwę jej katalogu w wp-content/plugins przez SFTP, albo poleceniem wp plugin deactivate nazwa-wtyczki.
• Jeśli strona utknęła w trybie konserwacji, usuń plik .maintenance z katalogu głównego WordPressa.
• Przywróć poprzednią wersję wtyczki. Jeśli aktualizacja zmieniła bazę danych, samo przywrócenie plików może nie wystarczyć i trzeba odtworzyć także bazę z kopii zrobionej tuż przed zmianą.
• Zapisz, co się stało i jaka wersja jest problematyczna, i wróć do aktualizacji dopiero po poprawce autora albo zmianie w motywie.

Gdy strona jest całkowicie niedostępna, przydatna będzie lista kroków ze strony nie działa strona internetowa.