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

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

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

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

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

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

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

Запуск:

./mt2d-fixtags.pl database fieldname taxonomy-id [migrate_map_table]
Например:
./mt2d-fixtags.pl blog tags 1
  • database - база данных Друпала
  • fieldname - tags или categories, имя поля из mt_posts, которое служит справочником.
  • taxonomy-id - номер таксономии (соответствующей tags или categories).
  • migrate_map_table - имя созданной Migrate таблицы мэппинга внешний идентификатор - Node-ID. Умолчание - migrate_map_1

После запуска данного скрипта, можно деинсталлировать более ненужные модули Migrate,Table Wizard, Schema (но если вы опытный сварщик, то вы побэкапите ваши базы перед этим).

Иерархическое меню из списка категорий

Рекомендованый ранее Taxonomy Block - ф топку. Некрасивое форматирование, да и больше одного уровня вложенности (т.е. всего - два) - не поддерживает. Site Menu - вот выбор настоящего джыдая.

RSS-потоки

В переносимых моих сайтах RSS-потоки устроены следующим образом:

  • /index.xml и /comments.xml редиректятся на FeedBurner средствами http-сервера.
  • А FeedBurner-у подсунуты секретные потоки с другим URL

Простейший и работающий способ - средиректить на FeedBurner и стандартный /rss.xml (тем же способом) и забыть о проблеме. Секретный поток для FeedBurner делается средствами Views (например, добавкой еще одного представления Feed к стандартному View из поставки.

Чуть более сложный способ, но тоже реализуемый без настроек - это породить страницу /frontpage средствами Views (это стандартный View из комплекта), поменять там адрес RSS-потока на index.xml, переключить на /frontpage главную страницу сайта. Этим способом будут изжиты все ссылки на /rss.xml.

Третий способ - URL Alter, на выход меняем rss.xml на index.xml, на вход - наоборот.

RSS-поток по комментариям

Секретный поток для FeedBurner делается средствами Views из готовой заготовки comments/recent

Но! Комментарии в Movable Type не имеют сабжекта. А RSS-поток по комментариям строится из их сабжекта же. Поэтому нужно или править скрипт импорта комментариев (надо, об обновленной версии будет объявлено отдельно) или выполнить такой вот простой SQL-запрос после их импорта:

 update comments set subject=substring(comment from 1 for 60) where length(subject)<1;
что тоже полечит проблему. Кроме того, LJ Sync (см. ниже) не пишет заголовок комментария, если его нет в ЖЖ, а значит тоже надо править.

Синхронизация с ЖЖ

Мои правки к модулям синхронизации описаны в отдельной записи.

Если использовались мои средства синхронизации MovableType и ЖЖ, то нужно перенести таблицы мэппинга идентификаторов записей ЖЖ и Standalone.

Кроме того, для LJ Crosspost 1.5 нужно поставить патч из списка pending patches, без него в LJ будет добавляться Read More даже для записей, где никакого more нету.

Сразу после установки модулей и правок нужно запустить скрипт импорта таблиц (качать тут). Запуск скрипта:

./mt2ljmaps.pl src-db dest-db [id-mapping-table [blog-id]]
  • src-db - исходная БД (Movable Type)
  • dest-db - БД Drupal
  • id-mapping-table - таблица с мэппингом MT Entry ID - Drupal Node ID. Умолчание - migrate_map_1.
  • blog-id - ID блога Movable Type для которого делается перенос.
Скрипт обнуляет все таблицы мэппинга в dest-db перед импортом, поэтому запускать его надо до первой синхронизации.

Разные мелочи

404-я ошибка

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

Русский перевод

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

В очень большой степени проблема решается тем, что с drupaler.ru берется перевод, разбитый на части (Drupal 6 package format (translations directories)), и из него применяется только перевод к модулю locale.

К сожалению (для меня), многие 3rd-party модули уже идут с готовым переводом на русский, отчего административный интерфейс получается частично русифицированным. Меня - раздражает, но сделать ничего не могу.

Общий марафет

Просто список модулей для памяти:

Нерешенные вопросы

  • Правильный мэппинг старых URL (pager, теги) в новые. Ну и какой-то анализатор частотных 404-х ошибок (хотя есть встроенный Друпальский)
  • RSS-поток с комментариями для Яндекс-Блогов

Заключение

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

TODO

  • Привести синхронизацию с ЖЖ в разумное состояние (в частности, при удалении записи - надо и из ЖЖ удалять автоматом).
  • Кэширование. Нет, вроде не капает, но у меня в этом месте перфекционизм.
  • Мои патчи в очередной раз разошлись с Comment Notify/текущим постгресом, надо опять туда смотреть.
  • Смотреть на 404-е, писать редиректы....

P.S.

Мигрирую сайты на ДрупалПомогу советами. ДорогоОчень дорого.

Comments

Thanx. Кросспосты я не всегда просматриваю....

Поздравляю с переездом! Представляю каких сил это стоило! :)

А раздражение от старого сайта было гораздо сильнее, если считать на год

Дизайн пострадал, имхо, было лучше

Я еще ни разу не видел, чтобы смена старого (=привычного) дизайна на новый (=непривычный) всем бы нравилась. Даже при том, что я большинство плашек оставил на старых местах

А факт в том, что читаемость (=глубина просмотра) сильно выросла. А детали увижу дня через три, когда данные накопятся.

Э... скорее через четыре, ибо гугл аналитикс я профукал :)

К сожалению (для меня), многие 3rd-party модули уже идут с готовым переводом на русский, отчего административный интерфейс получается частично русифицированным. Меня - раздражает, но сделать ничего не могу.

Можешь себе поставить английский язык, а посетителям - русский.

А нет никакого смысла - посетители вывод модулей практически не видят. А если себе поставить английский, то месяцы будут на басурманском.

Куча тэгов зело огромна и страшна вышла -- того и гляди страница упадет вправо от тяжести. :) А еще я бы поправил заголовок комментария, который уполз вправо от нижележащего текста -- отчего все кучкуется и простору требует.

У меня с шириной экрана 1024 и больше - 98 процентов аудитории.

Для них длинная колбаса комментариев выглядит куда приличнее чем раньше даже на ширине 1024:
http://blog.lexa.ru/2007/12/25/sberbank_sdelal_moj_den.html#comments
(не говоря про возможность сделать пошире для 80% посетителей)

А раньше центральная колонка была фиксированной ширины 600 пикселов, просто это уже забыли.

Я не про ширину экрана. Проведем вертикальную линию от заголовка комментария вниз (скриншот не охота делать). Все под заголовком будет левее левой части заголовка. Т.е.:

__Про каменты
Автор
Текст

Хотя я понимаю, что подобрать минималисткий дизайн сейчас проблема...

Я не дизайнер - и не понимаю в чем тут проблема.

Ну да, так. Ну и что? Если заголовок на пару букв влево подвинуть - то что изменится?

http://www.sergeignatkin.ru/images/_others/lexa-ru.gif

Ну просто красивше, на мой взгляд. Но я не настаиваю.

Мне надо мельче разжевывать.

Заголовок оставить на месте, а текст подвинуть на 2em вправо?

Угу, или пикселами -- я тут как правильно не знаю. См. мыло.

Я согласен про теги. Хотя они и были такие

Но чтобы люди туда ходили (подписывались на RSS и все такое) - надо чтобы они были видны. Людям и, я извиняюсь, поисковикам.

Я понимаю, что они такие были и зачем они нужны тоже, примерно. Но тут вопрос уникальности -- вот у тебя есть тэг windows, например, или еще какие, кот. в контексте подаваемого тобою, на мой взгляд, мало роли играют. Ну вот кто только в таким тэгом не пишет! -- и зачем тебе это? А вот какая нибудь CUDA, или там обработка изображений -- вот тут да, тут ты можешь выступать поставщиком контента и соотв. тэг иметь можешь. ,) Поэтому я бы проредил жестоко. Два SQL-запроса написать и неск. раз выполнить. ,) Ну ведь если это показывается, то показывается пользователю, а не поисковику. Поисковику можно и белым по белому написать, раз уж так ему нужно. Ну вообщем я думаю идею передал.