Jak bezpiecznie aktualizować WooCommerce i wtyczki

Dlaczego aktualizacje psują sklepy

Sklep WooCommerce to zestaw elementów: WordPress, WooCommerce, motyw, bramki płatności i kilka lub kilkanaście wtyczek, często od różnych autorów. Aktualizacja jednego z nich może zmienić zachowanie innego. Najczęstsze źródła problemów to:

• zmiany w funkcjach platformy, do których wtyczka nie została dostosowana. Przykładem jest przechowywanie zamówień (HPOS). Rozszerzenia deklarują w kodzie zgodność z tą funkcją, a WooCommerce ostrzega, gdy próbujesz ją włączyć przy niezgodnej wtyczce,
• podniesione wymagania techniczne. Portal dla deweloperów WooCommerce publikuje ostrzeżenia o zmianach, na przykład o wymaganiach wersji PHP,
• nieaktualizowane przez dłuższy czas wtyczki, które zaczynają się różnić od nowych wersji platformy,
• jednoczesna aktualizacja wielu elementów bez testu, więc nie wiadomo, który z nich spowodował błąd.

Z drugiej strony nieaktualizowany sklep jest narażony na znane luki. Cel nie polega na unikaniu aktualizacji, tylko na ich kontrolowaniu.

Krok 1: kopia plików i bazy

Według dokumentacji WooCommerce dane sklepu leżą w dwóch miejscach: w bazie danych (produkty, zamówienia, strony, ustawienia) i w katalogu wp-content (motywy, wtyczki, przesłane pliki). Kopia musi obejmować oba. Dokumentacja wskazuje, że najwygodniejsza jest automatyczna usługa kopii zapasowych.

Co zrobić:

1. Wykonaj kopię bazy i katalogu wp-content bezpośrednio przed aktualizacją.
2. Zapisz kopię poza serwerem sklepu, na przykład w osobnej usłudze lub na innym dysku.
3. Sprawdź, czy kopia daje się odtworzyć. Kopia, której nigdy nie przywracano, jest tylko założeniem.
4. Zanotuj numery wersji aktualizowanych elementów, żeby wiedzieć, do czego wracać.

Przywracanie nie jest trywialne, zwłaszcza jeśli sklep przyjmował zamówienia po utworzeniu kopii. Zamówienia złożone po wykonaniu kopii trzeba będzie odtworzyć osobno, dlatego okno aktualizacji warto wybierać w porze o małym ruchu.

Krok 2: kopia sklepu na środowisku testowym

Środowisko testowe (staging) to kopia sklepu, na której możesz testować zmiany bez wpływu na klientów. Możesz je utworzyć przez usługę hostingową albo odtworzyć kopię zapasową na osobnej instalacji WordPress.

Zasady:

1. Skopiuj bazę i pliki na środowisko testowe.
2. Odłącz od niego prawdziwe płatności i wysyłkę maili do klientów oraz integracje, które mogłyby zmienić dane produkcyjne (na przykład synchronizację z ERP). Środowisko testowe nie powinno przypadkiem składać zamówień ani wysyłać maili do klientów.
3. Zablokuj indeksowanie środowiska testowego przez wyszukiwarki.
4. Używaj trybu testowego bramek płatności tam, gdzie jest dostępny.

Uważaj na integracje. Kopia sklepu z kluczami do zewnętrznych systemów może łączyć się z produkcyjnym ERP i zmieniać dane. Wymień klucze na testowe albo wyłącz integracje na czas testów.

Krok 3: kolejność aktualizacji

Dokumentacja WooCommerce zaleca na środowisku testowym zaktualizować WooCommerce, rozszerzenia, bramki płatności i motyw, a następnie przetestować najważniejsze procesy. Po przejściu testów ten sam zestaw aktualizacji stosuje się na produkcji. Nie uruchamiaj kilku większych aktualizacji naraz, chyba że dokładnie ten zestaw był wcześniej testowany na kopii.

Praktyczna kolejność:

1. Kopia zapasowa.
2. Aktualizacja i testy na środowisku testowym.
3. Włączenie trybu konserwacji na produkcji na czas okna serwisowego (dokumentacja radzi to zrobić, żeby klienci nie finalizowali zamówień w trakcie zmian w plikach i bazie; w panelu WooCommerce odpowiada za to tryb „Coming soon”).
4. Aktualizacja WooCommerce w sekcji Wtyczki. Poczekaj do zakończenia procesu.
5. Jeśli pojawi się komunikat o aktualizacji bazy danych, uruchom ją i obserwuj zaplanowane akcje.
6. Aktualizacja pozostałych wtyczek, motywu i bramek płatności.
7. Weryfikacja sklepu na produkcji.

Rdzeń WordPress aktualizuj osobnym krokiem. Dokumentacja WordPress zaleca kopię zapasową przed aktualizacją, a niewielkie aktualizacje bezpieczeństwa mogą instalować się automatycznie. Większe wydania wymagają ręcznego uruchomienia. Wersje rdzenia i wymagania wtyczek sprawdź w dokumentacji przed aktualizacją, bo jej nie zgadujesz.

Krok 4: testy koszyka, płatności i integracji

Dokumentacja WooCommerce wymienia, co sprawdzić: strony produktów, koszyk, kasę, płatności, dostawę, podatki i e-maile z zamówieniami. Dodaj do tego własne procesy.

Lista testów:

1. Strona główna, kategorie, strona produktu (w tym wariantu) ładują się bez błędów.
2. Dodanie do koszyka, zmiana ilości, usunięcie.
3. Kod rabatowy.
4. Wybór dostawy i naliczenie kosztu.
5. Podatki i ceny netto/brutto, zgodnie z ustawieniami.
6. Zamówienie testowe każdą metodą płatności (tryb testowy lub małą kwotą, którą potem zwrócisz).
7. Maile do klienta i do ciebie po złożeniu zamówienia.
8. Rejestracja i logowanie klienta.
9. Integracje: przeniesienie zamówienia do ERP, synchronizacja stanów, generowanie faktur, etykiet przewoźnika.
10. Panel administracyjny: lista zamówień, edycja produktu, powiadomienia o błędach.

Po aktualizacji sprawdź także powiadomienia w panelu, nieudane zaplanowane akcje i ostrzeżenia o rozszerzeniach.

Statusy zamówień pomagają ocenić stan: zamówienie testowe powinno trafić w oczekiwany status, na przykład „w realizacji” po opłaceniu, a „wstrzymane” przy przelewie czekającym na potwierdzenie.

Krok 5: plan wycofania

Zanim zaktualizujesz produkcję, zapisz, co zrobisz, gdy coś pójdzie nie tak. Dokumentacja WooCommerce nie opisuje szczegółowo cofania wersji wtyczek. Zaleca wstrzymanie kasy (checkoutu), przywrócenie sklepu z kopii zapasowej, jeśli to konieczne, oraz zdiagnozowanie problemu na środowisku testowym przed kolejną próbą na produkcji.

Plan powinien odpowiadać na pytania:

• kto decyduje o wycofaniu i według jakiego kryterium (na przykład: nie działa płatność, nie wchodzą zamówienia),
• ile czasu masz na naprawę przed przywróceniem z kopii,
• jak przywrócić bazę i pliki oraz ile to trwa,
• jak odtworzysz zamówienia złożone między kopią a przywróceniem,
• kto kontaktuje się z klientami, jeśli wystąpił problem.

Testuj przywracanie na środowisku testowym, zanim będziesz go potrzebować.

Kiedy aktualizacje robić, a kiedy wstrzymać

Aktualizuj regularnie, bo opóźnienia kumulują ryzyko. Wstrzymaj się, gdy:

• trwa szczyt sprzedaży (na przykład akcja promocyjna) i nie masz czasu na testy,
• ostrzeżenia dla deweloperów wskazują zmianę, której twoje wtyczki jeszcze nie obsługują,
• wtyczka krytyczna dla sprzedaży nie ma jeszcze zgodności z nową wersją, a dostawca zapowiedział poprawkę,
• nie masz kopii lub środowiska testowego.

Nie zostawiaj jednak aktualizacji bezpieczeństwa na później bez powodu. Zaplanuj stałe okno, na przykład co dwa tygodnie, i trzymaj się go.

Lista kontrolna

• Kopia bazy i wp-content wykonana i zapisana poza serwerem.
• Przywracanie kopii sprawdzone.
• Środowisko testowe odizolowane od płatności, maili i integracji produkcyjnych.
• Zestaw aktualizacji przetestowany na środowisku testowym.
• Tryb konserwacji włączony na czas aktualizacji.
• Testy koszyka, płatności, maili i integracji wykonane po aktualizacji.
• Plan wycofania spisany, z osobą decyzyjną.
• Okno aktualizacji poza szczytem sprzedaży.

Dokumentuj każdą aktualizację

Prowadź prostą listę zmian: data, co zaktualizowano, z jakiej wersji na jaką, kto to zrobił, co sprawdzono i jaki był wynik. Taka lista kosztuje kilka minut, a oszczędza godziny, gdy za miesiąc pojawi się błąd i trzeba ustalić, co się zmieniło. Zapisuj też, które testy są obowiązkowe po każdej aktualizacji, żeby nie zależały od pamięci jednej osoby.

Dobrym zwyczajem jest też wyznaczenie jednej osoby odpowiedzialnej za aktualizacje i jednej do zastępstwa. Sklep, w którym „wszyscy mogą kliknąć aktualizuj”, to sklep, w którym nikt nie wie, kiedy ostatnio coś zmieniono.

Po aktualizacji: obserwacja przez kilka dni

Po wejściu zmian na produkcję przez kolejne dni zaglądaj do listy zamówień, e-maili sklepu i zaplanowanych akcji. Błędy w integracjach i powiadomieniach często wychodzą dopiero przy pierwszych prawdziwych zamówieniach, a nie w testach. Zapisz, kto za to odpowiada, i ustal, do kogo zgłaszać nieprawidłowości, żeby nie czekały na kolejną aktualizację.

Podsumowanie

Aktualizacje nie muszą być ryzykowne, jeśli przejdziesz je w stałej kolejności: kopia, test na kopii, wąskie okno na produkcji, testy po zmianie i plan wycofania. Największą różnicę robi środowisko testowe odizolowane od integracji. Jeśli utrzymujesz sklep z własnymi wtyczkami lub integracjami i potrzebujesz pomocy przy ich aktualizacji, zobacz usługi M8T.