Pelican и наполнение заготовки сайта хоть чем-нибудь

Фундамент готов

Но до финишной отделки еще далеко, пока даже стены не возведены. Разработка сайта на Pelican складывается из таких пунктов:

• контент;
• тема;
• плагины;
• настройка.

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

• Контент. Собственно статьи, блогпосты, сообщения разного рода, составляющие информационную ценность сайта. Пишется на reStructuredText или Markdown, лично я предпочел второй вариант, хотя первый обеспечивается пеликаном сразу, а для второго надо ставить соответствующий модуль Python. Каждый пост пишется в отдельном файле и складывается в папку «content», логично, не правда ли? Pelican сам разберется, в каком виде и в какое место сайта впихнуть написанное, основываясь на метаданных в начале контентного файла и на структуре шаблонов.

• Тема. Влияет на внешний вид сайта. Включает в себя разметку веб-страниц, для чего содержит шаблоны для разных их вариантов, и оформление, задаваемое таблицами стилей в файлах css, которых может быть и несколько. Здесь же могут храниться общие для всего сайта и привязанные к теме иконки, шрифты, сценарии JavaScript. Шаблоны основаны на шаблонизаторе Jinja2 («дзиндзя»). Обычно присутствует базовый, задающий общий стиль, и его наследники, определяющие особенности отображения статичных страниц, статей, привязанных к дате, страниц со списками статей по тегам, категориям, авторам, датам, еще каких-нибудь страниц, не предусмотренных авторами Pelican, но придуманных автором сайта.

• Плагины. Дополнительные модули Python, обеспечивающие функциональность, не заложенную в базе. Могут повышать удобство написания и быть незаметны для посетителей сайта (типа assets) или помогать в разработке непосредственно внешнего вида страниц (например, tag_cloud, который делает модное облако тегов).

• Настройка. Файлы конфигурации pelicanconf.py и publishconf.py в корне проекта сайта. Определяют массу всяческих деталей, влияющих на процесс генерации страниц сайта. По сути, содержат набор переменных, которые либо управляют процессом генерации, либо используются непосредственно в коде страниц.

Контент — это то, с чем придется работать постоянно на протяжени всего времени жизни сайта. Если перестать писать — сайт закончится. Он не сразу пропадет с просторов сети, но живым его уже нельзя будет назвать.

Тему можно взять готовую и использовать так. Можно взять готовую и чуть-чуть подкорректировать ее до полной неузнаваемости. Можно взять, и написать с нуля самому.

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

Добавление плагинов отложим на попозже.

Заготовка для контента

Начнем, пожалуй, с текстового наполнения. Дальнейшие эксперименты с внешним видом и поведением надо все-таки на чем-то проверять. Сделаем файл first.md (непременно UTF-8) следующего содержания:

Title: Заголовок первой статьи
Date: 2016-01-20 10:00
Modified: 2016-01-20 11:00
Category: Рыба
Tags: блог, разное, тест, проверка
Slug: fish
Lang: ru
Translation: false
Status: published
Authors: Аноним, Аполлинарий Афиногенович Семиникейский-Дудытченко
Summary: Сильно сокращенное описание, из которого можно понять, зачем вообще 
читать эту статью в развернутом виде.

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

Может делиться на абзацы[^1]. Может **усиливать** и *выделять*. Может
использовать <abbr title="HyperText Markup Languige">HTML</abbr>-теги напрямую.

[^1]: И это далеко не все возможности&hellip;

## Может включать заголовки и подзаголовки

* может содержать списки
* из нескольких пунктов,
* например, ненумерованных.

Может [ссылаться](http://example.link.com) на какую-нибудь несуществующую фигню, 
или даже проще: <http://example.link.com>

Как видно, файл начинается с метаданных, из которых Pelican понимает, как его обрабатывать и куда засовывать. Далее идет текст, при написании которого надо использовать некоторые правила — соблюдать синтаксис языка Markdown. Тогда статья будет корректно преобразована в HTML, то есть, в нужные места будут вставлены соответствующие теги. Коротких шпаргалок по Markdown в интернете достаточно, например, здесь или тут, можно посмотреть и описание синтаксиса, допустим, вот и еще

Подробнее о метаданных

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

• Date: Дата написания статьи. Может отображаться в самой статье, будет использоваться для сортировки статей по дате в ленте. Если не поставить, то будет выставлена в зависимости от настройки в файле конфигурации, параметр DEFAULT_DATE, который можно поставпть ‘fs’, тогда будет браться системная дата создания файла.

• Modified: Дата правки статьи. Может использоваться в некоторых темах или самостоятельно.

• Category: Категория, которая является верхним уровнем навигации, наравне со страницами и пользовательскими пунктами. Если есть несколько статей с одинаковыми категориямти — они будут выведены списком при клике по этой категории в меню. В папке «content» для статей должна быть папка «articles». В ней можно сделать папки с именами категорий и складывать статьи по соответствующим папкам, тогда этот пункт метаданных при настройках по умолчанию не нужен. Если же статья будет в корне «articles», но без этого пункта метаданных, будет использоваться опция файла конфигурации DEFAULT_CATEGORY, по умолчанию — ‘misc’.

• Tags: Тэги, метки, ярлыки — ключевые слова, по которым можно найти статьи схожей тематики, если это предусмотрено навигацией по сайту. Можно использовать для создания облака тегов, можно просто отображать внизу каждой статьи. Вещь необязательная, но полезная.

• Slug: Ключевое слово, используемое для создания имени HTML-файла статьи. Если отсутствует, будет сделано автоматически из Title, с использованием транслитерации при необходимости, поэтому в большинстве случаев может отсутствовать. Не должно повторяться у разных статей, иначе будет сгенерирована только последняя статья из имеющих одинаковый Slug, остальные затрутся. Полезная вещь при создании многоязычных версий: у версий одной статьи на разных языках надо ставить одинаковый Slug, но разные Lang.

• Lang: Язык статьи. Может отсутствовать, используется опция файла конфигурации DEFAULT_LANG, по умолчанию — ‘en’.

• Translation: Не нужная пока что штука, устанавливается в true, чтобы не дать пеликану скрыть в навигации статью с языком, отличающимся от DEFAULT_LANG, например, чтобы показать оригинал переведенной статьи.

• Status: Может быть published (по умолчанию) или draft. В последнем случае статья считается черновиком и не используется при формировании навигации. Ее можно будет найти на сайте, только если точно знать ее адрес. Используется, например, в том случае, чтобы дать почитать ограниченному кругу, которому автор разошлет URL личной почтой. Статус draft на сегодняшний день для статей работает, а для страниц почему-то нет. Однако, для страниц есть статус hidden — скрытая. Страницы с таким статусом генерируются в том месте, где и должны (статьи со статусом draft — в папке draft), однако на них не создаются ссылки в других местах сайта, то есть, опять же, попасть на такую страницу можно только введя ее адрес прямо в строке браузера. Ну, или щелкнув по ней, запустить на отображение, если она лежит у вас дома.

• Authors: Если авторов, пишущих для сайта, несколько, то можно сделать поиск статей, принадлежащих конкретному перу. Если отсутствует, будет использоваться значение опции файла конфигурации AUTHOR.

• Summary: Отображается в лентах статей — в списках, отсортированных по времени, тегу, автору и все такое. Что интересно: запись должна быть в одну строку. Это уже в статье простые переносы (без пустой строки) игнорируются. В примере строка перенесена, и вот результат: то, что до переноса, отображается в summary, а то, что после — уже в тексте статьи.

Как видно, не все метаданные являются настоятельно необходимыми, можно использовать лишь часть. Верно и обратное — если вдруг понадобится какая-то хитрая переменная, не предусмотренная разработчиками Pelican, можно ее добавить в заголовок, а потом в шаблоне использовать, типа того:

Danger: red

А потом где-нибудь в шаблоне статьи (придется немного править тему), рядом с заголовком, вставить такое:

{% if article.danger %}
Класс опасности: {{ article.danger }}
{% endif %}

И тогда в месте, определенном шаблоном, для статей с этой метаинформацией появится «Класс опасности: red». А для прочих статей не появится ничего.

Переплавка заготовок

Стоит для массовости сделать еще одну заготовку-рыбу, с учетом необязательности тегов, файл second.md:

Title: Заголовок второй статьи
Date: 2016-01-20 15:00
Category: Разное
Tags: блог, разное, тест
Summary: Еще одна рыба, просто для массовости.

Снова рыба, снова заготовка текста, просто так, для заполнения места. Ну, в 
самом деле, не цитировать же снова Цицерона «О пределах добра и 
зла», да еще и в этом ужасном, хотя и общепринятом, подрезанном и 
искаженном виде.

Теперь надо сделать вручную папку «articles» в папке «content» и перенести туда оба файла. Даем команду в консоли

c:\python33\Scripts\pelican.exe content

Получаем в ответ

Done: Processed 2 articles, 0 drafts, 0 pages and 0 hidden pages in 4.30 seconds.

Видим, что в обработке участвовало 2 статьи. При желании можно в папке «content» добавить папку «pages», и сложить туда что-то подобное статье, чтобы посмотреть, чем в конечном итоге отличаются статьи от страниц, но это не принципиально. Интересно, что в папке «output» появились файлы, в том числе, fish.html и zagolovok-vtoroi-stati.html: одна именована по Slug, заданному явно, а другая — по преобразованному автоматически. Это и есть наши статьи. Они появились на странице, открывающейся при запуске index.html, причем, вторая, как ближайшая по времени — выше по тексту и полностью, а первая — в ленте, после «Other articles», и с использованием Summary.

Дизайн по-прежнему не то, чтобы ужасен — он просто отсутствует напрочь. И ссылки работают плохо: «Заголовок первой статьи» или «read more» не дают возможности почитать первую статью. Никуда не ведут теги и категории. Пока что их можно посмотреть, прямо запустив соотвествующий файл (например, tags.html или first.html), заодно можно посмотреть, как Markdown-разметка переплавилась в HTML-разметку.

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