LJ Sync за несколько дней эксплуатации совершено опротивел. Изрядную часть его достоинств я почикал, оставил только импорт комментариев, но и с этим оно справляется не на пятерку:
Комментарии с пустым сабжектом - так и оставляет пустым, в результате RSS без ссылок, список свежих комментариев - тоже без них. Поправить недолго, но...
Уведомления о ЖЖ-комментах приходят дважды, один раз из ЖЖ, второй раз из моего блога. Это, типа, фича.
Работает долго т.к. каждый раз разбирает многомегабайтный XML в котором весь мой ЖЖ за все времена.
У меня исторически имеет место бардак с именами 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 '%-%';
Делаем категории тегами (чтобы не заполнять значения).
Импортируем.
Меняем тип таксономии категории на "Multiple select/Mandatory".
Правим пути к категориям.
Увы, но где-то на этом пути теряются категории у изрядной части записей и теги - у единиц, повторный импорт лечит только частично.
Я подозреваю, что крышу рвет, если есть теги, совпадающие с категориями, но не уточнял.Теги портит LJ Sync, пришлось его еще шашкой....
Пришлось написать скрипт (качать тут), который правит эту проблему, анализируя таблицу mt_posts
самостоятельно (запускать после импорта, когда все теги/категории уже созданы).
Ставим LiveJournal Sync (плюс нужные модули для работы jbackup.pl)
И все работает (PROFIT!)
Ну, если быть точным, то для LJ Sync нужно поставить еще патч из его pending patches, а то синхронизированное туда приезжает тут же обратно, второй копией.
А если быть совсем точным, то LJ Sync не работает с PostgreSQL. REPLACE INTO {table}, убил бы нафиг....
Но. LJSync делает куда больше чем не нужно:
Вытаскивает из ЖЖ записи, которые там появились независимо. Это хорошо, если есть адын standalone-блог и адын ЖЖ, но у меня два стандалона гадят в один ЖЖ.
Темизирует look-and-feel Друпала "под ЖЖ". С синенькими заголовками комментариев и заголовками записей в ЖЖ-шном духе.
Для всех ЖЖ-шных комментаторов заводится аккаунт на Друпале. Оно так и на MT у меня было, но на MT эти аккаунты были бесправные, а тут в них можно авторизоваться (если OpenID включить) ну и типа писать.
Описанная ниже методика предназначена для заливки пустого сайта на Drupal. Задача доливки контента на сайт, где уже что-то есть - не ставилась.
Более того, на стадии импорта комментариев все старые комментарии точно будут стерты.
Если вам нужно пополнение имеющегося сайта, то описанные ниже скрипты нужно взять за основу и допилить.
Кроме того, никакими enterprise-features, вроде транзакций или обработки ошибок я категорически не заморачивался. Предполагается, какбэ, что импортом данных
мы занимаемся тихо в уголочке, поступлением новых данных на старый сайт можем управлять, а после завершения импорта просто подменим сайт на скаку.
Импорт записей
Задача: вытащить записи (посты) из БД MovableType и запихать их в БД Drupal в виде объектов типа Story. Создание Drupal-объекта связано с заполнением
нескольких таблиц (node, node_revisions и прочие node_*, url_aliases), пополнением таблицы тегов, другими словами эту работу не хочется делать вручную
(SQL-запросами), а хочется перевесить на внутреннюю механику Drupal (ведь при создании записи оно как-то само все делается...).
План работ тривиален и прост:
Ставим модули Table Wizard и Migrate.
Добавляем нужные поля в структуру данных записи Story (не вручную, включением готовых модулей).
Запускаем скрипт, который перенесет нам данные постов в БД Drupal.
Импортируем образованную таблицу с постами в Table Wizard.
Первый пункт особых вопросов вызвать не должен, обычные модули. За собой потянут Views и Schema, их тоже надо выкачать и поставить,
до кучи полезен и Views UI.
В качестве короткой заметки на тему вчерашнего и ряда следующих текстов.
Для Drupal есть модуль Pathauto, который делает человеко понятные урлы: заменяет пробелы на минусы (или подчеркивания), меняет ужасные /taxonomy/term/NNN на /tags/имя-тега и так далее.
Все из себя настраиваемое и вообще хорошее, если бы не одно но:
Оно умеет транслитерацию (в частности, URL данного текста странслировался бы в ...i_transliteratsiya.....
Оно умеет формировать URL-ы из кучи макросов (дата, рубрика и все такое), этого богатства более чем хватает для жизни.
Но! Включение транслитерации - глобальное. Или мы транслитерируем все (URL заметок, теги и т.п.) или не транслитерируем ничего.
А у меня в блоге принято, что теги русские, а URL заметок - латинские.
Если в паттерн для формирования URL включить текст 'no-transliterate-me', то данный текст будет удален, а то что осталось - не будет транслитерировано.
Все очень на скорую руку, только для таксономии (тегов), но там по образу и подобию несложно доточить для других типов - муторно, но можно.
К сожалению, модуль написан достаточно плотно, транслитерация делается на очень ранней стадии, поэтому сделать более удобные макросы по месту [notr-macro] и [macro] - сходу не получилось.
Автор слышал о проблеме и справедливо замечает, что и размножение макросов и отдельные настройки для каждого типа данных - плохо. И я с ним согласен, но вот мне - надо,
Я понимаю, что читать такой сугубо специфический текст может быть скучно, особенно на каникулах. В то же время, я не нашел разумных русскоязычных текстов на эту тему, поэтому мои записки могут оказаться полезными тем, кто столкнется с подобной задачей.
Короче, не нравится - не читайте :)
Статус этих записок
Записки пишутся по горячему, с небольшой задержкой относительно реальных действий. На момент написания первой части (которую вы сейчас читаете) есть ощущение, что все получится, но реальный перенос данных даже на тестовой машине сделан частично. Но уже есть ощущение успеха, минимально необходимая функциональность точно будет, а дальше будем посмотреть.
Зачем переезжать
Моя причина очень простая: мне надоело поддерживать две платформы (Drupal и Movable Type). При этом, по комплексу свойств Друпал побеждает, а значит с MT пора прощаться. А новогодние каникулы - хороший повод позаниматься чем-то полезным.
Q: On http://www.movabletype.jp/documentation/mt5/db/mysql-from-sqlite.html I read:
From the Movable Type 5, SQLite and PostgreSQL are no longer supported.
A: Yes, it's true. MT5 will deprecate core support for SQLite and PostgreSQL. But, these databases can still be used with MT if a plugin is written to add support; the Enterprise Pack defines the drivers necessary to use the Oracle database with MT.
Вот и выяснилось, чем придется заниматься на новогодних каникулах, писать тестировать LJ-кросспост для Друпала (оказалось, он уже есть, что же я торможу?)
Если кто-то общается с командой MT, передайте им при случае, чтобы думали верхней жопой передней головой, платформа их была выбрана мной исключительно за поддержку PgSQL и только это ее и берегло.
Передайте разработчикам <программы такой-то>, что лучше бы они ее больше не разрабатывали
Похоже, что тестировать варез становится просто немодно, чем дальше, тем больше огорчаюсь.
Про моральных индусов я уже плакался, но там речь шла о 3rd-party модуле, а сейчас удивляюсь прямо таки на Drupal core. Удивляюсь, соответственно, сильнее, ибо для core поддержка PostgreSQL заявлено, а вот с тестированием... впрочем я повторяюсь.
Drupal закричал мне, что у меня все устарело, нужно срочно апгредиться. Ну, как он любит. Поапгрейдил, в том числе и Comment Notify до версии 1.2, про натягивание которого на Postgresql я уже писал.
Поапгрейдив, имею вопрос: а что, в MySQL у поля написано NOT NULL, то там самостоятельно появится еще и DEFAULT ...? Потому что я не верю, что автор Comment Notify его совсем не тестирует, однако в нем:
В таблице заводится крайне полезное поле, позволяющее не слать повторные нотификации если комментарий редактировался. Но оно NOT NULL и без DEFAULT.
Вставка в эту таблицу делается без инициализации данного поля.
Патчить можно или сам модуль или процедуру инсталляции/апгрейда. Точнее, без правки .install никак не обойтись, поэтому вот минимальный патч, который превращает Comment Notify 1.2 в работающий под Postgresql (про MySQL ничего не знаю, не проверял):
Решил по случаю воскресенья поапргейдить блоговый движок. C Movable Type 4.21 на 4.23.
Обнаружил неприятность: в поиске (включая поиск по тегу) пролюбили локализацию дат. То бишь, независимо от настроек блога, название месяцев пишутся английские, а формат даты тоже тамошний (Месяц, число год).
RU-Center прислал очень любезное письмо, дескать с 29 января повышаем цену за регистрацию-продление иностранных доменов (.NET, .COM, .ORG, .BIZ,
INFO, .CC, .TV, .ME). А на календаре - 20-е.
Разница для COM/ORG - почти 40 процентов удорожания, для остальных доменов не смотрел.
У кого есть свободные электрические (да и обычные) рубли, тот еще может поиграть в игру "защитись от девальвации" и даже немножко выиграть: продлевать NET/COM/ORG можно на любое количество лет, сколько денег не жалко.
Ру-центру, естественно, тоже приятно, они ваши деньги получат сейчас, а не через несколько лет.
Вместе с тем, количество требуемых изменений очень невелико и патч вполне
компактный. Проблемы обычные: ifnull, concat, "UPDATE table LEFT JOIN table2".
Вместе с тем, количество требуемых изменений очень невелико и патч вполне
компактный. Проблемы обычные: ifnull, concat, "UPDATE table LEFT JOIN table2".
Накладывается поверх чистой установки (или апгрейда) модуля Comment Subscribe версии 6.x-1.2. Исправляются несовместимости с PostgreSQL плюс немножко еще:
Утерянные автором мои патчи к предыдущей версии - восстановлены (автор взял не все.
Правится (внесенная мной же, потом поправленная мной, но не автором модуля) бага с отсылкой многих одинаковых сообщений одному получателю.
Подписка автора ноды на все комментарии к ней может редактироваться (в авторской версии - только ставится в момент создания).
Таблица с подписками на все комментарии заполняется, даже если на сайте нет ни одного комментария.
Патч сейчас засабмичу автору, посмотрим на результат второй итерации....
Мне на Libraw.su понадобилось отселить переходящую на личности дискуссию, дабы в конкретном обсуждении сохранить высокое отношение сигнал/шум.
Удивительно, но готовых средств - нет. Хотя мне казалось, что это востребованная функциональность (флеймеров - в курилку, троллей - в загончик для троллей). В надежде, что часто это делать не придется, обошелся руками:
Заводим топик в нужном форуме, запоминаем его Node ID (пусть оно будет 173414).
Для каждого из комментариев смотрим его comment-id (администратору он виден в URL ссылок edit/delete) и делаем:
DELETE FROM z_commentsubscribe WHERE cid=ID-комментария; -- сносим подписку, это команда для comment-subcribe, для Comment Notify должно быть как-то похоже
UPDATE comments SET nid=Node-ID WHERE cid=ID-комментария; -- переносим куды следует.
Дальше чистим кэши - и все работает.
Кто бы модуль написал, чтобы у комментария/ветки комментариев появился линк "отнести в отстойник"...
Последние два месяца я собирался прикрутить к 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.
Сначала надо установить новый вариант предыдущего патча:
drupal-noindex-patch2.gz
После его применения, все страницы, для которых включена фильтрация внешних ссылок, будут иметь ссылки замененными на a href="#link" onClick="return URL-ссылки"
Далее в шаблон страницы, где-то ниже текста комментариев (мы же боремся с ссылками в комментариях, правильно) нужно разместить такой вот javascript-код:
var links = document.getElementsByTagName('A');
for(var i=0; i < links.length; i++)
{
if(links[i].href.match(/\#link/) && typeof links[i].onclick == 'function'){
links[i].href=links[i].onclick();
}
}
После этого наступает счастье: пользователи ничего не замечают (ну, кроме тех, у кого выключен Javascript, у тех после каждой ссылки появляется слово [link]), а поисковые машины индексируют только текст ссылки, но не учитывают ее как ссылку. Чего мы и добивались.
По совету Николая Сиварева удалось избавиться от главного недостатка моего предыдущего noindex-патча для Movable Type: неудобства при открытии ссылки по правой кнопке.
Правда патч усложнился и теперь состоит из двух частей.
На Movable Type нужно наложить вот этот вот патч: patch-nofollow-img-js2.gz. В результате все внешние ссылки получат вид <a href="#link" onClick="return 'http://link-target';">
В темплейт, где-то в районе footer нужно добавить следующий Javascript-код:
var links = document.getElementsByTagName('A');
for(var i=0; i < links.length; i++)
{
if(links[i].href.match(/\#link/) && typeof links[i].onclick == 'function'){
links[i].href=links[i].onclick();
}
}
После чего наступит одержание и полное счастье. Подобный патч к Drupal тоже в ближайшее время изготовлю.
По совету Николая Сиварева удалось избавиться от главного недостатка моего предыдущего noindex-патча для Movable Type: неудобства при открытии ссылки по правой кнопке.
Правда патч усложнился и теперь состоит из двух частей.
На Movable Type нужно наложить вот этот вот патч: patch-nofollow-img-js2.gz. В результате все внешние ссылки получат вид <a href="#link" onClick="return 'http://link-target';">
В темплейт, где-то в районе footer нужно добавить следующий Javascript-код:
var links = document.getElementsByTagName('A');
for(var i=0; i < links.length; i++)
{
if(links[i].href.match(/\#link/) && typeof links[i].onclick == 'function'){
links[i].href=links[i].onclick();
}
}
После чего наступит одержание и полное счастье. Подобный патч к Drupal тоже в ближайшее время изготовлю.
В моих правках к модулю Comment Subscribe для его работы с PostgreSQL обнаружилась бага: если кто-то отвечал в треде несколько раз, то он может получить несколько писем-уведомлений, когда ответит кто-то еще.