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.

Cały problem w tym, że wtyczki WordPressa nie działają w próżni. Każdy plugin wchodzi w interakcje z motywem, z innymi wtyczkami i z 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, jest ryzyko, że wywoła konflikt z innymi elementami „ekosystemu” strony – najczęściej chodzi po prostu o inną wtyczkę.

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.

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. Błąd krytyczny po aktualizacji wtyczki prawdopodobnie zablokuje dostęp do panelu /wp-admin. Dlatego w pierwszej kolejności trzeba będzie dostać się do plików strony bezpośrednio na serwerze, przez klienta FTP – na przykład FileZillę. Aby to zrobić, musisz oczywiście znać dane dostępowe do serwera: host, login, hasło oraz port.

2. Znajdź 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 ).

   Uruchomi to tryb debugowania. W folderze wp-content znajdziesz plik debug.log – od tej pory po każdej próbie wejścia na stronę w pliku tym będzie pojawiać się informacja, na jakim pliku i na której konkretnie linijce kodu występuje błąd krytyczny.

3. Jeżeli wpis w logach wskazuje na którąś z zaktualizowanych wcześniej wtyczek, 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.
4. Jeśli strona dalej pokazuje komunikat o błędzie krytycznym – wróć do debug.log, sprawdź, jaki jest kolejny problem i próbuj wyłączać wadliwe wtyczki aż do skutku.
5. Gdy strona już ruszy, a Ty odzyskasz dostęp do panelu admina, najlepiej będzie po prostu cofnąć aktualizacje wadliwych pluginów do tych wersji, na których działały wcześniej. Przyda Ci się tu wtyczka WP Rollback, z pomocą której można jednym kliknięciem pobrać dowolną starszą wersję każdego pluginu z biblioteki WordPressa.

Po rollbacku strona powinna działać normalnie. Teraz możesz na spokojnie przeanalizować, między którymi konkretnie pluginami wystąpił konflikt i czy da się go rozwiązać. Być może niedługo twórcy wtyczki wydadzą łatkę, a może trzeba będzie znaleźć jakąś alternatywę dla tych pluginów – na pewno odradzamy korzystanie z przestarzałych wersji wtyczek dłużej niż to konieczne.

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!