Aktualizacja wtyczek WordPress bez awarii: kopia, test, wdrożenie

Aktualizacja wtyczek WordPress przebiega bezpiecznie, jeśli za każdym razem robisz te same trzy kroki, w tej samej kolejności: kopia zapasowa, test na kopii strony, wdrożenie na produkcji i sprawdzenie, czy wszystko działa. Aktualizacje łatają luki bezpieczeństwa wtyczek i błędy. Dlatego odkładanie ich „na później” jest zwykle groźniejsze niż sama aktualizacja. Ten poradnik piszę dla właścicieli i administratorów stron firmowych oraz sklepów WooCommerce, którzy nie mają własnego działu IT. Niżej cały proces, krok po kroku.

Dlaczego aktualizacja wtyczek WordPress potrafi zepsuć stronę?

Najczęściej winne są konflikty: wtyczka kontra inna wtyczka, motyw, wersja WordPressa albo PHP na serwerze. Nowe wydanie jednej wtyczki potrafi zmienić funkcję, z której korzysta druga. Albo wymaga nowszego PHP, niż daje hosting. Objawy? Różne. Biały ekran, komunikat o błędzie krytycznym, rozjechany wygląd, a w sklepie koszyk albo płatności, które nagle przestają działać.

Najbardziej podatne są WooCommerce z rozszerzeniami, page buildery (wtyczki do składania stron metodą przeciągnij i upuść) oraz wtyczki płatności i wysyłki. Ryzyko rośnie też, gdy aktualizacja grzebie w strukturze bazy danych. Tylko że rezygnacja z aktualizacji tego ryzyka nie usuwa. Wcale. Ogranicza je dopiero proces, który pozwala szybko wrócić do stanu sprzed zmian.

Krok 1: kopia zapasowa przed aktualizacją

Przed każdą aktualizacją potrzebujesz pełnej kopii plików i bazy danych. Takiej, którą da się naprawdę odtworzyć, a nie tylko „jest gdzieś na serwerze”. Tak samo mówi oficjalna instrukcja aktualizacji WordPressa: kopia pozwala przywrócić stronę, gdy coś pójdzie nie tak. W kopii musi się znaleźć:

• baza danych,
• katalog wp-content z wtyczkami, motywami i plikami w uploads,
• plik wp-config.php.

Trzymaj ją poza serwerem strony. Bo awaria hostingu potrafi zabrać ze sobą i stronę, i kopię naraz. W sklepie rób backup tuż przed aktualizacją, żeby po ewentualnym przywróceniu nie zgubić świeżych zamówień. I co jakiś czas zrób próbne odtworzenie (dzień awarii to najgorszy moment, żeby odkryć, że kopia jest pusta albo niekompletna).

Krok 2: test w środowisku testowym WordPress

Środowisko testowe, czyli staging, to kopia strony pod osobnym adresem. Sprawdzasz na niej aktualizację bez żadnego ryzyka dla klientów. Sporo hostingodawców daje staging na jedno kliknięcie. Możesz też postawić kopię na subdomenie albo lokalnie, na swoim komputerze. Aha, zablokuj na niej indeksowanie i wysyłkę maili. Inaczej klienci dostaną powiadomienia o testowych zamówieniach, a tego nikt nie chce.

Zanim klikniesz „aktualizuj”, przeczytaj changelog, czyli listę zmian, i sprawdź zgodność z Twoją wersją WordPressa, WooCommerce i PHP. Wtyczki aktualizuj pojedynczo albo w małych grupach. Wtedy wiesz, która narobiła bałaganu. Po każdej zmianie przejdź listę kontrolną:

1. strona główna i kluczowe podstrony,
2. formularze kontaktowe i wyszukiwarka,
3. koszyk i zamówienie testowe,
4. panel administracyjny,
5. log błędów PHP.

Krok 3: wdrożenie na stronie produkcyjnej i kontrola po aktualizacji

Na produkcji działaj w godzinach najmniejszego ruchu i powtarzaj dokładnie to, co przeszło test. Nic więcej. Tuż przed wdrożeniem zrób świeżą kopię, nawet jeśli poprzednia powstała dzień wcześniej. Po aktualizacji przejdź tę samą listę kontrolną co na stagingu i wyczyść cache. Wtyczka prosi o aktualizację bazy danych? Uruchom ją od razu.

Bywa, że proces przerwie się w połowie i zostaje komunikat o nieudanej aktualizacji. Jest na to sposób: zgodnie z dokumentacją WordPressa usuń przez FTP plik .maintenance z głównego katalogu instalacji.

Co zrobić, gdy aktualizacja wtyczki psuje stronę?

Najszybciej pomaga wyłączenie wtyczki, która wywołała błąd. Jak to nie wystarczy, przywracasz kopię. A jeśli nie masz dostępu do panelu? Zmień nazwę katalogu tej wtyczki w wp-content/plugins przez FTP albo menedżer plików hostingu. WordPress przestanie ją ładować i po sprawie.

Przy błędzie krytycznym WordPress wysyła też na adres administratora maila z linkiem do trybu odzyskiwania. Logujesz się przez niego do panelu i wyłączasz wadliwą wtyczkę. Potem wracasz do poprzedniej wersji wtyczki albo odtwarzasz całą kopię i zgłaszasz problem autorowi. Przy wtyczkach z licencją błąd zgłaszasz producentowi. W sklepie z wtyczkami K4.pl licencje obejmują aktualizacje i wsparcie, a gdy gotowe rozwiązanie nie pasuje, wtyczkę można zamówić na miarę.

Automatyczne aktualizacje wtyczek: kiedy je włączyć, a kiedy nie?

Automat dobrze się sprawdza przy prostych, stabilnych dodatkach. Ale w sklepie wtyczki, od których zależy sprzedaż, moim zdaniem lepiej aktualizować ręcznie. Automatyczne aktualizacje włączasz albo wyłączasz dla każdej wtyczki osobno, na liście wtyczek w panelu. Z rdzeniem jest inaczej: według dokumentacji WordPressa drobne wydania i poprawki bezpieczeństwa instalują się w tle, a większe trzeba zatwierdzić przyciskiem.

WooCommerce, bramki płatności i page buildery? Zawsze przez test, bez wyjątków. Automat ma sens tylko wtedy, gdy masz codzienną kopię zapasową i monitoring dostępności strony, który da znać o awarii, zanim zauważą ją klienci.

Jak często aktualizować i jak to zaplanować w firmie?

Najlepiej sprawdza się stały rytm. Na przykład przegląd aktualizacji raz w tygodniu, a poprawki bezpieczeństwa od razu, bez czekania na „dzień aktualizacji”. Prosty harmonogram: przegląd listy, kopia, staging, wdrożenie i krótka notatka, co i kiedy poszło. Ta notatka to mała rzecz, ale bardzo przyspiesza szukanie winnego, gdy po kilku dniach coś zacznie działać inaczej.

No i sprzątanie. Nieużywane wtyczki i te porzucone przez autorów wyrzucaj regularnie, bo każda to kolejna rzecz do aktualizowania i kolejna potencjalna luka. Regularna aktualizacja wtyczek WordPress według schematu kopia, test, wdrożenie szybko wchodzi w nawyk. A taki nawyk chroni i stronę, i sprzedaż.

Najczęstsze pytania