Отличие Albireo от других Flat-File CMS
В семействе Flat-File CMS довольно много систем, которые сильно отличаются друг от друга. Я работаю в этом направлении с 2013 года и у меня есть некоторый опыт, который позволяет оценить то или иное решение и применить его к Albireo CMS. За всё время я изучил штук 50 разных flat-file систем. Albireo CMS от них отличается тем, что в ней реализованы только лучшие решения.
История Albireo CMS
Это важно, поскольку поможет понять шаги, которые привели к текущему устройству системы.
Изначально я сделал Landing Page Framework. Это было в 2013 году. LPF был ориентирован только на лендинги и с этой задачей он справлялся отлично. Постепенно я его добавил в него генератор статичных сайтов и простую админ-панель.
Однако, проект я закрыл, поскольку разочаровался в структуре страниц. LPF использовал очень простую схему, когда каталог и был адресом страницы. Сама страница состояла из двух файлов: контент и переменные:
lpf-content/
pages/
about/ <- адрес страницы вашсайт/about
text.php <- это контент
variables.php <- это переменные
Когда я стал делать сайты на несколько десятков страниц, такая структура оказалась очень неудобной, поэтому постепенно я трансформировал страницу в index.php, где была специальная секция с переменными, но при этом можно было использовать и variables.php и другие служебные файлы.
Секция, где указывались переменные обозначалась в php-комментарии примерно так:
/* === TITLE: заголовок META: description: описание keywords: ключи viewport: width=device-width, initial-scale=1.0 generator: Landing Page Framework VAR: simple: true compress_text: true === */
Так стало намного удобней, но страница всё равно размещалась в отдельном каталоге и у неё был фиксированный адрес.
Фактически мне просто не хватало опыта использования LPF, чтобы понять проблемные места. Но за несколько лет я сделал несколько сайтов документации, курсы HTML и структура LPF показывала свою неэффективность.
Другой ошибкой в LPF было использование формата YAML, который на первый взгляд кажется интересным и оптимальным, но на деле создавал очень много проблем. Например он очень строг к отступам, он плохо работает с типами данных, он отвратительно компилируется в php-массив и, его php-библиотека жутко тормознутая. Именно поэтому мне пришлось придумывать специальный «умный кэш», чтобы сгладить все недостатки YAML. YAML очень замороченный формат, который просто не оправдывает своей сложности.
В 2020 году я сделал Albireo Framework, который сразу рассматривал как преемника LPF и как проект, который в будущем должен перерасти в полноценную CMS.
В отличие от LPF, Albireo Framework уже работал с более понятной структурой каталогов, а записи размещались в отдельных файлах, а не каталогах. Работать с такой структурой намного удобней.
Но, поскольку у меня был опыт создания сайтов только на LPF, то в Albireo Framework я также допустил несколько ошибок. Кто помнит, это вылилось в «танцы» со сменой структуры каталогов. Потом я не сразу сообразил, что страницы могут повторять структуру подкаталогов. Потом были шаманства с админ-панелью, которую я в итоге вынес отдельно.
Также неверно были продуманы каталоги данных пользователя, каталоги конфигурации, не было полноценной шаблонизации и несколько других шероховатостей. То есть чем больше я делал сайтов на Albireo Framework, тем больше отмечал в своём ТЗ таких идей для исправлений.
При этом, в Albireo Framework я отработал огромное количество новых идей и задумок. Например layout-шаблоны, кэширование через «снимки файлов», логику админ-панели (они по сути обычные страницы), структуру каталогов, идея вынести поля страницы в php-комментарий /** **/, отдельные doc-шаблоны, в общем эта разработка оказалась для меня очень динамичной. В итоге я довёл её до состояния, когда она перестала быть framework, а должна получить полноценный статус content management system.
Albireo CMS как проект
Первоначальная запись по этим работам у меня отмечена как 28-10-2022 10:53. Изначально я просто составлял ТЗ, где описывал все свои хотелки. Потом продумывал как их можно реализовать и описывал алгоритмы. Потом у меня был длительный этап отработки оптимальной структуры каталогов.
Уже после этого я сделал первую версию, которую перенес из Albireo Framework и стал переделывать под свои задачи.
Параллельно я занимался тестированием, особенно мне было интересно определить максимальное количество файлов, с которым может работать система. Потом было несколько сильных изменений, когда я смог-таки реализовать изначальную задумку использовать sqlite-базу как структурированный кэш. Изначально у меня именно так и планировалось, но я отменил этот пункт как очень сложный к реализации. Однако, всё-таки смог.
Когда у меня получилось собрать что-то полноценно работающее, я перевел свои сайты и несколько других на Albireo CMS для тестирования в «реальных» условиях. То есть постепенно я отрабатывал задачи вёрстки, интеграции сторонних библиотек, работу с Berry CSS и т.п.
Важное отличие от Albireo Framework в том, что в CMS — другая админ-панель. В ней я хотел сделать своё видение того, как мне удобно редактировать тексты. Мне нравится, когда текстовый редактор занимает большое пространство, чтобы был предпросмотр тут же, чтобы было меню, как в обычных windows-программах, чтобы были горячие клавиши Ctrl+S, Ctrl+B, Ctrl+I; чтобы можно было загружать файлы на сервер прямо мышкой в редактор; чтобы тут же был список изображений/файлов и список файлов, как это сделано в Obsidian'е.
Это всё огромадный объём работы для одного человека. Хорошо, что подоспел ChatGPT, который помог мне решить несколько очень сложных задач.
Другой задачей, которую я ставил изначально — это полная документация проекта. Я помню много недовольства, когда делал MaxSite CMS, где не было документации и людям приходилось собирать инфу с моих сайтов. Поэтому здесь я сразу сказал, что никакого релиза не будет до полной документации. Я этот подход использовал, когда выпускал Berry CSS 3-й версии, где на доки у меня ушло примерно два месяца. Здесь я уже не затягивал и постепенно сайт документации наполнялся и всегда держится в актуальном состоянии.
На текущий момент (август 2025) Albireo CMS проходит альфа-тестирование.
Другие Flat-File CMS
Дальше я буду упоминать некоторые CMS, как пример использования или реализации каких-то возможностей. Я не ставлю задачу знакомить вас с другими системами, а просто хочу описать именно отличия, которые делают Albireo CMS особенной.
Структура файлов страниц
Казалось бы Flat-File CMS по определению подразумевают хранение данных в файлах, а значит по идее можно работать с системой напрямую с файлами, минуя админ-панель. На деле же, некоторые системы фактически не позволяют работать с файлами, поскольку используют сложный формат данных.
Например Kirby разбивает файл на секции с помощью разделителя ----, формируя как бы разные данные страницы. Automad работает похожим образом с разделителем -, а внутри секции размещается сложная JSON-структура. В одной из систем (Pulse) данные страницы сжаты в одну строчку в JSON-формате.
Такой подход делает непригодным использование системы без админ-панели.
Но в целом преобладает подход, когда начало страницы выделяется секцией ---, которая указывает на (Markdown/YAML) конфигурацию. Здесь есть варианты, например во Flextype данные можно указывать в MD, JSON, JSON5, YAML и NEON форматах.
Преобладающий формат YAML, поскольку он более-менее простой, хотя сильно усложненный для обычного использования.
Например в Grav:
taxonomies:
fields:
header.taxonomy:
default:
category: ['blog','page']
tag: ['test']
options:
category: ['grav']
validate:
type: commalist
Тут я уточню, что YAML это не просто текст, это форматированное представление данных. Это примерно тоже самое, что и JSON, который также очень чувствителен к синтаксису. Проблема не в том, как пользователь будет писать этот код в файле страницы, а в том, как yaml-парсер сможет корректно преобразовать его в php-массив/строку/число и т.п.
В Albireo CMS все поля «одноранговые», в них невозможно разместить то, что их может сломать.
category: blog, page
tag: animal, ❤️🐱
author: Bill
favorite: +
моё поле: вкл
другое: <h1>тест <?= 'Hello!' ?></h1>
# комментарий
type: blog
css.style[]: li {margin-bottom: 20px}
Поскольку YAML строгий формат, то поля страницы в других CMS каким-то образом «зашиты» в саму систему. Это сильно отличает Albireo от других CMS — у меня можно создавать любые поля в любом формате. Это возможно потому что каждое поле обрабатывается ровно там, где оно используется.
Например, если поле содержит число, то значение поля проверяется там, где оно используется (скажем через intval()). То есть системе всё равно что-там содержится в полях страниц.
Почему я отказался от структуры аля-YAML? Представьте себе, что поле страницы — это обычное input-поле где-нибудь в админке. Пользователю предлагается ввести значение, но ему же не нужно думать о структуре или типе данных. Он всегда выводит текст (string), а система уже сам решает что и как это интерпретировать.
Использование YAML заставляет пользователя думать о правильности ввода данных. То есть разработчики CMS перекладывают ответственность за входные данные на пользователя.
Хранение страниц
В большинстве flat-file системах преобладают два способа.
Первый — аля-LPF, когда каталог страницы и есть её slug (адрес). Внутри каталога может быть предопределенный файл контента, например entry.md (Flextype), default.md (Grav) и т.п. Также в этом каталоге могут размещаться дополнительные файлы, скажем изображения или описание структуры в yaml-формате.
Второй способ — это когда страница определяется только своим файлом. Это значит, что её адрес будет совпадать с именем файла.
Кроме того, системы по разному интерпретируют вложенность каталогов. Здесь нет какого-то правила, поскольку каждый придумывает свой подход. Например подкаталог может учитываться как часть адреса страницы, или, наоборот, никак не учитываться. Некоторые системы позволяют группировать страницы по подкаталогам, которые воспринимаются как некие «рубрики».
Наверное стоит упомянуть и то, как именно может задаваться адрес страницы. Многие CMS не позволяют менять slug страницы и полностью формируют адрес исходя из каталога страницы и/или имени файла.
Часть CMS позволяет указывать адрес, но в жёстких правилах, скажем только английские буквы, цифры и некоторые символы. Здесь идея разработчиков в том, что адрес обязан соответствовать правилам именования файлов.
В Albireo CMS я учитывал опыт работы с LPF, и хотел сделать так, чтобы адрес мог быть произвольным. Поэтому адрес формируется с учетом каталога (если есть) плюс имя файла. Имя файла автоматически конвертируется в «традиционную» для URL модель: скажем пробелы заменяются на символ -. То есть смысл в том, чтобы адрес был более читаемым и не вызывал излишнее url-кодирование для браузера.
С другой стороны, в Albireo CMS страница может иметь произвольный адрес, если использовать поле slug. Здесь оно произвольно в буквальном смысле: как пример я часто привожу использование эмодзи. Хитрость в том, что адрес страницы никак не связан с её файлом, поэтому пользователь волен выбирать всё что ему вздумается.
Кроме того, в Albireo CMS можно задать паттерн адреса slug-pattern, где можно указать любые другие адреса, по которым будет работать страница. Например slug-pattern: category/(.*?) сделает так, что страница будет обслуживать все адреса с category. В других CMS ничего подобного просто нет.
Есть ещё один момент, на который стоит обратить внимание: имена файлов/каталогов могут иметь числовой префикс. Этот подход используется во многих CMS для того, чтобы обеспечить произвольную сортировку страниц. Особенно полезно это для создания документации. Смысл в том, что числовой префикс как бы «игнорируется» системой при формировании адреса, но при этом учитывается для сортировки. В Albireo CMS реализован подход с префиксом ЧИСЛО.имя как для файлов, так и для каталогов.
Использование PHP
Другое важное отличие Albireo CMS — использовании PHP по прямому назначению. Я встретил только одну старую систему, где файлы страниц были php-файлом (как в LPF). Во всех остальных случаях это md- или txt-формат.
Markdown — это не исполняемый файл, в нём невозможно разместить динамический контент. В нём часто даже невозможно разместить произвольный html-код или css-стили, js-скрипты — этот формат просто не может понять что с этим делать.
Поэтому, системы, которые используют такой подход — кастрированные. Абсурдность в том, что система написана на PHP, но PHP не может использоваться в тексте. Я бы ещё понял, если бы это была база данных, где невозможно выполнить php-код, но тут именно файл, который просто за счёт своего расширения не может быть выполнен.
Поэтому Albireo CMS, наверное единственная Flat-File CMS, где разрешено использовать нативный PHP. А там где PHP, там и любой другой формат данных: хоть текст, хоть Markdown, хоть HTML, хоть, прости господи, HAML.
Albireo CMS как раз из-за того, что работает на PHP, позволяет делать что угодно своим пользователям. Такой свободы нет в других системах.
Использование HTML
Это выглядит странно, но некоторые CMS не позволяют использовать произвольный html-код в тексте записи. Например Typemill настойчиво предлагает обрамить весь HTML в code-блоки, то есть сделать из него преформатированный текст.
Другие системы каким-то невероятным образом использую html не в прямом написании, а в html-сущностях (monstra), то есть вместо <h2>Welcome!</h2> нужно писать <h2>Welcome!</h2>.
Я вижу проблему в том, что системы жестко завязаны на Markdown, точнее на библиотеку, которая выполняет парсинг текста, и тут у многих свои чудеса. Более того, я вижу, что используется не «классический» Markdown, а свои «велосипеды», отсюда и фатальные ошибки парсинга.
В Albireo CMS текст выводится как есть. При желании используется произвольный парсинг: стандартно это TextSimple, но есть и Markdown в виде библиотеки Parsedown. Если нужен какой-то другой парсинг, то он подключается в виде php-функции, которая указывается в поле parser. Можно указать сразу несколько парсеров: parser: textsimple, my_bbcode, trim.
Конфигурация
Почти все CMS в качестве конфигурации используют либо YAML, либо JSON, хотя встречаются и те, где используются ini-файлы.
Важно вот что: php-массив идеально годится для хранения конфигурации, но в других CMS используется прослойка, которая предлагает другое, принципиально не отличающееся от PHP, написание кода, при том, что на выходе всё равно нужно получить php-массив. 😜
В Albireo CMS используется только PHP. За счет этого решается две задачи. Первая — конфигурация может быть динамической, и вторая — получается высокая скорость и эффективность использования.
Шаблонизация
Многие CMS рассчитаны на Twig. Это, конечно, ужасно, потому что шаблон получается страшный по раздробленности и сильно требовательный к ресурсам. Есть системы, которые предлагают фиксированную структуру из php или html-файлов. Также есть те, где фиксированы css-стили.
Если кратко, то вы не найдёте систем, где можно было бы произвольно интегрировать совершенно сторонний лендинг, или css-библиотеку, или js-скрипт. В некоторых системах, для того, чтобы подключить что-то вроде аля-jQuery нужно создавать целый php-модуль или класс.
Albireo CMS я разрабатывал с прицелом на легкую интеграцию со сторонними библиотеками. Я могу со 100% уверенностью заявить, что нет других CMS, где это реализовано столь просто и элегантно.
Гибкость настройки
Все flat-file CMS имеют достаточно жесткую структуру и не позволяют либо создавать свои поля, либо кастомизировать поведение страниц. Скажем, нет систем (во всяком случае, я не встречал), где у страницы можно задать шаблон, отличный от других страниц. Или изменить парсер текста. Или использовать какой-то сторонний скрипт только на этой странице.
Архитектурно все эти системы повторяют одну и туже схему, когда данные формируются на уровне сайта/шаблона, поэтому страница сильно ограничена в собственных настройках.
Albireo CMS отличается тем, что в ней нет понятия «общих данных», в ней данные принадлежат только индивидуальным страницам. То есть каждая страница 100% изолирована от других, а значит она может иметь свой шаблон, свой дизайн, свои скрипты, свои изображения, свои модули, шапку, подвал, сайдбары и т.д.
Именно благодаря такой архитектуре, Albireo CMS позволяет очень гибко настраивать любые страницы и определять их функционал. Здесь просто нет ограничений, которыми изобилуют другие CMS.
Сложность управления. Админ-панель
Моя принципиальная позиция в том, что flat-file CMS должна уметь работать без админ-панели. Когда система основана на базе данных, то админ-панель необходимое условие, поскольку нет другого способа оперировать данными. Но, когда все данные в файлах, то можно оперировать ими напрямую. В этом и есть суть CMS на файлах.
Однако, многие flat-file CMS используют админ-панель так, что она является единственным способом работы с сайтом. Это выражается в особом формате данных. Или данные в md-файле, а конфигурация в соседнем yaml-файле, то есть во многих системах очень сложно управлять данными без админки.
Главная проблема в том, что авторы таких систем стремятся имитировать работу с базой данных. Например выносят отдельными полями заголовок записи, метки и другие поля. То есть пытаются сделать аля-WordPress. Стратегическая ошибка в том, что поля страницы могут быть произвольными, и это отличает их от систем на базе данных (там они фиксированы). Поэтому невозможно создать форму в админке под произвольные поля страниц.
Технически такие задачи решаются путем создания «описательного» файла, который указывает какие html-поля нужно сделать, и программного файла, обслуживающего эти опции.
В итоге админ-панель становится очень запутанной и сложной. Например в Typemill вообще невозможно разобраться. В Grav красивые цвета админ-панели, но всё, что касается более-менее сложных полей, то в них становится уже совершенно нереально разобраться. Потому что всё это «великолепие» конвертируется в/из формата YAML. То есть намного проще и быстрей вбить нужное поле в виде текста непосредственно в файле страницы, чем пытаться разобраться в мудрённых полях админки.
Я уже упоминал, что в Albireo CMS текстовое поле редактора занимает почти всё пространство браузера см. скриншоты: есть верхнее небольшое меню, меню редактора и служебные панели снизу и справа (служит произвольным ограничением ширины контента). Но вот, скажем в Grav текстовое поле настолько куцое, что пользоваться им решительно невозможно. Я подсчитал — оказалось, что текстовый редактор занимает всего лишь 25% площади страницы! И довольно типовое значение для всех других CMS.
Установка. Демо-данные. Комплектация
Albireo CMS декларирует нулевую установку. Просто загрузили файлы и все работает. Во многих других Flat-File системах есть специальный установщик (install). Он выполняет непонятные действия, а также создаёт первого пользователя. Это всё ради того, чтобы организовать доступ к админ-панели.
У меня другой подход, когда пользователи могут быть добавлены в любой момент.
Но самое печальное, если система для установки требует Composer, а где-то я встречал рекомендацию использовать Docker... Это показывает насколько разработчики системы далеки от реальности пользователей с их дешёвыми виртуальными хостингами.
Во многих системах нет начального наполнения. Либо вообще пусто, то есть ни одной страницы сайта, либо примитивные 2-3 страницы.
Мне не нравится такой подход, поэтому в Albireo CMS в комплекте сразу почти 70 готовых демо-страниц с изображениями и всей структурой. При этом в комплекте с Lite идут несколько интегрированных профессиональных лендингов, а в полной версии их будет 27 штук (суммарно это 87 готовых страниц). Это позволяет сразу получить готовый сайт, на котором можно потренироваться и «пощупать» возможности системы.
Что касается комплектации, то почти все системы поставляются «голыми». Лично я не понимаю эту логику, поскольку пользователю нужны xml-карты, rss, контактная форма, карта сайта, условия использования, главная, 404. И это при том, что сразу нужна поддержка всех meta-полей для HEAD, Open Graph и прочие возможности без которого немыслим современный сайт. По какой-то извращённой логике, разработчики CMS считают, что это некий бонус, который пользователи должны устанавливать отдельно. Что мешает сделать это частью системы, для меня загадка.
Плагины. Расширение функционала
Сама по себе концепция плагинов отвратная. Это из-за того, что плагин необходимо прицепить к системе, а значит появляется такое извращение как хуки (hooks / actions). Это всё дурное наследие WordPress.
Конечно, же схема бездумно копируется авторами CMS.
В Albireo CMS нет ничего подобного, поскольку здесь не нужна прослойка в виде плагина. Если нужно интегрировать любую функциональность, то это делается напрямую. Это подразумевает поддержку PSR4, Композера, а также любых произвольных функций и php-классов. В системе нет потребности что-то подключать через хуки, поскольку функционал используется как есть. Ему не нужны посредники.
Использование ИИ
У меня были идеи по интеграции нейросетей непосредственно в Albireo CMS (это не сложно), но я отказался от них, поскольку развитие ИИ очень быстрое. Поэтому я выбрал более простой путь, когда результат ИИ можно легко интегрировать в Albireo CMS. Скажем Копилот выдал html-код — всё что нужно сделать — это просто его вставить в файл.
Есть и обратная интеграция. Есть готовые промпты для ИИ, которые можно использовать как заготовки. Есть динамические промпты, которые готовят для ИИ данные по структуре сайта, например для того, чтобы ИИ мог проанализировать и выдать рекомендации.
Интеграцию с ИИ, на текущий момент рассматривают только владельцы крупных CMS-бизнесов (там большие $вложения). Они хотят использовать нейросети для генерации контента, а также для формирования поддержки и аналитики. Также есть идеи о том, чтобы ИИ брал на себя часть работы по генерированию динамического контента, например выписки по счетам в pdf-файлах.
В этом разрезе Albireo CMS может использоваться, поскольку это не просто управление контентом, а мощный программный комплекс, который позволяет легко интегрировать сложные решения, например создание собственного API или полноценного раздела поддержки пользователей.
Я ни разу не встречал и даже не слышал, чтобы flat-file CMS планировали делать что-то подобное.
Ресурсоёмкость
Я не ставил себе цель выполнять сравнение производительности flat-file CMS с большим количеством страниц. Единственная система, где я это сделал — Grav. Уже при 10 страницах потребление php-памяти было что-то около 15Мб, а скорость генерации примерно 0.5 секунд. Возможно, другие системы не такие прожорливые.
Админка Grav показывает 0.9 секунд при 35 Мб памяти.
Наверное стоит ещё упомянуть и то, что админка Grav при каждом обновлении страницы отправляет данные сайта куда-то в Сеть. Это к вопросу о безопасности.
Системы, которые требуют Composer получаются самые большие по объёму. Опять же, я не ставлю цели критиковать, просто по мне идея FLAT-FILE CMS как раз в миниатюризации сайта.
К сожалению, я не могу сравнить размеры «ядра» систем, поэтому просто приведу данные Albireo CMS Lite для информации.
- Каталог
system— примерно 200Кб. Это ядро, конфигурации, языки, виджеты, и даже трансфрер данных из MaxSite CMS. - Каталог
website— примерно 28Мб, но из них почти всё — это лендинги и демо-данные (19Мб), изображения (примерно 5Мб) и каталог ресурсов (шрифты и сторонние библиотеки - примерно 5Мб).
Если оставить самый минимум, то получится 1,7Мб на всё.
Какое число файлов страниц могут выдержать другие системы, мне неизвестно. Например этот сайт — примерно 450 файлов (0.235s/0.68Mb). Тестирование показало, что 1000 страниц — вообще без проблем, а максимум я ставлю в 10 тысяч. Но, уверен, это сильно зависит от мощности сервера. Всё-таки такое количество — очень крупный сайт.
То есть для меня важно, чтобы система могла работать быстро и не съедать все ресурсы сервера.
Если у вас есть опыт работы с flat-file CMS, поделитесь опытом в комментариях!