Drupal

Drupal Comment Notify (опять)

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 = ....

Продолжаю воспитание модулей 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

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

comment_subscribe-12-pgsql.diff.gz

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

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

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

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

Мне на 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

    Последние два месяца я собирался прикрутить к 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, вторая попытка

    В духе нового патча для 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 < 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Внезапно возникшее отвращение к 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

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

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

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

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

    Drupal, BlogAPI и теги

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

    По идее, для этого предназначен Aggregator, но его интеграция с Taxonomy запланирована только в Drupal 7. Кроме того, pull мне очень не понравился, хочется push. Для push есть BlogAPI, там даже поддерживается установка категорий (тоже довольно диким способом, ибо информация о словарях недоступна, можно получить только список терминов), но вот установка тегов (т.е. терминов, которых в словаре может не быть) через стандартный BlogAPI невозможна. mt_tags - не поддерживаются и не обрабатываются.

    Я уже почти поправил BlogAPI (всего то нужно задать один параметр конфигурации - в какой словарь класть теги, остальное все тривиально) и оно уже почти работало, но нашлось готовое решение.

    Inline Tags делает все что нужно. Не стандартным путем (т.е. использовать готовое поле tags в blog-редакторе и передачу значений в mt_tags), но вполне приемлемым: список тегов пишется в [tags][/tags] и все работает (проверено).

    Drupal: микроправки к BlogAPI

    Все-таки Drupal пишут индусы. Пришлось по уши залезть в код, чтобы выяснить, отчего не работают metaWebLog.getCategories и mt.getCategoryList. Просто забыли проверить авторизацию, отчего, по счастью, просто все сломалось, а не стало отдавать все всем наружу. Не тестируют.

    Патч: blogapi.diff.gz

    Патч зашлю в Drupal сегодня.

    Стандартное уведомление: если вы не знаете что такое патч, то он вам не нужен.

    P.S. Работу с массивами в PHP проектировали ненатуралы.

    Update: правка вошла в Drupal 6.5

    nofollow-noindex патч для Drupal 6.4

    Ссылками в комментариях спамят не только этот блог, но и мои сайты на Drupal (libraw.org,gpgpu.ru и так далее). В отличие от MovableType, антиспам-средства у Drupal развиты еще меньше, приходится пропускать без модерирования только зарегистрированных юзеров, но и это не вполне помогает.

    Мировая часть проблемы в Drupal решена - ко всем ссылкам в юзерском контенте можно добавлять rel=nofollow, отчего спамить под гугл становится неинтересно. Остается яндекс, который rel=nofollow не понимает (насколько мне известно), но зато понимает "рамблеровский" (придуманный Димой Крюковым) тег <noindex>.

    Сооответственно, нужно добавить три строчки кода к modules/filter/filter.module:

    Сделано примерно так же, как для Movable Type:

    • Сама ссылка заменяется на явоскриптовую
    • В 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:

    Сделано примерно так же, как для Movable Type:

    • Сама ссылка заменяется на явоскриптовую
    • В noscript,noindex, a.. rel=nofollow помещается слово [link] которое и становится ссылкой для Javascript-disabled people (стандартные стили у Drupal такие, что картинка переносится на новую строку и красивая стрелка не получается).

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

    Наблюдения за жизнью пауков в банке

    В Drupal-сообществе есть (или был?) такой Vrencian Zoltan. Буквально сегодня у него отняли доступ к CVS, мотивируя это тем, что он дублирует уже существующие модули.

    Однако я этих модулей пересмотрел за последнее время более полусотни и из посмотренного, выбрал один именно от этого автора (легкий пост текстов с картинками) ибо этот модуль:

    • лучше варианта конкурента;
    • есть версия под 6-й друпал, чего у конкурента нет.
    Да и вообще, судя по комментариям, мужик честно доделывал чужую работу до состояния, когда можно удобно использовать.

    Ну ладно, его дело, собственно, но что делать пользователям модуля ?
    Сейчас у меня Друпал орет, дескать неподдерживаемый модуль, снесите срочно! Соответственно, этот warning теперь будет висеть всегда, пока не снесу. И других, более важных, предупреждений я не увижу (если не буду проверять статус каждый день).

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

    Drupal + PostgreSQL = фиаско

    Умный Беляев не ошибался: Drupal с Postgresql не живет. Увы.

    Последней каплей оказалась попытка побэкапить MySQL-ный вариант сайта и все-таки отнести его на Postgres (я его лучше знаю, лучше умею бэкапить, лучше умею настраивать и так далее).
    Увы, Backup and Migrate получает список таблиц для бэкапа через 'SHOW TABLE STATUS', а это место, понятное дело, в постгресе не работает.

    Впрочем, справедливости ради, на маленькой базе на MySQL оно работает в пару раз быстрее за счет query cache. А большой базы у меня пока нет.

    Drupal и PostgreSQL

    Попытка использовать Drupal совместно с PostgreSQL 8.3 с грохотом провалилась. Основная функциональность работает, но стоит копнуть чуть глубже и налетаешь на проблемы. Например на эту, судя по переписке там ниже - проблема не только в блоках (ну и вообще, идея делать join по двум полям, одно числовое, а второе - какое-то, несколько потрясла)

    Довольно печально, кстати, смотреть, как ошибка найденная 2 месяца назад - не поправлена, хотя с тех пор было 1 или 2 релиза.

    Натыкался и на проблемы с форматом даты, при попытке поставить русский формат (DD.MM.YYYY) оно прямо в таком формате и в базу хочет записаться.

    Еще про Drupal: словил невнятный подземный стук. Смена языка пользователем сначала работала, а потом почему-то перестала, работает только смена в системе в целом. В том же месте другие грабли: экспорт строк для перевода экспортирует только те строки, которые встречались системе при работе, нормального способа экспортировать все на свежеустановленной CMS - не нашел.

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

    Pages

    Subscribe to Drupal