Aktualizacja wtyczki, zmiana motywu czy nowa funkcja potrafią zepsuć działającą stronę, a najgorszy moment na taką niespodziankę to ruch na żywo. Środowisko testowe (staging) to osobna kopia strony z własną bazą, na której sprawdzasz zmiany w izolacji, zanim trafią do odwiedzających. Na hostingu webh przygotujesz je na dwa sposoby, wtyczką albo ręcznie na subdomenie, a ten poradnik pokazuje oba i wyjaśnia, jak bezpiecznie przenieść zmiany na produkcję.
Czym jest staging i po co go używać
Staging to pełna kopia Twojej strony: Te same pliki, ta sama (skopiowana) baza danych, ale pod innym adresem i na osobnej bazie. Pozwala:
- Przetestować aktualizacje WordPress, wtyczek i motywów, zanim zainstalujesz je na żywej stronie,
- Bezpiecznie wprowadzać zmiany w wyglądzie i funkcjach, bez ryzyka, że odwiedzający zobaczy stronę w trakcie prac,
- Odtworzyć i naprawić problem, którego nie chcesz diagnozować na produkcji.
Najważniejsza zasada: Staging i produkcja to dwa oddzielne środowiska. Kopia ma własną bazę danych, więc zmiany na stagingu nie ruszają prawdziwej strony, dopóki sam ich nie przeniesiesz.
Dwie drogi: Wtyczka albo subdomena
Wybierz metodę zależnie od tego, jak wygodnie czujesz się z plikami i bazą danych.
Najprościej: Wtyczka do stagingu
Wtyczki do tworzenia kopii roboczej (staging) wykonują większość pracy za Ciebie: Tworzą kopię strony, podmieniają w niej adresy i pozwalają później przenieść zmiany z powrotem. To najwygodniejsza droga, jeśli nie chcesz ręcznie kopiować plików i bazy.
Wskazówka
Po utworzeniu kopii wtyczką i tak zabezpiecz ją przed światem (patrz sekcja niżej). Wtyczka tworzy środowisko, ale to Ty decydujesz, czy nie wpadnie do wyszukiwarki.
Ręcznie: Kopia na subdomenie
Metoda ręczna daje pełną kontrolę i nie wymaga dodatkowej wtyczki. Wykorzystuje to, że hosting webh nie ogranicza liczby subdomen ani baz danych.
- Utwórz subdomenę na kopię, np.
staging.twojadomena.pl, jak opisujemy w artykule o subdomenach. - Załóż nową bazę danych dla kopii, zgodnie z poradnikiem o bazach MySQL. Staging musi mieć własną bazę, oddzielną od produkcji.
- Skopiuj pliki strony do katalogu subdomeny przez FTP lub menedżer plików, jak opisujemy w poradniku o SSH i FTP.
- Zaimportuj bazę produkcyjną do nowej bazy (eksport i import w phpMyAdmin), a w pliku
wp-config.phpna stagingu wpisz dane nowej bazy. - Podmień adresy URL w skopiowanej bazie ze starego adresu na adres stagingu, żeby kopia ładowała się pod właściwą subdomeną.
Informacja
Adresy w bazie podmienisz bezpiecznie wtyczką typu “search and replace” albo, na pakiecie z dostępem SSH, poleceniem wp search-replace (WP-CLI). Ręczna edycja zwykłym “znajdź i zamień” potrafi uszkodzić dane zapisane w bazie, dlatego korzystaj z narzędzi przeznaczonych do WordPress. Tę samą operację opisujemy przy zmianie adresu WordPress.
Po tych krokach pod adresem stagingu masz działającą kopię strony, niezależną od produkcji.
Zabezpiecz staging przed światem
Kopia robocza nie powinna być widoczna ani dla odwiedzających, ani dla Google. Dwa powody: Nie chcesz, żeby ktoś korzystał z niedokończonej wersji, i nie chcesz, żeby wyszukiwarka zaindeksowała kopię jako duplikat treści.
- Zablokuj indeksowanie. W ustawieniach czytania WordPress na stagingu zaznacz “Proś wyszukiwarki o nieindeksowanie tej witryny”. Trzymaj tę opcję włączoną tylko na kopii, nigdy na produkcji.
- Załóż hasło na katalog subdomeny stagingu, korzystając z zabezpieczania katalogu hasłem. Wtedy do kopii wejdzie tylko osoba znająca hasło.
Uwaga
Po przeniesieniu zmian na produkcję sprawdź, czy żywa strona nie ma zaznaczonego zakazu indeksowania. Zostawiony przez pomyłkę na produkcji blokuje całą witrynę w Google, co opisujemy też w artykule o migracji bez utraty pozycji.
Przenoszenie zmian na produkcję
Gdy zmiana działa na stagingu, czas przenieść ją na żywą stronę. Tu liczy się ostrożność, bo produkcja ma świeższe dane (nowe zamówienia, komentarze, treści), których nie chcesz nadpisać starszą bazą ze stagingu.
- Zadbaj o aktualną kopię produkcji przed wdrożeniem (własną lub z automatycznych kopii hostingu, poradnik o kopiach). To Twój punkt powrotu, gdyby coś poszło nie tak.
- Przenieś zmiany w sposób adekwatny do ich rodzaju:
- zmiany w plikach (motyw, wtyczki) zwykle wgrywasz na produkcję jako pliki,
- zmiany dotyczące tylko zawartości i ustawień zapisanych w bazie wymagają większej ostrożności, bo nadpisanie całej bazy produkcyjnej skasuje dane, które przybyły w międzyczasie.
- Sprawdź żywą stronę po wdrożeniu: Stronę główną, kilka podstron, formularze i (w sklepie) ścieżkę zakupu.
Wskazówka
Hosting webh wykonuje kopie co godzinę i przechowuje je przez 21 dni, więc niezależnie od metody wdrożenia masz dodatkowy bezpiecznik. Jeśli wdrożenie coś popsuje, cofniesz produkcję do stanu sprzed godziny.
Najczęstsze pytania
Czy webh ma staging jednym kliknięciem?
Hosting nie udostępnia osobnego przycisku tworzącego staging, ale przygotujesz go bez przeszkód: Albo wtyczką do kopii roboczej, albo ręcznie na subdomenie z osobną bazą, bo liczba subdomen i baz nie jest ograniczona.
Czy staging zużywa dodatkowe zasoby pakietu?
Kopia zajmuje miejsce na dysku i własną bazę, więc liczy się do zasobów Twojego pakietu jak każda inna strona. Po zakończeniu testów możesz ją usunąć, żeby zwolnić miejsce.
Czy zmiany na stagingu wpływają na żywą stronę?
Nie, dopóki sam ich nie przeniesiesz. Staging ma własną bazę i własne pliki, więc to izolowane środowisko. Produkcja zmienia się dopiero wtedy, gdy świadomie wdrożysz na nią przetestowane zmiany.
Jak nie dopuścić, żeby Google zaindeksował kopię?
Włącz na stagingu zakaz indeksowania w ustawieniach czytania WordPress i dodatkowo załóż hasło na katalog subdomeny. Razem zatrzymują zarówno roboty wyszukiwarek, jak i przypadkowych odwiedzających.