Wersja testowa WordPressa. Jak stworzyć stage?

Wersja testowa WordPressa (tzw. stage), to osobna kopia całej Twojej strony, na której możesz testować zmiany i aktualizacje w odizolowanym środowisku. Nawet jak coś zepsujesz, to uszkodzenia pozostaną na wersji testowej i nie trafią do głównej strony.

Każda aktualizacja motywu, wtyczki, a nawet samego WordPressa może spowodować różnego rodzaju problemy na stronie, które uniemożliwią jej wyświetlanie. Jeśli Twoja strona jest popularna, to z pewnością nie możesz pozwolić sobie nawet na najmniejsze przerwy w jej działaniu. WordPress nie jest jednak takim systemem, o którym można swobodnie zapomnieć. Trzeba dokonywać aktualizacji zarówno samego WordPressa, jak i zainstalowanych komponentów (motywów, wtyczek).

Ryzyko uszkodzenia występuje zatem zawsze, dlatego polecamy tworzyć kopie zapasowe WordPressa. Czy to jedyny sposób na to, aby odpowiednio się przygotować do większej aktualizacji lub wprowadzania zmian na stronie? Nie. Możesz jeszcze stworzyć tzw. stage. To oddzielna, wersja testowa WordPressa, przeznaczona do testów, widoczna tylko dla Ciebie. Dzięki temu wszystkie zmiany, które wprowadzasz na stronę, są wdrażane w oddzielnym środowisku testowym. Coś poszło nie tak? Nic nie szkodzi, Twoja publiczna wersja strony pozostaje nienaruszona. Wszystko poszło dobrze na wersji testowej? Świetnie, możesz teraz to samo wdrożyć na wersji publicznej.

Czym jest tzw. stage, czyli wersja testowa WordPressa?

Wersja testowa strony (tzw. stage), zwana również wersją roboczą czy deweloperską, to nic innego jak działająca kopia Twojej strony, odseparowana od głównej witryny, uruchomiona pod innym adresem. Co najważniejsze, jest niedostępna dla nikogo poza Tobą. Nie jest także indeksowana przez Google.

Służy ona do eksperymentowania, a także testowania zmian i aktualizacji przed wprowadzeniem ich do wersji produkcyjnej strony, czyli tej głównej, dostępnej dla wszystkich.

Wersja testowa (stage) wyróżnia się następującymi cechami:

• nie jest dostępna publicznie (jest widoczna tylko dla Ciebie oraz ewentualnych współpracowników),
• nie jest indeksowana w wyszukiwarkach internetowych,
• zmiany wprowadzone na wersji testowej nie mają wpływu na główną, publiczną wersję strony.

Jak widzisz, zaletą posiadania wersji testowej WordPressa jest możliwość bezstresowego testowania aktualizacji, zmian i nowości. Nawet jeśli zrobisz coś nie tak i strona ulegnie uszkodzeniu, to nie wpłynie to w żaden sposób na wersję produkcyjną, czyli główną stronę pod Twoją domeną.

Wersja testowa WordPressa – w jaki sposób ją utworzyć?

Z pewnością domyślasz się już, że istnieje kilka sposobów na wykonanie stage’a. Masz rację – ilość metod na wykonanie stage’a jest ogromna i różnią się one poziomem zaawansowania, funkcjonalności, możliwości szybkiej migracji zmian pomiędzy różnymi środowiskami, a także kosztem. Wybór odpowiedniej metody zależy od skali projektu i potrzeb.

W tym artykule, jak w większości przypadków, skupimy się na osobach początkujących, które chcą stworzyć oddzielną, odseparowaną wersję strony w celu testowania np. nowych motywów czy wtyczek przed zainstalowaniem ich na wersji produkcyjnej. Nasz stage będzie zatem odseparowaną kopią do testowania zmian, które planujemy wprowadzić docelowo na wersji produkcyjnej.

Darmowa wersja wtyczki WP Staging – czy to dobry wybór?

Większość początkujących użytkowników, szukających rozwiązań stagingowych pod WordPressa, z pewnością już natknęła się w repozytorium WordPressa na wtyczkę WP Staging, która pozwala jednym kliknięciem stworzyć wersję testową strony. Brzmi dobrze, prawda? Pamiętaj jednak, że darmowa wersja WP Staging ma poważne ograniczenia, które stawiają cały sens użycia bezpłatnej wersji pod znakiem zapytania.

W darmowej wersji nie możemy użyć osobnej bazy MySQL dla wersji testowej, przez co współdzieli ona tę samą bazę, co wersja produkcyjna (tabele wersji testowej tworzą się z innym prefiksem w tej samej bazie). To niezbyt dobre rozwiązanie – po co nam wersja testowa, skoro nadal jest ona powiązana z wersją produkcyjną? W przypadku uszkodzenia bazy przez wersję testową dojdzie również do uszkodzenia wersji produkcyjnej.

Co więcej, w darmowej wersji sama instalacja (pliki strony) również nie jest w pełni odseparowana od wersji produkcyjnej. Sklonowana, testowa wersja WordPressa rezyduje bowiem w podkatalogu głównej, produkcyjnej wersji.

Dopiero płatna wersja pozwala ominąć to ograniczenia i wykorzystać oddzielną bazę danych, a także klonować witrynę do niestandardowych lokalizacji lub innych domen/subdomen. Innymi słowy, jeśli chcesz korzystać z wtyczki WP Staging, to tylko w płatnej wersji.

Czy mogę utworzyć stage WordPressa za darmo?

Najprostszym sposobem w takim wypadku jest ręczne stworzenie wersji testowej poprzez skopiowanie witryny do innej lokalizacji, do której tylko my mamy dostęp. Z reguły najlepiej stworzyć stage’a na całkowicie odseparowanym serwerze (np. na serwerze lokalnym, stworzonym za pomocą chociażby Laragon lub XAMPP), jednak jeśli nie masz takiej możliwości, to warto wiedzieć, że można to też zrobić na istniejącym serwerze w ramach swojego hostingu, wykorzystując subdomenę, dostępne wolne miejsce na serwerze i możliwość stworzenia oddzielnej bazy danych. Taki scenariusz też pokażemy w tym artykule.

Wystarczy utworzyć kopię strony i uruchomić ją jako drugiego WordPressa pod subdomeną na naszym serwerze, a następnie zablokować dostęp hasłem dostępowym lub ustawić autoryzację poprzez adres IP.

W tym celu należy:

• utworzyć na serwerze kopię swojej strony na WordPressie w osobnym katalogu
• stworzyć subdomenę (np. test.adres-witryny.pl), która posłuży jako adres wersji testowej i skierować ją na katalog z utworzoną kopią plików WordPressa
• stworzyć nową, oddzielną bazę danych i zaimportować do niej bazę ze swojego produkcyjengo WordPressa
• dostosować ustawienia adresów URL i bazy danych w wersji testowej WordPressa
• wyłączyć indeksowanie strony, aby wersja testowa nie była indeksowana przez Google

Oczywiście, proces samego kopiowania WordPressa można nieco skrócić i ułatwić, wykorzystując wtyczkę Duplicator (pozwala ona dość szybko stworzyć kopię WordPressa i odtworzyć ją pod innym adresem – czy to na innym hostingu, czy to na localhost). Może się jednak zdarzyć, że przy dużej stronie Duplicator pominie niektóre pliki. Warto także pamiętać, że niedawno wtyczka ta miała sporą lukę w zabezpieczeniach, dlatego my polecamy tradycyjne rozwiązania bez wtyczek, które mogą się wydawać nieco dłuższe i męczące, ale za to w pełni bezpieczne.

Pokażę Ci zatem, jak ręcznie uruchomić wersję testową swojego WordPressa na swoim serwerze lokalnym.

Krok 1: Utwórz kopię plików swojego WordPressa w osobnym katalogu

Zacznijmy od plików WordPressa na serwerze. Musisz zrobić kopię swojego WordPressa w osobnym katalogu, który posłuży jako miejsce na stage’a.

Sposób 1: Stworzenie kopii WordPressa w osobnym katalogu za pomocą SSH

Jeśli masz dostęp SSH do swojego serwera, możesz utworzyć kopię całej instalacji (plików) za pomocą jednej komendy.

Przykładowo, jeśli WordPress jest zainstalowany w katalogu public_html/wordpress, a kopię chcesz utworzyć w katalogu public_html/wpstage, to komenda będzie wyglądać następująco:

 cp -r public_html/wordpress public_html/wpstage/

Najpierw podajemy ścieżkę do istniejącej instalacji (produkcyjnej), a następnie do nowej (stage). Podmień ścieżki na odpowiednie dla siebie.

Wykonanie tej komendy utworzy kopię całego folderu WordPressa w głównym katalogu dostępowym z całą zawartością folderu WordPressa.

Sposób 2: Tradycyjne kopiowanie z serwera FTP

Jeśli nie masz dostępu SSH, to musisz ręcznie zrobić kopię plików swojego WordPressa w osobnym katalogu na serwerze. W tym celu zaloguj się za pomocą dowolnego klienta FTP (np. FileZilla) na swój serwer.

Znajdź i otwórz katalog na serwerze FTP, w którym przechowujesz swoją stronę na WordPressie. Zaznacz wszystkie pliki i foldery WordPressa, a następnie skopiuj je na dysk twardy. W tym celu kliknij zaznaczone elementy prawym przyciskiem myszy i wybierz Pobierz.

Klient FTP rozpocznie pobieranie plików Twojego WordPressa na dysk. Gdy to nastąpi, kolejnym krokiem jest stworzenie nowego, oddzielnego folderu na serwerze, przeznaczonego na wersję testową strony, i przekopiowanie do niego plików WordPressa.

Przejdź do głównego folderu swojego serwera (public_html) i stwórz w nim nowy katalog pod stage WordPressa. Na potrzeby poradnika nazwiemy go wpstage.

Następnie wyślij do katalogu wpstage wszystkie foldery i pliki swojego WordPressa, które przed chwilą pobrałeś na dysk komputera. Ten proces może potrwać dłuższą chwilę.

W ten sposób utworzyłeś na swoim serwerze kopię całej strony w osobnym katalogu.

Krok 2: Stwórz subdomenę, czyli osobny adres pod wersję testową WordPressa

Kolejnym krokiem jest przygotowanie adresu, pod którym wersja testowa WordPressa będzie dostępna. Nie musisz kupować nowej domeny. Najprościej skorzystać z subdomeny, czyli dodatkowego adresu internetowego, który możesz stworzyć w ramach swojej aktualnej domeny. Dzięki temu wersja testowa będzie dostępna np. pod adresem test.adres-witryny.pl, podczas gdy wersja produkcyjna dalej będzie działać z adresu adres-witryny.pl.

Proces tworzenia subdomeny może różnić się w zależności od tego, gdzie masz wykupiony hosting. Jeśli masz hosting w LH.pl, to subdomenę możesz stworzyć w swoim panelu klienta, przechodząc do zakładki Serwery > Strony WWW. Zobacz, jak stworzyć subdomenę w LH.pl.

W trakcie dodawania subdomeny należy wskazać, na jaki katalog na serwerze ma ona kierować. Wpisz tu nazwę katalogu, w którym znajduje się utworzona w pierwszym kroku kopia plików WordPressa. W naszym wypadku będzie to folder wpstage.

W ten sposób utworzyłeś subdomenę i przekierowałeś ją na katalog, w którym przechowywana jest kopia Twojej strony.

Krok 3: Wyeksportuj bazę danych WordPressa

Pliki to nie wszystko – WordPress opiera się także na bazie danych. Ją również musimy wyeksportować, a następnie skopiować do nowej, czystej bazy, przeznaczonej pod wersję testową WordPressa. Operacje na bazie danych wykonamy za pomocą narzędzia phpMyAdmin, dostępnego w ramach każdego hostingu.

Link do phpMyAdmin znajdziesz w swoim panelu klienta – w LH.pl jest to sekcja Twoje serwery > Bazy MySQL.

Zaloguj się do swojej bazy danych za pomocą phpMyAdmin, wpisując login i hasło do bazy. Jeśli masz problemy z zalogowaniem do bazy, zapoznaj się z poradnikiem, jak zalogować się do bazy danych w LH.pl.

W kolumnie po lewej znajdziesz listę baz danych. Wybierz bazę danych swojego WordPressa. Następnie przejdź do zakładki Eksport.

Ustaw eksport w następujący sposób:

Metoda eksportu: dostosuj

Tabele: upewnij się, że zaznaczone są wszystkie na liście

Wyjście: zaznacz pole “Zapisz wynik do pliku” i jako kompresję ustaw “.gzip”

Na samym dole kliknij przycisk Wykonaj i poczekaj, aż plik z kopią bazy zostanie wygenerowany i rozpocznie się jego pobieranie. Zapisz go w dogodnym miejscu na dysku twardym.

Po wyeksportowaniu bazy danych wyloguj się z phpMyAdmin. W tym celu kliknij ikonę drzwi w górnym lewym rogu.

W ten sposób utworzyłeś i pobrałeś kopię wszystkich danych z bazy danych MySQL Twojego WordPressa. Następnym krokiem będzie utworzenie nowej bazy pod wersję testową i zaimportowanie do niej wyeksportowanej kopii.

Krok 4: Utwórz nową bazę danych i zaimportuj do niej kopię bazy WordPressa

Gdy mamy już kopię bazy danych wersji produkcyjnej WordPressa, to teraz musimy utworzyć nową bazę danych pod wersję testową i zaimportować do niej dane naszej strony.

W swoim panelu klienta przejdź do zarządzania bazami danych (w LH.pl to zakładka Serwery > Bazy MySQL) i utwórz nową bazę danych pod testowego WordPressa.

Możesz nadać jej dowolną nazwę – na potrzeby poradnika będzie to wpstagesql. Jeśli nie wiesz, jak to zrobić, zapoznaj się z poradnikiem, w którym pokazujemy, jak stworzyć nową bazę danych.

WAŻNE! Zapamiętaj lub zapisz sobie gdzieś nazwę nowej bazy danych, a także login i hasło do niej – będą one później potrzebne.

Przejdź ponownie do phpMyAdmin w swoim hostingu, ale tym razem zaloguj się do swojej nowej bazy danych. W kolumnie po lewej stronie wybierz swoją nową, pustą bazę danych, którą przed chwilą utworzyłeś. W naszym wypadku jest to baza, która w nazwie posiada wartość wpstagesql. Powinna być pusta – upewnij się, że nie ma w niej żadnej tabel.

Po jej wybraniu przejdź do zakładki Import. Kliknij przycisk Wybierz plik, a następnie wskaż plik z wyeksportowaną wcześniej bazą danych.

Po wskazaniu pliku kliknij Wykonaj i poczekaj, aż dane do bazy danych zostaną zaimportowane.

W ten sposób zaimportowałeś kopię bazy produkcyjnego WordPressa do bazy danych przeznaczonej pod testowego WordPressa.

Krok 5: Wskaż adres testowego WordPressa w nowej bazie danych

Po zaimportowaniu bazy danych nie wychodź jeszcze z phpMyAdmin – musisz w zaimportowanej bazie zmienić adres URL, aby wskazywał na Twojego testowego WordPressa, a nie tego produkcyjnego. To konieczne, aby powiązać nową bazę danych z testowym WordPressem.

Przejdź w phpMyAdmin do tabeli wp_options. W tabeli wp_options znajdziesz dwa wiersze, które zawierają adres Twojej strony: siteurl oraz home.

Zauważ, że aktualnie kierują one na adres Twojego głównego, produkcyjnego WordPressa (w moim wypadku http://adres-witryny.pl).

W obu tych wierszach musisz kliknąć Edytuj, a następnie zmienić swój obecny adres strony (np. http://adres-witryny.pl) na adres subdomeny (http://test.adres-witryny.pl) testowego WordPressa. Po zmianie adresu kliknij Wykonaj.

Jeśli prawidłowo wykonaliśmy zmiany, to teraz zarówno sireurl jak i home będą kierować na subdomenę, którą przygotowaliśmy pod testowego WordPressa.

Uwaga! W przypadku subdomeny zwróć uwagę na kwestię certyfikatu SSL i protokołu https. Jeżeli dla swojej domeny głównej wygenerowałeś bezpłatny certyfikat SSL (Let’s Encrypt) LUB zakupiłeś płatny certyfikat BEZ funkcji Wildcard, to Twoje subdomeny nie są objęte protokołem https. Oznacza to, że wpisując adres subdomeny należy używać przedrostka http zamiast https.

W ten sposób zaktualizowałeś ustawienia adresu URL w bazie testowego WordPressa, aby wskazywały one na domenę powiązaną ze stage’em.

Krok 6: Wskaż nową bazę danych w pliku wp-config.php testowego WordPressa

Została jeszcze jedna istotna rzecz do skonfigurowania. Aby WordPress zadziałał z utworzonej kopii, należy w jego ustawieniach (pliku wp-config.php) wprowadzić dane do nowej bazy danych.

W tym celu zaloguj się na serwer FTP, przejdź do katalogu z testowym WordPressem (np. folder wpstage), a następnie edytuj plik wp-config.php. Znajdziesz tu następujące, przykładowe linie:

define( 'DB_NAME', 'serwerXXXX_wordpress' );
define( 'DB_USER', 'serwerXXXX_wordpress' );
define( 'DB_PASSWORD', 'haslodoPRODUKCYJNEJbazydanych' );  

Tu przydadzą Ci się dane, które miałeś zapisać lub zapamiętać podczas tworzenia nowej bazy danych pod wersję testową.

Zmień nazwę bazy danych i nazwę użytkownika, wpisując tu dane do nowej bazy danych (np. serwerXXXX_wpstagesql). To samo zrób z hasłem – usuń stare i wpisz hasło do nowej bazy danych, którą stworzyłeś w poprzednich krokach.

define( 'DB_NAME', 'serwerXXXX_wpstagesql' );
define( 'DB_USER', 'serwerXXXX_wpstagesql' );
define( 'DB_PASSWORD', 'haslodoTESTOWEJbazydanych' );  

Zapisz zmiany w pliku i zamknij okno edytora. FileZilla automatycznie wykryje zmiany w pliku i zaoferuje jego przesłanie na serwer. Potwierdź tę czynność.

W ten sposób zaktualizowałeś konfigurację testowego WordPressa, aby korzystał on z nowej bazy danych.

Krok 7: Zaloguj się do testowego WordPressa i zaktualizuj wszystkie pozostałe wystąpienia adresów URL

Twój testowy WordPress jest już gotowy. Możesz teraz go wyświetlić, wpisując adres utworzonej subdomeny w przeglądarce.

To całkowicie oddzielna instalacja, niezależna, w żaden sposób niepowiązana z wersją produkcyjną. Odpala się z oddzielnego folderu i wykorzystuje osobną bazę danych. Żadne zmiany tu wprowadzone nie trafią do strony produkcyjnej pod głównym adresem.

W twojej testowej wersji WordPressa mogą jednak nadal występować wywołania treści lub odnośników z adresu produkcyjnego WordPressa. Aby się ich pozbyć, warto skorzystać z wtyczki Better Search Replace i zaktualizować wszystkie adresy w bazie na testowej wersji.

Zainstaluj wtyczkę, po czym udaj się w panelu WordPressa do zakładki „Narzędzia > Better Search Replace”. W zakładce „Search / Replace” wypełnij odpowiednio poniższe pola.

• Search for – wpisz tu adres produkcyjnej strony
• Replace with – wpisz tu adres stage’a, czyli adres w subdomenie
• Select tables – zaznacz w tym miejscu wszystkie tabele
• Run as dry run – dopóki ta opcja jest zaznaczona, żadne zmiany NIE zostaną wprowadzone, więc należy ją odznaczyć

Sprawdź, czy na pewno stary i nowy adres został poprawnie wpisany. Upewnij się także, czy uwzględnione zostały przedrostki http lub https. Następnie kliknij „Run Search/Replace”.

Krok 8: Wyłącz indeksowanie w wyszukiwarkach oraz dostosuj ostatnie rzeczy

Na sam koniec warto wykonać jeszcze jedną ważną rzecz: wyłączyć indeksowanie w Google testowej wersji. W tym celu zaloguj się do panelu administratorskiego swojego testowego WordPressa. Po zalogowaniu się przejdź do zakładki Ustawienia > Czytanie.

W tym miejscu znajdź i zaznacz pole Proś wyszukiwarki o nieindeksowanie tej witryny. Zachowaj zmiany klikając przycisk Zapisz zmiany.

W ten sposób zabezpieczysz się przed ewentualnym indeksowaniem i duplikowaniem treści z wersji testowej.

Dodatkowo, jeśli nie planujesz dokonywać testów w kodach marketingowych, śledzących i analitycznych, to warto wyłączyć je na stage’u, aby nie przesyłały twoich testowych wejść do statystyk (lub, alternatywnie, możesz utworzyć i skonfigurować osobne usługi Google Analytics, Google Tag Manager itp. pod stage).

Warto także zablokować dostęp do wersji testowej, zabezpieczając stronę hasłem lub dostępem na adres IP. Wtedy nikt bez podania hasła nie będzie mógł wyświetlić Twojego testowego WordPressa, nawet jeśli zna do niego adres. Możesz to zrobić za pomocą pliku .htaccess – zobacz, jak zabezpieczyć katalog na serwerze hasłem.

Aby dodatkowo się zabezpieczyć, warto przeanalizować, co tak naprawdę potrzebujesz na wersji testowej. Czy są Ci potrzebne wszystkie wtyczki? Być może są wśród nich takie, które działanie mają ograniczone do produkcji? Czy są one konieczne do twoich testów? Czy przechowujesz jakiekolwiek dane osobowe lub adresy e-mail klientów? Na stage’u możesz je usunąć lub zanonimizować dane osobowe, aby nigdy nigdzie nie wyciekły – zwłaszcza, że to strona testowa, na której będziesz sporo eksperymentować. Staraj się, aby stage zawierał tylko to, co jest najbardziej konieczne do testów lub prac programistycznych, które planujesz.

Wersja testowa WordPressa a wersja produkcyjna. Jak przenieść zmiany ze stage na produkcję?

No dobrze, masz teraz dwie wersje WordPressa – jedną produkcyjną (pod główną domeną) i jedną testową (pod subdomeną). Przymierasz się do aktualizacji strony lub wprowadzenia nowych funkcji, więc najpierw robisz to i testujesz na wersji testowej. Jeśli wszystko pójdzie dobrze na stage’u, to możesz to samo wykonać na wersji produkcyjnej. To najprostszy scenariusz dla początkujących użytkowników, którzy używają stage’a do nieskomplikowanych testów – testujemy aktualizację, wtyczkę lub motyw na stage’u i jak wszystko jest OK, to wykonujemy to samo na produkcji.

Jak widzisz, ręcznie stworzony prosty stage ma swoje ograniczenia w kwestii śledzenia i synchronizacji zmian pomiędzy stronami. W takiej sytuacji pojawiają się płatne rozwiązania wtyczkowe, takie jak WP Staging w wersji Premium, które pozwalają “wypychać” zmiany wprowadzone na wersji testowej do wersji produkcyjnej WordPressa jednym kliknięciem. Jeśli zależy Ci na szybkim klonowaniu i synchronizowaniu całej strony w obie strony z uwzględnieniem bazy danych, to warto zainwestować w rozwiązanie dedykowane do budowy stage’a.

Poza WP Staging możesz także zapoznać się z narzędziami WP StageCoach lub WPMerge.io.

Alternatywą dla gotowych, kompleksowych rozwiązań są ręczne konfiguracje w oparciu o Git oraz skrypty synchronizujące bazę danych. To jednak rozwiązania dla zaawansowanych użytkowników i wymagają większej wiedzy, gdyż nieumiejętne skonfigurowanie takich narzędzi może sprawić, że w trakcie takich działań coś może pójść nie tak (np. może zostać przekopiowana tylko część zmian, co poskutkuje uszkodzeniem strony produkcyjnej). Musisz dokładnie wiedzieć, jak uzupełniane mają być pomiędzy nimi dane oraz które zmiany mają być ignorowane (bo wynikają np. z konfiguracji stage’a).

Jeśli nie czujesz się z tym pewnie i nie wiesz, jakie zmiany w bazie powinny być synchronizowane, to w tym wypadku najlepiej potraktować wersję testową jako środowisko robocze, w którym eksperymentujemy i sprawdzamy stabilność naszych zmian. Gdy wszystko pójdzie dobrze, to wprowadzone zmiany należy ręcznie odwzorować na wersji produkcyjnej.