Перенос данных с сайта на сайт (Drupal)

Часто возникает задача переноса контента на новый сайт или между различными версиями сайта. Рассмотрим перенос данных с одного Drupal-сайта на второй Drupal-сайт. Проблемы переноса материалов с других CMS (Joomla, Wordpress и др.) на CMS Drupal обсудим в другой раз.
Под «переносом контента» будем считать перенос nod, связанных с ними терминов таксономии и комментариев, а также пользователей, написавших эти комментарии и nod-ы.

Зачем это нужно?

Выделим 2 главных случая, когда это необходимо:

• Перенос материалов со старого Drupal-сайта на новый.
  Пример: у нас есть Drupal-сайт, с неправильной архитектурой и похаченный, но с огромным количеством контента. Где клиент взял этот чудо сайт и кто занимался разработкой лучше не знать. Наша задача состоит в том, что нужно сделать новый сайт, с почти таким же функционалом, перенести на него все статьи, комментарии и, конечно, юзеров.
• Перенос материалов с локальной dev-версии на stage-сервер.
  Пример: над сайтом трудятся несколько разработчиков. Каждый из них работает на своем локальном dev-сервере, создает меню, nod-ы, словари и термины. Каждый из них, выполнив свою задачу, должен отправить изменения на stage-сервер. Как это сделать, не мешая друг другу?

Здесь-то и возникают вопросы, которые необходимо решать.

Почему не скопировать таблицы или всю БД?

Собственно, это первое, что приходит в голову. Но если немного подумать, то становится ясно, что этого нельзя делать. Если несколько разработчиков работают с одним сайтом, то вы просто поломаете что-то, что там уже сделано или делается в этот момент. Это недопустимо.
Даже если вы точно знаете, что с теми таблицами, которые предстоит заменить, никто не работает, возникает другая проблема: связи между таблицами. Мы не можем просто скопировать таблицу node, потому что у нее большое количество связей с другими таблицами. К примеру, вы откроете схему модуля node и узнаете, что нужно скопировать. Это вам вряд ли поможет, потому что остается много других проблем. Например, есть такой нюанс (точнее один из многих нюансов, но рассмотрим реальный пример, который забрал немало времени у наших разработчиков): если вы удачно перенесли nod-у, но в поле автора nod-ы указан идентификатор юзера, которого не существует на этом сайте, то nod-а не будет нигде отображаться.
На следующей диаграмме (рис. 1) схематически изображены основные связи таблицы node с другими таблицами в практически базовой сборке Drupal. На ней видны связи между экспортируемыми объектами, которые нужно сохранить. Иначе, весь смысл в таком переносе контента теряется.

Модули для переноса контента?

Наконец, мы дошли до самого интересного – модулей Drupal, которые осуществляют перенос контента (я перечислю только основные, наиболее известные):

• Node export (как понятно из названия) экспортирует nod-ы, прост в использовании.
• Taxonomy export, соответственно, переносит словари и термины таксономии. Так же простой и выполняет свою задачу отлично.
• модули Node import, Menu import, User import я объединены в одну группу, потому что они осуществляют только импорт, и в основном используются для переноса материалов с других систем. Экспорт формировать нужно вручную.
• самый многофункциональный модуль – Deployment, а точнее связка Deployment + Services. На нем остановимся наиболее подробно.

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

Node export

Как уже написано выше, экспортирует nod-ы, прост в использовании. Умеет экспортировать nod-ы как по одной штуке, так и несколько сразу. Отдает результат в текстовом поле или в виде файла (это настраивается). Также можно настроить поля, которые будут очищаться при экспорте, причем для каждого content type.

Импортировать, так же, можно, вставив текст импорта в текстовое поле или загрузив файл.

Преимущества:

• Понимает CCK-поля (стандартные, Imagefield, Upload).
• Экспортирует вложения, картинки. Причем, по умолчанию, экспортирует все в один файл: нет отдельно картинок, отдельно содержимого nod-ы. Это очень радует.
• Возможность работы через Drush. Поддержка Drush обычно здорово ускоряет работу.

Недостатки:

• Не экспортирует комментарии.
• Не создает контент-тайп, переносит только название. Если на сайте-получателе не будет такого же контент-тайпа, то импорт не удастся.
• Не создает термины таксономии, переносит только идентификаторы. На сайте-получателе должны быть такие же термины (с такими же идентификаторами), как на сайте-отправителе. Иначе, связи потеряются – не очень хорошо.
• Не создает юзеров, переносит только идентификаторы. Если указанного юзера нет, то автором станет root.

Вывод: сайт-получатель должен быть идентичен сайту-отправителю.

Taxonomy export

Модуль отлично справляется со своей задачей. Может переносить как определения словарей, так и словари с терминами, сохраняя иерархию и соответствия «контент-тайп - словарь», если, конечно, такой контент-тайп на сайте-получатале существует.

Так же как Node export, умеет отдавать данные как в браузер в текстовое поле, так и в виде файла.
Умеет обновлять существующие словари и термины. Одно главное условие – идентификаторы словарей и терминов должны совпадать на сайте-отправителе и получателе.

Недостаток один. Нет смысла использовать модуль вместе с Node export. Если вы хотите сохранить зависимости между nod-ами и терминами на сайте-получателе, то у вас ничего не получится, потому что модуль создает записи с новыми идентификаторами(отличными от  соответствующих на сайте-отправителе). Все связи теряются.

Node import, Menu import, User import

Скажу всего пару слов. Эти модули осуществляют импорт из CSV-файлов, которые необходимо перед этим сформировать. Эти модули не осуществляют экспорт, так как они используются в основном для переноса материалов с других систем на Drupal.

Deployment + Services

Теперь мы подошли к главному модулю, которому я уделю больше всего внимание. Основной принцип работы модуля (рис. 2) заключается в том, что, так сказать, он сам занимается импортом данных на сайте-получателе. Точнее, отправляет нужные команды, на которые реагирует модуль Services на сайте-получателе. Все, что нужно сделать, это выбрать элементы для отправки и запустить deployment.

Отметим, что на сайте-отправителе нужно установить модуль Deployment и настроить его, указав адрес сервера-получателя. А на сайте-получателе необходимо установить модуль XMLRPC и Services, включить в его настройках авторизацию по идентификатору сессии (авторизацию по ключу Deployment не поддерживает).
Подробней о настройке можно почитать в файле INSTALL.txt

Состав модуля Deployment:

• Deploy book pages
• Deploy Comments
• Deploy Content Type.
• Deploy Dates
• Deploy Files
• Deploy Nodereferences
• Deploy System Settings
• Deploy Userreferences
• Deploy Views
• Node Deployment
• Taxonomy Deployment
• User Deployment

Достоинства:

• Понимает CCK-поля (стандартные, Date, Nodereference, Userreference)
• Умеет экспортировать комментарии. 
  Не экспортирует комментарии вместе с nod-ами. Если нужно экспортировать и комментарии, то они переносятся отдельно, но связи при этом сохраняются.
• При экспорте материалов (node), сохраняет связи с таксономией (создает термины, если таковых нет).
  Термины экспортирует 1 раз. То есть, если такой термин уже есть, то дубль создаваться не будет.
• При экспорте материалов (node), сохраняет автора (переносит, если такого нет). 
  То же самое, что и с терминами. Создает юзера 1 раз.
• Умеет экспортировать настройки любого модуля (если он использует system_settings_form()). 
  Не совсем перенос контента, но весьма удобная вещь. Можно перенести любые настройки, оформленные через system_settings_form(). Еще один стимул разработчикам использовать эту функцию.
• Deployment plans. 
  Очень удобная и полезная фича. Ниже мы рассмотрим ее подробнее.

Недостатки:

• Работает только с Services 6.x-2.x. 
  Третью версию Services не поддерживает и не собирается.
• Не поддерживает Filefield/Imagefield
  Все вложения и картинки теряются..
• Конфликт с модулем Upload
  Конфликт, который заключается он в том, что если на сайте-получателе включен модуль Upload, то nod-ы переноситься не будут, без всяких ошибок и предупреждений. В логе деплоймента будет указано, что nod-а удачно отправлена, а на самом деле ее не будет. Происходит это из-за того, что модуль Upload каким-то образом меняет форму создания nod-ы, после чего, деплоймент корректно работать с ней больше не сможет.

Deployment plans

Deployment plan – это набор элементов, которые необходимо отправить на сайт-получатель. В этот набор можно добавить все: nod-ы, комментарии, настройки, термины таксономии.

К примеру, можно создать деплоймент план «Настройки» и добавить туда настройки нужных нам модулей. После этого отправить все настройки за один раз.
На рис. 3 мы добавляем в деплоймент план 2 ноды. Модуль сам распознает связи и, соответственно, добавляет их автоматически.

Затем (рис. 4) можно просмотреть добавленные в план элементы и удалить их, если они не нужны.

Выводы

Подведем итог:

• Нет единого универсального решения.
  Node export не очень хорошо справляется с таксономией, Deployment не ладит с вложениями (хотя автор обещал вскоре добавить их поддержку, не знаю когда). Если задача не тривиальна, то решение все равно придется доделывать вручную, вмешиваться в те же таблицы, писать свои мини-скрипты экспорта/импорта.
• Делайте backup`ы перед любым импортом.
  Даже если вы уверены, что импорт не затронет существующих данных, все равно лучше перестраховаться, ибо потом будет мучительно обидно исправлять то, что поломал ваш импорт.

Автора автра