Как человеку, который застал примитивный веб-дизайн девяностых, мне странно видеть, что теперь для любого сайта ставят полноценный движок. WordPress, Drupal, Joomla и прочие популярные CMS рассчитаны на тысячи страниц и поддержку ресурса силами целой команды. Но зачастую их используют, чтобы сделать персональный блог или даже сайт-визитку. Стоит ли городить огород, если всё, что нам нужно — это публиковать статический контент?

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

Если ты вдруг подумал, что я предлагаю тебе уподобиться пещерным людям и вручную делать каждый .html, то ты ошибаешься. Современный способ иной: запустить CMS на локальной машине, а на сервер выкладывать только статические файлы. Это оставляет возможность пользоваться шаблонизатором: если тебе понадобится поменять что-то в теме, то править каждую страницу не придется.

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

В 2013 году в «Хакере» уже публиковалась подборка статических блогогенераторов, статья называлась «Просто пиши». Однако с тех пор прошло много времени и не все перечисленные проекты до сих пор поддерживаются. К тому же в этом классе программ появились новые лидеры. Среди движков на Node.js популярен Hexo, а поклонникам Ruby рекомендую глянуть на Jekyll.

Здесь же мы рассмотрим работу с движком Lektor, который написан на Python и сочетает в себе простоту, удобство и расширяемость, а также обладает вебовой админкой. Запустив локальный сервер, ты сможешь просматривать и редактировать сайт так, будто ты работаешь с полноценной CMS. Закончив редактировать, ты одной командой сможешь синхронизировать изменения с копией на сервере.

Lektor — это новый проект Армина Ронахера, автора популярного минималистичного веб-фреймворка Flask и языка шаблонов Jinja2. Собственно, в Lektor, как и во Flask, используются шаблоны Jinja, и именно в них — вся сила «Лектора».

Ставим Lektor

Команда установки Lektor написана прямо на главной странице сайта. Если у тебя macOS или Linux, то ты можешь просто скопировать ее в командную строку и запустить:

Аналогичная команда есть и для Windows, она заметно длиннее.

Ещё тебе нужно убедиться, что в системе есть Python 2.x и библиотека Imagemagick. В Ubuntu все зависимости ставятся одной командой:

В Windows и macOS для установки Imagemagick тебе сначала понадобится поставить пакетный менеджер — Chocolatey или Homebrew соответственно. Кстати, для macOS у Lektor есть десктопное приложение, которое само установит тебе утилиты командной строки — нужно лишь выбрать пункт меню Install Shell Command.

Если же ты собираешься модифицировать сам Lektor, то разработчики рекомендуют ставить версию с GitHub и создать виртуальное окружение (в других случаях оно не нужно). Руководство ты найдешь на странице проекта.

Разбираем простой проект

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

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

В последнем случае к тестовому проекту будет добавлена страница с постами и шаблон для них. Рекомендую согласиться — лишние примеры не повредят.

WWW

Сайт getlektor.com — отличное пособие по Lektor сразу в двух смыслах: во-первых, там есть документация, во-вторых, этот сайт сам сделан на Lektor и в нем использованы некоторые неочевидные трюки. Так что в его исходниках всегда можно что-нибудь подсмотреть.

Чтобы глянуть, на то, что у тебя вышло, пиши lektor server. Запустится локальный сервер, при помощи которого можно тестировать сайты. Обычно он доступен по адресу http://127.0.0.1:5000/.

Вот, как будет выглядеть тестовая страница.

Обрати внимание на карандаш в правом верхнем углу — это ссылка на редактирование страницы в админке.

Теперь посмотрим, что творится в папке с проектом.

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

• assets — папка для статического контента, общего для всего проекта (стили, значки и т.п.);
• content — основная директория для сайта. Каждый подкаталог в ней соответствует одной странице. Обрати внимание: картинки к отдельным страницам размещаются в них же, а не в assets.
• models — папка с описаниями моделей данных в виде файлов .ini.
• templates — папка с шаблонами HTML в формате Jinja2. Названия файлов соответствуют названиям файлов с моделями.

Формат ini тебе наверняка знаком по Windows — это список пар ключ = значение, которые обычно разбиты на секции. Файл с расширением .lektorproject, который лежит в корневом каталоге проекта — это, считай, тот же ini. Пока что в нем записано только название проекта, но позже мы впишем сюда адрес сервера, куда Lektor будет загружать сайт.

Файлы .lr — это тоже простой текст, в них храниться все содержимое сайта (так что сразу закрепляй это расширение за удобным редактором). На каждую страницу — по своей папке со своим contents.lr. Можно сказать, что их формат аналогичен Markdown, но на самом деле всё чуть сложнее: в .lr хранится содержимое переменных, описанных в модели, и один из форматов этих переменных — Markdown.

Звучит замысловато? Просто открой contents.lr из корня папки content и загляни внутрь. Ты увидишь, что там задано две переменные — title и body (переменные отделяются друг от друга тремя черточками на отдельной строке). Первая содержит заголовок текста и имеет формат «строка», вторая — текст страницы, записанный в виде Markdown. Если страницы будут иметь ещё какие-то характерные элементы, то ты сможешь создать переменные для них и легко менять из админки.

Чтобы узнать, как выглядят модели, открой файл page.ini из папки models. Внутри ты увидишь три секции: model, fields.title и fields.body. Первая — это название нашей модели и заголовок страницы в админке. Он будет соответствовать названию страницы (заметь, что тут используется формат шаблона).

Каждая секция fields.* описывает одно поле на странице редактирования поста. Сейчас ты видишь описание двух полей: title в формате string и body в формате Markdown. Помимо этого для каждого из них задано текстовое название (label), которое будет выводиться во время редактирования страницы.

К примеру, если каждый из твоих постов будет сопровождаться картинкой, то можно добавить вот такое поле:

Впрочем, конкретно в этом случае проще подхватывать заглавные картинки автоматически — для этого нужно было бы придумать им одинаковое название и задать его в шаблоне. Кстати, заглянем напоследок в папку с шаблонами. В ней ты найдешь три файла: layout.html, page.html и pagination.html в подкаталоге macros. Если ты уже работал с шаблонизатором Django или другими похожими шаблонами, то язык Jinja2, который здесь используется, будет понятен тебе с первого взгляда.

Добавляем свои поля в модель

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

Именно для таких случаев у Lektor есть возможность настраивать админку и добавлять кастомные поля в модель. В документации ты найдешь страницу, где перечислены все возможные типы полей. Мы используем тип select, чтобы выбирать выравнивание и checkboxes — чтобы создать поле с чекбоксами «Жирный» и «Курсив».

Клонируем модель page.ini, обозвав, скажем, text.ini. Внутри нового файла меняем name на Text и добавляем две секции:

Теперь прописываем в CSS те стили, которые нужно включать в соответствии с выбором опций. Называем соответствующие классы center, left, bold и italic и делаем так, чтобы они применялись только к тегу <h2> (чтобы прописывать их не каждому подзаголовку, а всему контейнеру с текстом).

Почти всё готово. Осталось как-то прокинуть мостик между интерфейсом и включением стилей CSS на странице. Это делается при помощи шаблонов.

Сначала создаем для страницы рассказа новый шаблон. Копируем page.html, называем text.html (в соответствии с моделью) и заменяем описание block body на следующее:

Как видишь, выбранные пункты вставляются в качестве параметров свойства classконтейнера с текстом. Пункт списка (align) можно добавлять как есть, а вот названия чекбоксов приходят в виде массива — мы его перебираем и вставляем в шаблон каждый элемент.

Чтобы проверить, как всё сработало, открываем админку и создаем новую страницу (Add Page). Нам предложат задать название и выбрать модель — выбираем Text. Ура, появились элементы интерфейса, которые мы описывали в модели.

Задаем что-нибудь, сохраняем и смотрим в файл contents.lr. В нем всё выглядит примерно так же, как и в админке. В принципе, ничто не мешало создать страницу вручную.

Если заглянешь в HTML, открыв в браузере код собранной страницы, то увидишь, что там стоит class="center bold italic". Ну и, конечно, подзаголовок должен приобрести выбранное нами начертание.

Делаем галерею

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

Берем новый шаблонный проект и проводим подготовительную работу.

1. Клонируем папку с любой страницей — например, about. Называем ее gallery.
2. Клонируем модель page.ini и называем gallery-page.ini. Править ее не придется.
3. Открываем gallery/contents.lr и добавляем в начало _model: gallery-page и --- на следующей строке.
4. Открываем layout.html и добавляем в массив с названиями и адресами страниц (см. врезку) строку ['/gallery', 'Gallery'].
5. Клонируем page.html и называем gallery-page.html.

Теперь у нас есть страница для галереи, а также модель и шаблон для нее, но внутри нет картинок. Добавить их поможет объект attachments, в который Lektor собирает все мультимедийные файлы, найденные в папке со страницей. К примеру, метаданные картинок лежат в this.attachments.images. Lektor может даже сгенерировать превью, если вызывать для картинки метод .thumbnail(n), где n — новая ширина.

В результате код галереи будет выглядеть примерно следующий образом. Вставлять его нужно внутрь block body в нашем gallery-page.html.

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

Что делать, если на странице с галереей есть какие-то картинки, которые не должны в нее войти? Мне приходят на ум как минимум два решения: первое — отфильтровать их по какому-то префиксу, добавив в шаблон блок if..endif и проверяя наличие подстроки в названии файла с картинкой; второе — создать фиктивную страницу (к примеру, gallery-images), скинуть все картинки в ее папку, а в шаблоне галереи вместо картинок к текущей папке (this.attachments.images) брать их из другой: site.get('/gallery-images').attachments.images.

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

Деплоим сайт

Предположим, что ты закончил первую версию сайта и ее пора заливать на сервер. Lektor с этим отлично справится, но сначала тебе нужно решить, каким способом деплоить. Lektor нативно поддерживает GitHub Pages, а для Amazon S3 есть готовый плагин. Но в большинстве случаев выбор будет между FTP и rsync. Если у тебя есть доступ к серверу по SSH, то rsync — для тебя, если нет, то придется заливать по старинке через FTP.

Предположим, что у нас есть шелл и на сервере установлен rsync (к примеру, в Ubuntu он стоит по умолчанию). Открывай файл .lektorproject в корне проекта и дописывай туда вот такую секцию.

Теперь все, что нужно для деплоя — это написать lektor deploy и ввести пароль. Lektor при помощи rsync посмотрит, какие файлы требуют обновления, и загрузит новую версию. Теперь можешь зайти на сервер и посмотреть, как выглядит сайт в сборе.

Пределы возможностей

Как видишь, сделать на Lektor можно если не что угодно, то очень многое.
Да, от динамики придется отказаться, но, по-хорошему, действительно нужна она только в одном случае — если пользователи сохраняют что-то на сайте перманентно. Те же комментарии, аналитику и поиск можно (и зачастую лучше) подключить сторонние, а это, наверное, 80-90% случаев, когда без серверных скриптов никак. К тому же современный JavaScript позволяет делать локально самые разные фокусы.

Второй большой недостаток статического генератора — это невозможность редактировать сайт силами нескольких человек. Но даже это ограничение при желании можно обойти, сложив проект в репозиторий.

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

Читайте ещё больше платных статей бесплатно: https://t.me/nopaywall