Przejdź do treści
codecollab.pl
§ Blog aktualizacja woocommerce

Bezpieczne aktualizacje WooCommerce - checklista

Jeden klik „aktualizuj wszystko" potrafi w minutę położyć sklep, który działał latami - i prawie zawsze dzieje się to w najgorszym momencie

Autor Krystian Kacik Data Czas czytania 9 min

Aktualizacja WooCommerce sama w sobie jest dobra - łata dziury bezpieczeństwa, naprawia błędy, dokłada funkcje. Problem nie jest w aktualizowaniu, tylko w tym, JAK większość ludzi to robi: wchodzą do panelu, widzą czerwoną „6” przy zakładce wtyczek, klikają „zaznacz wszystko”, potem „aktualizuj” i idą na kawę. W 9 na 10 przypadków przejdzie gładko. Ten dziesiąty to telefon „sklep nie działa, klienci nie mogą zapłacić”, zwykle w piątek po południu.

Widzę to u klientów regularnie. Nie dlatego, że są nieostrożni - po prostu nikt im nie powiedział, że aktualizacja sklepu to nie to samo, co aktualizacja telefonu. WooCommerce to nie jeden program, tylko silnik (WordPress), wtyczka sklepu (WooCommerce), motyw i kilkanaście dodatków, które muszą ze sobą rozmawiać. Wystarczy, że jeden dodatek nie nadąży za nową wersją i checkout przestaje przyjmować płatności, choć cała reszta sklepu wygląda normalnie.

Poniżej rozkładam to na checklistę, którą sam stosuję przy każdej aktualizacji u klienta. Nie jest skomplikowana - chodzi o kolejność i o to, żeby mieć drogę odwrotu, zanim cokolwiek ruszysz.

Dlaczego „aktualizuj wszystko” potrafi położyć sklep

Sklep to układ zależności. WooCommerce wypuszcza nową wersję, ale Twoja bramka płatności, wtyczka do faktur, motyw i dodatek do wysyłek były pisane pod wersję poprzednią. Najczęściej autorzy nadążają i wszystko gra. Czasem jeden z nich się spóźnia albo porzucił projekt - i wtedy nowa wersja WooCommerce „rozjeżdża się” z tym dodatkiem.

Najgorsze jest to, że awaria bywa niewidoczna z poziomu strony głównej. Sklep się ładuje, produkty są, koszyk działa - a płatność wywala błąd dopiero na ostatnim kroku, którego sam właściciel nigdy nie testuje, bo przecież nie kupuje u siebie codziennie. Klient próbuje zapłacić, dostaje białą stronę albo komunikat błędu i wychodzi. Ty się o tym dowiadujesz po dniu albo dwóch, ze spadku zamówień.

Druga pułapka to motyw. Sporo sklepów stoi na motywie z dokupionymi modyfikacjami albo na „child theme” zrobionym kiedyś przez kogoś. Aktualizacja motywu rodzica potrafi nadpisać te zmiany i nagle układ produktu wygląda inaczej, znika przycisk albo psuje się strona kasy. To nie znaczy, że nie wolno aktualizować - znaczy, że trzeba wiedzieć, co się zmieni, zanim klikniesz.

Krok 1: Backup, zanim cokolwiek ruszysz

To jest punkt zero i nie ma od niego wyjątku. Zanim klikniesz jakąkolwiek aktualizację, musisz mieć pełną, świeżą kopię - i pliki, i bazę danych. Pliki to motyw, wtyczki i wgrane zdjęcia. Baza to całe serce sklepu: produkty, zamówienia, klienci, ustawienia. Jedno bez drugiego nie wystarczy, żeby cofnąć sklep do stanu sprzed awarii.

Ważne, żeby backup był wykonany TUŻ przed aktualizacją, a nie „był jakiś z zeszłego tygodnia”. Jeśli przez ten tydzień spłynęły zamówienia, przywrócenie starej kopii oznacza, że je tracisz. Świeża kopia to gwarancja, że w najgorszym razie wracasz do stanu sprzed pięciu minut, a nie sprzed pięciu dni.

Co pomaga: zanim klikniesz aktualizację, zrób pełny backup plików i bazy i sprawdź, gdzie fizycznie leży - tak, żeby dało się go realnie przywrócić, nie tylko „pobrać kiedyś”. Backup, którego nie umiesz odtworzyć, to nie backup.

Krok 2: Najpierw staging, nigdy od razu na żywym sklepie

Staging to kopia sklepu postawiona pod adresem testowym, niewidoczna dla klientów i Google. Na niej robisz aktualizację najpierw - i dopiero jak wszystko przejdzie i checkout działa, powtarzasz to samo na sklepie produkcyjnym. To różnica między „testuję na kopii, którą mogę zepsuć bezkarnie” a „testuję na żywym sklepie, na którym akurat ktoś próbuje kupić”.

Większość porządnych hostingów pod WordPress ma postawienie stagingu na jeden klik. Jeśli Twój go nie ma, to też sygnał - to jeden z powodów, dla których w ogóle warto siedzieć na hostingu dedykowanym pod WooCommerce. Na stagingu możesz spokojnie sprawdzić nową wersję, popsuć, cofnąć, popsuć znowu - klient niczego nie zobaczy.

Jeśli sklep jest mały i prosty, a aktualizacja drobna, można odpuścić staging - ale wtedy backup z kroku 1 robi się absolutnie krytyczny, bo to Twoja jedyna droga odwrotu. Przy sklepie, który realnie zarabia, staging jest tańszy niż jeden dzień stojącego checkoutu.

Krok 3: Aktualizuj pojedynczo i według ważności

Tu jest sedno różnicy między „bezpiecznie” a „na pałę”. Nie aktualizuj wszystkiego naraz. Rób to pojedynczo, w sensownej kolejności, i po każdym kroku sprawdzaj, czy sklep nadal działa. Jeśli coś się posypie, od razu wiesz, który dodatek to zrobił - zamiast zgadywać między dwunastoma naraz.

Kolejność, którą stosuję:

  1. Najpierw rdzeń - WordPress, potem sama wtyczka WooCommerce. To fundament, pod który dostosowują się wszystkie dodatki.
  2. Potem wtyczki krytyczne dla sprzedaży - bramka płatności, dostawy, faktury. To one decydują, czy klient zapłaci, więc je testujesz najuważniej.
  3. Potem reszta wtyczek - pojedynczo, sprawdzając po każdej.
  4. Na końcu motyw - bo to on najczęściej nadpisuje wcześniejsze przeróbki i potrafi zmienić wygląd kasy.

Po każdym kroku rzut oka na sklep: strona główna, produkt, koszyk. Brzmi jak więcej roboty niż „zaznacz wszystko”, ale zajmuje kilkanaście minut, a oszczędza dzień gaszenia pożaru.

Co pomaga: aktualizuj jeden element naraz i po każdym sprawdzaj checkout. Gdy coś pęknie, masz jednego podejrzanego, nie dwunastu - naprawa zajmuje minuty, nie godziny.

Krok 4: Sprawdź kompatybilność motywu i wtyczek, zanim klikniesz

Zanim w ogóle ruszysz aktualizację, warto wiedzieć, czy nowa wersja jest zgodna z resztą sklepu. WooCommerce w panelu zwykle ostrzega, jeśli wykryje, że jakaś wtyczka nie deklaruje zgodności z nową wersją - tego ostrzeżenia nie ignoruj. Przy każdej ważnej wtyczce można w jej opisie sprawdzić, do jakiej wersji WordPress i WooCommerce jest testowana.

Szczególną uwagę zwróć na dodatki, które dawno nie miały aktualizacji. Wtyczka, której autor nie ruszał od dwóch lat, to dzwonek alarmowy - nie nadąży za nowym WooCommerce i prędzej czy później coś rozjedzie. Lepiej taką wymienić na utrzymywany odpowiednik z wyprzedzeniem, w spokoju, niż w panice po awarii.

Przy płatnościach traktuj to wyjątkowo poważnie. Bramka płatności to dodatek, na którym dosłownie stoją Twoje przychody - jej zgodność z nową wersją sprawdzaj zawsze, a samą aktualizację bramki rób osobno i z pełnym testem zakupu po fakcie.

Krok 5: Po aktualizacji przejdź pełną ścieżkę zakupu

Najczęstszy błąd po aktualizacji: właściciel patrzy na stronę główną, widzi że „działa” i zamyka temat. A awaria prawie zawsze siedzi tam, gdzie nie patrzy - na ostatnim kroku płatności. Dlatego po każdej aktualizacji (najpierw na stagingu, potem na żywym sklepie) zrób realny zakup testowy od początku do końca.

Konkretnie przejdź:

  • dodanie produktu do koszyka i otwarcie koszyka
  • przejście do kasy i wpisanie danych
  • wybór dostawy i sprawdzenie, czy koszty się liczą
  • realne kliknięcie płatności i powrót na stronę potwierdzenia
  • sprawdzenie, czy zamówienie pojawiło się w panelu i czy poszedł mail z potwierdzeniem

Większość bramek ma tryb testowy, w którym przejdziesz całą płatność bez prawdziwej transakcji. Jeśli go nie masz, na żywym sklepie zrób jeden zakup za parę złotych i zwróć sobie. To najtańszy test, jaki istnieje - bo alternatywą jest dowiedzieć się o zepsutym checkoutcie od klienta, który już nie wrócił. Jeśli sklep dodatkowo bywa wolny po zmianach, warto przy okazji rzucić okiem na to, dlaczego sklep WooCommerce potrafi spowolnić - aktualizacje czasem dokładają tu swoje.

Krok 6: Miej plan wycofania, zanim zaczniesz

Plan wycofania to po prostu odpowiedź na pytanie „co robię, jeśli się posypie” - przygotowana ZANIM zaczniesz, nie wymyślana w panice. Jeśli przeszedłeś przez staging, plan jest prosty: nie wypuszczasz zmian na żywy sklep, dopóki na kopii wszystko nie działa. Sklep produkcyjny stoi nietknięty.

Jeśli aktualizowałeś bezpośrednio na produkcji i coś pękło, plan opiera się na backupie z kroku 1: przywracasz pliki i bazę do stanu sprzed aktualizacji i sklep wraca do działania. Dlatego ten pierwszy backup jest tak ważny - bez niego „wycofanie” oznacza grzebanie po omacku pod presją, z klientami pukającymi do zamkniętej kasy.

Czasem winowajca jest jeden - wtedy nie trzeba cofać całości, wystarczy wyłączyć albo cofnąć jeden dodatek, który rozjechał checkout. Ale żeby to wiedzieć, musisz było aktualizować pojedynczo (krok 3). Wszystko się tu spina: backup daje drogę odwrotu, staging chroni żywy sklep, a aktualizowanie po kolei mówi Ci dokładnie, co cofnąć.

Po co stała opieka, skoro to da się zrobić samemu

Całą tę checklistę można przejść samemu - i przy jednym sklepie raz na kwartał to nawet sensowne. Problem w tym, że aktualizacje nie przychodzą raz na kwartał. WordPress, WooCommerce i kilkanaście wtyczek dostają poprawki co tydzień, część z nich łata realne dziury bezpieczeństwa, których nie wolno odkładać. I tu większość właścicieli wpada w jedną z dwóch pułapek: albo klikają „aktualizuj wszystko” w biegu (i ryzykują awarię), albo nie aktualizują miesiącami (i ryzykują włamanie).

Stała opieka rozwiązuje dokładnie to. Aktualizacje robi ktoś, kto ma backup, staging i ten plan wycofania ustawione z góry - po cichu, regularnie, z testem checkoutu po każdej zmianie. Ty nie dostajesz telefonu „sklep nie działa” i nie musisz pamiętać, że pojawiła się krytyczna łatka. To jest różnica między „sklep się nie zepsuł, bo miałem szczęście” a „sklep się nie zepsuł, bo ktoś tego pilnuje”.

Co pomaga: ustal jeden stały rytm aktualizacji z backupem i testem checkoutu - czy to samodzielnie w kalendarzu, czy w ramach stałej opieki. Regularność bije zrywy: lepiej co dwa tygodnie po kawałku niż raz na pół roku „wszystko naraz” i modlitwa.

Najczęstsze pytania

Czy aktualizacja WordPressa jest bezpieczna? Sama w sobie tak - to wersje nieaktualne są niebezpieczne, bo łatwo je zaatakować przez znane dziury. Ryzykowny bywa sposób: „aktualizuj wszystko” bez kopii zapasowej i bez sprawdzenia sklepu po. Z backupem i testem checkoutu (kroki wyżej) aktualizacja to rutyna, nie hazard. A jeśli mimo wszystko coś pęknie - najczęściej kończy się to błędem krytycznym, który da się cofnąć w godzinę.

Ile kosztuje aktualizacja WordPressa u specjalisty? Jednorazowe uporządkowanie zaniedbanego sklepu (przegląd, backup, aktualizacje po kolei, test) to zwykle kilka godzin pracy. W ramach stałej opieki aktualizacje wchodzą w miesięczny abonament - cennik jest na stronie opieki, a dokładną wycenę podaję po obejrzeniu sklepu, na piśmie.

Co jeśli strona już leży po aktualizacji? Nie instaluj niczego od nowa. Przejdź plan naprawy z tekstu o błędzie krytycznym - w większości przypadków to jedna wtyczka do wyłączenia.

Od czego zacząć u siebie

Jeśli nie wiesz, czy Twój sklep jest aktualny i bezpieczny - albo boisz się kliknąć aktualizację, bo „ostatnio coś się posypało” - nie zgaduj, podeślij mi link. Zrobię bezpłatny przegląd, sprawdzę, co jest przeterminowane, gdzie czają się ryzykowne dodatki i czy checkout działa jak należy. Powiem wprost, co zaktualizować najpierw i czego dotykać ostrożnie. Wycenę dostajesz na piśmie w 24 h, bez „od X zł”.

Wyślij zakres - wycena 24h

Powiązane: Stała opieka nad sklepem · Dlaczego sklep WooCommerce wolno działa

§ Wycena 24h

Twój sklep zwalnia albo wygląda staro, a nie wiesz, od czego zacząć?

Opisz zakres w dwóch zdaniach albo podeślij link. Wskażę, co poprawić najszybciej, a wycenę dostajesz na piśmie w 24 godziny - bez „od X zł".

Wyślij zakres - wycena 24h