Темплейты MovableType

Меняя, в очередной раз, много темплейтов MT, задумался об более человечной их структуре.

Я уже писал, что темплейты MT расчитаны скорее на секретаршу, чем на программистов продвинутых пользователей. В то же время, позиционируется MT на продвинутый рынок. Даже возможность прицепить к блогу весь набор темплейтов одним движением руки уже сильно бы полечила, появились бы генераторы темплейтов на препроцессоре и т.п.

На мой вкус, человеческая темплейтная система должна строиться от других принципов:

  • Нужны layout-темплейты. Т.е. задание структуры (количество колонок, их состав и пр.) и общих по всему блогу элементов (header, footer, навигация) в одном месте. Конечно, в сложных случаях layout-ов будет много, но почти гарантированно один layout распространяется больше чем на одну страницу. Редактировать одно и то же в нескольких местах - глупо.
  • Нужны блоковые темплейты. Очевидный пример блока - это представление первых строк записи в индексах. Оно повторяется во всех архивах, в результатах поиска и так далее. Редактировать такую кучу мест - не менее глупо, чем править заголовки по всему блогу

Русификация MovableType

Русификация MovableType состоит из таких шагов
  1. Русификация дат
  2. Русификация имен файлов для dirify
  3. Перевод темплейтов и системных сообщений
Первые два пункта требуют правок кода, каковые правки и были сделаны. Все действия производились над MovableType 3.33

UTF-8 и только он

Мы живем в 21-м веке, когда передача лишних байтов через всю планету не стоит вообще ничего. Работа с многобайтовыми кодировками сейчас поддержана везде, на очень старые версии браузеров закладываться смысла нет (примечание от меня, как от автора Russian...

MovableType - сосет

Попытка разобраться с MovableType оставила двойственное впечатление:
  • Штука, несомненно, очень хорошая, вложена масса труда
  • Но при этом, сосет не нагибаясь
и ведь чем ближе рассматриваешь, тем больше хочется ругаться. Ужос просто!

Сначала о хорошем:

  • Штука - работает.
  • Поддерживается UTF-8, причем без глупостей. PostgreSQL-ю UTF8 ставят насильно, за что авторам MT большое спасибо - у меня в силу исторических причин default client encoding другая (скажем, багзиллу пришлось недавно дохакивать в этом месте).
  • Можно поставить и сразу начать
  • ...

Растет, голубчик

За три месяца количество живых сайтов в домене .RU увеличилось на 12 процентов: 24 сентября их было 477 тысяч, 22 декабря - 535 тысяч.

Двенадцать процентов квартальных - это почти 60% годовых (а с марта по сентябрь росло так же).

А если просто посчитать в дЕньгах за базовые услуги, двадцатка в год за домен и десятка в месяц за хостинг, то этот рынок прирос за квартал на 8 миллионов. Это без третьего уровня, com, info и так далее.

Postgresql 8.2, UTF8 и русские буквы

В отличие от PostgreSQL 8.1.x, табличка преобразования UTF8<—>CP1251 уже нормальная, € там имеется.

Однако сама идеология осталась порочной, мне не нужны ошибки при попытке конверсии, я хочу их маскировать. Впрочем патч от 8.1.5 вполне подходит и к 8.2

Трудности перевода

На сайте СУПа весь октябрь висел замечательный контакт для потенциальных сотрудников
    ... E-mail... ...телефон... Алексей Ишков Director of Execution

Потом одумались и перевели:

    ...... Алексей Ишков Директор по производству

Postgresql 8.1.x и UTF-8

В PostgreSQL начиная с версии 8.1.4 ужесточили правила конверсии из UTF-8 в однобайтовые кодировки. Если раньше при неконвертируемом символе было предупреждение, которое попадало в лог (или в приложение, если оно читало Warnings) и все работало, то сейчас неправильный символ приводит к ошибке и запрос не выполняется.

Тут же выяснилось, что у этих криворуких уродов таблица преобразования из/в windows-1251 неверная, там пропущен символ €. Пришлось, как водится, править.

патч для таблиц перекодировки UTF8<->CP1251 PostgreSQL 8.1.4 и 8.1.5

Заметим, что введение такой безусловной функциональности в minor-версии &mdash это моветон. Разработчики нам обещают, что в пределах minor-а все будет работать без backup/restore базы, а это нифига не так, приложения просто перестали работать совсем. Впрочем, багу с конверсией посчитали vulnerability, что вполне верно если перекодировке подвергается пользовательский ввод. Но не во всех приложениях это впрямую пользовательский ввод, более того у нас правильность символов контролируется на этапе ввода, а значит нам такая неотключаемая проверка нафиг не нужна.

Пришлось делать патч, который ее относительно safe выключает: все неизвестные символы при преобразовании UTF8->однобайтная кодировка меняются на пробел. Вот этот патч: качать. Естественно, этот патч можно рекомендовать только тем, кто понимает что делает.

Pages

Subscribe to blog.lexa.ru: все статьи