Как упростить многосайтовую миграцию WordPress с помощью MU-Migration

Миграция отдельного сайта WordPress в сетевую (или «многосайтовую») среду — утомительное и сложное занятие, верно и обратное. WordPress Importer работает достаточно хорошо для небольших и простых сайтов, но оставляет место для улучшений. Он экспортирует контент, но не данные конфигурации сайта, такие как конфигурации виджетов и настройщиков, плагины и настройки сайта. Импортер также с трудом справляется с большим объемом контента. В этой статье вы узнаете, как оптимизировать этот тип миграции с помощью MU-Migration, подключаемого модуля WP-CLI.

Понимание мультисайтов

Мультисайт WordPress позволяет запускать несколько веб-сайтов в рамках одной установки WordPress. Ее часто называют «многосайтовой сетью». WordPress.com, вероятно, является самым большим примером многосайтовой сети, в которой работают тысячи сайтов в одном и том же экземпляре WordPress.

Мультисайт WordPress может идеально подходить для нескольких вариантов использования, некоторые из них включают в себя:

• У вашего клиента может быть несколько свойств, и может иметь смысл объединить все его сайты в уникальную установку WordPress, используя один домен, но не ограничиваясь им.

• После того, как вы настроите его, вы сможете легко и просто запускать новые сайты и использовать темы и плагины, уже доступные в сети.

Глубокое понимание того, как работает мультисайт, выходит за рамки этой статьи, но вы можете ознакомиться со следующими ссылками:

• «Создайте сеть», Кодекс, WordPress.org

• «Мультисайт WordPress: практические функции и методы», Кевин Лири, Smashing Magazine

Понимание проблем

Различия между структурой одного сайта и мультисайта WordPress вполне разумны. При использовании нескольких сайтов каждый дочерний сайт получает свой собственный набор таблиц базы данных, за исключением пользовательской таблицы ( wp_user ), которая является общей для всех сайтов. В WordPress это работает так: каждый набор таблиц дочернего сайта имеет идентификатор сайта, добавленный к имени каждой таблицы ( wp_X_posts , wp_X_postmeta , wp_X_options ).

Сама эта структура базы данных уже вносит некоторые сложности. Например, как бы вы перенесли дочерний сайт с мультисайта на одиночную установку? Очевидно, вы не можете просто экспортировать и импортировать базу данных в одну установку — имена таблиц разные! Вам потребуется либо переименовать таблицы в экспортированном файле .sql , либо использовать ALTER TABLE SQL для переименования таблиц после их импорта. То же самое верно и для обратного способа: если вы импортируете один сайт в мультисайт, префиксы таблиц также должны быть обновлены. Звучит как слишком много работы, не так ли?

Таблица пользователя в мультисайте является глобальной, а это означает, что вы не можете просто импортировать таблицу пользователя с вашего единственного сайта, поскольку она полностью переопределит глобальную таблицу пользователя мультисайта. Если вы делаете обратное, извлекая дочерний сайт из WordPress и импортируя его на один сайт, вы переносите всех пользователей сети, даже тех, которые не принадлежат переносимому дочернему сайту. Кроме того, при переносе дочернего сайта с одного мультисайта на другой экспорт пользовательской таблицы полностью исключается.

Лучшее решение — экспортировать пользователей по отдельности, но это создает другую проблему: когда пользователи импортируются, они получают разные идентификаторы. Чтобы решить эту проблему, необходимо отслеживать идентификаторы новых пользователей, создавать таблицу сопоставления и использовать таблицу сопоставления для обновления всех ссылок на идентификаторы пользователей в WordPress! Опять же, слишком много работы, не так ли?

Это всего лишь два примера проблем, с которыми можно столкнуться при работе с подобными миграциями. Есть множество других мелких вещей, о которых также необходимо позаботиться, например, перемещение папки загрузки в нужное место, перенос записей в базе данных, которые ссылаются на идентификатор сайта, и т. д.

Встречайте MU-миграцию

MU-Migration — это подключаемый модуль WP-CLI, который я создал, работая над миграцией нескольких клиентов, а позже открытый исходный код от 10up. Он был задуман для упрощения процесса перемещения сайтов с отдельных сайтов WordPress на многосайтовый экземпляр (или наоборот). По сути, он экспортирует все в ZIP-пакет, который затем можно использовать для импорта сайта в нужную установку WordPress.

Он работает путем экспорта содержимого сайта и, при необходимости, темы, плагинов и папок для загрузки в zip-пакет, который можно легко импортировать в другую установку WordPress. При использовании MU-Migration вам не нужно беспокоиться о базовых технических деталях миграции. Он просто позаботится обо всем этом за вас, чтобы вы могли сосредоточиться на том, что важно: обеспечить успешную миграцию для ваших клиентов.

Установка WP-CLI и MU-миграции

Чтобы использовать MU-Migration, вам сначала нужно установить WP-CLI, официальный инструмент командной строки WordPress. Установить WP-CLI так же просто, как запустить следующие команды на вашем сервере:

 $ 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

После выполнения этих шагов вы сможете запустить WP-CLI, набрав просто wp из любой установки WordPress, если вы находитесь в корневом каталоге WordPress.

Например, в папке установки WordPress попробуйте выполнить следующую команду:

 $ wp theme status

Это простая команда, которая выводит список всех доступных тем с выделением активной в данный момент.

Наконец, чтобы установить MU-Migration, вы можете использовать команду package install . Используйте следующую команду, чтобы загрузить и установить MU-Migration в качестве подключаемого модуля WP-CLI.

 $ wp package install 10up/mu-migration

Запуск простой миграции

Использовать MU-Migration довольно просто. Для нашего первого сценария мы собираемся переместить один сайт WordPress в многосайтовую установку WordPress.

Экспорт одного сайта

Начнем с экспорта одного сайта. Для этого нам нужно использовать команду export all :

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

Приведенная выше команда экспортирует весь сайт в ZIP-архив, флаги --themes , --plugins и --uploads являются необязательными и будут включать текущую тему, все плагины и папку загрузки соответственно в экспорт. В зависимости от размера вашего сайта завершение процесса может занять некоторое время, но для большинства сайтов процесс экспорта не должен занимать более пары минут.

По завершении он создаст файл с именем single-site.zip , содержащий все данные сайта, темы и плагины, а также каталог загрузки. Следующий шаг — переместить его на сервер, где находится мультисайт WordPress. Вы можете использовать предпочитаемый вами SFTP-клиент или более надежное решение, такое как rsync .

Импорт одного сайта в мультисайт

С экспортированным файлом на вашем многосайтовом сервере все, что вам нужно сделать, это использовать команду импорта из многосайтового каталога WordPress; Само собой разумеется, что и WP-CLI, и MU-Migration также должны быть установлены на целевом сервере.

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

Приведенная выше команда возьмет файл single-site.zip , извлечет его и импортирует все в мультисайт. Это создаст новый дочерний сайт в вашей сети. Параметр --new_url является необязательным; он даст указание MU-Migration выполнить поиск и замену, чтобы заменить все вхождения URL-адреса экспортированного сайта на указанный. Этот параметр удобен, когда миграция включает изменение URL-адреса или если вы импортируете локально или даже в промежуточной среде.

Процесс импорта обычно занимает больше времени и зависит от размера импортируемого сайта, но не бойтесь, MU-Migration будет держать вас в курсе по мере выполнения миграции. Когда процесс завершится, MU-Migration сообщит вам конечный URL вашего импортированного сайта. Настоятельно рекомендуется сбросить все слои кэша , которые работают на вашем сервере, особенно Memcache или Redis.

Повторный запуск миграции

При выполнении миграции довольно часто сначала выполняется пробный прогон с целью тестирования перед выполнением окончательной миграции, что обычно означает еще один экспорт и повторный импорт в целевую многосайтовую установку. Однако обратите внимание, что в нашем первом примере миграции MU-Migration создала новый дочерний сайт в сети, чтобы импортировать один сайт поверх него. Повторный запуск той же самой команды приведет к созданию еще одного дочернего сайта, что не совсем то, чего мы ожидаем.

К счастью, можно указать blog_id , который указывает MU-Migration переопределить дочерний сайт с указанным blog_id . Например, предположим, что предыдущая команда импорта создала дочерний сайт с 2 в качестве идентификатора, и вы хотите повторно запустить миграцию. Вы можете сделать следующее:

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

Если вы не знаете blog_id , вы можете получить его через настройки администратора сети или запустив $ wp site list .

Извлечение подсайта из мультисайтовой установки

MU-Migration также поддерживает извлечение дочерних сайтов из мультисайтовых установок и их импорт на другой мультисайт или на один сайт.

Для этих двух сценариев мы запустим команду экспорта из мультисайтовой установки, а не из одного сайта; это означает, что нам нужен способ указать, какой дочерний сайт мы хотим экспортировать. Для этого нам просто нужно передать параметр --blog_id в команду экспорта:

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

В этом примере мы экспортируем дочерний сайт с идентификатором, равным 3; это создаст ZIP-файл, который можно импортировать на другой мультисайт или на один сайт. Команда для импорта на один сайт и на мультисайт точно такая же, MU-Migration определит, работает ли он на мультисайте или нет, и автоматически приспособится к этому. Кстати, при импорте в другой многосайтовый экземпляр вы также можете указать параметр --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= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ]

Советы по выполнению больших миграций

В то время как предыдущие примеры очень хорошо работают для миграции малого и среднего размера, миграция больших сайтов в многосайтовую среду или из нее может занять разумное время. В этом разделе я поделюсь некоторыми уроками, полученными при выполнении нескольких корпоративных миграций.

Создайте план миграции

Миграция данных часто необходима, но во многих проектах ею пренебрегают. Миграции могут быть громоздкими и сложными, но при правильном планировании они могут быть безболезненными. Создание плана миграции должно быть первым шагом любого проекта миграции.

Типичный план миграции включает в себя такие вещи, как:

• Влияние миграции на любые производственные редакционные процессы (т. е. зависание контента, различные требования к миграции).

• Как долго ожидается миграция?

• Как будут восстанавливаться резервные копии? Как будет обрабатываться неудачная миграция?

• Как процесс экспорта повлияет на производительность сайта? Многие сайты не могут позволить себе экспорт базы данных в часы пик.

Как правило, миграция должна быть как можно более плавной, и в идеале в день запуска вся тяжелая работа уже была бы завершена, и должны быть выполнены только те шаги, которые строго необходимы. Это означает, что вы должны перенести все, что можете, до фактической даты запуска, поскольку это даст вам возможность исправить ошибки и провести контроль качества. Если это новая сборка сайта и вы переносите данные, вы часто можете извлечь выгоду из окна заморозки контента и заблаговременно перенести свой контент. Вы также можете использовать стратегии для постепенного перемещения вашего контента, если это возможно. В следующем разделе вы найдете пример этой техники.

Несмотря на то, что надлежащий план миграции часто игнорировался, он может избежать множества проблем при миграции. Не позволяйте непредвиденным обстоятельствам привести к сбою миграции, планируйте заранее! Для более подробного обсуждения планирования миграции я рекомендую вам ознакомиться с разделом о миграции лучших практик 10up.

Используйте Rsync для постепенного копирования загрузок

Папка загрузки больших сайтов может быть очень большой, и сжатие ее в ZIP-файл для последующего извлечения — не всегда лучшее и быстрое решение. Есть несколько других способов скопировать папку загрузки на целевой сервер. Обычно используемым инструментом для корпоративной миграции является rsync , который может передавать файлы между серверами быстрее, чем при использовании стандартного решения SFTP, и, кроме того, он может приостанавливать и восстанавливать передачу. Он отслеживает то, что уже было передано, а это означает, что мы можем постепенно синхронизировать наши файлы. Например, вы можете начать синхронизацию файлов за пару дней до фактической миграции, чтобы выиграть время. Затем, в день миграции, все, что вам нужно сделать, это синхронизировать файлы, чтобы убедиться, что все, что было добавлено с момента последней синхронизации, перенесено на целевой сервер.

Единственная оговорка этого подхода заключается в том, что вам нужно будет вручную переместить подкаталоги загрузок в нужное место, так как мультисайт имеет немного другую структуру для папки загрузок: каждый сайт получает свою собственную подпапку, где ее имя является идентификатором сайта. .

В качестве последнего примера давайте посмотрим, как мы можем перенести один большой сайт в экземпляр с несколькими сайтами. Мы начнем с экспорта одного сайта в ZIP-архив и выполнения пробного теста на целевом сервере. В этот момент сайт не будет доступен никому, поскольку домен все еще указывает на старый сервер, а это означает, что вы можете безопасно указать файл вашего хоста на новый сервер, чтобы протестировать миграцию. Вы также можете включить такой плагин, как «Ограничение доступа к сайту», на целевом сайте, чтобы гарантировать, что он никоим образом не будет общедоступным.

Для нашего пробного теста мы экспортировали сайт за несколько дней или недель до запланированной даты миграции, чтобы протестировать и понять, сколько времени займет процесс. Обратите внимание, что папка загрузки не включена.

Сначала сделайте пробный прогон

Всегда сначала делайте пробный прогон. В идеале пробный запуск должен происходить на реальном сервере или в промежуточной среде с аналогичным серверным стеком.

Рассмотрите возможность использования --mysql-single-transaction

Команда import также поддерживает --mysql-single-transaction , который объединяет экспорт SQL в единую транзакцию, чтобы сразу зафиксировать все изменения из импорта, предотвращая перегрузку сервера базы данных записью, особенно в кластерных средах MySQL.

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

С помощью rsync мы можем легко передать сгенерированный экспортированный файл:

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

Затем мы запускаем команду импорта на целевом сервере:

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

Теперь нам нужно знать, что такое blog_id только что созданного дочернего сайта; мы можем получить эту информацию, запустив:

Из вывода приведенной выше команды мы знаем, что наш сайт был импортирован с идентификатором 2. Нам понадобится это, чтобы правильно переместить папку загрузки с помощью rsync . С сервера одного сайта мы запустим следующее:

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

Приведенная выше команда скопирует всю папку загрузки в нужное место при многосайтовой установке, которая находится в папке сайтов и внутри папки, имя которой является просто идентификатором сайта (в данном случае 2). Теперь мы можем отредактировать файл хоста, чтобы указать домен одного сайта на многосайтовый сервер; затем мы можем провести некоторое тестирование, чтобы убедиться, что миграция работает должным образом.

Для окончательной миграции все будет точно так же, за исключением того, что мы будем передавать --blog_id=2 в команду импорта:

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

И в качестве преимущества синхронизация загрузки будет происходить намного быстрее, поскольку rsync будет передавать только те файлы, которые были изменены или добавлены с момента последней синхронизации.

Заключение

Миграция на многосайтовую среду или с нее сложна, и инструмент, представленный в этой статье, упрощает весь процесс миграции, сводя усилия к паре команд CLI. MU-Migration уже более года активно используется в продакшене и является проектом с полностью открытым исходным кодом. Плагин разработан на Github, и запросы на включение приветствуются!