2010

Друпал - усугубляем бардак с алиасами

У меня исторически имеет место бардак с именами URL: все они порождены из заголовков записей, но

  • В большинстве случаев дефис заменен подчеркиванием (и в заголовок данной записи специально добавлен дефис, чтобы проверить).
  • В некоторых случаях дефис оставлен дефисом, это привет MovableType, настроенного по умолчанию из лета 2008 года.
  • В некоторых случаях дефис вовсе скушали, какая-то версия MT заменяла конструкцию ' - ' не на '___' и не на '_-_', а на '__'.
Причем, как выяснилось по логам, есть внешние ссылки на разные представления одного и того же, уж не знаю откуда они взялись.

Проблема лечится вот таким вот SQL-оператором (regexp_replace() - чисто постгресовское, MySQL-аналог найдите сами. Это только для nodes, с таксономией в моем случае проблем нет совсем.

 insert into url_alias(src,language,dst) select src,language,regexp_replace(dst,'-','_','g') from url_alias where src like 'node%' and dst like '%-%';

Миграция Movable Type -> Drupal. Синхронизация с ЖЖ, наведение марафета, финал

Руководство по прыжкам с парашютом, издание второе, исправленное

Теги/рубрики/категории

При миграции контента с тегами и категориями был предложен такой метод

  1. Делаем категории тегами (чтобы не заполнять значения).
  2. Импортируем.
  3. Меняем тип таксономии категории на "Multiple select/Mandatory".
  4. Правим пути к категориям.

Увы, но где-то на этом пути теряются категории у изрядной части записей и теги - у единиц, повторный импорт лечит только частично. Я подозреваю, что крышу рвет, если есть теги, совпадающие с категориями, но не уточнял.Теги портит LJ Sync, пришлось его еще шашкой....

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

С шашкой на Drupal: LiveJournal Sync Ugly Hack

Синхронизация Drupal с ЖЖ оказалась гораздо более простым делом, чем в случае Movable Type:

Ну, если быть точным, то для LJ Sync нужно поставить еще патч из его pending patches, а то синхронизированное туда приезжает тут же обратно, второй копией.

А если быть совсем точным, то LJ Sync не работает с PostgreSQL. REPLACE INTO {table}, убил бы нафиг....

Но. LJSync делает куда больше чем не нужно:

  • Вытаскивает из ЖЖ записи, которые там появились независимо. Это хорошо, если есть адын standalone-блог и адын ЖЖ, но у меня два стандалона гадят в один ЖЖ.
  • Темизирует look-and-feel Друпала "под ЖЖ". С синенькими заголовками комментариев и заголовками записей в ЖЖ-шном духе.
  • Для всех ЖЖ-шных комментаторов заводится аккаунт на Друпале. Оно так и на MT у меня было, но на MT эти аккаунты были бесправные, а тут в них можно авторизоваться (если OpenID включить) ну и типа писать.
Всего этого я ну никак простить не мог.

Миграция MovableType -> Drupal. День 2: миграция контента и URL

Предуведомление

Описанная ниже методика предназначена для заливки пустого сайта на Drupal. Задача доливки контента на сайт, где уже что-то есть - не ставилась. Более того, на стадии импорта комментариев все старые комментарии точно будут стерты.

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

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

Импорт записей

Задача: вытащить записи (посты) из БД MovableType и запихать их в БД Drupal в виде объектов типа Story. Создание Drupal-объекта связано с заполнением нескольких таблиц (node, node_revisions и прочие node_*, url_aliases), пополнением таблицы тегов, другими словами эту работу не хочется делать вручную (SQL-запросами), а хочется перевесить на внутреннюю механику Drupal (ведь при создании записи оно как-то само все делается...).

План работ тривиален и прост:

  • Ставим модули Table Wizard и Migrate.
  • Добавляем нужные поля в структуру данных записи Story (не вручную, включением готовых модулей).
  • Запускаем скрипт, который перенесет нам данные постов в БД Drupal.
  • Импортируем образованную таблицу с постами в Table Wizard.
  • Делаем импорт через Migrate.
  • Полируем результат.
Первый пункт особых вопросов вызвать не должен, обычные модули. За собой потянут Views и Schema, их тоже надо выкачать и поставить, до кучи полезен и Views UI.

Drupal: pathauto и транслитерация

В качестве короткой заметки на тему вчерашнего и ряда следующих текстов.

Для Drupal есть модуль Pathauto, который делает человеко понятные урлы: заменяет пробелы на минусы (или подчеркивания), меняет ужасные /taxonomy/term/NNN на /tags/имя-тега и так далее.

Все из себя настраиваемое и вообще хорошее, если бы не одно но:

  • Оно умеет транслитерацию (в частности, URL данного текста странслировался бы в ...i_transliteratsiya.....
  • Оно умеет формировать URL-ы из кучи макросов (дата, рубрика и все такое), этого богатства более чем хватает для жизни.
  • Но! Включение транслитерации - глобальное. Или мы транслитерируем все (URL заметок, теги и т.п.) или не транслитерируем ничего.
А у меня в блоге принято, что теги русские, а URL заметок - латинские.

Короче, патч: pathauto-transliterate.diff.gz

Если в паттерн для формирования URL включить текст 'no-transliterate-me', то данный текст будет удален, а то что осталось - не будет транслитерировано.

Все очень на скорую руку, только для таксономии (тегов), но там по образу и подобию несложно доточить для других типов - муторно, но можно.

К сожалению, модуль написан достаточно плотно, транслитерация делается на очень ранней стадии, поэтому сделать более удобные макросы по месту [notr-macro] и [macro] - сходу не получилось.

Автор слышал о проблеме и справедливо замечает, что и размножение макросов и отдельные настройки для каждого типа данных - плохо. И я с ним согласен, но вот мне - надо,

При случае, подумаю про эту тему еще.

Миграция MovableType -> Drupal. День 1: постановка задачи

Предуведомление

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

Короче, не нравится - не читайте :)

Статус этих записок

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

Зачем переезжать

Моя причина очень простая: мне надоело поддерживать две платформы (Drupal и Movable Type). При этом, по комплексу свойств Друпал побеждает, а значит с MT пора прощаться. А новогодние каникулы - хороший повод позаниматься чем-то полезным.

Pages