Klonowanie strony WordPress: co kopia zachowuje, a co się psuje

Po co budować stronę WordPress pod kopiowanie?

Klient prowadzi lokalne strony pozyskujące zapytania, każda pod inny rodzaj usługi. Wszystkie robią to samo: opisują usługę, pokazują telefon, zbierają zgłoszenie. Różnią się nazwą, kolorami, danymi kontaktowymi i treścią. Każdą można budować osobno, tylko że wtedy dwudziesta strona kosztuje tyle samo co pierwsza.

Zlecenie objęło więc najpierw stronę-wzorzec, a w kolejnym etapie skrypt, który ją klonuje. Od siebie dodałem skrypty, które wzorzec instalują i aktualizują. Od takiej strony wymaga się więcej niż od zwykłej: ma dalej działać, kiedy ktoś ją skopiuje i zmieni dane firmy, a dobry wygląd w dniu oddania to łatwiejsza część.

Jak skopiować całą stronę WordPress, żeby niczego nie zgubiła?

Skopiować ją razem z bazą danych. Tak działają narzędzia do klonowania w panelach hostingu i wtyczki do migracji; Duplicator na przykład pakuje pliki strony i bazę do jednego pliku. Formularz na stronie, menu w nagłówku i zdjęcie w bloku wskazują w WordPressie na inne rekordy przez numer. Kopia bazy przenosi wszystkie te numery bez zmian, więc każde odwołanie dalej trafia tam, gdzie trzeba.

Zanim oddałem stronę-wzorzec, sprawdziłem to na niej, zamiast zakładać. Skopiowałem jej bazę i wgrane pliki do drugiego, pustego WordPressa pod innym adresem, doinstalowałem ten sam motyw i wtyczki, a stary adres podmieniłem w całej bazie. Kopia miała wszystkie 28 klas globalnych GenerateBlocks, w których zapisany jest wygląd (tyle ich wtedy było), a obliczone style nie różniły się od oryginału ani w jednym miejscu. Formularz wyświetlił się ze wszystkimi polami, dane firmy były w danych strukturalnych, a starego adresu nie było nigdzie w kodzie strony.

Ten test ma dwa ograniczenia. Kopię zrobiłem sam, na drugim WordPressie, a nie narzędziem do klonowania w panelu hostingu klienta, choć mechanizm jest ten sam: pliki i baza pod nowym adresem. Poza tym zrobiłem go, zanim powstały menu w nagłówku i zdjęcia na kafelkach, więc dla tych dwóch rzeczy argument jest w następnej sekcji.

Kiedy numery rekordów z bazy przestają działać?

Kiedy stronę się odbudowuje, a nie kopiuje. Strona-wzorzec jest zapisana w plikach motywu: każdą jej sekcję opisuje wzorzec bloków, a skrypt instaluje te wzorce w pustym WordPressie. Nowa instalacja to nowa baza, która numeruje wszystko od początku.

Wyszło to przy pierwszej instalacji. Wzorzec bloków sekcji z formularzem trzymał formularz jako "formId":28, bo taki numer formularz dostał w mojej lokalnej bazie. Na serwerze klienta ten sam formularz był wpisem numer 6. GenerateBlocks Pro osadza formularz właśnie po numerze, więc wzorzec w tej postaci pokazałby formularz na jednej maszynie, mojej, a wszędzie indziej nic.

Dlatego w motywie i jego wzorcach bloków nie ma żadnego numeru wymyślonego przez bazę. Formularz odnajduje się po slugu, czyli po stałej nazwie, w chwili składania strony. Menu w nagłówku też jest odczytywane po slugu, a skrypt aktualizacji zakłada to menu, jeśli go nie ma. Zdjęcie zastępcze na kafelkach usług to plik motywu, a nie wgrany obraz, bo numer wgranego obrazu należy do bazy, do której go wgrano. Przeszukanie motywu nie znajduje ani jednego takiego numeru. Skopiowana strona poradziłaby sobie bez szukania po slugu i bez zdjęcia w motywie, formularz straciłaby dopiero strona odbudowana z motywu.

Co ma się różnić między kopiami?

Wszystko, co różni strony, jest w jednym miejscu w Customizerze: nazwa firmy, logo, kolor marki, telefon, e-mail i adres. To sześć rzeczy do ustalenia, wpisywanych w dziewięć pól, i nic poza tym nie trzeba ruszać po skopiowaniu strony.

Adres zajmuje cztery z tych dziewięciu pól, celowo. Google chce adresu firmy w rozbiciu na składniki, a nie jako jednej linijki dowolnego tekstu. Jedno pole trzeba by potem rozbijać na oko, a pierwszy adres wpisany w nieoczekiwanej postaci bez żadnego ostrzeżenia dałby błędne dane strukturalne na stronie, której cały sens to lokalne wyniki wyszukiwania. Widoczna linijka w stopce składa się z tych samych czterech części, więc to, co czyta gość, i to, co czyta Google, nie mogą się rozjechać.

Czy wszystkie kopie mają wyglądać tak samo?

Radziłem trzymać wygląd w kodzie motywu, gdzie da się go wersjonować i gdzie pięćdziesiąt stron nie rozjedzie się z czasem. Klient powiedział nie i w tej samej wiadomości podał powód: te strony mają się od siebie różnić, a nie być identyczne. To nie są oddziały jednej sieci.

Miał rację, a ja odpowiadałem na pytanie, którego nie zadał. Jednakowe strony mają sens, kiedy sprzedaje się markę. Tutaj każda strona sama jest towarem i ma sprawiać wrażenie innej lokalnej firmy. Wygląd został więc w bazie jako klasy globalne, które da się zmieniać na każdej stronie osobno, a ja, zamiast pilnować, żeby strony się nie rozjechały, miałem sprawić, żeby rozjazd był tani.

Kopia testowa pokazała, co to znaczy w praktyce. Zmieniłem kolor marki i nazwę firmy tylko na kopii. Kopia zmieniła się wszędzie, gdzie ten kolor występuje, a oryginał obok został dokładnie taki, jaki był.

Jak aktualizować skopiowane strony, kiedy już działają?

Trzema skryptami. Pierwszy, instalator, robi z pustego WordPressa stronę-wzorzec. Drugi wdraża zmiany: przenosi motyw, usuwa pliki, które wypadły z repozytorium, uruchamia trzeci skrypt i czyści cache. Trzeci, migracja treści, zmienia to, co już stoi na stronach.

Każdy z nich można puścić drugi raz bez szkody. Instalator uruchomiony ponownie naprawia, zamiast dublować. Porównuje też to, co stoi na stronie, z tym, co sam by zapisał, przy różnicy odmawia i podaje, który skrypt puścić zamiast niego. To zabezpieczenie wzięło się z sytuacji, do której prawie doszło: kiedy pierwsza runda poprawek była gotowa, ponowne uruchomienie instalatora zastąpiłoby własny nagłówek klienta, jego tekst i dane firmy moimi przykładowymi. Klient sam edytuje swoje strony, więc każdy skrypt, który ich dotyka, musi zakładać, że jest tam jego tekst.

Migracja czyta bloki już stojące na stronie i zmienia tylko to, co musi, a sformułowania klienta zostawia w spokoju. Migracja ma test z ośmioma asercjami. Dwie z nich sprawdzają, że tekst klienta przechodzi słowo w słowo i że drugi przebieg zostawia kod HTML identyczny co do bajta.

Co sprawdzić po przeniesieniu kopii strony WordPress na inną domenę?

Pierwsza rzecz to cache strony. Na hostingu klienta zapisanie nazwy firmy w Customizerze od razu czyściło stronę zapisaną w cache. Zmiana tego samego pola z wiersza poleceń cache już nie czyściła: niezalogowany gość dalej dostawał starą nazwę. Skrypt, który wpisuje dane nowej strony, musi sam wyczyścić cache, bo inaczej nowa strona może pokazać pierwszym gościom dane strony, z której ją skopiowano.

Gdzie kończy się ten projekt?

Samo kopiowanie stron było drugim etapem i klient nigdy go nie opłacił. Nie zbudowałem skryptu do klonowania i ani razu nie użyłem narzędzia do klonowania w panelu hostingowym klienta. Pokazać mogę stronę-wzorzec, skrypty, które ją instalują i aktualizują, oraz kopię testową opisaną wyżej.

Nie ma tu więc żadnych liczb o działających stronach, ruchu ani pozycjach, bo żadnych nie mierzyłem.