Jak usprawnić migracje wielostanowiskowe WordPress za pomocą MU-Migration

Migracja samodzielnej witryny WordPress do środowiska sieci witryn (lub środowiska „wielostronnego”) jest żmudnym i trudnym przedsięwzięciem, ale jest również odwrotnie. Importer WordPressa działa dość dobrze w przypadku mniejszych, prostszych witryn, ale pozostawia miejsce na ulepszenia. Eksportuje zawartość, ale nie dane konfiguracji witryny, takie jak konfiguracje widżetów i dostosowywania, wtyczki i ustawienia witryny. Importer ma również problemy z obsługą dużej ilości treści. W tym artykule dowiesz się, jak usprawnić tego typu migrację za pomocą MU-Migration, wtyczki WP-CLI.

Zrozumienie wielu witryn

Multisite WordPress umożliwia uruchamianie wielu witryn w ramach tej samej instalacji WordPress. Jest często określany jako „sieć wielostanowiskowa”. WordPress.com jest prawdopodobnie największym przykładem sieci wielostanowiskowej, obsługującej tysiące witryn w ramach tej samej instancji WordPress.

Multisite WordPress może być idealnym rozwiązaniem dla kilku przypadków użycia, niektóre z nich obejmują:

• Twój klient może mieć wiele właściwości i sensowne może być skonsolidowanie wszystkich jego witryn w unikalną instalację WordPress, współdzielącą jedną domenę, ale nie ograniczając się do niej.

• Po skonfigurowaniu jest to prosty i nieskomplikowany proces uruchamiania nowych witryn i wykorzystywania motywów i wtyczek już dostępnych w sieci

Dogłębne zrozumienie działania wielu witryn wykracza poza zakres tego artykułu, ale możesz sprawdzić następujące linki:

• „Stwórz sieć”, Kodeks, WordPress.org

• „WordPress Multisite: praktyczne funkcje i metody”, Kevin Leary, Smashing Magazine

Zrozumienie wyzwań

Różnice między strukturą pojedynczej witryny a wielowitrynowej WordPress są całkiem rozsądne. W przypadku wielu witryn każda podwitryna otrzymuje własny zestaw tabel bazy danych, z wyjątkiem tabeli użytkownika ( wp_user ), która jest współużytkowana we wszystkich witrynach. Sposób, w jaki działa to w WordPressie, polega na tym, że każdy zestaw tabel podwitryn ma identyfikator witryny dodany do nazwy każdej tabeli ( wp_X_posts , wp_X_postmeta , wp_X_options ).

Już sama struktura bazy danych wprowadza pewne komplikacje. Na przykład, jak przeprowadzić migrację podwitryny z wielu witryn do pojedynczej instalacji? Oczywiście nie można po prostu wyeksportować i zaimportować bazy danych do pojedynczej instalacji — nazwy tabel są różne! Musisz albo zmienić nazwy tabel w wyeksportowanym pliku .sql , albo użyć zapytania ALTER TABLE SQL , aby zmienić nazwy tabel po ich zaimportowaniu. To samo dotyczy odwrotnego sposobu: jeśli importujesz pojedynczą witrynę do wielu witryn, przedrostki tabel również będą musiały zostać zaktualizowane. Brzmi jak za dużo pracy, prawda?

Tabela użytkownika w multisite jest globalna, co oznacza, że ​​nie możesz po prostu zaimportować tabeli użytkownika z Twojej pojedynczej witryny, ponieważ całkowicie zastąpiłoby to globalną tabelę użytkownika multisite. Jeśli robisz odwrotnie, wyodrębniając podwitrynę z WordPressa i importując do jednej witryny, przeniesiesz wszystkich użytkowników sieci, nawet tych, którzy nie należą do migrowanej podwitryny. Ponadto w przypadku migracji podwitryny z jednej witryny wielowitrynowej do innej eksportowanie tabeli użytkownika jest całkowicie poza tabelą.

Najlepszym rozwiązaniem jest wyeksportowanie użytkowników osobno, ale pojawia się inny problem: po zaimportowaniu użytkowników otrzymają różne identyfikatory. Aby rozwiązać ten problem, konieczne jest śledzenie identyfikatorów nowego użytkownika, utworzenie tabeli mapowania i użycie tabeli mapowania do aktualizacji wszystkich odwołań do identyfikatorów użytkowników w WordPress! Znowu za dużo pracy, prawda?

To tylko dwa przykłady wyzwań, z którymi można się zmierzyć, mając do czynienia z takimi migracjami. Jest kilka innych drobnych rzeczy, którymi również należy się zająć, takich jak przeniesienie folderu przesłanego do właściwej lokalizacji, migracja rekordów w bazie danych, które odwołują się do identyfikatora witryny itp.

Poznaj MU-Migration

MU-Migration to wtyczka WP-CLI, którą stworzyłem podczas pracy nad kilkoma migracjami klientów, a później udostępniłem ją jako open source przez 10up. Został pomyślany w celu usprawnienia procesu przenoszenia witryn z pojedynczych witryn WordPress do instancji wielostanowiskowej (lub odwrotnie). Zasadniczo eksportuje wszystko do pakietu ZIP, którego można następnie użyć do zaimportowania witryny w żądanej instalacji WordPress.

Działa poprzez eksportowanie zawartości witryny i opcjonalnie motywu, wtyczek i przesyłanie folderów do pakietu zip, który można łatwo zaimportować do innej instalacji WordPress. Korzystając z MU-Migration, nie musisz martwić się o podstawowe szczegóły techniczne migracji. Po prostu zajmie się tym wszystkim za Ciebie, dzięki czemu możesz skupić się na tym, co ważne: zapewnieniu pomyślnej migracji swoim klientom.

Instalowanie WP-CLI i MU-Migration

Aby korzystać z MU-Migration, musisz najpierw zainstalować WP-CLI, oficjalne narzędzie wiersza poleceń WordPress. Instalacja WP-CLI jest tak prosta, jak uruchomienie poniższych poleceń na serwerze:

 $ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar $ chmod +x wp-cli.phar $ sudo mv wp-cli.phar /usr/local/bin/wp

Po wykonaniu tych kroków będziesz mógł uruchomić WP-CLI, wpisując po prostu wp z dowolnej instalacji WordPress, o ile jesteś w katalogu głównym WordPress.

Na przykład w folderze instalacyjnym WordPressa spróbuj uruchomić następujące polecenie:

 $ wp theme status

Jest to proste polecenie i wyświetla listę wszystkich dostępnych motywów, podświetlając, który z nich jest aktualnie aktywny.

Wreszcie, aby zainstalować MU-Migration, możesz użyć polecenia package install . Użyj następującego polecenia, aby pobrać i zainstalować MU-Migration jako wtyczkę WP-CLI.

 $ wp package install 10up/mu-migration

Prowadzenie prostej migracji

Korzystanie z MU-Migration jest dość proste. W naszym pierwszym scenariuszu zamierzamy przenieść pojedynczą witrynę WordPress do instalacji wielostanowiskowej WordPress.

Eksportowanie pojedynczej witryny

Zaczniemy od wyeksportowania jednej witryny. W tym celu musimy użyć polecenia export all :

 $ wp mu-migration export all single-site.zip --themes --plugins --uploads

Powyższe polecenie wyeksportuje całą witrynę do pakietu ZIP, flagi --themes , --plugins i --uploads są opcjonalne i będą zawierać w eksporcie odpowiednio bieżący motyw, wszystkie wtyczki i folder przesyłania. W zależności od rozmiaru witryny zakończenie procesu może zająć trochę czasu, ale w przypadku większości witryn proces eksportu nie powinien zająć więcej niż kilka minut.

Po zakończeniu utworzy plik o nazwie single-site.zip zawierający wszystkie dane witryny, motywy i wtyczki, a także katalog przesyłania. Następnym krokiem jest przeniesienie go na serwer, na którym mieszka WordPress multisite. Możesz użyć preferowanego klienta SFTP lub bardziej niezawodnego rozwiązania, takiego jak rsync .

Importowanie pojedynczej witryny do wielu witryn

Gdy wyeksportowany plik znajduje się na serwerze wielostanowiskowym, wystarczy użyć polecenia importu z katalogu wielostanowiskowego WordPress; nie trzeba dodawać, że zarówno WP-CLI, jak i MU-Migration muszą być również zainstalowane na serwerze docelowym.

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site

Powyższe polecenie pobierze plik single-site.zip , rozpakuje go i zaimportuje wszystko do wielu witryn. Utworzy nową podstronę w Twojej sieci. Parametr --new_url jest opcjonalny; poinstruuje MU-Migration wykonanie wyszukiwania i zamiany w celu zastąpienia wszystkich wystąpień adresu URL wyeksportowanej witryny na określony. Ten parametr jest przydatny, gdy migracja obejmuje zmianę adresu URL lub jeśli importujesz lokalnie, a nawet w środowisku przejściowym.

Proces importowania zwykle trwa dłużej i zależy od rozmiaru importowanej witryny, ale nie obawiaj się, MU-Migration będzie Cię informować na bieżąco w trakcie migracji. Po zakończeniu procesu MU-Migration poinformuje Cię o końcowym adresie URL zaimportowanej witryny. Zdecydowanie zaleca się opróżnienie wszystkich warstw pamięci podręcznej działających na serwerze, w szczególności Memcache lub Redis.

Ponowne uruchamianie migracji

Podczas wykonywania migracji dość często wykonuje się najpierw test na sucho w celu przetestowania rzeczy przed uruchomieniem ostatecznej migracji, co zwykle oznacza wykonanie kolejnego eksportu i ponownego importu w docelowej instalacji wielostanowiskowej. Należy jednak pamiętać, że w naszym pierwszym przykładzie migracji MU-Migration utworzył nową podwitrynę w sieci, aby zaimportować na nią pojedynczą witrynę. Ponowne uruchomienie dokładnie tego samego polecenia doprowadziłoby do powstania kolejnej podstrony, co nie jest dokładnie tym, czego byśmy się spodziewali.

Na szczęście możliwe jest określenie blog_id , który nakazuje MU-Migration nadpisanie podwitryny podanym blog_id . Załóżmy na przykład, że poprzednie polecenie importu utworzyło podwitrynę z 2 jako identyfikatorem i chcesz ponownie uruchomić migrację. Możesz wykonać następujące czynności:

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site --blog_id=2

Jeśli nie znasz identyfikatora blog_id , możesz go uzyskać przez Ustawienia administratora sieci lub uruchamiając $ wp site list .

Wyodrębnianie podstrony z instalacji wielostanowiskowej

MU-Migration obsługuje również wyodrębnianie podwitryn z instalacji wielostanowiskowych i importowanie ich do innej wielostanowiskowej lub do jednej witryny.

W tych dwóch scenariuszach uruchomilibyśmy polecenie eksportu z instalacji wielostanowiskowej, a nie z pojedynczej lokacji; oznacza to, że potrzebujemy sposobu na określenie, którą podwitrynę chcemy wyeksportować. W tym celu wystarczy przekazać parametr --blog_id do polecenia export:

 $ wp mu-migration export all subsite-3.zip --themes --plugins --uploads --blog_id=3

W tym przykładzie eksportujemy podwitrynę o identyfikatorze równym 3; spowoduje to utworzenie pliku ZIP, który jest gotowy do zaimportowania do innej witryny wielostanowiskowej lub do jednej witryny. Polecenie importowania do jednej witryny i wielu witryn jest dokładnie takie samo, MU-Migration wykryje, czy działa na wielu witrynach, czy nie i dostosuje się do tego automatycznie. Na marginesie, podczas importowania do innego wystąpienia z wieloma witrynami można również określić parametr --blog_id , aby zastąpić istniejącą podwitrynę.

 $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ]

Wskazówki dotyczące przeprowadzania dużych migracji

Chociaż poprzednie przykłady działają bardzo dobrze w przypadku migracji małych i średnich rozmiarów, migracja dużych witryn do lub z wielu witryn może zająć rozsądną ilość czasu. W tej sekcji podzielę się kilkoma lekcjami wyciągniętymi podczas wykonywania kilku migracji typu korporacyjnego.

Utwórz plan migracji

Migracje danych są często konieczne, ale to zaniedbana część wielu projektów. Migracje mogą być uciążliwe i złożone, ale odpowiednio zaplanowane mogą być bezbolesne. Tworzenie planu migracji powinno być pierwszym krokiem każdego projektu migracji.

Typowy plan migracji obejmuje takie rzeczy jak:

• Wpływ migracji na dowolne procesy redakcji produkcyjnej (tj. zamrażanie treści, zróżnicowane wymagania dotyczące migracji).

• Jak długo ma trwać migracja?

• Jak zostaną przywrócone kopie zapasowe? Jak zostanie obsłużona nieudana migracja?

• Jak proces eksportu wpłynie na wydajność witryny? Wiele witryn nie może sobie pozwolić na eksport bazy danych w godzinach szczytu.

Zgodnie z ogólną zasadą migracje powinny przebiegać tak płynnie, jak to tylko możliwe, a najlepiej w dniu startu wszystkie ciężkie podnoszenie zostałyby już zakończone i należy wykonać tylko ściśle niezbędne kroki. Oznacza to, że należy przeprowadzić migrację wszystkiego, co się da, przed faktyczną datą uruchomienia, ponieważ zapewni to miejsce na naprawienie błędów i kontrolę jakości. Jeśli jest to nowa kompilacja witryny i migrujesz dane, często możesz skorzystać z okna zamrażania zawartości i przenieść zawartość z wyprzedzeniem. Jeśli to możliwe, możesz również użyć strategii do stopniowego przenoszenia treści. Sprawdź następną sekcję, aby zapoznać się z przykładem tej techniki.

Chociaż wielokrotnie zaniedbywany, odpowiedni plan migracji może uniknąć wielu różnych problemów związanych z migracją. Nie pozwól, aby nieoczekiwane okoliczności spowodowały niepowodzenie migracji, planuj z wyprzedzeniem! Aby uzyskać bardziej dogłębną dyskusję na temat planowania migracji, zachęcam do zapoznania się z sekcją dotyczącą migracji w najlepszych praktykach 10up.

Użyj Rsync do progresywnego kopiowania przesłanych plików

Folder przesyłania dużych witryn może być bardzo duży, a skompresowanie go do pliku ZIP w celu późniejszego rozpakowania nie zawsze jest najlepszym i najszybszym rozwiązaniem. Istnieje kilka innych sposobów kopiowania folderu przesyłania na serwer docelowy. Powszechnie używanym narzędziem do migracji typu korporacyjnego jest rsync , który może przesyłać pliki między serwerami szybciej niż przy użyciu standardowego rozwiązania SFTP, a ponadto może wstrzymywać i przywracać transfery. Śledzi to, co zostało już przesłane, co oznacza, że ​​możemy progresywnie synchronizować nasze pliki. Na przykład możesz rozpocząć synchronizację plików na kilka dni przed rzeczywistą migracją, aby zyskać trochę czasu. Następnie w dniu migracji wystarczy zsynchronizować pliki, aby upewnić się, że wszystko, co zostało dodane od ostatniej synchronizacji, zostanie przesłane na serwer docelowy.

Jedynym zastrzeżeniem tego podejścia jest to, że musisz ręcznie przenieść podkatalogi przesyłania we właściwe miejsce, ponieważ wiele witryn ma nieco inną strukturę folderu przesyłania: każda witryna otrzymuje własny podfolder, w którym jej nazwa jest identyfikatorem witryny .

Jako ostatni przykład zobaczmy, jak możemy przenieść dużą pojedynczą witrynę do instancji wielolokacyjnej. Zaczniemy od wyeksportowania pojedynczej witryny do pakietu ZIP i uruchomienia testu na serwerze docelowym. W tym momencie witryna nie byłaby dostępna dla nikogo, ponieważ domena nadal wskazuje na stary serwer, co oznacza, że ​​możesz bezpiecznie wskazać plik hosta na nowy serwer w celu przetestowania migracji. Możesz także włączyć wtyczkę, taką jak Ogranicz dostęp do witryny w witrynie docelowej, aby upewnić się, że nie jest ona w żaden sposób publicznie dostępna.

W naszym teście próbnym wyeksportowaliśmy witrynę na kilka dni lub tygodni przed planowaną datą migracji, aby przetestować i zorientować się, jak długo potrwa proces. Pamiętaj, że folder przesyłania nie jest uwzględniony.

Najpierw wykonaj suchy bieg

Zawsze najpierw wykonuj suchobieg. W idealnym przypadku próba uruchomienia powinna mieć miejsce na rzeczywistym serwerze lub w środowisku przejściowym z podobnym stosem serwerów.

Rozważ użycie --mysql-single-transaction

Polecenie import obsługuje również --mysql-single-transaction , która owija eksport SQL w jedną transakcję, aby jednocześnie zatwierdzić wszystkie zmiany z importu, zapobiegając przeciążeniu serwera bazy danych przez zapis, zwłaszcza w klastrowych środowiskach MySQL.

 $ cd /path/to/wordpress $ wp mu-migration export all site.zip --themes --plugins

Dzięki rsync możemy łatwo przenieść wygenerowany wyeksportowany plik:

 $ rsync -aP site.zip [email protected]:/var/www/multisite/

Następnie uruchamiamy polecenie importu na serwerze docelowym:

 $ ssh [email protected] $ cd /var/www/multisite $ wp mu-migration import all site.zip

Teraz musimy wiedzieć, jaki jest identyfikator blog_id nowo utworzonej podwitryny; możemy uzyskać te informacje, uruchamiając:

Z danych wyjściowych powyższego polecenia wiemy, że nasza witryna została zaimportowana z identyfikatorem 2. Będzie nam to potrzebne do prawidłowego przeniesienia folderu uploads za pomocą rsync . Z serwera z jedną lokacją uruchomilibyśmy:

 $ rsync -azP wp-content/uploads/ [email protected]:/var/www/multisite/wp-content/uploads/sites/2/

Powyższe polecenie skopiuje cały folder przesyłania we właściwe miejsce w instalacji wielostanowiskowej, która znajduje się pod folderem witryn i wewnątrz folderu, którego nazwa jest tylko identyfikatorem witryny (w tym przypadku 2). W tym momencie możemy teraz edytować plik hosta, aby skierować domenę pojedynczej witryny do serwera wielostanowiskowego; wtedy możemy przeprowadzić kilka testów, aby upewnić się, że migracja działała zgodnie z oczekiwaniami.

W przypadku ostatecznej migracji wszystko będzie takie samo, z wyjątkiem tego, że do polecenia importu --blog_id=2 :

 $ wp mu-migration import all site.zip --blog_id=2

A jako korzyść, synchronizacja przesyłania będzie przebiegać znacznie szybciej, ponieważ rsync przeniesie tylko te pliki, które zostały zmienione lub dodane od ostatniej synchronizacji.

Wniosek

Migracja do lub z wielu witryn jest trudna, a narzędzie przedstawione w tym artykule upraszcza cały proces migracji, zmniejszając wysiłek do kilku poleceń CLI. MU-Migration jest aktywnie wykorzystywany w produkcji od ponad roku i jest projektem całkowicie otwartym. Wtyczka jest rozwijana na Github i mile widziane pull requesty!