Kopia testowa strony na WordPressie. Jak ją utworzyć i sprawdzać na niej zmiany?

Aktualizacja wtyczki, zmiana motywu albo nowa wersja PHP potrafią w kilka sekund zepsuć stronę, która do tej pory działała bez zarzutu. Jeśli taka zmiana trafia od razu na witrynę odwiedzaną przez klientów, każdy błąd widać natychmiast: znika formularz, rozsypuje się układ, sklep przestaje przyjmować zamówienia. Kopia testowa, nazywana też wersją roboczą albo środowiskiem staging, pozwala sprawdzić wszystko wcześniej, w miejscu, którego nikt poza właścicielem nie ogląda.

Ta instrukcja jest przeznaczona dla osób, które prowadzą firmową stronę albo sklep na WordPressie i same wykonują aktualizacje lub zlecają je bez stałej opieki technicznej. Nie wymaga wiedzy programistycznej, choć w jednej z trzech opisanych dróg potrzebny będzie dostęp do panelu hostingu i bazy danych.

Po lekturze wiadomo będzie, jak utworzyć kopię testową trzema sposobami, jak ukryć ją przed Google i osobami postronnymi, co na niej wyłączyć, żeby nie wysyłała wiadomości do prawdziwych klientów, jak sprawdzać na niej zmiany i jak bezpiecznie przenieść je potem na działającą stronę.

Czym jest kopia testowa i kiedy naprawdę jest potrzebna?

Kopia testowa to drugi, w pełni działający egzemplarz tej samej strony: te same pliki, ta sama baza danych, te same wtyczki i ustawienia, tylko pod innym adresem. Najczęściej jest to subdomena, na przykład test.mojafirma.pl, albo podkatalog, na przykład mojafirma.pl/test. Wszystko, co zostanie na niej zmienione, pozostaje na niej i nie wpływa na witrynę, którą widzą klienci.

Kopia testowa nie jest tym samym co kopia zapasowa. Kopia zapasowa to archiwum, które leży i czeka na awarię. Kopia testowa to działająca strona, na której się pracuje. Jedna nie zastępuje drugiej: przed pracami potrzebne są obie, a sposób wykonania i sprawdzenia archiwum opisałem we wpisie o tym, jak zrobić kopię zapasową WordPressa, która naprawdę działa.

Z mojej praktyki wynika, że kopia testowa jest potrzebna przede wszystkim w kilku sytuacjach: przed dużą aktualizacją WordPressa, przed aktualizacją wtyczki sklepu lub kreatora stron, przed zmianą motywu, przed zmianą wersji PHP na serwerze, przed instalacją wtyczki, która ingeruje w bazę danych, oraz przy każdej większej przebudowie układu strony. Przy drobnej poprawce tekstu nie ma sensu jej tworzyć.

Którą z trzech dróg wybrać: hosting, wtyczka czy kopia ręczna?

Kopię testową da się utworzyć na trzy sposoby. Różnią się one nakładem pracy, wymaganą wiedzą i tym, jak łatwo przenosi się później zmiany na działającą stronę. Wybór zależy głównie od tego, co oferuje hosting i jak duża jest witryna.

Narzędzie w panelu hostingu

Wielu dostawców hostingu udostępnia w panelu klienta gotową funkcję tworzenia kopii testowej, zwykle w sekcji poświęconej WordPressowi. Nazwy tej funkcji różnią się między firmami: bywa to „Staging”, „Kopia testowa”, „Klonowanie” albo „Środowisko testowe”. Działa to zazwyczaj tak, że po wskazaniu instalacji WordPressa i adresu docelowego hosting sam kopiuje pliki i bazę oraz podmienia adresy.

To najwygodniejsza droga, ponieważ kopia powstaje poza WordPressem, a więc także wtedy, gdy kokpit działa wolno. Często dostępne jest również przeniesienie zmian z kopii na stronę główną jednym poleceniem. Ponieważ każdy hosting nazywa i układa te funkcje inaczej, dokładnej ścieżki trzeba szukać w pomocy swojego dostawcy albo zapytać o nią obsługę. Pytanie może brzmieć: „Czy w moim pakiecie jest funkcja tworzenia kopii testowej WordPressa i gdzie ją znajdę w panelu?”.

Wtyczka do tworzenia kopii testowej

Jeśli hosting nie ma takiej funkcji, kopię można utworzyć wtyczką. W katalogu wtyczek WordPressa najbardziej znana jest WP STAGING. W wersji podstawowej, która nie wymaga opłaty, klonuje ona całą witrynę do podkatalogu na tym samym serwerze. To dobre rozwiązanie dla małych i średnich stron, o ile na koncie hostingowym jest wystarczająco dużo wolnego miejsca.

Kopia ręczna na subdomenie

Trzecia droga to samodzielne skopiowanie plików i bazy danych na subdomenę. Wymaga najwięcej pracy i uwagi, ale daje pełną kontrolę: kopia ma własną bazę danych, własny adres i jest całkowicie niezależna od strony głównej. Wybiera się ją, gdy witryna jest duża, gdy wtyczka nie radzi sobie z klonowaniem albo gdy kopia ma stać na innym serwerze.

Co przygotować niezależnie od wybranej drogi?

Niezależnie od wybranej drogi kilka rzeczy trzeba sprawdzić wcześniej. Zajmuje to kilkanaście minut, a chroni przed najczęstszymi niepowodzeniami, czyli przerwanym kopiowaniem z powodu braku miejsca i brakiem dostępu do panelu w najmniej odpowiedniej chwili.

1. Wykonanie pełnej kopii zapasowej plików i bazy danych oraz pobranie jej poza serwer, na dysk komputera lub do chmury.
2. Sprawdzenie w panelu hostingu, ile miejsca zajmuje strona i ile zostało wolnego. Kopia testowa zajmie mniej więcej tyle samo co oryginał, więc wolnego miejsca powinno być wyraźnie więcej niż rozmiar witryny.
3. Przygotowanie danych dostępowych: logowanie do panelu hostingu, konto administratora WordPressa, a przy kopii ręcznej także dane do bazy danych i do menedżera plików lub FTP.
4. Uporządkowanie strony: usunięcie nieużywanych wtyczek i motywów oraz starych archiwów kopii zapasowych leżących w katalogu wp-content. Nie ma powodu, żeby je powielać.
5. Spisanie listy rzeczy do sprawdzenia po zmianach: najważniejsze podstrony, formularze, koszyk, logowanie klientów, wyszukiwarka na stronie.

Jeśli strona działa w sieci witryn (WordPress Multisite), trzeba to uwzględnić przy wyborze narzędzia. Podstawowa wersja WP STAGING nie obsługuje sieci witryn, a ręczna zmiana adresów w takiej instalacji wymaga edycji kilku tabel bazy. W takim przypadku radzę skorzystać z narzędzia hostingu albo powierzyć zadanie osobie z doświadczeniem.

Jak utworzyć kopię testową wtyczką WP STAGING?

Wtyczka wykonuje całą pracę w kokpicie: kopiuje pliki do podkatalogu, powiela tabele bazy danych pod innym przedrostkiem i ustawia adresy tak, żeby kopia działała pod własnym adresem. Panel wtyczki jest w dużej części po angielsku, dlatego nazwy przycisków podaję tak, jak opisuje je strona wtyczki w katalogu WordPressa, a tam, gdzie mogą się różnić między wersjami, opisuję czynność ogólnie.

1. W kokpicie należy otworzyć menu „Wtyczki” i przejść do ekranu dodawania nowej wtyczki.
2. W polu wyszukiwania wpisuje się WP STAGING, a następnie przy właściwej wtyczce klika przycisk instalacji i po chwili przycisk włączenia.
3. W menu kokpitu pojawia się nowa pozycja „WP Staging”. Po jej otwarciu trzeba wybrać tworzenie nowej witryny testowej. Strona wtyczki opisuje tę opcję jako „Create a Staging Site”.
4. Wtyczka prosi o nazwę kopii. Nazwa staje się nazwą podkatalogu, więc najlepiej użyć krótkiego słowa bez polskich znaków i spacji, na przykład test.
5. Na kolejnym ekranie widać listę tabel bazy danych i katalogów do skopiowania. Przy pierwszej kopii najbezpieczniej pozostawić zaznaczenie domyślne. Wyłączyć można jedynie katalogi z archiwami kopii zapasowych.
6. Po uruchomieniu klonowania nie należy zamykać karty przeglądarki ani jej odświeżać aż do komunikatu o zakończeniu. Przy dużej stronie trwa to kilkanaście minut lub dłużej.
7. Po zakończeniu wtyczka pokazuje adres kopii, na przykład mojafirma.pl/test. Logowanie odbywa się tym samym kontem administratora co na stronie głównej.

Kopię łatwo odróżnić od oryginału: pasek administracyjny u góry ekranu ma na niej kolor pomarańczowy. To drobiazg, który w praktyce chroni przed najgroźniejszą pomyłką, czyli wprowadzaniem zmian testowych na działającej stronie w przekonaniu, że pracuje się na kopii.

Co trzeba wiedzieć o ograniczeniach wersji podstawowej?

Po pierwsze, do kopii mają dostęp wyłącznie administratorzy. Osoba niezalogowana zobaczy okno logowania zamiast treści, co jednocześnie chroni kopię przed przypadkowymi gośćmi. Po drugie, kopia powstaje tylko w podkatalogu na tym samym serwerze. Własna subdomena, osobna baza danych i inny katalog są dostępne w wersji płatnej.

Po trzecie, po pierwszym klonowaniu na kopii wyłączone są bezpośrednie odnośniki. Adresy podstron mają wtedy postać z numerem, a nie z czytelną nazwą. Do sprawdzania aktualizacji to nie przeszkadza. Jeśli jednak testowane są przekierowania albo adresy, bezpośrednie odnośniki trzeba na kopii włączyć zgodnie z dokumentacją wtyczki.

Po czwarte i najważniejsze: przenoszenie zmian z kopii na działającą stronę jednym poleceniem jest funkcją wersji płatnej. W wersji podstawowej kopia służy do sprawdzenia, czy zmiana jest bezpieczna, a potem tę samą zmianę wykonuje się ręcznie na stronie głównej. Przy aktualizacjach to w zupełności wystarcza.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl, a przejmę sprawę: utworzę kopię testową dopasowaną do hostingu i wielkości strony, zabezpieczę ją przed Google i przekażę gotowe środowisko do sprawdzania zmian.

Jak utworzyć kopię ręcznie na subdomenie?

Kopia ręczna składa się z czterech czynności: przygotowania miejsca, skopiowania plików, skopiowania bazy danych i zmiany adresów. Każdą z nich wykonuje się w panelu hostingu, a nazwy narzędzi zależą od dostawcy. Zasada pozostaje ta sama wszędzie.

Przygotowanie subdomeny i bazy danych

1. W panelu hostingu należy utworzyć subdomenę, na przykład test.mojafirma.pl, i zapamiętać katalog, do którego została przypisana.
2. Dla subdomeny trzeba włączyć certyfikat SSL, żeby kopia działała pod adresem zaczynającym się od https, tak jak strona główna.
3. W sekcji baz danych tworzy się nową, pustą bazę oraz użytkownika z pełnymi uprawnieniami do niej. Nazwę bazy, nazwę użytkownika, hasło i adres serwera bazy trzeba zanotować.
4. Menedżerem plików lub przez FTP kopiuje się całą zawartość katalogu strony głównej do katalogu subdomeny, łącznie z plikami ukrytymi, takimi jak .htaccess.
5. W narzędziu phpMyAdmin wybiera się bazę strony głównej, otwiera zakładkę „Eksport” i pobiera plik z rozszerzeniem sql. Następnie wybiera się nową bazę, otwiera zakładkę „Import” i wczytuje pobrany plik.
6. W katalogu subdomeny otwiera się plik wp-config.php i w wierszach DB_NAME, DB_USER oraz DB_PASSWORD wpisuje dane nowej bazy.

Szczególnej uwagi wymaga ostatnia czynność. Jeśli plik wp-config.php na kopii nadal wskazuje starą bazę, kopia i strona główna będą korzystać z tych samych danych. Każda zmiana na kopii trafi wtedy od razu do witryny widocznej dla klientów, czyli cały sens kopii testowej zostanie utracony.

Zmiana adresów w kopii

Zaimportowana baza nadal zawiera adres strony głównej. Bez zmiany adresów próba otwarcia kopii skończy się przeniesieniem na stronę główną. Najprostszy sposób, opisany w dokumentacji WordPressa, to dopisanie w pliku wp-config.php kopii dwóch wierszy nad komentarzem informującym o końcu edycji:

define( 'WP_HOME', 'https://test.mojafirma.pl' );
define( 'WP_SITEURL', 'https://test.mojafirma.pl' );

Adresy wpisuje się z początkiem https i bez ukośnika na końcu. Po zapisaniu pliku kopia otworzy się pod własnym adresem i da się na niej zalogować. Dokumentacja zaznacza, że przy tej metodzie pola „Adres WordPressa (URL)” i „Adres witryny (URL)” w menu „Ustawienia”, zakładka „Ogólne”, stają się nieedytowalne. Na kopii testowej to zaleta, bo nikt nie zmieni ich przypadkiem.

Te dwa wiersze nie zmieniają jednak adresów zapisanych w treści wpisów, w ustawieniach kreatora stron i w menu. Obrazki i część linków nadal będą prowadzić do strony głównej. Żeby kopia była w pełni samodzielna, stary adres trzeba zamienić na nowy w całej bazie.

Nie wolno robić tego zwykłą funkcją „znajdź i zamień” w pliku sql ani prostym zapytaniem w phpMyAdmin. Dokumentacja WordPressa ostrzega, że taka zamiana uszkadza dane zapisane w specjalnym formacie, w którym przechowywana jest długość tekstu. Skutkiem bywają znikające widżety i ustawienia motywu. Bezpieczne są narzędzia, które ten format rozumieją: polecenie WP-CLI albo wtyczka do zamiany adresów w bazie, na przykład wymieniana w dokumentacji Better Search Replace.

Jeśli hosting udostępnia WP-CLI, w katalogu kopii uruchamia się najpierw polecenie próbne, które pokazuje liczbę zmian, ale niczego nie zapisuje:

wp search-replace 'https://mojafirma.pl' 'https://test.mojafirma.pl' --skip-columns=guid --dry-run

Jeżeli raport wygląda sensownie, to samo polecenie uruchamia się ponownie bez końcówki --dry-run. Przed jego wykonaniem trzeba mieć pewność, że polecenie działa w katalogu kopii, a nie strony głównej. Na koniec na kopii otwiera się menu „Ustawienia”, zakładkę „Bezpośrednie odnośniki”, i bez zmieniania czegokolwiek klika „Zapisz zmiany”. WordPress odtwarza wtedy reguły adresów dla nowego miejsca.

Jak ukryć kopię przed Google i osobami postronnymi?

Kopia testowa to duplikat całej witryny. Jeśli trafi do wyników wyszukiwania, Google zobaczy dwie identyczne strony pod dwoma adresami, a klienci mogą wejść na wersję, w której nic nie działa tak, jak powinno, albo złożyć zamówienie, które do nikogo nie dotrze. Dlatego zabezpieczenie kopii wykonuje się od razu po jej utworzeniu, a nie „przy okazji”.

Hasło na cały katalog jako najpewniejsza ochrona

Najskuteczniejszym zabezpieczeniem jest hasło ustawione po stronie serwera. Większość paneli hostingowych ma funkcję ochrony katalogu hasłem. Po jej włączeniu dla katalogu kopii przeglądarka przed pokazaniem czegokolwiek prosi o nazwę użytkownika i hasło. Robot wyszukiwarki nie zna hasła, więc nie zobaczy ani jednej podstrony, a osoba postronna nie obejrzy niedokończonych zmian.

Trzeba mieć świadomość jednego skutku ubocznego. Hasło na serwerze blokuje również połączenia, które WordPress wykonuje sam do siebie, dlatego narzędzie „Kondycja witryny” może na kopii zgłaszać problemy z wewnętrznymi połączeniami i zaplanowanymi zadaniami. Na kopii testowej jest to oczekiwane i nie oznacza usterki.

Ustawienie w kokpicie jako drugie zabezpieczenie

Na kopii należy otworzyć menu „Ustawienia”, zakładkę „Czytanie”, i w wierszu „Widoczność dla wyszukiwarek” zaznaczyć pole „Proś wyszukiwarki o nieindeksowanie tej witryny”, a następnie kliknąć „Zapisz zmiany”. WordPress dodaje wtedy do każdej podstrony znacznik z regułą noindex. Sam WordPress zaznacza, że to prośba, której spełnienie zależy od wyszukiwarki, i że ustawienie nie blokuje dostępu do strony.

Często popełniany błąd polega na dodatkowym zablokowaniu kopii w pliku robots.txt „dla pewności”. Dokumentacja Google wyjaśnia, że reguła noindex działa tylko wtedy, gdy robot może otworzyć stronę i ją odczytać. Jeśli plik robots.txt zabrania wejścia, robot reguły nie zobaczy, a adres może mimo to pojawić się w wynikach, gdy prowadzą do niego linki z innych stron. Więcej o tym pliku napisałem we wpisie o tym, jak ustawić plik robots.txt.

W praktyce stosuję prostą zasadę: hasło na serwerze jako ochrona główna i zaznaczone pole w zakładce „Czytanie” jako zabezpieczenie na wypadek, gdyby hasło zostało kiedyś zdjęte. Bardzo ważne jest też to, żeby po przenoszeniu bazy z kopii na stronę główną sprawdzić, czy to pole nie zostało przeniesione razem z nią. Zaznaczone na działającej stronie potrafi usunąć ją z wyników wyszukiwania.

Jak oznaczyć kopię i co na niej wyłączyć?

Kopia jest wiernym odbiciem strony, a więc dziedziczy także wszystko, co strona robi sama: wysyła wiadomości, łączy się z bramką płatności, publikuje zaplanowane wpisy, przekazuje dane do narzędzi analitycznych. Bez wyłączenia tych mechanizmów kopia testowa zaczyna działać równolegle z oryginałem i wprowadza zamieszanie.

Typ środowiska w pliku wp-config.php

WordPress ma wbudowany sposób oznaczania, czym jest dana instalacja. W pliku wp-config.php kopii, nad komentarzem o końcu edycji, dopisuje się wiersz:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Dokumentacja WordPressa przewiduje cztery wartości: local, development, staging i production. Jeśli nic nie zostanie ustawione, WordPress przyjmuje wartość production, czyli uznaje instalację za działającą stronę. Wartość inna niż cztery dozwolone jest traktowana tak samo.

Samo oznaczenie nie wyłącza niczego automatycznie. Jego sens polega na tym, że wtyczki i motywy mogą odczytać typ środowiska i dostosować do niego swoje działanie, na przykład wstrzymać wysyłkę danych albo pokazać ostrzeżenie. Nie każda wtyczka to robi, dlatego pozostałe rzeczy trzeba sprawdzić ręcznie. Wartość development dodatkowo włącza tryb debugowania, więc na kopii przeznaczonej do zwykłego sprawdzania aktualizacji lepiej pozostać przy staging.

Lista rzeczy do wyłączenia lub przestawienia

• Wysyłka wiadomości e-mail: potwierdzenia zamówień, powiadomienia z formularzy, biuletyny. Na kopii należy wyłączyć wtyczkę do wysyłki albo skierować pocztę na własny adres.
• Płatności: bramkę płatniczą przestawia się w tryb testowy, a gdy go nie ma, wyłącza się metodę płatności.
• Integracje z zewnętrznymi systemami: magazyn, faktury, kurier, porównywarki cen, automatyczna publikacja w mediach społecznościowych.
• Kody narzędzi analitycznych i reklamowych, żeby wejścia na kopię nie mieszały się z danymi prawdziwych odwiedzin.
• Pamięć podręczna i sieć dostarczania treści. Na kopii lepiej je wyłączyć, bo utrudniają ocenę, czy zmiana rzeczywiście została wprowadzona.
• Automatyczne kopie zapasowe wykonywane wtyczką, które niepotrzebnie zajmowałyby miejsce na koncie.

Jak sprawdzać zmiany na kopii, żeby test miał sens?

Test jest wartościowy tylko wtedy, gdy kopia jest aktualna. Kopia sprzed kilku miesięcy ma inne wersje wtyczek i inną zawartość niż strona, więc wynik sprawdzenia niewiele mówi. Przed każdą większą turą zmian kopię należy utworzyć od nowa albo odświeżyć funkcją aktualizacji kopii w narzędziu, którym została zrobiona.

1. Przed zmianą trzeba przejść po liście najważniejszych podstron i zanotować, jak działają: wygląd, formularz, koszyk, logowanie. To punkt odniesienia.
2. Zmiany wprowadza się pojedynczo. Najpierw jedna wtyczka, potem sprawdzenie strony, dopiero potem kolejna. Przy aktualizacji wszystkiego naraz nie da się ustalić, co wywołało błąd.
3. Po każdej zmianie należy otworzyć stronę w oknie prywatnym przeglądarki oraz na telefonie i ponownie przejść po liście.
4. W sklepie trzeba złożyć zamówienie testowe od dodania produktu do koszyka aż po ekran podziękowania, z płatnością w trybie testowym.
5. W kokpicie kopii należy otworzyć menu „Narzędzia”, pozycję „Kondycja witryny”, i sprawdzić, czy nie pojawiły się nowe ostrzeżenia poza tymi, które wynikają z hasła na serwerze.
6. Wynik każdej zmiany zapisuje się w krótkiej notatce: co zostało zmienione, w jakiej kolejności i z jakim skutkiem. Ta notatka będzie planem prac na działającej stronie.

Na kopii testowej można bez obaw włączyć zapis błędów do pliku, czego na działającej stronie należy unikać dłużej niż to konieczne. Błędy, których nie widać na ekranie, często ujawniają się właśnie tam. Sposób włączenia i odczytania takiego pliku opisałem we wpisie o tym, jak włączyć tryb debugowania WordPressa.

Kopia jest też właściwym miejscem na sprawdzenie nowej wersji PHP, o ile hosting pozwala ustawić ją osobno dla subdomeny lub katalogu. Jeśli wersję da się zmienić tylko dla całego konta, test na kopii w tym samym koncie nie oddzieli jej od strony głównej. Szczegóły opisałem we wpisie o tym, jak przetestować zmianę wersji PHP przed przełączeniem.

Jak przenieść sprawdzone zmiany na działającą stronę?

To moment, w którym najłatwiej o stratę danych, dlatego najpierw trzeba zrozumieć, na czym polega ryzyko. Od chwili utworzenia kopii strona główna żyje dalej: przychodzą zamówienia, komentarze, zgłoszenia z formularzy, rejestrują się klienci. Te dane są w bazie strony głównej, a w bazie kopii ich nie ma.

Jeśli cała baza kopii zostanie wgrana w miejsce bazy strony głównej, wszystko, co pojawiło się w międzyczasie, przepadnie. Dotyczy to zarówno ręcznego importu, jak i narzędzi przenoszących zmiany jednym poleceniem, jeżeli zaznaczone zostanie przenoszenie całej bazy. W sklepach i serwisach z kontami użytkowników uważam taką operację za zbyt ryzykowną.

Bezpieczna droga: powtórzenie zmian według notatki

Przy aktualizacjach wtyczek, motywu, WordPressa i wersji PHP najbezpieczniej jest powtórzyć na stronie głównej te same czynności, które zostały sprawdzone na kopii, w tej samej kolejności. Przed rozpoczęciem wykonuje się świeżą kopię zapasową, a prace planuje na porę najmniejszego ruchu. Po każdej czynności należy otworzyć stronę i przejść po liście kontrolnej.

Przenoszenie narzędziem hostingu lub wtyczki

Jeśli zmiany są rozległe, na przykład przebudowany został układ wielu podstron, ręczne powtarzanie bywa niewykonalne. Wtedy korzysta się z funkcji przenoszenia w narzędziu hostingu albo w płatnej wersji wtyczki. Tam, gdzie narzędzie pozwala wybrać zakres, przenosi się pliki oraz tylko te tabele bazy, których dotyczyła zmiana, a tabele z zamówieniami, użytkownikami i komentarzami pozostawia nietknięte. Gdy nie ma pewności, które tabele są bezpieczne, decyzję należy skonsultować z osobą znającą bazę WordPressa.

Po przeniesieniu trzeba od razu sprawdzić trzy rzeczy na stronie głównej: czy w zakładce „Czytanie” pole dotyczące wyszukiwarek jest odznaczone, czy w pliku wp-config.php nie pozostał wiersz z wartością staging oraz czy w treści nie ma linków prowadzących do adresu kopii.

Co zrobić, gdy kopia nie działa poprawnie?

Większość problemów z kopią testową ma kilka powtarzalnych przyczyn. Poniżej opisuję te, które spotykam najczęściej, wraz ze sposobem ustalenia przyczyny.

Adres kopii przenosi na stronę główną

Oznacza to, że w bazie kopii nadal zapisany jest adres strony głównej. Należy sprawdzić, czy w pliku wp-config.php kopii znajdują się wiersze WP_HOME i WP_SITEURL z adresem kopii i czy plik .htaccess nie zawiera przekierowania na domenę główną. Pomaga też otwarcie adresu w oknie prywatnym, ponieważ przeglądarka zapamiętuje wcześniejsze przekierowania.

Strona główna kopii działa, a podstrony zwracają błąd 404

Przyczyną są reguły adresów, które nie zostały odtworzone dla nowego miejsca. Na kopii należy otworzyć „Ustawienia”, zakładkę „Bezpośrednie odnośniki”, i kliknąć „Zapisz zmiany”. Jeśli kopia stoi w podkatalogu, warto też sprawdzić, czy plik .htaccess w tym podkatalogu istnieje i czy serwer ma prawo go zapisać.

Kopia wyświetla się bez stylów albo bez obrazków

Zwykle część adresów w bazie nadal wskazuje stronę główną albo adres bez https. Rozwiązaniem jest zamiana adresów w całej bazie narzędziem opisanym wcześniej oraz wyczyszczenie pamięci podręcznej. Kreatory stron przechowują własne pliki stylów, które po zmianie adresu trzeba wygenerować ponownie funkcją dostępną w ich ustawieniach.

Klonowanie zatrzymuje się w połowie

Najczęstsze powody to brak wolnego miejsca na koncie oraz limity czasu i pamięci serwera. Należy sprawdzić zajętość konta, wykluczyć z kopiowania katalogi z archiwami i dużymi plikami, a w razie potrzeby poprosić hosting o informację, jaki limit został przekroczony. Przy bardzo dużych stronach pewniejsza jest kopia ręczna albo narzędzie hostingu.

Nie można zalogować się do kopii

Logowanie odbywa się danymi ze strony głównej z chwili utworzenia kopii, więc hasło zmienione później na kopii nie zadziała. Problem powodują też wtyczki zabezpieczające oraz wtyczki ukrywające adres logowania. Autorzy WP STAGING zalecają w takim przypadku aktualizację wtyczki do najnowszej wersji, a gdy to nie pomaga, wyłączenie w jej ustawieniach dodatkowego uwierzytelniania kopii.

Jakich błędów unikać przy pracy z kopią testową?

Pierwszy błąd to pozostawienie kopii bez opieki. Zapomniana kopia nie jest aktualizowana, a mimo to działa na serwerze i ma te same konta administratorów co strona główna. Luka w nieaktualnej wtyczce na kopii daje dostęp do tego samego konta hostingowego. Kopię, która nie jest już potrzebna, należy usunąć razem z jej bazą lub tabelami, najlepiej tym samym narzędziem, którym została utworzona.

Drugi błąd to praca na nie tej stronie. Przy dwóch otwartych kartach z identycznym kokpitem pomyłka jest kwestią czasu. Pomaga pomarańczowy pasek we wtyczce, inna nazwa witryny wpisana na kopii w ustawieniach ogólnych, na przykład z dopiskiem TEST, oraz otwieranie kopii w innej przeglądarce niż strona główna.

Trzeci błąd to umieszczanie na kopii danych klientów bez zastanowienia. Kopia zawiera dane osobowe z zamówień i formularzy, więc podlega tym samym obowiązkom ochrony danych co strona główna. Hasło na serwerze, ograniczona liczba osób z dostępem i usunięcie kopii po zakończeniu prac to w tym przypadku minimum. Dostępu do kopii nie powinno się przekazywać wykonawcy bez uregulowania z nim zasad przetwarzania tych danych.

Najczęstsze pytania

Czy kopia testowa może zaszkodzić pozycjom strony w Google?

Kopia zabezpieczona hasłem na serwerze nie jest dostępna dla robotów, więc nie wpływa na widoczność strony głównej. Kłopot pojawia się wtedy, gdy kopia jest otwarta i trafia do indeksu jako duplikat albo gdy ustawienie zniechęcające wyszukiwarki zostanie przeniesione z kopii na działającą stronę. Oba przypadki da się wykluczyć, stosując zabezpieczenia opisane wyżej i sprawdzając zakładkę „Czytanie” po każdym wdrożeniu.

Subdomena czy podkatalog: gdzie lepiej umieścić kopię?

Dla samego testowania nie ma to większego znaczenia. Podkatalog jest prostszy i tak działa podstawowa wersja WP STAGING. Subdomena z osobną bazą danych lepiej oddziela kopię od strony głównej i jest wygodniejsza, gdy kopia ma istnieć dłużej. Przy kopii ręcznej radzę wybierać subdomenę.

Jak długo można trzymać kopię testową?

Tak długo, jak trwają prace, i nie dłużej. Kopia starzeje się z każdym dniem, bo strona główna się zmienia, a jednocześnie wymaga tych samych aktualizacji bezpieczeństwa co oryginał. Po zakończeniu prac najlepiej ją usunąć, a przed kolejnymi utworzyć nową.

Czy do utworzenia kopii potrzebny jest programista?

Przy narzędziu hostingu i przy wtyczce nie. Obie drogi sprowadzają się do kilku kliknięć i ustawienia zabezpieczeń. Kopia ręczna wymaga swobodnego poruszania się po panelu hostingu, pliku wp-config.php i bazie danych, więc osobie bez takiego doświadczenia radzę wybrać jedną z dwóch pierwszych dróg.

Co zrobić, gdy na hostingu brakuje miejsca na kopię?

Najpierw należy usunąć z konta stare archiwa kopii zapasowych i nieużywane pliki, bo to one zajmują zwykle najwięcej miejsca. Jeśli to nie wystarczy, przy klonowaniu można pominąć katalog z plikami multimedialnymi, godząc się na brak części obrazków na kopii. Trzecia możliwość to większy pakiet hostingowy.

Czy zmiany treści wprowadzone na kopii pojawią się na stronie głównej?

Nie, o ile kopia ma własną bazę danych lub własne tabele. Wpis napisany na kopii pozostaje na kopii. Dlatego treści, które mają zostać opublikowane, najlepiej przygotowywać od razu na stronie głównej jako szkice, a kopię traktować jako miejsce do sprawdzania zmian technicznych i wyglądu.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Utworzenie kopii testowej nie jest trudne, ale wymaga spokoju, dostępu do kilku paneli i pewności, że żadna czynność nie dotknie strony, z której na co dzień korzystają klienci. Jeśli wygodniej jest to komuś powierzyć, chętnie się tym zajmę. Dobiorę sposób do hostingu i wielkości witryny, wykonam kopię zapasową, utworzę kopię testową, zabezpieczę ją hasłem i przed wyszukiwarkami, wyłączę na niej wysyłkę wiadomości i płatności, a potem sprawdzę zaplanowane zmiany i wdrożę je na działającej stronie tak, żeby nie przepadło żadne zamówienie ani zapytanie.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i krótko opisać, jaka zmiana jest planowana. Odpowiem, od czego zacząć i ile to potrwa.