Опять про MovableType и dirify

Сегодня меня порадовали, дескать подписка на комментарии в твоем блоге не работает.

Действительно, на ряде записей ссылка "подписаться на комментарии к этой записи по RSS" была битая, вела на несуществующий фид.

Разбирательство показало, что:

  • Это касается только записей, где последняя буква (буквы) в title - непечатная (мягкий-твердый знак или знаки препинания). Эти символы дирифицируются в подчеркивание.
  • Сами такие записи имели URL вида date/bla_bla_.html (фиды: bla_bla_.xml).
  • Ссылки из списков записей (по месяцам, по рубрикам) были правильными.
  • А вот ссылки, сформированные через <$MTEntryBaseName$> вели на bla_bla.html.
Засучив рукава, я полез читать исходники MovableType и мне открылось страшное.

Формирование URL записи у меня делалось вот так:

<$MTArchiveDate format="%Y/%m/%d"$>/<$MTEntryTitle dirify="1"$>.html
Рассмотрение исходников показало, что этот темплейт делает ровно то, что написано: вызывает dirify($title), результат может иметь подчеркивания на хвосте если заголовок кончается на "непечатные" символы.

А вот basename записи - это отдельное понятие. Basename формируется отдельно, вызовом встроенной функции make_unique_basename(), которая, помимо вызова dirify(), еще и скусывает лишние подчеркивания-минусы с хвоста. Замена подчеркиваний-минусов делается позже и довольно грязным хаком. Сформированный basename не имеет ничего общего с URL, который описан в Archive mapping

Нормально, да ? Имеем два URL, один используется при создании архивов и вообще почти везде, но недоступен в тегах (макросах). Второй - доступен в виде тега. Да, первый вычисляется на лету при выводе HTML-представления, а второй - хранится в базе.

Выход один: нужно таки формировать URL так же, как формируется basename. Для этого сгодится, например, такой Archive mapping, который сформирует ровно то, что хочется (вторая часть эквивалентна макросу %_b, но явное написание понятнее):

<$MTArchiveDate format="%Y/%m/%d"$>/<$MTEntryBaseName separator="_"$>.html
Перегенерируем весь сайт, для старых URL с подчеркиваниями на конце делаем или RewriteRule или симлинк. Я сделал симлинки, файлов таких было немного.

Естественно, описанное выше поведение - это ошибка в логике MovableType. На пустом месте размножили понятия, не гарантировали между ними связи и совершили прочие программистские грехи. Заметим, что default settings - это <$MTArchiveFile$>, который тоже вычисляется, что может привести к сюрпризам в ряде ситуаций).

Выводы обычные: другой бы на моем месте всех бы убил, один бы остался.

Comments

Всё правильно, MTEntryTitle не предназначен для URL. Это уже хак получается, если title дирифицировать. А вот MTEntryBaseName это правильный тег для формирования URL.

Андрей, это был рекомендованый (!) хак для MT 3.3, прямо из документации по dirify.

А претензия вообще к другому. Мы вычисляем URL на этапе template map, и это даже кое-где работает. Нормально, да ?

Работает и хорошо! :)
Есть плагин для фотогалереи, так там все URL и Archive Mapping сделаны именно через дирифицирование EntryTitle. Хотя нет, там дирифицирование всего, чего только можно, включая категории. dirify это ведь глобальный атрибут, который можно применить к любому тегу.

P.S Что-то не нашёл я в документации информации про этот хак.

Я могу еще раз повторить суть претензии
а) есть генерация имени файла (т.е. URL) в архиве (Template mapping)
б) есть некое стандартное имя файла.

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

Леша, а как вы побороли херню-с с тэгами на родной мове? Такое впечатление, что МТ4 их не узнает, и каждый заданный по-русски тэг воспринимает как новый. Вот, например, что он творит:

http://fiolent.biz/cgi-bin/mt/mt-search.cgi?tag=%D0%B3%D0%B5%D0%BC%D0%BE...

Ткнул в линку, не понял. Находится же 2 записи на геморрой и три на пьянку.

Пальцем ничего не трогал. Все и так работает.

http://blog.lexa.ru/tags/%D0%B1%D0%BB%D0%BE%D0%B3%D0%BE%D1%81%D1%84%D0%B...

Записей-то находится, но вот в меню каждый из двух или трех тэгов отображается отдельно, с отдельной -- я так понимаю -- заметкой, ему соответствующей. При этом на англоязычные "cardhu" или "test" все чудненько добавляется в ту же кучу.

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

У меня было такое в Movable Type 3.3. Оказалось, что нужно таблицу с тегами сделать в utf8 и сравнение utf8_general_ci. Лучше вообще это со всеми таблицами сделать.

Ага, спасибо, нашел это решение независимо. Почему-то уважаемый мастерхост полагает, что единственно правильная вещь в мире -- это 1251 по умолчанию.

Да, русские теги ввожу вручную, там автоподсказка для русского не работает. Там бывает поэтому разница в написании, я ее временами в Manage Tags ликвидирую.

Вывод - стандартным widget-ом от MT4, я там кроме заголовка ничего не менял. Существенная часть вот:

<ul class="widget-list">
<MTTags>
<li class="rank-<$MTTagRank max="10"$> widget-list-item">
<a href="<$MTTagSearchLink$>"><$MTTagName$></a>
</li>
</MTTags>
</ul>

А все хаки для дирифая уже применены для версии 4.0?

А там тех хаков (патчей) - только добавить русские буквы в таблицу транслитерации UTF8.

Мой патч для 3.3 туда подходит. Вот этот вот:
http://blog.lexa.ru/files/patch-dirify.gz

Да-да, не сомневаюсь, сам тож применял, и именно ваш (собственный уж больно коряв, хоть и тоже подходит ;)), правда только статическую версию патчей; это был просто фол последней надежды. Ну вот совсем не понимаю, что с этим делать...

Это фигня. Мой MT в админском интерфейсе и в сообщении "комментируете слишком часто" (которое показывается комментаторам без JS) временами срывается на испанский.

Я испанский язык нигде не ставил (ставил итальянский формат даты) и где это отключить - тоже не представляю.

Витус прав, слишком большая система уже.

А может БД (MySQL) не разуметь нормьально UTF-8? Вы какую пользуете?

У меня постгрес (8.2-чего-то). Но я не думаю, что у MySQL в этом месте проблемы, все-таки сейчас 21-й век.

что возвращает нас к вопросу о миллиарде обезьян и пишущих машинок

usenet показал, что войну и мир так не написать.

Меня вот больше интересует другое: летают ли авторы софта для боинга на своем произведении ?

у меня есть знакомая, которая долгое время была финдиром небольшой авиакомпании.

до сих пор она старается поездом, поездом

Я подумал о карьерных возможностях:
- потом в РЖД, пересесть в только автомобиль
- потом в ГАИ, не выходить из дома
- потом в ЖЭК

а потом в пампасы (только не с палаткой от Marmot ;)

Летают. Я говорил что "да я! да ни за что!", но мне объяснили что дублирование и ручное управление для того и делают, чтобы топливные насосы могли всякие дебилы программировать.

А при ручном управлении топливо качают тоже вручную ?

> А при ручном управлении топливо качают тоже вручную ?
Ага. Вдвоём, или втроём в зависимости от кратности дублирования. :-P

Add new comment