Drupal закричал мне, что у меня все устарело, нужно срочно апгредиться. Ну, как он любит. Поапгрейдил, в том числе и Comment Notify до версии 1.2, про натягивание которого на Postgresql я уже писал.
Поапгрейдив, имею вопрос: а что, в MySQL у поля написано NOT NULL, то там самостоятельно появится еще и DEFAULT ...? Потому что я не верю, что автор Comment Notify его совсем не тестирует, однако в нем:
В таблице заводится крайне полезное поле, позволяющее не слать повторные нотификации если комментарий редактировался. Но оно NOT NULL и без DEFAULT.
Вставка в эту таблицу делается без инициализации данного поля.
Патчить можно или сам модуль или процедуру инсталляции/апгрейда. Точнее, без правки .install никак не обойтись, поэтому вот минимальный патч, который превращает Comment Notify 1.2 в работающий под Postgresql (про MySQL ничего не знаю, не проверял):
Вместе с тем, количество требуемых изменений очень невелико и патч вполне
компактный. Проблемы обычные: 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]), а поисковые машины индексируют только текст ссылки, но не учитывают ее как ссылку. Чего мы и добивались.
В моих правках к модулю Comment Subscribe для его работы с PostgreSQL обнаружилась бага: если кто-то отвечал в треде несколько раз, то он может получить несколько писем-уведомлений, когда ответит кто-то еще.
Drupal-овская Taxonomy import/export via XML в версии 1.1 работала. Я даже научился туда XML-и генерировать и было мне счастье.
А версию 1.2 они сломали (мотивируя починкой Security Advisory). Короткие таксономии работают, а попытка залить туда 200 терминов кончается фиаско.
А ведь это модуль не ежедневного использования, шансов на починку гораздо меньше чем обычно. И обычно то не чинят, а ради одноразовой штуки заморачиваться не хочется вовсе. Я вот перешел на CSV import, хотя он и менее удобен: присвоить ID терминам нельзя.
Ответ по заявкам телезрителей (пришло в личную почту) на вопрос про сапам в комменатриях.
На удивление, простые народные средства помогают не тратить на эту проблему больше нескольких минут в день (на 5 сайтах с открытыми комментариями и приличным pagerank).
Хочется думать, что помогает в первую очередь бессмысленность спама по каментам: noindex+nofollow везде, отчего нет смысла тратить много усилий. Но безумные роботы таких тонкостей не знают и их реально много.
Несмотря на мой исходный пессимизм, появившееся неделю назад острое отвращение к MySQL заставило меня расчехлить напильник и наконец доработать Drupal 6.5 до устраивающей меня совместимости с PostgreSQL.
В настоящую минуту один из моих сайтов уже работает под PgSQL со всеми нужными мне модулями, а остальные будут переведены после нескольких дней тестирования первого.
Несмотря на мой исходный пессимизм, появившееся неделю назад острое отвращение к MySQL заставило меня расчехлить напильник и наконец доработать Drupal 6.5 до устраивающей меня совместимости с PostgreSQL.
В настоящую минуту один из моих сайтов уже работает под PgSQL со всеми нужными мне модулями, а остальные будут переведены после нескольких дней тестирования первого.
В процессе попыток использования Drupal 6.5 с PostgreSQL выявилась мелкая неприятность: интерфейс к постгресу не вполне правильно эскейпит строки со спецсимволами. Постгрес хочет, чтобы ему давали в виде E '\r\n', а Друпал дает без E.
Пожелание это новое, появилось в какой-то из восьмых версий, на функциональность не влияет, но противно забивать лог неизвестно чем.
Внезапно возникшее отвращение к 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 - подозревает и выставляет), что лечится простым патчем:
Для зарегистрированных на сайте пользователей, имя пользователя является ссылкой на профиль, если читающий не залогинен, то даже и ссылки нет. Для сторонних же пользователей, указавших при комментировании линк на сайт, имя является ссылкой на этот сайт. Конечно, эта ссылка защищена от гугла через rel=nofollow, но наши поисковики такого не понимают, а хотят noindex.
Задача: публиковать автоматические ленты новостей на сайтах. Новости берутся с веба, обрабатываются (распознается тематика, присваиваются теги), после чего появляются на сайте.
По идее, для этого предназначен Aggregator, но его интеграция с Taxonomy запланирована только в Drupal 7. Кроме того, pull мне очень не понравился, хочется push. Для push есть BlogAPI, там даже поддерживается установка категорий (тоже довольно диким способом, ибо информация о словарях недоступна, можно получить только список терминов), но вот установка тегов (т.е. терминов, которых в словаре может не быть) через стандартный BlogAPI невозможна. mt_tags - не поддерживаются и не обрабатываются.
Я уже почти поправил BlogAPI (всего то нужно задать один параметр конфигурации - в какой словарь класть теги, остальное все тривиально) и оно уже почти работало, но нашлось готовое решение.
Inline Tags делает все что нужно. Не стандартным путем (т.е. использовать готовое поле tags в blog-редакторе и передачу значений в mt_tags), но вполне приемлемым: список тегов пишется в [tags][/tags] и все работает (проверено).
Все-таки Drupal пишут индусы. Пришлось по уши залезть в код, чтобы выяснить, отчего не работают metaWebLog.getCategories и mt.getCategoryList. Просто забыли проверить авторизацию, отчего, по счастью, просто все сломалось, а не стало отдавать все всем наружу. Не тестируют.
Ссылками в комментариях спамят не только этот блог, но и мои сайты на Drupal (libraw.org,gpgpu.ru и так далее). В отличие от MovableType, антиспам-средства у Drupal развиты еще меньше, приходится пропускать без модерирования только зарегистрированных юзеров, но и это не вполне помогает.
Мировая часть проблемы в Drupal решена - ко всем ссылкам в юзерском контенте можно добавлять rel=nofollow, отчего спамить под гугл становится неинтересно. Остается яндекс, который rel=nofollow не понимает (насколько мне известно), но зато понимает "рамблеровский" (придуманный Димой Крюковым) тег <noindex>.
Сооответственно, нужно добавить три строчки кода к modules/filter/filter.module:
В noscript,noindex, a.. rel=nofollow помещается слово [link] которое и становится ссылкой для Javascript-disabled people (стандартные стили у Drupal такие, что картинка переносится на новую строку и красивая стрелка не получается).
Стандартный дисклеймер. Если вы не знаете что такое патч, то вам все вышеописанное не нужно.
Ссылками в комментариях спамят не только этот блог, но и мои сайты на Drupal (libraw.org,gpgpu.ru и так далее). В отличие от MovableType, антиспам-средства у Drupal развиты еще меньше, приходится пропускать без модерирования только зарегистрированных юзеров, но и это не вполне помогает.
Мировая часть проблемы в Drupal решена - ко всем ссылкам в юзерском контенте можно добавлять rel=nofollow, отчего спамить под гугл становится неинтересно. Остается яндекс, который rel=nofollow не понимает (насколько мне известно), но зато понимает "рамблеровский" (придуманный Димой Крюковым) тег <noindex>.
Сооответственно, нужно добавить три строчки кода к modules/filter/filter.module:
В noscript,noindex, a.. rel=nofollow помещается слово [link] которое и становится ссылкой для Javascript-disabled people (стандартные стили у Drupal такие, что картинка переносится на новую строку и красивая стрелка не получается).
Стандартный дисклеймер. Если вы не знаете что такое патч, то вам все вышеописанное не нужно.
Однако я этих модулей пересмотрел за последнее время более полусотни и из посмотренного, выбрал один именно от этого автора (легкий пост текстов с картинками) ибо этот модуль:
лучше варианта конкурента;
есть версия под 6-й друпал, чего у конкурента нет.
Да и вообще, судя по комментариям, мужик честно доделывал чужую работу до состояния, когда можно удобно использовать.
Ну ладно, его дело, собственно, но что делать пользователям модуля ?
Сейчас у меня Друпал орет, дескать неподдерживаемый модуль, снесите срочно! Соответственно, этот warning теперь будет висеть всегда, пока не снесу. И других, более важных, предупреждений я не увижу (если не буду проверять статус каждый день).
Я то перетерплю, у меня сайту два дня и текстов с картинками ровно два. Я могу и руками переделать все. А что делают те, у кого таких текстов сотни ? Замену я нашел, она более функционально, но и куда более монструозна. Но ведь это же перевставлять новые теги....
Умный Беляев не ошибался: Drupal с Postgresql не живет. Увы.
Последней каплей оказалась попытка побэкапить MySQL-ный вариант сайта и все-таки отнести его на Postgres (я его лучше знаю, лучше умею бэкапить, лучше умею настраивать и так далее).
Увы, Backup and Migrate получает список таблиц для бэкапа через 'SHOW TABLE STATUS', а это место, понятное дело, в постгресе не работает.
Впрочем, справедливости ради, на маленькой базе на MySQL оно работает в пару раз быстрее за счет query cache. А большой базы у меня пока нет.
Попытка использовать Drupal совместно с PostgreSQL 8.3 с грохотом провалилась. Основная функциональность работает, но стоит копнуть чуть глубже и налетаешь на проблемы. Например на эту, судя по переписке там ниже - проблема не только в блоках (ну и вообще, идея делать join по двум полям, одно числовое, а второе - какое-то, несколько потрясла)
Довольно печально, кстати, смотреть, как ошибка найденная 2 месяца назад - не поправлена, хотя с тех пор было 1 или 2 релиза.
Натыкался и на проблемы с форматом даты, при попытке поставить русский формат (DD.MM.YYYY) оно прямо в таком формате и в базу хочет записаться.
Еще про Drupal: словил невнятный подземный стук. Смена языка пользователем сначала работала, а потом почему-то перестала, работает только смена в системе в целом. В том же месте другие грабли: экспорт строк для перевода экспортирует только те строки, которые встречались системе при работе, нормального способа экспортировать все на свежеустановленной CMS - не нашел.
Резюме. Несмотря на то, что система мне очень понравилась, впечатление пионерской поделки временами перебивает все прочие.