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

И так, технических причин, побудивших меня отказаться от Drupal, которым я пользовался последние 5 лет, было три:

1. Хлопотность обслуживания. Помимо регулярных патчей для самого движка едва ли не каждую неделю выходили обновления для парочки из трех десятков используемых модулей. А автообновления в Drupal 6 предусмотрено не было.
2. Избыточная сложность. Все-таки Drupal предназначен для создания куда более сложных и развесистых сайтов, чем личный блог. Поэтому многие его возможности в лучшем случае играли роль мертвого груза, а в худшем — требовали совершать лишние клики, действия и шанс как-нибудь накосячить.
3. Тяжеловесность. За функционал надо платить, и плата выражается в потребляемой памяти, скорости работы и занимаемом дисковом пространстве. В последний год Drupal завел дурную привычку отжирать до 150 Мб в БД под какие-то свои кэши. И это при том, что объем всего контента этого блога на данный меньше 30 Мб, включая картинки, приаттаченные файлы и так далее. На мой взгляд, это как-то совсем неприлично для скромного блога.

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

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

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

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

Одним из первых таких генераторов стал Jekyll, за которым последовала масса клонов на самых разных языках и с разной специализацией. Вот несколько из них, наиболее известных: Octopress (ruby), Pelican (python), Second Crack (php), Blacksmith (node.js), Nikola (python), Hyde (опять python).

Среди всего этого многообразия я выбрал Acrylamid по трем причинам. Во-первых, он изначально ориентирован на блоги. Во-вторых, из коробки он умеет очень многое из того, что мне было нужно, а значит, не требовал мучительного поиска плагинов на каждый чих. В-третьих, написан он на python, который я знаю гораздо лучше ruby или node.js.

Вот краткий список того, что он умеет:

• markdown,
• живая перекомпиляция сайта при редактировании и локальный предпросмотр,
• перекомпиляция только изменившихся страниц,
• типографика и формулы,
• постраничный вывод списка постов,
• многоязычные посты,
• компиляция LESS,
• интеграция с Disqus
• и много другого полезного.

И самая важная фитча — «живой» разработчик, который активно развивает движок и охотно принимает pull request’ы. Выбор оказался удачным — для удовлетворения всех моих капризов мне хватило нескольких модификаций, которые были оперативно приняты в апстрим.

Однако, техническая разница между acrylamid и Drupal настолько велика, что перенос контента казался задачей очень нетривиальной. Само собой, терять посты и комментарии за 7 лет я был неготов. В качестве дополнительного усложнения задачи служило желание не накосячить в глазах поисковиков, так как смена движка вела к почти неизбежной смене структуры адресов страниц. В следующей заметке я как раз к этим вопросам и обращусь :-)

P.S. Dream Theater - Panic Attack