Staging to kopia Twojego sklepu, na której sprawdzasz aktualizacje, zanim zobaczą je klienci. Zrób kopię, wyłącz na niej e-maile do klientów i prawdziwe płatności, zaktualizuj wtyczki i złóż zamówienie testowe. Gdy wszystko działa, powtórz te same aktualizacje na żywym sklepie z aktualną kopią zapasową. Bazę danych przenoś z kopii tylko wtedy, gdy wiesz, jak pominąć zamówienia, bo inaczej stracisz te, które wpadły w trakcie testu.
Poniżej opisujemy całą drogę na przykładzie wtyczki WP Staging PRO: od zrobienia kopii, przez listę testów, po trzy sposoby wprowadzenia zmian na żywy sklep, z ryzykiem dla zamówień przy każdym z nich.
Czym jest staging i kiedy go potrzebujesz
Staging (po polsku: kopia testowa albo środowisko testowe) to działająca kopia Twojej strony. Możesz na niej klikać, aktualizować i psuć, a klienci dalej kupują w prawdziwym sklepie i niczego nie widzą.
Sam WooCommerce zaleca, żeby przed aktualizacją mieć aktualną kopię zapasową i sprawdzić aktualizację na stagingu. W swojej instrukcji pisze wprost: nie testuj aktualizacji na sklepie na żywo. Kopia testowa przydaje się więc przy każdej większej aktualizacji WooCommerce, bramki płatności albo motywu, a także przy zmianach w wyglądzie lub ustawieniach, których nie chcesz robić „na oczach” klientów.
Kopia testowa to nie to samo co kopia zapasowa. Kopia zapasowa to zapis plików i bazy danych, z którego odtworzysz stronę po awarii, a kopia testowa to osobna, działająca strona do sprawdzania zmian. Jak odtworzyć sklep z kopii zapasowej, opisaliśmy w poradniku przywracanie kopii z UpdraftPlus. Staging to też nie przeprowadzka: jeśli chcesz przenieść sklep na inny serwer, zajrzyj do tekstu jak przenieść WordPress na nowy hosting.
Kopię testową dają też niektóre firmy hostingowe w swoim panelu. Możesz też postawić kopię na własnym komputerze, ale tam strona może działać inaczej niż na serwerze, na przykład przez inną wersję PHP (języka, w którym działa WordPress) albo mniej pamięci. Im bardziej kopia przypomina serwer sklepu, tym więcej mówi test.
Zanim zaczniesz: kopia zapasowa i miejsce na serwerze
Przed pierwszym krokiem sprawdź trzy rzeczy:
- Aktualna kopia zapasowa sklepu na żywo — pliki i baza danych (baza to miejsce, w którym WordPress trzyma produkty, zamówienia, klientów i treść stron). Zrobisz ją np. wtyczką UpdraftPlus Premium albo w samej WP Staging PRO: w menu „WP STAGING” wybierz „Backup & Migration”, a potem „Create New Backup”.
- Wolne miejsce na serwerze. Kopia testowa zajmuje miejsce tak jak druga strona. Gdy miejsca zabraknie, kopiowanie przerwie się błędem. Pomaga usunięcie starych kopii testowych i starych kopii zapasowych oraz pominięcie w kopii starych folderów ze zdjęciami, np. z lat 2015–2016. Nie rób dwóch kopii naraz.
- Co możesz pominąć. Baza danych składa się z tabel, czyli osobnych „szuflad” na różne dane. Duże tabele, np. ze statystykami odwiedzin i logami wtyczek bezpieczeństwa, możesz w kopii pominąć — producent wtyczki sam to radzi.
Staging WordPress krok po kroku z WP Staging PRO
Panel wtyczki jest po angielsku i nie ma polskiego tłumaczenia, dlatego przy każdym kroku podajemy angielski napis przycisku i to, co on robi.
- Wgraj i włącz wtyczkę. Pobierz WP Staging PRO ze swojego konta w sklepie, a potem w WordPressie w menu wtyczek dodaj nową wtyczkę, wyślij pobrany plik na serwer i włącz ją.
- Utwórz kopię. W menu „WP STAGING” kliknij „Create Staging Site” (utwórz kopię testową). W polu „Enter Site Name (Optional)” wpisz krótką nazwę, np. „test”.
- Pomiń zbędne dane (opcjonalnie). W sekcjach „DB Tables” (tabele bazy) i „Files” (pliki) odznacz duże tabele ze statystykami i stare foldery ze zdjęciami. Kopia powstanie szybciej i zajmie mniej miejsca.
- Wyłącz e-maile z kopii. W ustawieniach zaawansowanych kreatora możesz wyłączyć wysyłkę wiadomości e-mail z kopii. W sklepie rób to zawsze — o powodach piszemy w następnej sekcji. Później zmienisz to w ustawieniach wtyczki na kopii.
- Uruchom kopiowanie. Kliknij „Start Cloning”. Czas zależy od wielkości sklepu. Gdy się skończy, kliknij „Open Staging Site”. Później wrócisz do kopii przyciskiem „Go to staging site”.
- Zaloguj się na kopii. Kopia powstaje domyślnie w podfolderze Twojej domeny, np. twojsklep.pl/test. Logujesz się tym samym loginem i hasłem co w sklepie.
- Nie przejmuj się innymi adresami podstron. Na kopii tzw. bezpośrednie odnośniki (ładne adresy podstron) są domyślnie wyłączone, więc adresy wyglądają inaczej niż w sklepie. To ustawienie kopii, nie błąd aktualizacji.
Wtyczka wyłącza kopię z indeksowania w Google i chroni ją logowaniem. Domyślnie wchodzą na nią tylko administratorzy, a w WP Staging PRO możesz wpuścić wybrane role, np. klienta, dla którego robisz stronę, albo programistę.
WP Staging PRO pozwala też postawić kopię na subdomenie (np. test.twojsklep.pl) albo w osobnej bazie danych, jeśli nie chcesz trzymać kopii obok sklepu.
Jeśli kopię zrobiłeś inaczej, np. w panelu hostingu, sprawdź w ustawieniach czytania WordPressa opcję, która prosi wyszukiwarki o nieindeksowanie witryny. Pamiętaj, że to tylko prośba do wyszukiwarek, a nie blokada: każdy, kto zna adres, wejdzie na kopię. Pewniej jest zabezpieczyć kopię hasłem.
Kopia testowa sklepu WooCommerce: co wyłączyć przed testem
Tego brakuje w większości poradników o stagingu, a w sklepie to najważniejsza część. Kopia ma prawdziwe dane: zamówienia, klientów, ich adresy e-mail oraz ustawienia płatności i wysyłki, bo wtyczka kopiuje całą bazę sklepu. Dlatego zanim zaczniesz klikać, wyłącz na kopii wszystko, co może dotrzeć do klientów albo do innych firm:
- E-maile. Bez tego klient może dostać wiadomość o zamówieniu testowym albo o zmianie statusu swojego prawdziwego zamówienia, którą właśnie sprawdzasz na kopii.
- Płatności. Przełącz bramki płatności w tryb testowy, jeśli bramka go ma, albo je wyłącz. Zamówienie testowe składaj bez prawdziwych pieniędzy.
- Integracje z innymi firmami. Wtyczki do faktur, Allegro, porównywarek cen czy kurierów mają na kopii te same dane dostępowe co sklep. Test może więc naprawdę wystawić dokument albo zmienić ofertę. Na czas testu wyłącz je albo przełącz w tryb testowy.
- Zadania w tle. To czynności, które WooCommerce wykonuje sam o ustalonej porze, np. pobiera płatność za subskrypcję albo wysyła przypomnienie. Na kopii też działają, więc przy subskrypcjach kopia może ponownie obciążyć klientów. Jeśli masz subskrypcje albo automatyczne e-maile, wyłącz zadania w tle na kopii. Jeśli nie wiesz jak, pomożemy w ramach płatnej usługi (link w ramce na końcu).
Test aktualizacji WooCommerce na kopii
Na kopii zaktualizuj w jednym podejściu wszystko, co chcesz potem zaktualizować na żywo: WooCommerce, jego dodatki, bramki płatności i motyw. Nie rób na żywo kilku dużych aktualizacji naraz, jeśli tego samego zestawu nie sprawdziłeś wcześniej na kopii.
Jeśli po aktualizacji WooCommerce zobaczysz prośbę o aktualizację bazy danych, uruchom ją. Na kopii możesz to zrobić od razu, na żywym sklepie tylko z aktualną kopią zapasową.
Potem przejdź po kolei tę listę:
- strona główna i kilka kart produktów wyglądają tak jak przed aktualizacją,
- produkt dodaje się do koszyka, a koszyk liczy cenę,
- zamówienie testowe przechodzi do końca,
- koszty wysyłki i podatki są takie jak w sklepie,
- płatność testowa przechodzi,
- e-maile o zamówieniu wychodzą (wysyłkę z kopii włącz tylko na czas zamówienia testowego złożonego na Twój własny adres i od razu wyłącz),
- w panelu nie ma nowych komunikatów o błędach ani nieudanych zadań w tle.
Wtyczki kupione u nas aktualizujesz ręcznie: pobierasz nową wersję ze swojego konta w sklepie i wgrywasz plik .zip, a ustawienia zostają. Kopia testowa to dobre miejsce, żeby zrobić to najpierw.
Coś się psuje na kopii? To dobra wiadomość: szukasz przyczyny spokojnie, a sklep sprzedaje dalej — jak to zrobić, opisaliśmy w tekście jak znaleźć źródło konfliktu wtyczek bez wyłączania sprzedaży. Jeśli aktualizacja zepsuła już sklep na żywo, zacznij od poradnika sklep WooCommerce nie działa po aktualizacji.
Jak przenieść zmiany z kopii na żywy sklep
Test przeszedł. Teraz ważna decyzja: od chwili zrobienia kopii w sklepie mogły wpaść nowe zamówienia, a na kopii ich nie ma. Masz trzy drogi:
| Droga | Kiedy | Co z zamówieniami z czasu testu | Wymaga WP Staging PRO na żywo |
|---|---|---|---|
| 1. Powtórz aktualizacje na żywo | aktualizacje wtyczek, WooCommerce, motywu | zostają nietknięte | nie |
| 2. Przenieś same pliki | zmienione pliki wtyczek lub motywu, bez zmian w bazie | zostają, bo baza się nie zmienia | tak |
| 3. Przenieś pliki i bazę | zmiany ustawień lub treści, których nie chcesz powtarzać ręcznie | przepadną, jeśli nadpiszesz tabele zamówień | tak |
Droga 1: powtórz to samo na żywym sklepie
Przy samych aktualizacjach to najbezpieczniejsza droga, bo nie nadpisujesz bazy sklepu, więc zamówienia złożone w czasie testu zostają.
- Zrób świeżą kopię zapasową sklepu.
- Włącz tryb „Coming soon” (strona wkrótce dostępna) w ustawieniach WooCommerce, w zakładce widoczności witryny.
- Zrób te same aktualizacje w tej samej kolejności co na kopii.
- Jeśli WooCommerce poprosi o aktualizację bazy danych, uruchom ją.
- Przejdź tę samą listę testów co na kopii.
- Wyłącz „Coming soon”.
Droga 2: przenieś same pliki
W WP Staging PRO na liście kopii wybierz „Push Changes” (przenieś zmiany). W kroku „Database Tables” nie zaznaczaj żadnej tabeli, a w „Select Files” wybierz tylko foldery wtyczek lub motywu, które zmieniłeś. Baza sklepu, a z nią zamówienia i klienci, zostaje bez zmian. Przeniesienie zmian wymaga WP Staging PRO także na stronie na żywo.
Droga 3: przenieś pliki i bazę — z ostrożnością
Każda tabela, którą zaznaczysz w „Database Tables”, całkowicie nadpisuje tę samą tabelę w sklepie na żywo. Nic się nie scala. Jeśli nadpiszesz tabele zamówień, zamówienia złożone od chwili zrobienia kopii przepadną. Producent wtyczki sam pisze, że automatycznego połączenia zamówień i produktów z dwóch stron nie da się zrobić niezawodnie, i radzi nie nadpisywać zamówień ani danych klientów.
Jeśli Twój sklep ma włączony nowy sposób zapisu zamówień (HPOS — ustawienie WooCommerce, w którym zamówienia mają własne tabele w bazie), i to na obu stronach, producent radzi odznaczyć przy przenoszeniu tabele zamówień, a przy subskrypcjach także tabele zadań w tle. Najpierw przećwicz to na osobnej kopii. Jeśli nie wiesz, czy masz HPOS, wybierz drogę 1 albo 2.
Przed każdym przeniesieniem z kopii:
- zrób kopię zapasową sklepu na żywo i pobierz jej plik na komputer,
- zostaw wyłączone opcje, które usuwają wszystkie wtyczki na stronie na żywo albo cały folder ze zdjęciami — chyba że dokładnie wiesz, po co je włączasz,
- przygotuj się na ponowne logowanie po przeniesieniu.
Producent opisuje też inny sposób: przed przeniesieniem wyeksportować zamówienia z żywego sklepu, wczytać je na kopię i przenieść bazę przy sklepie zamkniętym na czas prac.
Po teście: odśwież albo usuń kopię
Kopia szybko się starzeje: w sklepie przybywa zamówień i produktów. Przed kolejnym testem odśwież ją. „Update” kopiuje dane ze sklepu na kopię i je nadpisuje, więc zmiany zrobione wcześniej na kopii mogą przepaść. „Reset” usuwa kopię i robi ją od nowa.
Kopii, której już nie używasz, nie zostawiaj — zajmuje miejsce na serwerze i przy następnym kopiowaniu może go zabraknąć.
Sprawdzaj aktualizacje na kopii, zanim zobaczą je klienci. WP Staging PRO kosztuje u nas 149 zł: kopię sklepu robisz z panelu WordPressa, a gotowe zmiany przenosisz na żywą stronę tak, jak opisaliśmy wyżej.
Jeśli prowadzisz kilka stron albo robisz je klientom, zobacz pakiet wszystkich wtyczek i motywów — 999 zł za rok dostępu, WP Staging PRO jest w nim.
Nie chcesz robić tego sam? Pomożemy w ramach usługi instalacji i konfiguracji wtyczek — 250 zł netto (307,50 zł brutto) za godzinę pracy.
Pojedynczą wtyczkę pobierasz i aktualizujesz przez 365 dni; aktualizacje są ręczne, bez wsparcia autora wtyczki. Szczegóły: wtyczki GPL.
