Оптимизация перехода к мультисайтам и обратно с помощью MU-Migration

Дата публикации:Февраль 18, 2018

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

Мультисайты: что представляют собой

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

Мультисайты хорошо подходят для разных ситуаций, среди которых:

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

Разбираемся в проблеме

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

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

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

Самое лучшее решение – отдельный экспорт пользователей, но это приводит к еще одной проблеме: пользователи после импорта получат другие ID. Чтобы решить эту проблему, надо отслеживать идентификаторы пользователей, создавать таблицу сопоставления и использовать ее для обновления всех ссылок на пользовательские ID в WordPress. Слишком много работы, верно?

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

Встречаем MU-Migration

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

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

Установка WP-CLI и MU-Migration

Чтобы использовать 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 вы можете выполнить следующую команду:

$ wp theme status

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

Наконец, чтобы установить MU-Migration, вы можете использовать команду package install:

$ wp package install 10up/mu-migration

Выполнение простой миграции

Использовать плагин MU-Migration довольно просто. В нашем первом сценарии мы внесем отдельный WordPress-сайт в сеть мультисайтов:

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

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

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

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

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

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

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

$ 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, который сообщит плагину о том, что необходимо переписать сайт с указанным blog_id. К примеру, предположим, что предыдущая команда импорта создала сайт с 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.

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

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

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

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

В данном примере мы экспортируем сайт с ID 3; мы получим ZIP-файл, который будет готов к импорту в другую сеть мультисайтов или в отдельный сайт. Команда для импорта в отдельный сайт или в мультисайт та же самая, MU-Migration определит, запущена она для мультисайтов или нет, и автоматически скорректирует процесс. С другой стороны, при импорте в другую сеть мультисайтов вы можете также определить параметр —blog_id для перезаписи существующего сайта.

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

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

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

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

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

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

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

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

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

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

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

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

Давайте посмотрим, как мы можем перенести крупный отдельный сайт в мультисайтовую сеть. Мы начнем с экспорта сайта в ZIP-архив и выполнения тестового прогона на целевом сервере. В этот момент сайт не будет доступен для всех, поскольку домен по-прежнему указывает на старый сервер. Вы также можете включить плагин по типу Restrict Site Access на сайте назначения, чтобы гарантировать, что он закрыт от публики.

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

Делаем тестовый прогон

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

Используем флаг —mysql-single-transaction

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

$ 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 нашего нового сайта. Выполняем команду $ wp site list и получаем сведения:

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

$ rsync -azP wp-content/uploads/ root@172.99.99.99:/var/www/multisite/wp-content/uploads/sites/2/

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

Финальная миграция будет примерно такой же. Единственное отличие: мы передадим параметр —blog_id=2 в команду импорта.

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

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

Заключение

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

Источник: https://www.smashingmagazine.com

Поделиться

3 комментария

  1. Станислав says:

    Добрый день. Видимо, этот плагин не поможет решить простую проблему, которую разработчики Вордпресс, неизвестно, решили уже или нет? Элементарно нужно создать новый сайт в каталоге уже существующего почти 4 года основного сайта.
    Но как решить это
    «Постоянные ссылки по-прежнему будут работать, хотя на основном блоге (т.е. на первом из созданных) к адресам будет добавлен префикс blog, и они примут вид domain.com/blog/YYYY/MM/POSTNAME
    Это сделано, чтобы предотвратить конфликты между страницами и новыми сайтами в режиме подкаталогов. На текущий момент нет простого способа это изменить, поскольку в этом случае WordPress не сможет автоматически разрешать конфликты между основным и дочерними сайтами. Это будет исправлено в одной из следующих версий WordPress.»
    Неужели до сих пор не исправили такую простую вещь?

    Я даже задавал такой вопрос на одном форуме:
    «Если будет страница site.ru/brand-catalog на основном сайте, а доп.сайт будет называться site.ru/katalog — то тогда конфликт URL возникнет или нет?»
    И мне ответили: — Нет, не возникнет.
    Так почему тогда ВП не позволяет такое делать? Мне побожиться что ли перед моей установкой ВП, что не будет таких ссылок, на колени перед ним встать что ли?)))

    Или возможно так: 1.сделать на старом своем сайте мультисайт на поддомене — тогда выйдет сеть мультисайтов
    2. на Денвере состряпать тот самый нужный сайт katalog
    3. с помощью описанного в Вашей статье плагина импортировать сайт katalog в подкаталог мультисайта
    4. поддомен удалить.
    Или все равно на основном сайте возникнет префикс blog и все ссылки разрушит?
    Извините, если пишу полный бред, но ничего другого просто в голову не приходит.

    • Дмитрий says:

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

      Вот тут хорошо описано: https://premium.wpmudev.org/forums/topic/wordpress-multi-site-permalinks

      Там в комментариях есть пошаговый процесс.

      И потом у вас могут перестать открываться посты по старым ссылкам, т.е. надо будет в базе данных все править через SQL-запросы или вручную.

  2. Дмитрий says:

    И еще есть вот такой код для удаления /blog:

    https://gist.github.com/roborourke/4ab95cf90f94e4d5243c

    Но все это надо тестировать на практике.

Добавить комментарий для Дмитрий Отменить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *

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