1. Кнопки 'Split summary at cursor'/галки 'Show summary at full view' - нету. Но жить можно с визуальным редактором: TinyMCE получает кнопку, аналогичную Split, галка 'Show summary' при этом какбэ по умолчанию, но если что-то написать в Summary, то в списках постов будет именно оно.
Логика чуть другая, но жить можно.
Со вставлением картинок тоже чуть иначе, но тоже жить можно:
Поигрался с тестовым сайтом, поапгрейженным из Drupal6 в Drupal7, испытал мучительное недоумение.
Снес нахрен, поставил D7 с нуля, недоумение не стало менее мучительным.
У меня, по большому счету, требований очень мало:
Мне нужно писать тексты, причем я готов их прямо в HTML фигачить. От визивигов яваскриптовых - тошнит, если честно.
Мне нужно управлять текстом аннотации, которая на глагне показывается. И средств D6 мне более чем хватает (а там можно, если не доверяешь автомату, разделить текст на аннотацию и хвост, аннотации поставить галку "входит в полный текст"), т.е. я могу сколько хочу абзацев сделать аннотацией, а могу ее отдельно написать).
Мне нужно просто вставлять картинки:
простой браузер того, что уже залито на сервер.
простая кнопка, позволяющая поаплоадить (и задать alt/title, чем я не пользуюсь, впрочем)
вставка с указанием размера (оригинал, какие-то стандартные, возможность задать свои), выравнивания и действия при клике на картинку (ничего, открыть полный размер в новом/том же окне, перейти по ссылке).
Ну теги-категории, понятно и прочие мелкие галки (кросспост в ЖЖ, режим комментариев, задание URL)
Все, больше ничего не надо. Если захочу клип с Youtube - руками вставлю, надо редко.
Всю эту функциональность умеет Drupal6 из коробки + image/image assist + чуть-чуть других модулей.
А вот D7 привычную картину D6 нарушает в куче мест:
В очередной раз подошел к снаряду по имени Drupal7. Имею сказать:
1. Если у вас PostgreSQL, то даже Drupal 7.9 (текущий) не сможет поапгрейдиться гладко. Оно пытается сконвертировать поля типа text в тип bytea, а в PostgreSQL 9.1 (другие не пробовал) автоматического преобразования этих типов нет.
Лечение (применяется к базе PostgreSQL до апгрейда):
CREATE OR REPLACE FUNCTION text2bytea(text) RETURNS bytea AS
$BODY$
begin
return convert_to($1,'UTF-8');
end;
$BODY$
LANGUAGE 'plpgsql'VOLATILE;
CREATE CAST (text as bytea) with function text2bytea(text) as implicit;
Может я тут что и перепутал и as implicit не нужно, но работает и "базовый" сайт (core modules) переносит.
2. А вот в том, что касается contributed modules - счастья у меня нет:
Вдруг кому поможет, поэтому тут (у меня теплится слабая надежда, что в ближайшие годы новых экспериментов с летним временем не будет, поэтому самому такие записки вроде не нужны).
PHP:
У PHP база данных таймзон вшита в пузо и, конечно, не обновляется регулярно.
Но есть pecl-timezonedb, который ее оверрайдит, со свежей базой (последняя имеет номер версии 2011.13), с этим расширением с таймзонами все станет отлично и любимая всеми Europe/Moscow будет работать как полагается по новым правилам.
Но если вы живете под FreeBSD, то там /usr/ports/misc/pecl-timezonedb не обновлялся очень давно, посему:
Меняем там в Makefile 2010.9 на 2011.13
удаляем distinfo
make && make install
Добавляем timezonedb.so в список extensions.ini (на FreeBSD это сделает make install)
Перестартовываем PHP-fastcgi или Apache или что у вас там работает процесс-сервером для PHP
Ура, можно накатить первый стакан.
Drupal 6:
Сам по себе сразу начинает жить правильно (ну, насколько мне показалось). Т.е. таймзона меняется после апдейта PHP-timezonedb с +0300 на +0400 сама.
Но! В Administer-Date-and-time есть настройка про User Configurable time-zone. Если она включена, то пользователю будут показываться даты-времена в его таймзоне. И весь созданный им контент будет иметь время создания рассчитанное из юзерской таймзоны.
Но. Юзерская таймзона специфицирована в секундах смещения от UTC.
Выходов два: или для всех российских пользователей взять и поправить скриптом (по хорошему, с учетом даты регистрации), или просто отменить настройку пользовательских таймзон.
Я пошел по второму пути.
Вот берем два Друпальских модуля внешней авторизации:
Facebook Connect - позволяет одним кликом создать аккаунт на друпальском сайте, все мгновенно.
OpenID - аккаунт создать позволяет, но не верифицированный, уйдет E-mail, на полученный линк надо будет кликнуть (да и то, эта функциональность не так давно появилась, раньше можно было только существующий аккаунт привязать к OpenID-URL).
И сначала я на поведение OpenID ругался (про себя, да и вслух), а потом осознал сермягу:
В случае Facebook (ЖЖ, Твиттера, Вконтакте, MailRU....) я доверяю (или не доверяю) конкретному сервису (платформе). А они, в свою очередь, пытаются (своими немаленькими ресурсами) отличить людей от роботов и все такое. Список доверенных - невелик, а если вдруг чего, то и отозвать доверие недолго.
В случае протокола (технологии) - доверие делегируется неизвестно кому. Какому-то Васе или Пете, который асилел OpenID-сервер поднять. Но я точно знаю, что средний спамер (что по каментам, что по почте) технологически гораздо продвинутее, чем просто средний Вася. Более того, спамеры на порядки активнее "просто пользователей".
Получается, доверять технологии - нельзя. Платформе, за которой стоят конкретные люди и силы, заинтересованные в хорошей работе платформы - можно. Платформа может быть распределенной, конечно, но не изолированными островками неизвестного количества.
В режиме записок для памяти, пусть проиндексируется и лежит.
В последнее время меня достал спам в каментах. Мало того, что пробивают капчу и статистический антиспам, по каким-то причинам даже то, что как спам детектируется - вызывало приход почтового уведомления. Воспроизвести не удалось (все что я писал "вроде спама" - просто ложилось в спам же, без уведомления), пришлось двигать мебель и менять девочек.
Если у вас по каким-то причинам есть запись в таблице node, но нет ни одной записи с таким nid в node_revisions, то у вас ВНЕЗАПНО начнут портиться права доступа. Причем rebuild permissions будут помогать ненадолго, до попытки создания очередной node.
Детектируется проблема элементарно:
select nid from node n where not exists (select nid from node_revisions r where r.nid=n.nid);
Лечится - таким же delete.
Но я сегодня чуть не фалломорфировал, разбираясь.
Почему создание записи с revision не обернуто в транзакцию - мне удивительно, но подозреваю что это привет от MySQL.
Цирк с конями Приколы в национальном домене продолжаются, я уже смеяться устал.
Комедия в бесконечном числе действий:
Регламент регистрации в .РФ предусматривает отказ регистрации в случае, если нарушается нравственность и мораль. Список нарушений морали и нравственности установлен КЦ и широко обсуждался (гуглить по словам "ебля с перископом"), в том числе и в этом блоге.
Прошел уже месяц с приключениями, блокировками и прочим боданием Руцентра и КЦ, аморальный список действует (в числе прочего, домен старые-бляди.рф довольно долго торчал в whois с личным E-mail Лесникова в контактных данных, недавно поменяли).
И начинает снимать с регистрации уже зарегистрированные домены.
Которые ТУТ ЖЕ перехватывают другие регистраторы, а вы как думали.
Понятно, что у многих/большинства Руцентровских доменов Администратор - сам Руцентр, он может направить (сам себе?) письменное заявление о снятии с регистрации и снять. А владелец домена - при этом может пососать упса с витамином "С".
Попкорн кончается, надо бежать в магазин за новой дозой....
По случаю выходных, помацал Drupal 7 (в связке с PostgreSQL 9, гулять так гулять). Внутрь особо не заглядывал, просто покрутил в руках на тестовом сервере.
Имею сказать:
Штука - работает. Ну то есть я пробовал свежую инсталляцию, а не апгрейд старой, с апгрейдом лично у меня будут проблемы.
Модулей, прямо скажем, не хватает. Я смотрел список используемых у меня на разных сайтах, дойдя до буквы I обнаружил уже две проблемы и остановился. Проблемы такие:
Нету inline tags, а я этот модуль использую для публикации через BlogAPI (собственно, BlogAPI тоже нет, но вроде есть какая-то замена). Как-то можно обойтись, что-то похакать, может быть в замене BlogAPI категории работают.
Нету GeSHi Filter (syntax highlighter для кусочков кода) и это уже совсем большая потеря. Замены есть и не одна, но все с другим синтаксисом, вместо <code> что-то еще, а это готовые тексты-каменты править.
В-общем, пусть поживет еще несколько месяцев без меня....
Развлекаюсь тут с Amazon EC2 и вот чего не могу понять
Хочется, на самом деле, SUSE 11.2, потому что весь девелопмент проекта на нем и бинарники, соответственно, переносимы без лишних ужимок (и почти гарантированно думать про это не надо)
Но! Я попробовал два готовых имаджа с SUSE нужной версии и нужной битности и оба не загрузились. На консоли неясное, по ssh не пускают. Попал на круглую сумму, центов на пять.
С Амазоновским AMI (Amazon Linux) - никаких проблем, но см. выше.
Риторический вопрос, это опять моральные индусы меня окружают или же просто два раза из двух не повезло?
Update: сошлись с ними на 12-й федоре. И проект собирается (gcc 4.4 из коробки и все такое) и имеющийся образ с EBS - загрузился.
Скажите, а в чем тут обман? У меня задача - заменить самогенеренные, чтобы броузеры и SVN-клиенты не ругались на левый сертификат, никакого е-коммерса. Заплатить за это $10-15 в год с сайта (SVN-репозитория) мне совершенно не жалко, но может быть вышезаявленная цель не будет достигнута? Четвертак - уже жалко :).
У GoDaddy - chained сертификаты, но мне не кажется, что в 2010-м году это должно создавать какие-то проблемы. У RapidSSL все обещано "совсем честным"....
Когда я работал в одном маленьком сумасш начальником , меня очень интересовал вопрос: а что будет, если ужасный плоский рубрикатор Топ100 (из 50+ рубрик первого уровня) заменить на правильный иерархический?
Тогда у меня не хватило смелости принять это решение. Нет, если бы начальство велело, то я бы с превеликим удовольствием, но , а у меня не хватило силы воли, да и пользователи привыкли.
Прошло 8.5 лет и новое руководство Top100 таки решилось.
Вопрос у меня следующий: сейчас комментарии проиндексированы как отдельные документы (это делает возможным позиционирование в конкретный камент и это хорошо), отчего результатов стало больше (и это плохо). А как надо?
Критика всплывающего окна и прочие наезды на javascript не принимаются, со временем я переделаю это нормальным модулем со всякими наворотами, заодно научусь делать модули под Друпал, но пока оверлей на jQuery оказался сильно быстрее, чем разбираться еще и в этом.
Версия 0.02 исправляет известные на сегодня проблемы:
Если комментарий один (добавился один свежий), то неправильно импортировалось имя комментатора. Это фишка XML::Simple (разное поведение с одним значением и с несколькими), про которую я постоянно забываю.
Неправильно устанавливалась homepage автора комментария (ссылка на его ЖЖ).
Добавлен скрипт fixauthors.pl, который правит накопленные ошибки прямо в БД сайта.
за несколько дней эксплуатации совершено опротивел. Изрядную часть его достоинств я почикал, оставил только импорт комментариев, но и с этим оно справляется не на пятерку:
Комментарии с пустым сабжектом - так и оставляет пустым, в результате 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
самостоятельно (запускать после импорта, когда все теги/категории уже созданы).
Синхронизация Drupal с ЖЖ оказалась гораздо более простым делом, чем в случае Movable Type:
Ставим
Ставим (плюс нужные модули для работы jbackup.pl)
И все работает (PROFIT!)
Ну, если быть точным, то для LJ Sync нужно поставить еще , а то синхронизированное туда приезжает тут же обратно, второй копией.
А если быть совсем точным, то 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 UI.
В качестве короткой заметки на тему вчерашнего и ряда следующих текстов.
Для Drupal есть модуль , который делает человеко понятные урлы: заменяет пробелы на минусы (или подчеркивания), меняет ужасные /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 и только это ее и берегло.
Как нам 