Сразу скажу - мне не нравятся новые условия лицензирования MT. Не нравятся потому, что радость от того, что погремушку дают даром – исчезла, а новых (и нужных) функций взамен нет немного И это все. По этой причине, в частности, у меня до сих пор стоит MT 2.6 с чем-то (сам забыл), и вряд ли будет апдейт. Апдейт состоялся, причем вполне лицензионный (благодря членству в ProNet).

Тем не менее хочу сказать ряд лестных слов о MovableType и дать ряд советов, которые кому-то (когда-нибудь, где-нибудь) будут полезны, как всегда сдобрив это изрядной долей субьективности и радикализма.

Movable Type perk

###Перестройка и откуда она взялась Первое, что вызывает наибольшее число жалоб - rebuild. Так вот что я вам (уважаемые жалобщики) скажу.

У каждой СУКи есть такое невинное качество, о котором мало пишут в обзорах, которое редко фигурирует в оценках, но на которое вы, рано или поздно, наткнетесь. Это то, что называется “хакабельностью” – то бишь возможность “безболезненно” поменять кое-какие штучки в некой CMS, которую вы решили использовать.

Для меня лично оптимальная хакабельность выглядит так:

class MySite extends SuperCMS {
    function ShowArticleLink ($article_id) {
        //мои грязные хаки идут сюда
    }
}

Но идеала нет. У других людей хакабельность выглядит совсем по-другому (например, некоторые предпочитают писать на Python или Ruby, я уж не говорю про традиционный SSI). И вот ведь какая штука – подавляющее большинство традиционных PHP CMS-ок такой “хакабельности” не обеспечивают. К примеру - WordPress. Если вы с авторами сошлись во вкусе, и предпочитаете PHP - вам будет легко, поскольку шаблоны WP - чистый PHP без капли самодельщины, хочешь - хоть XSLT на него надень. Но только PHP. Все остальное - более менее вне обозримого поля деятельности (пока вы не начнете делать запросы к базе данных WP из своего кода самостоятельно). А Movable Type - пожалуйста. У меня так половина блога работает, по хорошему говоря - прямо в темплейты прошит PHP-код, делающий небольшие, но полезные вещи (навроде раскодирования трекбеков от блогов в Win-1251). Просто потому, что MT может выплевывать любую вещь, в которую можно вставить его-же, MT-шные теги.

Кстати, чтобы ребилды происходили повеселей - потрите ненужные шаблоны или выключите их ребилд про размещении новой записи.

###А я люблю в линейку Второе - шаблоны. Из всех встреченных мной систем шаблонов шаблоны MT - самые понятные. Почему?

  • XML-подобный синтаксис (все чего не хватает - возможности ставить теги MT в атрибутах HTML в фигурных скобках, как в XSL, чтобы подсветка синтаксиса не сходила с ума)
  • Отсутствие грязи навроде открывающих вопросительных знаков в шаблонах WP (они, кстати, бич любых страниц где PHP замешан в суп с HTML - ненавижу)
  • Внятные и человечные названия тегов

Программисты на JSP пользуются такой хорошей штукой, о которой большинство PHP-минималистов никогда не слышали - так называемые taglibs. Taglib - это набор тегов, которые дополняют обычный XHTML функциями, необходимыми для успешного встраивания его в веб-приложение. Как-правило, об их значении догадаться не представляет труда (если бы там был код на Java ситуация бы сильно осложнилась). Вот то что есть в MT - фактически Taglib. Автор движка Textpattern и вовсе взял такой подход на заметку, у него теги шаблонов даже имеют префикс namespace - txp, при случае даже валидными могут быть (при соответствующем DTD).

###Push и pull Третье - система вывода шаблонов в файлы. Вот тут, извините меня, ни один из суперблогокрутильников даже близко не стоял. В принципе - здесь важна разница концепции. Большинство движков - pull-системы, то есть вызываемый скрипт сам роется в базе CMS и вытаскивает нужный контент по запросу. MT – система push (в Bricolage это называется burn), то есть он генерирует (пресловутый rebuild) файлы явным образом. И у этого есть, ка коказалось, целый ряд существенных преимуществ, поскольку в MT можно выводить каждый тип архива неограниченным количеством способов, в неограниченное количество файлов. Хотите генерировать для блога .htaccess со специальными командами для mod_rewrite? Нет проблем. Хотите сменить схему архивов (и схему ссылок на них заодно) – элементарно, очищаете шаблон архива, меняя его на простой редирект и создаете новый. Хотите генерировать блог на embedded Ruby или на PHP? Нет проблем. Хотите генерировать XML на который потом будет накладываться XSL-шаблон? Секундное дело.

###Юникод Поставьте PublishCharset в mt.cfg в utf-8. До того как начнете писать записи, редактировать шаблоны и принимать комментарии.

Если решили сделать после - что же… во-первых, отключите все шаблоны от файлов (если шаблоны читаются из файлов). Во-вторых - сделайте текстовый дамп базы, в которой хранится ваша MT-инсталляция. В-третьих, перекодируйте этот дамп в utf-8, вычистите все из базы и залейте туда отконвертированный дамп.

###ЧПУ Ну вот тут помогать себе надо самим. Краткий рецепт таков. Mark Piligrim советует для “slug” (я предпочитаю называть это handle) использовать поле Keywords - все равно большинство поисковиков сегодня ничего, кроме free sex там не ищут. Например, handle этой записи - mt_with_pepper. Дальше оный handle элементарно включается в пермалинк. В моем же клиенте для блога есть специально подстроенная “напоминалка”, которая в случае забытого Handle говорит, что дескать…

No keywords, man!

То есть не заметив запостить что-то без handle практически невозможно. Далее следующий этап - как убрать назойливый index.чтототам из адресов. На это есть плагинчик - в каждой ссылке в шаблонах MT вставляем indexstripper=\“1\”, и умное регулярное выражение (как же я их ненавижу) уберет индекс вон.

При этом в Archiving прописывается для отдельных записей следующая страшная комбинация (копировать как одну строку):

<$MTArchiveDate format="%Y/%m/%d"$>/
<MTIfEmpty var="EntryKeywords"><$MTArchiveDate format="%H.%M.%S"$></MTIfEmpty>
<MTIfNonEmpty var="EntryKeywords"><$MTEntryKeywords$></MTIfNonEmpty>/index.php

Тег IfNonEmpty появился только в MT 2.66, для более ранних версий применяется такой же, только Not (тавтология торжествует).

В переводе на человеческий язык - создавать папки для года, месяца и дня, если для записи не указано ключевое слово - папку для записи со временем ее написания, если ключевое слово указано - то папкудля записи, названную этим ключевым словом, и в файл index.php в этой папке записать статью. Плюс не мешает “хакнуть” (пардон, обработать напильником) сам код MT.

Более того - в свежих версиях MT в базе уже есть поле entry basename - пока что к нему нет доступа через окно редактирования, но оно уже используется движком (туда кладется от-dirify-енный заголовок) для вывода файлов в стандартном архиве, и существует тег шаблонов <$MTEntryBasename$>. Только я вам этого не говорил.

И еще. От лишних папок и index.php тоже можно избавиться (чтобы было по файлу на каждую запись). Как - оставлю пытливому читателю на дом.

###Русские даты Tут все довольно прямолинейно, качаем и ставим. Склонять названия месяцов оно конечно не будет, но лучше чем ничего. Само собой, что “инъектировать” зловредный код с русскими датами нужно в той кодировке, в которой у вас блог (надеюсь что это UTF-8, иначе – чистить лук в подводной лодке и пусть вам слезится).

Плюс - (вот это чудовищный американизм) – неделя у MT начинается в воскресенье. Чтобы исправить эту воистину техасскую тупость, воспользуйтесь вот этими рекомендациями от Kost’a.

###Категории Как уже говорилось, полей для URL-handle в MT (как и в большинстве CMS, не ориентированных как следует на интренационального потребителя) нету. Есть функция Dirify, которая по идее должна очищать некий текст до его пригодности для названия файла или директории. Само собой, транслит эта функция не делает. А если мы хотим блоггинг на грузинском вести?

Следовательно - лезем в MT, и находим там для каждой категории спрятанный довольно глубоко Category Description. Вот он и будет нашим URL-handle (то что там хранится можно в сокращенном варианте прописать в название категории – оно теперь не имеет отношения к URL и может быть произвольной длины). В каждую категорию пробиваем нормальный латинский handle, в архивировании переводим с MTCategoryLabel на MTCategoryDescription - и вот, русские категории и нормальные URL без всяких dirify и /archives/cat_eiooen_oieiieeiae.html.

###Trackbacks Если у вас публичный блог, включите трекбеки и их autodiscovery (чтобы МТ публиковал на страницах записей RDF-фрагмент), и установите плагин для их перекодирования (иначе комфортного обмена трекбеками хотя-бы по-русски вам не видать).

###Напильник Убрать ссылки на трекбек, поиск и комментарии - что удобнее всего делать mod-rewrite (ибо на них идут данные из форм). Все формы переключаются в post (комментарии в MT берут POST, поиск - и POST, и GET), и в .htaccess прописывается:

RewriteEngine On
RewriteBase /
RewriteRule ^search/ “/cgi-bin/mt-search.cgi”
RewriteRule ^comments/ “/cgi-bin/mt-comments.cgi”

и выражение для трекбеков (с регулярными выражениями я всегда был не в ладах, но думаю что одним wildcard’ом дело обойдется).

Хинт - .htacces, как упоминалось выше, тоже можно генерировать с помощью MT. Один index template.

###К черту теги, я вам говорю Не только нормально хранить свои записи, но и удобно их писать. На помощь приходит поющий дуэт Markdown и SmartyPants. Но какая досада, SmartyPants выводит американские кавычки! Открываем ЛюбимыйТекстовыйРедактор и делаем в коде SmartyPants поиск и замену:

Открывающие двойные кавычки
&#8220 меняем на &#171

Закрывающие двойные кавычки
&#8221 меняем на  &#187

Открывающие внутренние кавычки
&#8216 меняем на &#8222

Закрывающие внутренние кавычки
&#8217 меняем на  &#8220

Один нюанс – внутренние кавычки надо набирать одинарные, а не двойные (что в принципе правильно). И вот – получаем “елочки” и ‘лапки’. В базе MT тексты останутся “как набрано”. “Плагины к браузеру IE” вместе с веб-формами забудьте как страшный сон. Кстати, и SmartyPants и Markdown можно использовать автономно от MovableType (просто как скрипты на Perl). По правде говоря я так и делаю (пишу HTML в Markdown и потом одной кнопкой перевожу в валидный XHTML).

###Мелко порезать Большинство модулей (template modules), которые, например, отвечают за навигационный блок, нужно не только отделить от шаблонов, но и сделать их отдельными Index-темплейтами. Тогда при одном ребилде такой блок будет перестраиваться один раз. Во все остальные страницы его стоит вставлять уже с помощью include того языка, на котором у вас эти страницы будут написаны. Чем меньше у вас будет выводов в разные темплейты, тем быстрее будет ребилд, и до своей трехтысячной записи вы доживете без инфаркта.

###И закрыть браузер А теперь забудьте, что писать в блог надо браузером. Есть программы, обеспечивающие офлайновое превью того, что вы пишете (с орфокорректором), сохранение всех записей и автоматическое размещение ваших заметок на блоге с помощью XML-RPC (который только у MT в достаточно развитом состоянии - по нему даже картинки можно заливать).

Редакция рекомендует читателям ecto от англоязычного японца из Голландии Адриана Тейселинга для MacOS X и BlogJet от будущего нашего IT-бизнеса Димы Честных. Обе упомянутые программы в целях поддержания интернационализма рекомендуется купить за деньги.

Чем не ÜberCMS? Это я еще не дошел до момента, когда вместо шаблонов MT (например, для отдельной записи) вы выводите пустые файлы, а все запросы к статьям обрабатываете через один файл на PHP, просто делая запросы в базу MovableType напрямую. Я еще не дошел до того, что у MT в принципе есть “зеркало” API на PHP (поддерживает существенно меньше функций но тем не менее полезно).

P.S. Как всегда, редакция не несет ответственности за… и т.д. Тем, кто вышесказанное будет сравнивать с тюнингованной девяткой-жигули передаю опосредованно, что это скорее LandRover в заказной комплектации. Это удобная хакабельность в действии. С перцем. Не на 93 процента лучше чем чудовищно, а просто – удобная.

P.P.S. Вот был бы MT opensource- запостил бы всю эту лабуду для скачивания, по хорошему – пара часов работы.