Как упорядочить WordPress Многоузловая миграция с MU-миграции

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

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

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

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

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

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

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

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

Понимание вызовов

Различия между структурой одного сайта и multisite 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 сайтов в многоузловой экземпляр (или наоборот). Это по существу экспортирует все в пакет, который затем может быть использован для импорта сайта в желаемой установки WordPress.

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

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

Для того, чтобы использовать MU-Миграция, сначала необходимо установить 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-Миграция довольно проста. Для нашего первого сценария, мы собираемся переместить один сайт WordPress в WordPress многоузловой установки.

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

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

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

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

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

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

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

$ 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-Миграция переопределить подсайт с указанным 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; это создаст файл, готовый к импорту в другой мультисайт или на одном сайте. Команда для импорта в один сайт и мультисайт точно такой же, MU-Миграция будет обнаруживать, если он работает на мультисайте или нет, и будет приспосабливаться к этому автоматически. На стороне примечания, при импорте в другой многоузловой экземпляр, вы также можете указать --blog_id параметр для переопределения существующего подсайта.

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

Советы для запуска больших миграций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сделайте сухой запуск первый

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

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

Импортная команда также поддерживает --mysql-single-transaction флаг, который обернет экспорт S’L в единую транзакцию, чтобы сразу префиксировать все изменения от импорта, предотвращая запись от подавляющего сервера базы данных, особенно в кластерных средах MyS’L.

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

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

$ rsync -aP site.zip root@172.99.99.99:/var/www/multisite/

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

$ ssh root@172.99.99.99
$ cd /var/www/multisite
$ wp mu-migration import all site.zip

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

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

$ rsync -azP wp-content/uploads/ root@172.99.99.99:/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 и тянуть запросы приветствуются!