Drupal

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

lexa - 07/Янв/2010 23:53

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

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

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

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

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

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

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

lexa - 06/Янв/2010 17:43

Синхронизация 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

lexa - 05/Янв/2010 21:53

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

Описанная ниже методика предназначена для заливки пустого сайта на 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 и транслитерация

lexa - 05/Янв/2010 16:40

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

Для 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: постановка задачи

lexa - 04/Янв/2010 15:53

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

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

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

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

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

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

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

Drupal + PostgreSQL (опять, да)

lexa - 14/Май/2009 10:51
Передайте разработчикам <программы такой-то>, что лучше бы они ее больше не разрабатывали

Похоже, что тестировать варез становится просто немодно, чем дальше, тем больше огорчаюсь.

Про моральных индусов я уже плакался, но там речь шла о 3rd-party модуле, а сейчас удивляюсь прямо таки на Drupal core. Удивляюсь, соответственно, сильнее, ибо для core поддержка PostgreSQL заявлено, а вот с тестированием... впрочем я повторяюсь.

Drupal Comment Notify (опять)

lexa - 24/Мар/2009 22:39

Drupal закричал мне, что у меня все устарело, нужно срочно апгредиться. Ну, как он любит. Поапгрейдил, в том числе и Comment Notify до версии 1.2, про натягивание которого на Postgresql я уже писал.

Поапгрейдив, имею вопрос: а что, в MySQL у поля написано NOT NULL, то там самостоятельно появится еще и DEFAULT ...? Потому что я не верю, что автор Comment Notify его совсем не тестирует, однако в нем:

  • В таблице заводится крайне полезное поле, позволяющее не слать повторные нотификации если комментарий редактировался. Но оно NOT NULL и без DEFAULT.
  • Вставка в эту таблицу делается без инициализации данного поля.

Патчить можно или сам модуль или процедуру инсталляции/апгрейда. Точнее, без правки .install никак не обойтись, поэтому вот минимальный патч, который превращает Comment Notify 1.2 в работающий под Postgresql (про MySQL ничего не знаю, не проверял):

comment-notify-1.2-install.diff.gz

Если вы переезжаете с Comment Subscribe, то нужно выполнить еще две SQL-команды (чтобы уже разосланные нотификации не рассылались повторно): 

UPDATE comment_notify set notified=1;
UPDATE comment_notify set notify=1 where cid in (SELECT cid FROM z_com
mentsubscribe WHERE subscribe > 0);

Drupal Comment Notify + PostgreSQL = ....

lexa - 28/Дек/2008 21:59

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

Как оно регулярно бывает с Друпалом, этот модуль с PostgreSQL тоже не работает. И почему я не удивлен.....

Вместе с тем, количество требуемых изменений очень невелико и патч вполне компактный. Проблемы обычные: ifnull, concat, "UPDATE table LEFT JOIN table2".

comment-notify-1.1-pgsql.diff.gz

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

Как оно регулярно бывает с Друпалом, этот модуль с PostgreSQL тоже не работает. И почему я не удивлен.....

Вместе с тем, количество требуемых изменений очень невелико и патч вполне компактный. Проблемы обычные: ifnull, concat, "UPDATE table LEFT JOIN table2".

comment-notify-1.1-pgsql.diff.gz

Drupal Comment Subscribe 6.x-1.2 и PostgreSQL

lexa - 27/Дек/2008 23:40

Я тут в соседнем микроблоге уже нажаловался на моральных индусов. А в этом блоге - конструктив.

comment_subscribe-12-pgsql.diff.gz

Накладывается поверх чистой установки (или апгрейда) модуля Comment Subscribe версии 6.x-1.2. Исправляются несовместимости с PostgreSQL плюс немножко еще:

  • Утерянные автором мои патчи к предыдущей версии - восстановлены (автор взял не все.
  • Правится (внесенная мной же, потом поправленная мной, но не автором модуля) бага с отсылкой многих одинаковых сообщений одному получателю.
  • Подписка автора ноды на все комментарии к ней может редактироваться (в авторской версии - только ставится в момент создания).
  • Таблица с подписками на все комментарии заполняется, даже если на сайте нет ни одного комментария.

Патч сейчас засабмичу автору, посмотрим на результат второй итерации....

Хозяйке на заметку: перенос в Drupal комментариев под другую ноду

lexa - 20/Дек/2008 22:11

Мне на Libraw.su понадобилось отселить переходящую на личности дискуссию, дабы в конкретном обсуждении сохранить высокое отношение сигнал/шум.

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

  • Заводим топик в нужном форуме, запоминаем его Node ID (пусть оно будет 173414).
  • Для каждого из комментариев смотрим его comment-id (администратору он виден в URL ссылок edit/delete) и делаем:
    1. DELETE FROM z_commentsubscribe WHERE cid=ID-комментария; -- сносим подписку, это команда для comment-subcribe, для Comment Notify должно быть как-то похоже
    2. UPDATE comments SET nid=Node-ID WHERE cid=ID-комментария; -- переносим куды следует.
  • Дальше чистим кэши - и все работает.

    Кто бы модуль написал, чтобы у комментария/ветки комментариев появился линк "отнести в отстойник"...

    • Drupal и memcached

    lexa - 14/Дек/2008 21:21

    Последние два месяца я собирался прикрутить к Drupal кэширование на memcached. Останавливало меня то, что модуль Memcache был только для Drupal 5.x (у меня используется 6-я версия), а Cache Router был в разобранном неработающем состоянии. Доводить же до ума еще и это место не хотелось.

    Как выяснилось, в течение ноября оба модуля были починены и сейчас выглядят полностью рабочими под Drupal 6.8. Правда производительность у них резко отличается:

    • Memcache не дал мне заметного прироста производительности, более ~50 запросов в секунду из него вытащить не удалось (а у меня с кэшированием родными средствами Drupal - ну чуть меньше).
    • Cache Router, наоборот, честно все кэширует и скорость работы из кэша - порядка 850-880 req/sec

    Соответственно, поставил я CacheRouter, выглядит работающим.

    Тестирование проводилось путем накатки суточного лога LibRaw.SU утилитой http_load. Считался, естественно, второй проход, подразумевалось что все разлеглось в кэши. Сервер: Dual Opteron 875, FreeBSD 6.4, Postgresql 8.3.5.

    noindex-патч для Drupal 6.x, вторая попытка

    lexa - 22/Ноя/2008 18:37

    В духе нового патча для Movable Type сделал новый nofollow-noindex патч для Drupal 6,x

    1. Сначала надо установить новый вариант предыдущего патча: drupal-noindex-patch2.gz
      После его применения, все страницы, для которых включена фильтрация внешних ссылок, будут иметь ссылки замененными на a href="#link" onClick="return URL-ссылки"
    2. Далее в шаблон страницы, где-то ниже текста комментариев (мы же боремся с ссылками в комментариях, правильно) нужно разместить такой вот javascript-код: 
      var links = document.getElementsByTagName('A');
      
for(var i=0; i &lt; links.length; i++)
      
{
      
   if(links[i].href.match(/\#link/) && typeof links[i].onclick == 'function'){
      
        links[i].href=links[i].onclick();         
      
    }
      
}

      После этого наступает счастье: пользователи ничего не замечают (ну, кроме тех, у кого выключен Javascript, у тех после каждой ссылки появляется слово [link]), а поисковые машины индексируют только текст ссылки, но не учитывают ее как ссылку. Чего мы и добивались.

    Drupal + PostgreSQL + comment_subscribe

    lexa - 02/Ноя/2008 12:02

    В моих правках к модулю Comment Subscribe для его работы с PostgreSQL обнаружилась бага: если кто-то отвечал в треде несколько раз, то он может получить несколько писем-уведомлений, когда ответит кто-то еще.

    К вопросу об опенсорсе

    lexa - 21/Окт/2008 23:00

    Drupal-овская Taxonomy import/export via XML в версии 1.1 работала. Я даже научился туда XML-и генерировать и было мне счастье.

    А версию 1.2 они сломали (мотивируя починкой Security Advisory). Короткие таксономии работают, а попытка залить туда 200 терминов кончается фиаско.

    А ведь это модуль не ежедневного использования, шансов на починку гораздо меньше чем обычно. И обычно то не чинят, а ради одноразовой штуки заморачиваться не хочется вовсе. Я вот перешел на CSV import, хотя он и менее удобен: присвоить ID терминам нельзя.

    Про спам в каментах

    lexa - 14/Окт/2008 13:46

    Ответ по заявкам телезрителей (пришло в личную почту) на вопрос про сапам в комменатриях.

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

    Хочется думать, что помогает в первую очередь бессмысленность спама по каментам: noindex+nofollow везде, отчего нет смысла тратить много усилий. Но безумные роботы таких тонкостей не знают и их реально много.

    С чувством невыразимого облегчения

    lexa - 12/Окт/2008 23:26
    
lexa@www:~# cd /var/db/pkg/
lexa@www:/var/db/pkg# pkg_delete -f *mysql*

    Натягивание Drupal на PostgreSQL

    lexa - 11/Окт/2008 10:10

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

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

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

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

    Drupal + PostgreSQL = еще один патч

    lexa - 09/Окт/2008 22:42

    В процессе попыток использования Drupal 6.5 с PostgreSQL выявилась мелкая неприятность: интерфейс к постгресу не вполне правильно эскейпит строки со спецсимволами. Постгрес хочет, чтобы ему давали в виде E '\r\n', а Друпал дает без E. Пожелание это новое, появилось в какой-то из восьмых версий, на функциональность не влияет, но противно забивать лог неизвестно чем.

    Патч прилагается: drupal65-pgsql8x-patch2.diff.gz

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

    Drupal + PostgreSQL: вторая попытка

    lexa - 05/Окт/2008 21:57

    Внезапно возникшее отвращение к MySQL (каменты тоже читать) заставило посмотреть на связку Drupal + PostgreSQL еще раз.

    Если аккуратно, то все работает. Т.е. к core у меня и раньше претензий не было, а сломался я в модуле Backup-Restore. Сейчас - с минимальным набором 3rd-party (Tagadelic, Inline Tags, Site Menu, Pathauto, Transliteration) все вроде живет. Точнее, Transliteration не транслитерирует, но оно этого и с MySQL не делало, но всяких сообщений об ошибках и прочих безобразий пока нет, за исключением одного:

    У меня на разных инсталляциях PostgreSQL стоит разный default client_charset. Где-то KOI8, где-то CP1251, но нигде не стоит UTF8 (базы все, естественно, в UTF). Это все по соображениям совместимости - много где живут скрипты многолетней давности и вставлять в каждый из них set client_charset мучительно.
    Drupal о такой подлости не подозревает (MovableType - подозревает и выставляет), что лечится простым патчем:

    drupal64.pgsql.diff.gz

    Drupal: второй патч для noindex

    lexa - 01/Окт/2008 13:32

    Помимо стандартного HTML Filter, который пришлось править для защиты от ссылочного спама, в Drupal обнаружилось еще одно аналогичное место: заголовок комментария.

    Для зарегистрированных на сайте пользователей, имя пользователя является ссылкой на профиль, если читающий не залогинен, то даже и ссылки нет. Для сторонних же пользователей, указавших при комментировании линк на сайт, имя является ссылкой на этот сайт. Конечно, эта ссылка защищена от гугла через rel=nofollow, но наши поисковики такого не понимают, а хотят noindex.

    Патч: drupal-themeinc-noindex.diff.gz

    Так как я не вижу никакого смысла в индексировании Яндексом юзерских ников анонимов, то ухищрения с яваскриптом не нужны, просто noindex и все.

    Pages

    Subscribe to Drupal