Aktualizacja wtyczki powinna trwać kilka sekund i niczego nie zmieniać w wyglądzie strony. Zdarza się jednak, że tuż po niej znika formularz, rozsypuje się układ, koszyk w sklepie przestaje przyjmować zamówienia albo zamiast strony pojawia się komunikat o błędzie. Dla firmy każda taka godzina oznacza utracone zapytania, więc najważniejsze jest szybkie przywrócenie działania, a dopiero potem szukanie winnego.
Ta instrukcja jest przeznaczona dla właścicieli firm i osób, które same opiekują się stroną na WordPressie. Opisuję w niej, jak potwierdzić, że przyczyną jest aktualizacja, jak wyłączyć wtyczkę nawet wtedy, gdy kokpit nie działa, skąd wziąć poprzednią wersję i jak ją wgrać trzema sposobami: przez kokpit, przez pliki na serwerze i jednym poleceniem.
Po lekturze czytelnik będzie także wiedział, kiedy sama podmiana plików nie wystarczy i trzeba sięgnąć po kopię zapasową, jak zatrzymać ponowną aktualizację oraz jak później bezpiecznie wrócić do najnowszej wersji. Powrót do starszego wydania traktuję jako rozwiązanie na przeczekanie, a nie stan docelowy, i w kilku miejscach wyjaśniam dlaczego.
Po czym poznać, że stronę zepsuła aktualizacja wtyczki?
Najmocniejszą wskazówką jest czas. Jeżeli strona działała poprawnie, a kłopot pojawił się kilka minut po kliknięciu aktualizacji, podejrzenie jest uzasadnione. Trudniej jest wtedy, gdy wtyczki aktualizują się same, na przykład w nocy. Wówczas problem zauważa się dopiero rano i nie wiadomo, co się zmieniło.
WordPress wysyła na adres administratora wiadomość po każdej automatycznej aktualizacji wtyczek. Zawiera ona listę zaktualizowanych wtyczek wraz z numerem wersji przed zmianą i po niej. To najprostsze źródło wiedzy o tym, co zostało zmienione i z której wersji. Warto przeszukać skrzynkę, zanim zacznie się cokolwiek wyłączać.
Objawy mogą być różne i nie zawsze wyglądają na awarię:
- komunikat „W witrynie wystąpił błąd krytyczny” albo pusty, biały ekran,
- brak dostępu do kokpitu przy działającej części publicznej lub odwrotnie,
- zniknięcie jednego elementu, na przykład formularza, galerii, mapy lub przycisku płatności,
- rozsypany układ strony, brak czcionek i kolorów,
- wyraźnie wolniejsze wczytywanie albo błędy pojawiające się tylko w niektórych podstronach,
- niedziałające funkcje w tle: wiadomości z formularza, powiadomienia o zamówieniach, eksport danych.
Sama zbieżność w czasie to jeszcze nie dowód. W tym samym dniu mogła zmienić się wersja PHP na hostingu, mógł się zaktualizować motyw albo sam WordPress. Dlatego przed cofnięciem wersji trzeba wykonać prosty test, opisany w kolejnej części.
Co zrobić w pierwszych minutach, zanim cokolwiek zostanie cofnięte?
Pośpiech jest w tej sytuacji najgorszym doradcą. Kilka minut poświęconych na zabezpieczenie obecnego stanu chroni przed tym, że naprawa pogorszy sprawę. Kolejność ma znaczenie.
- Zanotowanie objawów i godziny, o której zostały zauważone. Jeżeli na ekranie jest komunikat błędu, należy skopiować jego pełną treść, bo często zawiera ścieżkę do pliku konkretnej wtyczki.
- Wykonanie kopii zapasowej obecnego, zepsutego stanu: plików i bazy danych. Brzmi to dziwnie, ale ta kopia pozwala wrócić do punktu wyjścia, gdyby cofanie wersji poszło źle. Sposób wykonania opisałem we wpisie o tym, jak zrobić i sprawdzić kopię zapasową WordPressa.
- Ustalenie, jaka wersja wtyczki jest zainstalowana teraz. W kokpicie należy otworzyć „Wtyczki”, a następnie „Zainstalowane wtyczki”. Numer wersji widnieje pod opisem każdej wtyczki.
- Ustalenie, jaka wersja działała wcześniej. Źródłem jest wiadomość o automatycznej aktualizacji, kopia zapasowa sprzed zmiany albo dziennik zmian wtyczki, w którym wersje są ułożone po kolei.
- Wyłączenie podejrzanej wtyczki odnośnikiem „Wyłącz” na liście wtyczek i odświeżenie strony w oknie prywatnym przeglądarki.
Ostatni punkt jest właściwym testem. Jeżeli po wyłączeniu wtyczki błąd znika, a strona działa poza funkcją, za którą ta wtyczka odpowiada, winny jest ustalony. Jeżeli błąd pozostaje, przyczyna leży gdzie indziej i cofanie tej wtyczki niczego nie naprawi.
Gdy podejrzanych jest kilka, bo zaktualizowało się kilka wtyczek naraz, trzeba wyłączać je pojedynczo i po każdej zmianie odświeżać stronę. Dokumentacja WordPressa zaleca właśnie taką metodę: wyłączanie po jednej, aż do znalezienia tej, która wywołuje problem. Wyłączenie wtyczki nie kasuje jej ustawień, więc test jest bezpieczny.
Jedno zastrzeżenie dotyczy sklepów i stron z rezerwacjami. Wyłączenie wtyczki płatności, dostawy lub rezerwacji na czas testu oznacza, że klienci przez chwilę nie dokończą zamówienia. Taki test najlepiej przeprowadzić szybko i w porze najmniejszego ruchu, a jeśli to możliwe, na kopii testowej strony.
Jak wyłączyć wtyczkę, gdy kokpit nie działa?
Najtrudniejszy przypadek to błąd, który blokuje logowanie. Nie ma wtedy listy wtyczek ani odnośnika „Wyłącz”. Są trzy drogi wyjścia i każda prowadzi do tego samego celu: WordPress ma przestać wczytywać wadliwą wtyczkę.
Tryb odzyskiwania z wiadomości e-mail
Gdy WordPress wykryje błąd krytyczny, wysyła na adres administratora wiadomość z informacją, która wtyczka lub motyw go wywołały, oraz ze specjalnym odnośnikiem. Po jego otwarciu i zalogowaniu kokpit działa w trybie odzyskiwania, a wadliwa wtyczka jest w tej sesji wstrzymana. Można ją wtedy spokojnie wyłączyć. Szczegóły opisałem osobno: jak skorzystać z trybu odzyskiwania w WordPressie.
Zmiana nazwy katalogu wtyczki na serwerze
Jeżeli wiadomość nie dotarła, pozostaje dostęp do plików: program FTP albo menedżer plików w panelu hostingu. Wtyczki znajdują się w katalogu wp-content/plugins, każda we własnym podkatalogu. Zmiana nazwy podkatalogu wadliwej wtyczki, na przykład przez dopisanie na końcu -wylaczona, sprawia, że WordPress jej nie znajduje i traktuje jako wyłączoną.
Dokumentacja WordPressa opisuje też wariant dla sytuacji, w której nie wiadomo, która wtyczka zawiniła: zmianę nazwy całego katalogu plugins, na przykład na plugins.hold. Wyłącza to wszystkie wtyczki jednocześnie. Po zalogowaniu się do kokpitu należy przywrócić katalogowi pierwotną nazwę. Wtyczki pozostaną wyłączone, ale ich ustawienia zostaną zachowane, i będzie można włączać je po kolei.
Radzę zaczynać od pojedynczego katalogu, jeśli tylko wiadomo, o którą wtyczkę chodzi. Wyłączenie wszystkich wtyczek naraz na działającej stronie firmowej oznacza chwilowy brak formularzy, zabezpieczeń, pamięci podręcznej i ustawień SEO. To metoda skuteczna, ale przeznaczona na sytuację, w której nic innego nie pozwala wejść do kokpitu.
Polecenie WP-CLI na hostingu z dostępem SSH
Na serwerach z dostępem SSH i zainstalowanym narzędziem WP-CLI wtyczkę wyłącza jedno polecenie wpisane w katalogu strony: wp plugin deactivate nazwa-wtyczki. Nazwą jest nazwa podkatalogu wtyczki. Listę wtyczek wraz z wersjami i stanem pokazuje polecenie wp plugin list.
Po wyłączeniu wtyczki którąkolwiek z tych dróg strona powinna wrócić do działania bez jednej funkcji. To dobry moment na oddech: awaria jest opanowana, a przywrócenie poprzedniej wersji można przeprowadzić bez presji.
Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przejmę sprawę: ustalę, która wtyczka i która wersja zepsuła stronę, zabezpieczę dane i przywrócę ostatnie działające wydanie.
Skąd wziąć poprzednią wersję wtyczki?
Źródło zależy od tego, skąd wtyczka pochodzi. Są trzy możliwości i każda wymaga innego postępowania.
Wtyczki z katalogu WordPress.org
Katalog wtyczek WordPress.org przechowuje starsze wydania. Na stronie wtyczki, pod zakładkami z opisem i recenzjami, znajduje się odnośnik „Widok zaawansowany”. Na dole tego widoku jest część „Opcje zaawansowane” z nagłówkiem „Poprzednie wersje”, rozwijaną listą numerów i przyciskiem „Pobierz”.
- Otwarcie strony wtyczki w polskiej wersji katalogu WordPress.org i wyszukanie jej po nazwie.
- Kliknięcie odnośnika „Widok zaawansowany”.
- Przewinięcie strony do nagłówka „Poprzednie wersje”.
- Wybranie z listy numeru wersji, która działała przed aktualizacją. Na liście domyślnie widnieje pozycja „Wersja deweloperska”, której nie należy pobierać na stronę firmową.
- Kliknięcie „Pobierz” i zachowanie pliku ZIP na dysku bez rozpakowywania.
Katalog sam ostrzega przy tej liście, że poprzednie wersje wtyczek mogą być niebezpieczne lub niestabilne i że nie zaleca ich stosowania w działających witrynach. To uczciwe ostrzeżenie. Starsze wydanie może zawierać lukę, którą nowsze właśnie usunęło, dlatego wybiera się wersję bezpośrednio poprzedzającą wadliwą, a nie dowolnie starą.
Wtyczki płatne i pobrane od producenta
Wtyczek kupionych poza katalogiem nie ma na WordPress.org. Starsze wydania udostępnia zwykle producent w koncie klienta, w części z plikami do pobrania lub historią wersji. Jeżeli takiej listy nie ma, należy napisać do pomocy technicznej producenta z prośbą o konkretny numer wersji. Jedynym bezpiecznym źródłem jest producent lub własna kopia zapasowa.
Przestrzegam przed pobieraniem płatnych wtyczek z przypadkowych serwisów oferujących je bez licencji. Takie paczki bywają zmodyfikowane i zawierają złośliwy kod, a korzystanie z nich narusza warunki licencji. Zysk w postaci szybszego pobrania nie jest wart ryzyka zainfekowania strony.
Własna kopia zapasowa
Trzecim źródłem jest kopia plików strony sprzed aktualizacji. Wystarczy wydobyć z niej jeden katalog: wp-content/plugins/nazwa-wtyczki. Ta droga ma dodatkową zaletę, bo daje dokładnie te pliki, które działały na tej konkretnej stronie, łącznie z ewentualnymi tłumaczeniami.
Jak wgrać starszą wersję przez kokpit WordPressa?
To najprostsza metoda i wystarcza w większości przypadków. WordPress pozwala wysłać plik ZIP wtyczki, która jest już zainstalowana, i zastąpić nim obecną wersję. Warunkiem jest działający kokpit.
- W kokpicie należy otworzyć „Wtyczki”, a następnie „Dodaj wtyczkę”.
- U góry ekranu trzeba kliknąć „Wyślij wtyczkę na serwer”.
- W polu wyboru pliku wskazuje się pobrany wcześniej plik ZIP ze starszą wersją.
- Kliknięcie „Zainstaluj” rozpoczyna przesyłanie.
- WordPress rozpoznaje, że wtyczka jest już zainstalowana, i wyświetla zestawienie obecnej oraz przesłanej wersji: numer, autora, wymaganą wersję WordPressa i PHP. Pojawia się też uwaga, że przesłano wersję starszą od obecnej, wraz z zaleceniem wykonania kopii zapasowej bazy danych i plików.
- Po sprawdzeniu numerów należy wybrać przycisk zastąpienia obecnej wersji przesłaną. Drugi przycisk, „Anuluj i wróć”, przerywa operację bez zmian.
- Jeżeli wtyczka była wcześniej wyłączona, trzeba ją włączyć na liście „Zainstalowane wtyczki”.
Ustawienia wtyczki pozostają nietknięte, ponieważ są przechowywane w bazie danych, a podmianie ulegają wyłącznie pliki. Właśnie dlatego nie należy przed wgraniem starszej wersji usuwać wtyczki odnośnikiem „Usuń”.
To częsty i kosztowny błąd. Wiele wtyczek podczas usuwania kasuje z bazy własne ustawienia, formularze, a czasem całe tabele z danymi. Po ponownej instalacji wtyczka wraca wtedy pusta, jak tuż po pierwszym uruchomieniu. Zastąpienie plików przez przesłanie archiwum ZIP tego ryzyka nie niesie.
Istnieją również wtyczki, które dodają do listy wtyczek odnośnik do cofania wersji i same pobierają wybrane wydanie z katalogu WordPress.org. Działają poprawnie, ale wykonują dokładnie tę samą podmianę plików, co opisane wyżej kroki, i nie obsługują wtyczek spoza katalogu. Przy jednorazowej awarii nie widzę powodu, by instalować dodatkowe narzędzie.
Jak przywrócić starszą wersję przez pliki na serwerze lub jednym poleceniem?
Gdy kokpit nie działa albo przesyłanie pliku ZIP kończy się błędem, na przykład z powodu limitu wielkości pliku na hostingu, pozostaje praca bezpośrednio na plikach. Wymaga ona większej uwagi, ale daje pełną kontrolę nad tym, co trafia na serwer.
Podmiana katalogu przez FTP lub menedżer plików
- Rozpakowanie pobranego pliku ZIP na dysku komputera. W środku powinien znajdować się jeden katalog o nazwie wtyczki.
- Połączenie z serwerem przez FTP lub otwarcie menedżera plików w panelu hostingu i przejście do katalogu
wp-content/plugins. - Pobranie na dysk obecnego katalogu wtyczki jako dodatkowej kopii wadliwej wersji.
- Usunięcie z serwera katalogu wtyczki albo, jeśli wcześniej zmieniono mu nazwę w celu wyłączenia, usunięcie katalogu o zmienionej nazwie. Kasuje się wyłącznie pliki, baza danych pozostaje bez zmian.
- Wysłanie na serwer rozpakowanego katalogu ze starszą wersją, pod dokładnie taką samą nazwą, jaką miał katalog pierwotny.
- Odczekanie do końca przesyłania wszystkich plików i porównanie liczby plików po obu stronach. Przerwane przesyłanie daje niepełną wtyczkę i nowe błędy.
- Zalogowanie się do kokpitu, sprawdzenie numeru wersji na liście „Zainstalowane wtyczki” i włączenie wtyczki, jeśli jest wyłączona.
Nie zalecam wgrywania starszych plików na nowsze bez wcześniejszego usunięcia katalogu. Nowa wersja mogła zawierać pliki, których w starszej nie było. Pozostawione na serwerze, mieszają się z poprzednim wydaniem i potrafią wywołać błędy trudne do zrozumienia.
Polecenie WP-CLI
Dla wtyczek z katalogu WordPress.org najszybsza jest konsola. Polecenie instalacji przyjmuje numer wersji, a dodatkowa opcja pozwala nadpisać wersję już zainstalowaną. Gotowy wiersz do przepisania, z własną nazwą wtyczki i numerem wersji, wygląda tak:
wp plugin install nazwa-wtyczki --version=1.2.3 --force
Zgodnie z dokumentacją WP-CLI opcja --version pobiera wskazane wydanie z WordPress.org zamiast wersji stabilnej, a opcja --force nadpisuje zainstalowaną wtyczkę bez pytania o potwierdzenie. Brak pytania oznacza, że pomyłka w nazwie lub numerze zostanie wykonana od razu, dlatego przed naciśnięciem klawisza Enter trzeba przeczytać wiersz jeszcze raz. Wynik potwierdza polecenie wp plugin list.
Kiedy sama podmiana plików nie wystarczy i potrzebna jest kopia zapasowa?
Opisane metody cofają pliki wtyczki. Nie cofają zmian, które nowa wersja zdążyła wprowadzić w bazie danych. Większość drobnych aktualizacji bazy nie dotyka, ale duże wydania rozbudowanych wtyczek, takich jak sklepy, systemy rezerwacji, kreatory stron czy wtyczki członkowskie, potrafią przebudować sposób zapisu danych.
Po takiej zmianie starsze pliki trafiają na bazę w nowym układzie, którego nie rozumieją. Skutkiem mogą być nowe błędy, brakujące dane w panelu albo komunikat z prośbą o ponowną aktualizację bazy. Informację o zmianach w bazie producenci zwykle podają w dzienniku zmian przy danym wydaniu, często z wyraźnym ostrzeżeniem, że powrót do starszej wersji nie jest wspierany.
W takiej sytuacji bezpieczniejszą drogą jest przywrócenie pełnej kopii zapasowej sprzed aktualizacji: plików i bazy jednocześnie. Trzeba jednak znać cenę tej decyzji. Przywrócenie bazy cofa wszystko, co zapisano od chwili wykonania kopii, czyli zamówienia, zgłoszenia z formularzy, komentarze, nowych użytkowników i zmiany w treści.
Na stronie wizytówkowej, na której od wczoraj nic się nie zmieniło, strata jest żadna. W sklepie z kilkunastoma zamówieniami dziennie przywrócenie nocnej kopii w południe oznacza utratę porannych zamówień. Przed taką operacją należy więc wyeksportować zamówienia i zgłoszenia z ostatnich godzin, a kopię zepsutego stanu, wykonaną na samym początku, zachować do czasu upewnienia się, że niczego nie brakuje.
Jeżeli nie ma pewności, czy aktualizacja zmieniła bazę, najrozsądniej jest zapytać producenta wtyczki albo przeprowadzić próbę na kopii testowej strony. Wielu dostawców hostingu udostępnia w panelu własne kopie z ostatnich dni i możliwość utworzenia środowiska testowego. Warto sprawdzić to w panelu, zanim zapadnie decyzja.
Jak zatrzymać ponowną aktualizację i sprawdzić, czy naprawa zadziałała?
Przywrócona starsza wersja będzie widoczna na liście wtyczek z informacją o dostępnej aktualizacji. Jeżeli automatyczne aktualizacje są włączone, WordPress przy najbliższej okazji ponownie zainstaluje wadliwe wydanie i problem wróci. Trzeba temu zapobiec od razu.
Na ekranie „Zainstalowane wtyczki”, w kolumnie „Automatyczne aktualizacje”, przy cofniętej wtyczce należy kliknąć „Wyłącz automatyczne aktualizacje”. Jeżeli aktualizacjami zarządza także hosting, wtyczka bezpieczeństwa albo zewnętrzny panel do obsługi wielu stron, tę samą wtyczkę trzeba wykluczyć również tam. Więcej o rozsądnym podziale opisałem we wpisie o tym, co w WordPressie aktualizować automatycznie, a co ręcznie.
Od tej chwili nie należy też korzystać z przycisku zbiorczej aktualizacji wszystkich wtyczek, bo obejmie on również tę cofniętą. Pozostałe wtyczki aktualizuje się pojedynczo.
Samo zniknięcie komunikatu o błędzie nie oznacza, że wszystko działa. Sprawdzenie powinno objąć kilka miejsc:
- stronę główną i dwie lub trzy podstrony otwarte w oknie prywatnym, po wyczyszczeniu pamięci podręcznej we wtyczce, na serwerze i w sieci CDN,
- funkcję, za którą odpowiada cofnięta wtyczka: wysłanie próbnego formularza, przejście całej ścieżki zamówienia, wykonanie próbnej rezerwacji,
- logowanie do kokpitu i zapis dowolnego wpisu w edytorze,
- ekran „Kondycja witryny” w menu „Narzędzia”, na którym nie powinno być nowych krytycznych problemów,
- dziennik błędów, w którym po naprawie nie powinny przybywać nowe wpisy dotyczące tej wtyczki.
Dziennik błędów jest najpewniejszym sprawdzianem, ponieważ pokazuje także problemy niewidoczne na ekranie. Sposób jego uruchomienia i czytania opisałem we wpisie o tym, jak włączyć zapis błędów do pliku w trybie debugowania. Po zakończeniu sprawdzania zapis błędów należy wyłączyć.
Co zrobić, gdy powrót do starszej wersji nie pomógł?
Jeżeli po przywróceniu poprzedniej wersji błąd pozostał, możliwych wyjaśnień jest kilka. Każde da się sprawdzić osobno.
Pierwsze to pamięć podręczna. Strona może nadal wyświetlać zapisaną wcześniej, zepsutą wersję podstrony. Należy wyczyścić pamięć podręczną na wszystkich poziomach i obejrzeć stronę w oknie prywatnym albo na innym urządzeniu. Na niektórych serwerach zapamiętywany jest także skompilowany kod PHP i jego odświeżenie wymaga ponownego uruchomienia usługi PHP w panelu hostingu.
Drugie to zmiany w bazie danych, opisane wcześniej. Jeżeli po cofnięciu plików pojawiły się inne błędy niż przed nim, to znak, że starsza wersja nie radzi sobie z nowym układem danych. Pozostaje wtedy przywrócenie pełnej kopii albo powrót do nowej wersji i szukanie poprawki u producenta.
Trzecie to konflikt, a nie wada samej wtyczki. Nowa wersja mogła działać poprawnie, lecz przestała współpracować z inną wtyczką, z motywem albo z wersją PHP na serwerze. Wskazuje na to sytuacja, w której błąd znika po wyłączeniu innej wtyczki lub po chwilowym przełączeniu motywu na domyślny. W takim przypadku cofanie jednej wtyczki tylko maskuje problem.
Czwarte to pomyłka w ustaleniu winnego. Tego samego dnia mógł się zaktualizować motyw, sam WordPress albo hosting mógł zmienić wersję PHP. Wiadomości o automatycznych aktualizacjach i komunikaty od dostawcy hostingu pozwalają odtworzyć pełną listę zmian z ostatnich dni.
Gdy żadna z tych dróg nie daje wyniku, a firma traci zapytania, uważam, że nie należy przedłużać prób na działającej stronie. Przywrócenie pełnej kopii sprzed aktualizacji przywraca działanie, a dalsze szukanie przyczyny można prowadzić na kopii testowej.
Jak bezpiecznie wrócić do aktualnej wersji i jakich błędów unikać?
Starsza wersja wtyczki nie otrzymuje poprawek bezpieczeństwa. Im dłużej strona na niej pozostaje, tym większe ryzyko, że ktoś wykorzysta znaną już lukę. Cofnięcie wersji kupuje czas, a ten czas trzeba dobrze wykorzystać.
Pierwszym zadaniem jest zgłoszenie błędu autorowi. Wtyczki z katalogu WordPress.org mają na swojej stronie zakładkę „Wsparcie” z forum, na którym często widać już zgłoszenia innych osób z tym samym kłopotem. Przy wtyczkach płatnych zgłoszenie wysyła się przez pomoc techniczną producenta. Dobre zgłoszenie można oprzeć na takim wzorze: Po aktualizacji z wersji [numer] do wersji [numer] na stronie pojawia się [opis objawu]. Wersja WordPressa: [numer], wersja PHP: [numer], motyw: [nazwa]. Treść błędu z dziennika: [wklejony wpis]. Po powrocie do wersji [numer] problem ustępuje.
Drugim zadaniem jest obserwowanie dziennika zmian. Gdy pojawi się nowe wydanie z opisem poprawki, nie instaluje się go od razu na działającej stronie. Najpierw wykonuje się świeżą kopię zapasową, potem próbę na kopii testowej, a dopiero po pomyślnej próbie aktualizację właściwej strony, w porze małego ruchu i z kilkoma minutami na sprawdzenie najważniejszych funkcji.
Po udanej aktualizacji można ponownie włączyć automatyczne aktualizacje tej wtyczki, o ile wcześniej były świadomym wyborem. Przy wtyczkach, od których zależy sprzedaż, zalecam jednak aktualizacje ręczne, poprzedzone kopią.
Na koniec zestawienie błędów, które w tej sytuacji zdarzają się najczęściej:
- usunięcie wtyczki odnośnikiem „Usuń” przed wgraniem starszej wersji, co bywa równoznaczne z utratą jej ustawień i danych,
- cofanie wersji bez kopii obecnego stanu, przez co nie ma dokąd wrócić po nieudanej próbie,
- pobranie starszej wersji płatnej wtyczki z niepewnego źródła,
- wybranie wersji sprzed wielu wydań zamiast tej bezpośrednio poprzedzającej wadliwą,
- pozostawienie włączonych automatycznych aktualizacji, które po kilku godzinach przywracają wadliwe wydanie,
- przywrócenie pełnej kopii bazy w sklepie bez wcześniejszego zabezpieczenia nowych zamówień,
- uznanie sprawy za zamkniętą i pozostanie na starej wersji przez wiele miesięcy.
Warto też wiedzieć, czego WordPress pilnuje samodzielnie. Jeżeli instalacja aktualizacji nie powiedzie się w trakcie, na przykład nie uda się skopiować plików, system przywraca poprzednią wersję wtyczki z tymczasowej kopii w katalogu wp-content/upgrade-temp-backup. Przy aktualizacjach automatycznych WordPress dodatkowo sprawdza, czy zaktualizowana wtyczka nie wywołuje błędu krytycznego, i w razie potrzeby ją cofa. Mechanizmy te nie obejmują jednak aktualizacji, która technicznie się udała, a zepsuła wygląd lub jedną funkcję. Tymczasowa kopia jest po zakończeniu aktualizacji usuwana, więc nie zastępuje własnej kopii zapasowej.
Najczęstsze pytania
Czy po powrocie do starszej wersji wtyczka straci ustawienia?
Nie, o ile podmienione zostaną same pliki: przez przesłanie archiwum ZIP w kokpicie, przez podmianę katalogu na serwerze albo poleceniem WP-CLI. Ustawienia są zapisane w bazie danych i pozostają na miejscu. Utratą ustawień grozi natomiast usunięcie wtyczki odnośnikiem „Usuń”, ponieważ wiele wtyczek czyści wtedy swoje dane.
Czy WordPress ma wbudowany przycisk cofania wersji wtyczki?
Nie ma przycisku, którym administrator wybiera starszą wersję z listy. WordPress potrafi samodzielnie przywrócić poprzednią wersję tylko wtedy, gdy aktualizacja nie powiodła się technicznie albo gdy automatyczna aktualizacja wywołała błąd krytyczny. W pozostałych przypadkach starszą wersję trzeba pobrać i wgrać ręcznie.
Skąd wiadomo, która wersja była zainstalowana przed aktualizacją?
Przy aktualizacjach automatycznych numer poprzedniej i nowej wersji podaje wiadomość wysyłana przez WordPress na adres administratora. Przy aktualizacjach ręcznych pomaga kopia zapasowa sprzed zmiany, w której numer wersji znajduje się w nagłówku głównego pliku wtyczki. W ostateczności wybiera się wydanie bezpośrednio poprzedzające obecne według dziennika zmian.
Jak długo można bezpiecznie pozostać na starszej wersji?
Jak najkrócej. Starsze wydanie nie dostaje poprawek bezpieczeństwa, a kolejne aktualizacje WordPressa i PHP mogą z czasem przestać z nim współpracować. Rozsądnym celem jest powrót do aktualnej wersji zaraz po tym, gdy autor opublikuje poprawkę i zostanie ona sprawdzona na kopii testowej.
Co zrobić, gdy autor wtyczki nie odpowiada i nie wydaje poprawki?
Należy sprawdzić na stronie wtyczki w katalogu, kiedy była ostatnio aktualizowana i czy zgłoszenia na forum wsparcia są rozwiązywane. Jeżeli wtyczka wygląda na porzuconą, pozostanie na starej wersji jest tylko odkładaniem problemu. Dokumentacja WordPressa wskazuje w takiej sytuacji proste wyjście: wyłączyć wadliwą wtyczkę, poszukać podobnej, zainstalować ją i sprawdzić, czy problem ustąpił.
Czy zamiast wtyczki można cofnąć samą wersję PHP na hostingu?
Tylko wtedy, gdy przyczyną jest właśnie niezgodność z wersją PHP, co zwykle widać w treści błędu w dzienniku. Jeżeli nowa wersja wtyczki wymaga nowszego PHP niż ustawione na serwerze, rozwiązaniem jest podniesienie wersji PHP, a nie cofanie wtyczki. Zmianę wersji PHP także warto najpierw sprawdzić na kopii testowej.
Czy tę samą metodę stosuje się do motywu?
Zasada jest taka sama: WordPress pozwala przesłać archiwum ZIP zainstalowanego już motywu i zastąpić nim obecną wersję. Różnica dotyczy zmian wprowadzonych bezpośrednio w plikach motywu, które przy każdej podmianie przepadają, jeżeli nie zostały umieszczone w motywie potomnym. Przed podmianą motywu kopia jego katalogu jest więc obowiązkowa.
Czy cofnięcie wersji wtyczki wpływa na widoczność strony w Google?
Samo cofnięcie nie ma takiego wpływu. Znaczenie ma czas trwania awarii: strona zwracająca błędy przez wiele godzin traci odwiedzających, a roboty wyszukiwarki napotykają niedostępne podstrony. Krótka przerwa zwykle nie zostawia śladów, dlatego liczy się szybkie przywrócenie działania, a dopiero potem dokładna naprawa.
Brak czasu albo ochoty, żeby zająć się tym samodzielnie?
Awaria po aktualizacji zdarza się zwykle w najmniej odpowiedniej chwili, a praca na plikach serwera i bazie danych nie każdemu sprawia przyjemność. Chętnie zajmę się tym od początku do końca: zabezpieczę obecny stan strony, ustalę, która wtyczka i która wersja wywołała problem, przywrócę działające wydanie bez utraty ustawień, zatrzymam ponowną aktualizację, a po ukazaniu się poprawki przeprowadzę bezpieczny powrót do aktualnej wersji.
Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i krótko opisać, co się stało i od kiedy. Odpowiem, co da się zrobić od ręki i czego będę potrzebować, żeby strona jak najszybciej wróciła do normalnej pracy.
