Aktualizacja wtyczek WordPress

WordPress bardzo mocno zachęca do aktualizowania pluginów z poziomu panelu administracyjnego. W zakładce Wtyczki możesz pobrać i zainstalować update’y dla wszystkich rozszerzeń zbiorczo, a nawet – od wersji 5.5 – ustawić dla nich automatyczne aktualizacje.

Dla małego bloga albo prostej strony-wizytówki to bardzo wygodne. Ale już dla e-sklepu generującego dziesiątki tysięcy złotych dziennie? Ryzyko, że coś pójdzie nie tak, jest zbyt duże. Przy automatycznych aktualizacjach nie masz kontroli nad tym, w jakiej kolejności będą instalowane update’y, nie możesz też przetestować ich przed wdrożeniem na stronę. Poza tym, update update’owi nierówny; inaczej powinno się traktować łatki bezpieczeństwa, które naprawiają pojedyncze luki w kodzie – je należy instalować jak najszybciej – a inaczej duże aktualizacje, które potrafią czasem zupełnie zmienić logikę działania wtyczki.

Główny problem tkwi jednak w tym, że wtyczki WordPressa nie działają w próżni. Każdy plugin wchodzi w interakcje z motywem, innymi wtyczkami i samym core systemu. Twórcy wtyczek oczywiście testują je przed wydaniem kolejnego update’u… ale nie ma takiej możliwości, aby sprawdzili każdą możliwą konfigurację. Jeśli więc aktualizacja pluginu, przykładowo, zmienia hooki albo modyfikuje sposób ładowania skryptów, istnieje ryzyko, że wywoła konflikt z innymi elementami „ekosystemu” strony – najczęściej chodzi po prostu o inną wtyczkę. Ale nie zawsze; trzeba uważać też m.in. na zależności między wtyczkami a customowym kodem pisanym pod konkretny projekt albo na to, jak pluginy mogą współdziałać z integracjami. Tu zasada jest prosta: im większy projekt, tym większe też pole do konfliktu.

Konflikt między skryptami PHP, nawet najmniejszy, skończy się niestety błędem krytycznym… co oznacza tyle, że cała strona przestanie działać. I dlatego do aktualizacji wtyczek trzeba podejść bardzo ostrożnie i traktować je tak samo, jak każdą inną zmianę w kodzie.

Aktualizacja z panelu, WP-CLI czy Composer – czym różnią się te podejścia?

Same aktualizacje można wdrażać na kilka sposobów.

Najprościej będzie to zrobić z poziomu panelu administracyjnego WordPressa – wcale nie trzeba ich pobierać zbiorczo ani korzystać z automatycznych update’ów, można je instalować pojedynczo. Jednak nawet wtedy nie masz kontroli nad tym, jaką konkretnie wersję danej wtyczki pobierasz, bo WP zawsze będzie instalował tę najnowszą, a to może być ważne w kwestii kompatybilności np. z wersją PHP, którą obecnie masz na serwerze. Poza tym WordPress sam nigdzie nie dokumentuje historii zmian w kodzie… i dlatego przy większych projektach raczej nie przeprowadza się update’ów w ten sposób.

Lepszym rozwiązaniem – i tę drogę wybrałaby chyba większość administratorów – będzie instalowanie update’ów za pomocą WP-CLI, czyli interfejsu wiersza poleceń. Aby zaktualizować wtyczkę, wystarczy wpisać komendę typu wp plugin update woocommerce --version=8.5.1, nowe pliki zostaną od razu pobrane z biblioteki WP; co ważne, tutaj już możesz określić, którą konkretnie wersję wtyczki instalujesz. Jest też opcja, aby pobrać jednocześnie wszystkie dostępne aktualizacje (wp plugin update --all) albo – i to chyba największa zaleta – wyłącznie te pomniejsze. Wtedy do komendy dodajesz --patch, dla aktualizacji np. z wersji 1.3.3 do 1.3.4 albo --minor, dla update’ów rzędu z wersji 1.3 na 1.4.

Alternatywnie można też korzystać z Composera, czyli menedżera pakietów i zależności dla języka PHP – tutaj jednak panuje zupełnie inne podejście. Zamiast pobierać update’y bezpośrednio z biblioteki WP, korzystasz z zewnętrznych repozytoriów (WP Packages lub WPackagist), w których wtyczki mają format pakietów dostosowanych stricte pod Composera. Aby zainstalować aktualizacje, wystarczy w pliku composer.json zadeklarować, które wtyczki i w jakich wersjach mają wchodzić w skład projektu, uruchomić komendę composer update – Composer sam pobierze odpowiednie pakiety i zaktualizuje zależności w kodzie PHP strony. Dużym plusem jest to, że w osobnym pliku – composer.lock – Composer od razu zapisuje, co dokładnie zainstalował, więc całą historię aktualizacji można przechowywać w repozytorium Git i łatwo odtwarzać na wszystkich środowiskach.

Każdy administrator stron na WP powinien mieć swoją procedurę, przez którą zawsze przechodzi przy okazji aktualizacji wtyczek – obojętnie, czy tych pluginów jest pięć, czy piętnaście. Zazwyczaj wygląda ona tak, jak poniżej; warto się jej trzymać.

Z tych siedmiu kroków chyba najważniejszym są testy na stagingu.

Staging to odizolowana kopia Twojej strony z identyczną konfiguracją, wtyczkami, motywem i bazą danych, ale niedostępna dla użytkowników. Tworzy się ją po to, aby móc przetestować wszelkie zmiany w bezpieczny sposób, a nie na żywym organizmie.

Środowisko testowe dla WordPressa można przygotować na trzy sposoby:

• niektórzy hostingodawcy pozwalają to zrobić jednym kliknięciem z panelu hostingu; wtedy kopia strony pojawi się na tym samym serwerze, co wersja dostępna dla użytkowników, tyle że w osobnym katalogu i pod innym adresem URL;
• w bibliotece WordPressa dostępnych jest sporo wtyczek, które zrobią dokładnie to samo; taką opcję ma np. WP Staging albo Duplicator;
• można też ręcznie wykonać kopię strony na serwerze przez FTP i uruchomić na nim drugą instalację WordPressa.

Ważne, żeby środowisko stagingowe wyglądało identycznie jak produkcyjne – testowanie aktualizacji na kopii sprzed trzech miesięcy, gdy baza danych zdążyła przez ten czas urosnąć, mija się z celem. Dlatego kopię strony powinno się wykonywać przed testami za każdym razem od zera.

A co testujemy? Całą stronę, także te obszary, których aktualizacje teoretycznie nie dotyczą: wszystkie ścieżki użytkownika, działanie integracji z systemami zewnętrznymi, warto przyjrzeć się nawet warstwie wizualnej, ponieważ i tu czasem pojawiają się błędy. Chodzi o to, aby upewnić się, że po aktualizacji wtyczek nie ma żadnych „skutków ubocznych”; na tym, w skrócie, polegają testy regresji.

Jednak nawet jeśli przejdziesz przez aktualizację wtyczek krok po kroku zgodnie ze sztuką, i tak można trafić na błąd krytyczny. Co zrobić w takiej sytuacji?

1. Na początek sprawdź, czy działa WordPress Recovery Mode. Od wersji 5.2 WordPress ma wbudowany mechanizm ochrony przed błędami krytycznymi (Fatal Error Protection). Gdy taki błąd się pojawia, system próbuje wysłać na adres e-mail administratora wiadomość z linkiem uruchamiającym tryb odzyskiwania. Przez niego dostaniesz się do panelu WP – wadliwa wtyczka powinna być oznaczona, wtedy możesz ją dezaktywować jednym kliknięciem. Niestety, nie przy każdym błędzie ta ścieżka będzie w ogóle dostępna.

2. Sprawdź logi błędów. Jeśli nie możesz rozwiązać problemu z pomocą Recovery Mode, musisz znaleźć przyczynę samemu. Radzilibyśmy zacząć od trybu debugowania WordPressa; aby go włączyć, musisz dostać się do plików strony na serwerze (przez FTP, np. FileZillę albo przez menedżera plików na hostingu), znaleźć plik wp-config.php, a w nim linię define('WP_DEBUG', false). Zastąp ją wpisem:

   define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ).

   W folderze wp-content znajdziesz potem plik debug.log – od tej pory po każdej próbie wejścia na stronę w pliku tym będzie pojawiać się informacja, w jakim folderze, na jakim pliku i na której konkretnie linijce kodu występuje błąd krytyczny. To już wystarczy, żeby zidentyfikować wadliwą wtyczkę. Przy okazji, od razu warto też porównać wpisy z debug.log z logami błędów PHP (serwera). W panelu hostingu powinna znajdować się sekcja typu „Logi”, „Dziennik błędów” albo „Error Log”; przejrzyj ją, aby upewnić się, że źródło błędu leży tylko we wtyczkach, a nie np. w konfiguracji serwera.

3. Cofnij ostatnie zmiany najbezpieczniejszą dostępną metodą. Jeżeli widzisz, że problem pojawił się bezpośrednio po aktualizacji wtyczek, pora na rollback do wersji strony sprzed update’u, tak aby przynajmniej użytkownicy odzyskali do niej dostęp. Opcji znów jest kilka; możesz przywrócić całą stronę z backupu, cofnąć się do poprzedniej konfiguracji wtyczek w composer.lock, zapisanej w Gitcie (jeśli korzystasz z Composera) lub ręcznie cofnąć wersje wadliwych wtyczek.
4. Dezaktywuj problematyczną wtyczkę przez WP-CLI. Jeśli wtyczka nie jest absolutnie niezbędna do działania strony, możesz ją po prostu wyłączyć. Najprościej zrobić to przez WP-CLI, komendą wp plugin deactivate nazwa-wtyczki.
5. W ostateczności możesz dezaktywować wtyczkę również przez zmianę nazwy folderu w plikach strony na serwerze. W tym celu przejdź do katalogu wp-content, a następnie do folderu plugins; znajdź podfolder wadliwej wtyczki i zmień jego nazwę (np. z wtyczka na wtyczka.disabled). WordPress uruchomi wtedy stronę bez niej. Ale to jest tylko metoda „na wszelki wypadek”, lepiej korzystać z WP-CLI albo Composera.
6. Po przywróceniu strony nie zostawiaj problemu samemu sobie. Gdy strona znów działa, możesz na spokojnie przeanalizować, z czego konkretnie wynika konflikt w kodzie. Na pewno warto byłoby odtworzyć konfigurację wywołującą błąd krytyczny na stagingu, jeszcze raz prześledzić logi oraz cały stack trace. Być może jesteś w stanie rozwiązać ten konflikt samemu, a być może trzeba będzie poczekać na kolejny update od twórców wtyczki. W najgorszym scenariuszu trzeba będzie zastanowić się nad jakąś alternatywą dla wadliwych pluginów; na szczęście tych w bibliotece WordPressa nie brakuje. Na pewno odradzamy korzystanie ze starszych wersji wtyczek dłużej niż to konieczne.
7. Wyłącz tryb debugowania po zakończeniu diagnostyki. Bardzo ważna rzecz – gdy skończysz pracę z logami na głównej wersji strony (na produkcji), koniecznie wróć do wp-config.php i przywróć wpisom debugowania wartości false (albo po prostu usuń dodane linie).

Regularne update’y wtyczek, poprzedzone testami na stagingu, są jednym z podstawowych zadań w ramach każdej usługi stałej opieki technicznej WordPress. Jeżeli myślisz o tym, aby powierzyć swoją stronę specjalistom właśnie pod kątem aktualizacji, koniecznie zadbaj o to, aby częścią umowy było SLA. Przy wdrażaniu update’ów, zwłaszcza w witrynach, które mają po kilkadziesiąt wtyczek, błędy zdarzają się dosyć często. Dobrze sformułowane SLA zabezpieczy Cię przed kosztami ich naprawy i zapewni, że zespół software house’u zareaguje na problem w krótkim czasie, nawet w ciągu godziny.

Takie wsparcie otrzymasz w Smartbees – jeśli potrzebujesz pomocy przy aktualizacji wtyczek WordPress, skontaktuj się z nami. Porozmawiajmy, jakiej opieki potrzebuje Twoja strona!