В прошлые выходные завершил таки переезд блога на 7-ю версию Drupal. Отдельная история, достойная примечания и отнюдь не усыпанная розами. Поначалу, пойдя по стандартному пути апгрейда с шестерки на семерку, подробно описанному на drupal.org, создал отдельную локальную копию блога и начал экспериментировать на ней. Попыток было приличное количество, соломку старался стелить везде, где только можно, однако во всех случаях процесс обновления движка заканчивался почти под занавес какой-нибудь ошибкой и все приходилось начинать заново.
Люди, успевшие поближе познакомиться с новой версией, предупреждали, что с апгрейдом не все так просто. Седьмая версия движка явила собой не просто обновление предыдущей версии, она фактически стала совершенно другой изнутри версией CMS, еще более гибкой, мощной и удобной в плане своих возможностей. Как я и сам успел заметить, кардинально поменялись и API (набор внутренних функций, используемых при создании модулей и обеспечивающих их взаимодействие друг с другом), структура таблиц и ядро системы. Легко представить поэтому, сколь трудна была задача написать скрипт, который бы программно и без ошибок сумел перелопатить все это хозяйство из одной системы в совершенно другую.
После того, как было потрачено n-ое количество часов на попытки апдейта версии вместе с данными, мне вдруг стало жалко времени и возникла мысль о других подходах. Первое, что пришло в голову — миграция данных. Миграция данных — самое, пожалуй, правильное решение для подобных случаев. Разумно и логично не пытаться писать сложнейший код, который бы конвертировал таблицы из одних в другие (так реализован механизм обновлений модулей в Друпале, работает очень хорошо и надежно, но, как показала практика, оказался не вполне пригоден для обновления системы в целом), а просто обеспечить вывод данных в XML-файл опреденного формата, которые потом можно было бы точно так же разобрать и занести в новые структуры обновленного движка. Такой механизм встроен, например, в WordPress, почему бы не встроить его и в Durpal, тем более что по другим возможностям Друпал значительно обгоняет Вордпресс. С другой стороны, понятно, почему не встроен — Друпал позволяет создавать на порядки большее разнообразие типов данных и сущностей по сравнению с Вордпресс и охватить все это разнообразие в готовом виде было бы проблематично. Осмотрелся по сторонам, точнее — снова в репозитарии drupal.org и нашел там соответствующий модуль Migrate (http://drupal.org/project/migrate). Народ его сильно хвалил, однако оказалось, что это всего лишь фреймворк, то есть каркас для написания своих классов для миграции данных. Все бросить и засесть за написание своих процедур для парсинга и дальнейшего рассовывания данных из всех задействованных полей? М-да, подобная мысль не внушила радости. Дальнейшие поиски вывели еще на пару девелоперских решений для миграции данных с 6-й на 7-ю версию, но даже не оформленных как модули, а лежащих в GIT-репозитарии. Как было написано, представляли они собой экспериментальные решения и позволяли мигрировать лишь отдельные типы данных.
Можно было бы поэкспериментировать, но тут я снова уперся в свой лимит времени, которое мог потратить на апгред блога, поэтому, учитывая небольшой объем материалов, решил проделать его гибридным и несколько примитивным способом, за что рискую подвергнуться осмеянию сторонников чистых и «правильных» подходов: методом «Copy-Paste» для статей и импортом с помощью запросов комментариев и пользователей. Этот вариант оказался более успешным, хотя и с некоторыми оговорками. Оказалось, например, что если раньше комментарии в 6-ой версии Друпала хранились в одной таблице базы данных, то в семерке они расползлись аж по трем таблицам. Пришлось делать соответствующие запросы. чтобы растащить данные по ним для новой версии. Экспорт удался, но подоспела еще одна свежая мысль: а не делегировать ли управление комментариями на внешний сервис, у которого есть функции экспорта/импорта? Прошел и это. Экспортировал все комментарии на сервис Discus (теперь, правда, мои собственные ответы в них выглядят как ответы гостя :)).
С пользователями тоже не все прошло бесшовно — учетные записи импортировал, но вот пароли преобразовывать не стал — в 7-ой версии Drupal используется более сложный алгоритм для создания хэша пароля, не ограничивающийся одним лишь однократным применением функции md5. Однако с этим проблемы не должно быть: любой зарегистрированный пользователь может запросить новый пароль для входа, и он будет тотчас сгенерирован и выслан ему на e-mail.
Наконец, оформление. С темой как и в прошлый раз сильно заморачиваться не стал, решил избавиться от поднадоевшей головы с цветными шестеренками в качестве логотипа, взял в качестве базовой добротно сделанную «Короллу» (http://drupal.org/project/corolla), приглянувшуюся гибкостью, наличием неплохой документации, большим количеством настроек и использованием HTML5, немного поменял шаблон вывода постов (дату, например), и, наконец, раскрасил ее немного пейзажами оставшегося в доброй памяти небольшого итальянского городка Лукка, в который 3 года назад занесла Фортуна.
И не просто занесла — так сложилось, что была возможность самому на машине туда добраться из Пизы (около 40 километров), поэтому с помощью гугловских карт нашел маршрут и с их помощью проложил путь через запутанные развязки перед самим городком, которые, к счастью, оказались достаточно хорошо видны на спутниковых фотографиях. Благодаря такой предварительной подготовке доехал до общественной стоянки у древней городской стены старого внутреннего города нигде не заплутав. Этот момент добавил особого драйва к воспоминаниям об этом необычном и очень симпатичном тосканском городке.
Итак, переезд завершен, обживаюсь с новым интерфейсом и возможностями, и едем с ними дальше. Много было мыслей по поводу совместимости и различных подходов к сохранению накопленных данных, но пусть это будет темой уже другой истории…