Pełna kopia strony na subdomenie w godzinę: pliki, baza, search-replace bez psucia danych serializowanych i blokada indeksowania. Bez płatnych wtyczek.
Staging to pełna, działająca kopia Twojej strony pod osobnym adresem - poligon, na którym testujesz aktualizacje, zmiany motywu czy nową wtyczkę, zanim dotkniesz wersji, którą widzą klienci. Różnica między „mam staging" a „nie mam" ujawnia się zawsze w najgorszym momencie: przy aktualizacji, która kładzie stronę w środku dnia. Na kopii testowej ta sama awaria to wzruszenie ramion i szukanie przyczyny przy kawie.
W tym poradniku budujemy staging ręcznie, na subdomenie, metodą działającą na każdym hostingu z DirectAdmin - bez płatnych wtyczek. Po drodze omijamy dwie miny, na których wysypuje się większość samodzielnych prób: podmianę adresów w danych serializowanych i indeksację kopii przez Google.
Potrzebny na pewno: przed dużymi aktualizacjami (WooCommerce, Elementor, zmiana wersji PHP), przy przebudowie strony, która ma zostać podmieniona w całości, przy testowaniu wtyczek ingerujących głęboko (cache, bezpieczeństwo, wielojęzyczność) i wszędzie tam, gdzie strona zarabia - w sklepie każda godzina awarii to policzalna strata.
Przesada: przy poprawce literówki czy podmianie zdjęcia. Zdrowy rozsądek: zmiany treści robi się na produkcji, zmiany mechaniki - na stagingu.
Staging nie zastępuje kopii zapasowych - to narzędzia do różnych rzeczy (testowanie przyszłości vs przywracanie przeszłości). O drugim filarze przeczytasz w poradniku o kopiach zapasowych strony.
W DirectAdmin utwórz subdomenę, np. test.twojadomena.pl - dostanie własny katalog. Czym w ogóle jest subdomena i czemu nie warto do testów używać podkatalogu, wyjaśnia osobny tekst. Od razu po utworzeniu wystaw dla niej certyfikat SSL (na naszym hostingu darmowy Let's Encrypt generuje się z panelu) - kopia bez HTTPS będzie straszyć ostrzeżeniami i zafałszuje testy.
Następnie utwórz drugą bazę danych z osobnym użytkownikiem (sekcja MySQL Management). Zapisz nazwę bazy, użytkownika i hasło - za chwilę trafią do konfiguracji kopii. Nigdy nie podpinaj stagingu pod bazę produkcyjną - to najkrótsza droga do przetestowania zmian bezpośrednio na klientach.
Najszybciej przez SSH (przy tysiącach plików FTP jest męczarnią):
cp -a ~/domains/twojadomena.pl/public_html/. ~/domains/twojadomena.pl/public_html/test/
Ścieżka docelowa zależy od tego, gdzie panel umieścił katalog subdomeny - sprawdź ją w menedżerze plików. Flaga -a zachowuje strukturę i czasy plików. Jeśli strona waży dużo, a chcesz oszczędzić transfer i miejsce, katalog wp-content/uploads można na stagingu pominąć - kopia będzie bez części obrazków, ale do testów mechaniki zwykle to wystarcza i odchudza całość o gigabajty.
Zrzut i wgranie do nowej bazy - dwa polecenia przez SSH z użyciem WP-CLI (uruchamiane w katalogu produkcji):
wp db export ~/prod.sql
a następnie import do bazy stagingu (w katalogu kopii, po skonfigurowaniu wp-config.php z kroku 4):
wp db import ~/prod.sql
Alternatywnie phpMyAdmin: eksport z bazy produkcyjnej, import do testowej. Przy bazach powyżej kilkudziesięciu MB rób to jednak przez SSH - import w przeglądarce lubi się przerywać w połowie. Więcej poleceń tego typu znajdziesz w przewodniku po WP-CLI.
W katalogu stagingu otwórz wp-config.php i podmień dane bazy na te z kroku 1: DB_NAME, DB_USER, DB_PASSWORD. Dopisz też dwie linie, które ułatwią życie:
define('WP_ENVIRONMENT_TYPE', 'staging');define('DISALLOW_INDEXING', true);
Pierwsza informuje WordPressa i porządne wtyczki, że to środowisko testowe (część wtyczek, np. płatności czy SMTP, umie się wtedy same przełączyć w tryb bezpieczny). Druga linia to nasza konwencja pomocnicza - samo w sobie nic nie robi, właściwą blokadę indeksowania ustawisz w kroku 6.
Baza kopii wciąż wskazuje na adres produkcyjny - staging będzie przekierowywał na produkcję albo mieszał zasoby z obu stron. Adresy trzeba podmienić, ale nie wolno robić tego zwykłym szukaj-zamień w pliku SQL. WordPress trzyma część danych w formacie serializowanym, gdzie zapisana jest długość każdego tekstu; podmiana zmienia tekst, nie długości, i dane stają się nieczytelne. Objawy: znikające ustawienia motywu, rozsypane widżety, Elementor bez stylów.
Jedyna poprawna droga to narzędzie rozumiejące serializację. W katalogu stagingu:
wp search-replace 'https://twojadomena.pl' 'https://test.twojadomena.pl' --dry-run
Wariant --dry-run pokazuje liczbę trafień bez zapisu; gdy wynik wygląda rozsądnie, uruchom bez tej flagi. Dokładnie ta sama technika obowiązuje przy przenosinach na inny adres - opisujemy ją też w poradniku o przeniesieniu WordPressa na nową domenę.
Po podmianie wyczyść cache (jeśli LiteSpeed Cache jest aktywny na kopii - Purge All) i zaloguj się do kokpitu stagingu pod nowym adresem.
Kopia testowa dostępna publicznie to dwa problemy naraz: Google widzi duplikat całej strony, a klienci mogą przypadkiem trafić na wersję z testowymi cenami. Trzy blokady, od najważniejszej:
Indeksowanie: w kokpicie stagingu Ustawienia - Czytanie - zaznacz „Proś wyszukiwarki o nieindeksowanie". Dla pewności dodaj w .htaccess stagingu nagłówek:
Header set X-Robots-Tag "noindex, nofollow"
Dostęp: najlepiej katalog na hasło (Password Protected Directories w DirectAdmin) albo ograniczenie do własnego IP. Wtedy problem indeksacji znika w ogóle, bo robot nie wejdzie.
Maile: sklep na stagingu potrafi wysyłać prawdziwe powiadomienia do prawdziwych klientów przy testach zamówień. Wyłącz wysyłkę wtyczką typu „disable emails" albo przestaw SMTP kopii na tryb logowania zamiast wysyłania. To samo dotyczy zadań cyklicznych - jeśli produkcja ma podpięte płatne API, na kopii podmień klucze na testowe.
Na stagingu testuj dokładnie ten scenariusz, który planujesz na produkcji: ta sama kolejność aktualizacji, te same wtyczki. Po testach masz dwie drogi przeniesienia:
Droga bezpieczna (zalecana): powtórz kroki na produkcji. Staging służy jako dowód, że operacja przechodzi czysto - na produkcji wykonujesz ją drugi raz, już bez nerwów, poprzedzoną zwykłym backupem. Tak pracujemy przy aktualizacjach u klientów; procedurę od strony produkcji opisuje poradnik o bezpiecznej aktualizacji WordPressa.
Droga kopiowania stagingu na produkcję bywa kusząca, ale ma poważny haczyk w sklepach i na stronach z formularzami: przez czas Twoich testów produkcja zdążyła zebrać nowe zamówienia i wpisy. Nadpisanie jej bazą stagingu je skasuje. Ten wariant jest bezpieczny tylko przy stronach statycznych treściowo albo przy świadomym scalaniu - co wykracza poza „szybki poradnik".
Zapomniany staging to klasyczna furtka włamań: kopia sprzed roku, z dziurawymi wtyczkami, wciąż dostępna publicznie. Zasady higieny: staging bez hasła nie istnieje dłużej niż czas testów; po zakończeniu prac kopię kasujesz albo odświeżasz przed kolejną rundą; staging liczy się do miejsca na dysku (razem z bazą), więc przy ciasnym pakiecie sprzątanie to też kwestia limitów.
Ręczny staging na subdomenie to godzina pracy przy pierwszym podejściu i kwadrans przy każdym kolejnym: subdomena + osobna baza, kopia plików, kopia bazy, wp-config, search-replace przez WP-CLI (nigdy ręcznie!), blokada indeksowania i dostępu. W zamian dostajesz miejsce, gdzie żadna aktualizacja nie jest straszna, a „duża zmiana na stronie" przestaje oznaczać pracę nocą z sercem w gardle.
Na naszym hostingu wszystkie klocki są w cenie każdego pakietu: subdomeny, osobne bazy, SSL dla subdomen, SSH z WP-CLI i katalogi na hasło. A jeśli wolisz, żebyśmy postawili staging za Ciebie - napisz, robimy to regularnie przy okazji opieki nad stronami.
Wszystkie poradniki z kategorii: WordPress