Obsidian как CMS: сайт из папки с заметками

Obsidian хранит заметки как обычные файлы Markdown в обычной папке. Это его главное свойство: база не заперта в чужой базе данных, её видно в проводнике, её можно открыть блокнотом.

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

Что вообще значит «использовать Obsidian как CMS»

Обычная система управления сайтом — это админка в браузере, база данных и сервер. Вы пишете текст в форме, он ложится в базу, при открытии страницы сервер собирает её заново.

Схема с заметками устроена иначе:

Вы пишете в Obsidian, как писали до этого. Никакой админки.
Генератор проходит по папке и собирает статический сайт: страницы, меню, поиск, карту сайта.
Готовые файлы выкладываются на хостинг. При открытии страницы ничего не собирается — она уже собрана.

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

Что ломается при переносе

Это главная часть, и обычно про неё узнают в процессе.

Вики-ссылки. В заметках ссылки выглядят как [[Название заметки]], а в вебе нужен адрес вида /zametki/nazvanie/. Генератор обязан уметь разрешать такие ссылки: находить заметку по имени файла, заголовку или полю, и подставлять её настоящий адрес. Если он этого не умеет, вся внутренняя связность базы — а это самое ценное, что в ней есть, — превращается в текст в квадратных скобках.

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

Не всё должно быть опубликовано. В базе лежат черновики, личные записи, рабочие списки. Нужен явный признак публикации — поле в начале файла вроде draft: true, — и лучше, чтобы по умолчанию заметка была закрыта, а не открыта.

Имя файла — не адрес. «Как я выбирал хостинг.md» не годится в URL. Нужно отдельное поле для адреса, и его нельзя менять после того, как страницу проиндексировали.

Вложения. Картинки в Obsidian лежат в служебной папке и вставляются своим синтаксисом. Их надо перенести, переименовать и не сломать пути.

Специфический синтаксис. Выноски, блочные ссылки, встраивания одной заметки в другую, задачи — это диалект Markdown, а не стандарт. Генератор либо понимает его, либо выдаёт кашу.

Как это выглядит, когда работает

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

Сайт, который вы сейчас читаете, собран им же. И учебный сайт про Obsidian — семь разделов, боковая навигация и поиск, который работает без сервера, прямо в статике.

Сборка сотен страниц занимает секунды, поэтому цикл «поправил текст — посмотрел результат» остаётся мгновенным.

Чего вы лишаетесь

Честный список, потому что подход подходит не всем.

Нет админки. Публикация — это сборка и выкладка. Их можно свести к одной команде или автоматизировать, но человеку, который не хочет знать слово «сборка», такой сайт не отдашь.
Плохо для команды. Когда тексты правят пятеро и правят одновременно, база файлов начинает конфликтовать. Один-два автора — идеально, отдел контента — нет.
Нет форм и личных кабинетов. Статика не умеет ничего исполнять на сервере. Про то, как при этом принимать заявки, — отдельный разбор.
Нужен генератор, который понимает именно ваш диалект. Универсального решения нет: чем экзотичнее плагины, тем выше шанс, что что-то приедет неправильно.

Когда база уже большая

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

Тут помогает не генератор, а анализ: я разбирал свою базу векторными представлениями текстов — заметки сближаются по смыслу, а не по совпадению слов, кластеры получают человеческие названия, и отдельно видно пары, которые стоило бы связать, но они не связаны. Это даёт черновик структуры будущего сайта — какие разделы в базе есть на самом деле, а не какие вы предполагали.

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