CMS для людей

28-04-2024Время чтения ~ 19 мин.Albireo Framework / CMS 678

За всё время было создано наверное десятки тысяч самых разных CMS для сайтов (Content management system). Понятно, что львиная их доля была написана просто так, скажем, в учебных целях, другая часть под какие-то свои задачи. Популярных систем вообще можно пересчитать по пальцам, а актуальных, то есть тех, которые ещё держатся на плаву, осталось довольно много, но все они стараются копировать другие системы. Корень проблемы в истории развития CMS.

Исторически можно считать, что первой полноценной CMS для сайтов стала Mambo с 2000 года. Это ужасная-ужасная система, но которая дала толчок к пониманию того, что сайтом можно хоть как-то реально управлять. В последующем Mambo превратилась в Joomla, где стала более дружелюбней и покладистей. Но суть не в этом, а в том, что на заре сайтостроения никто элементарно не понимал, как нужно делать правильно. Поэтому и лепили снеговиков кто на что горазд.

Следующей системой, которая заслуживает упоминания — это b2 (cafelog.com). Где-то с 2001 по 2003 год эта система развивалась аж до версии 0.6, после чего была успешно заброшена. Но её подобрал один ушлый паренёк, который превратил её в WordPress. Опять же речь не об этом, а о том, что в b2 был заложен более-менее понятный механизм работы CMS, который применяется до сих пор.

Бала ещё Movable Type, но она была написана на Perl. Кроме того, авторы MT много игрались с лицензией, и это послужило причиной ухода от их системы.

Базис такой. Есть MySQL, есть админка, через которую работают с этой базой — публикуются записи, всякие настройки. Технически это index.php, который подключает функции ядра, потом формирует html-код страницы. Часть ядра была выделена отдельным каталогов, админка тоже отдельной, остальные файлы разбросаны кто-как.

Со временем была добавлена система плагинов, парсеры текста (основной был textlite, потом markdown), но изначально не было системы шаблонов. То есть всё что нужно было выводить, вся вёрстка производилась в главном index.php. Но, по сравнению с Mambo, это был настоящий прорыв.

Фактически, если современный php-программист решит написать свою CMS, то, если он не предусматривает систему шаблонов, то фактически он пишет систему уровня b2 (0.6) или WordPress версии 1.2 (2004 года). Если же система шаблонов всё-таки требуется, то рекомендую обратить внимание уже на версию WordPress 1.5 (2005 год).

Интересно, что система шаблонов WordPress развилась как костыль вывода страницы в b2. В b2 изначальная идея была верной — получение данных, а потом их вывод в теле html-кода. Да, это лапша кода, но архитектурно подход верный. Перед выводом страницы, подключался файл blog.header.php, который и получал все нужные данные для вывода. Но в WordPress тот же самый wp-blog-header.php вдруг стал отвечать за всё — он сразу стал подключаться в index.php и уже содержал в себе всю логику остальных подключений. Это артефакт до сих пор входит в WordPress.

То есть структура WordPress уже с самых первых версий стала увеличивать запутанность файлов и логики. То есть вместо того, чтобы почистить код (на тот момент не самый объёмный), и привести логику работы системы в порядок, они стали просто лепить новый код поверх старого. Переломной должна была стать версия 2.4, но после бурных обсуждений, они вообще отказались о её выпуска и продолжили в том же направлении с 2.5. Чтобы было понятно, WordPress на тот момент (2008 год) казался очень продвинутой системой, но он не считался CMS в понимании того времени. Именно тогда стали появляться разработки, которые позволили бы сделать из WordPress полноценную CMS (WordPress as CMS). То есть вместо нагромождения кода, предлагалось сделать некий php-фреймворк на базе которого уже и лепить систему. Но победила глупость, как обычно.

Идея использования фреймворка для построения CMS родилась не сразу. Были разные проекты, но самым важным можно однозначно считать CodeIgniter. Его появление (2006 год) перевернуло мировоззрения многих программистов, потому что ребята из EllisLab были не просто технически грамотными, но и понимали архитектуру систем и возможности (и потребности) языка.

Но я вижу главную причину того, что CodeIgniter стал ведущим php-фреймворком в том, что его разработчики делали его для другого своего проекта — ExpressionEngine CMS. Никто толком не знает что это за система, поскольку её код был закрыт, а сама система стоит 250$. Но важно только то, что CodeIgniter развивался не на пустом месте, а от реальных потребностей клиентов. Именно поэтому CodeIgniter практически идеально ложился на потребности php-разработчиков.

Проблемы с CodeIgniter случились из-за внутренних разборок в EllisLab. Фреймворк имел особую лицензию, поэтому со стороны никто не решался продолжать его развивать. Были баг-фиксы, но к 2013 году CodeIgniter фактически перестал развиваться и его отставание от возможностей PHP уже были очень большими (взять например ту же автозагрузку классов, работу с сессиями и т.п.). Вместо того, чтобы просто открыть лицензию на CodeIgniter, EllisLab больше года занимались тем, кому бы его передать. Выбор пал на Технологический институт Британской Колумбии, что фактически означало полный крах развития фреймворка. Студенты, которые не имеют опыта разработки, по определению не могут написать что-то стоящее.

Но, как говорится, свято место пусто не бывает, стали появляться другие php-фреймворки. Здесь стоит отметить Yii и Laravel. Изначально они архитектурно были очень близки к CodeIgniter, но главное, что они поддерживали новые возможности PHP. И это дало толчок к их развитию.

Однако новые фреймворки содержат одну фундаментальную проблему: они не отвечают реальным запросам сайтостроителей. Современный php-фреймворк — это сферический конь в вакууме. Его разработчики придумывают новые библиотеки, всякие механизмы, но всё это оторвано от реальности. Я допускаю, что 1% php-программистов нужны все эти замысловатые возможности, но остальным 99% более чем достаточно простых и понятных библиотек. Всё из-за того, что фреймворк развивается сам по себе, и не имеет никакой обратной связи от тех, кто делает CMS для своих клиентов. Потому что клиента не интересует внутреннее устройство, но вебмастер, который обслуживает сайт, должен иметь в распоряжении готовые решения. Но фреймворк, вместо того, чтобы предоставить несколько готовых функций, как это было в CodeIgniter, предлагает совершить огромное количество телодвижений.

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

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

Здесь камень в огород не только разработчикам фреймворков, но и авторов CMS.

Почти все CMS в той или иной мере повторяют другие популярные системы. В основном это WordPress, поскольку считается, что в нём реализован более-менее удобный интерфейс управления сайтом.

Когда я делал MaxSite CMS (2008 год), то изначально задача именно так и ставилась — сделать систему, которая будет перекрывать все возможности WordPress, но при этом быть полноценной CMS: гибкой, лёгкой и быстрой. Так оно и случилось, и многие другие разработчики пытаются пойти по этому же пути — копированию WordPress.

При разработке своей CMS, даже в учебных целях, не следует слепо копировать другие системы. Я брал WordPress (как основную идею), потому что очень неплохо в нём ориентировался и знал все проблемные места. За несколько лет поддержки русского WordPress я накопил много идей и готовых решений, но которые невозможно было реализовать в рамках этой системы. Поэтому когда я стал делать MaxSite CMS, то уже знал что именно хочу получить в итоге.

Если у разработчика нет опыта работы с CMS, то всё что он сможет сделать, так это придумать hello world с прикрученным сторонним визуальным редактором. Это не CMS. Полноценная CMS должна удовлетворять запросы клиента, причём такие, о которых вебмастер может даже не догадываться.

Простой пример. Например в MaxSite CMS есть плагин meta_robots, который позволяет указать разные meta-опции для разных страниц. Это очень специфичная потребность, которая потребовалась одному моему постоянному клиенту. Изначально я прописывал эти meta в файлах шаблона, но потом всё-таки сделал отдельный плагин. Другие пользователи системы даже не предполагали, что может быть такая потребность, но зато теперь у них есть такая возможность. А теперь подумайте, как именно вы будете реализовывать разные meta в своей системе, если на этапе создания системы вы даже не предполагаете о существовании такой потребности?

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

Следует признать тот факт, что все существующие CMS имеют архитектуру 20-летней давности и уже морально устарели. Подавляющее большинство систем содержат код, который просто не нужен и должен быть удалён. Огромное количество кода, функций, классов элементарно никем не используются, хотя и являются частью системы. Разработчики систем, в погоне за модой, добавляют возможности, которые сто лет как не нужны пользователям.

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

Сейчас я расскажу, как я вижу будущую Albireo CMS.

Наверное стоит сразу отметить, что у меня большой опыт создания сайтов и работы с клиентами. Поэтому при проектировании CMS я учитываю именно свой опыт и понимание того, как должны работать та или другая часть системы. Очень часто я предлагал возможности, которые на практике оказались редко используемыми. Поэтому CMS следует снабжать только теми возможностями, которые будут востребованы 80% пользователей.

Типы сайтов

Albireo CMS работает на файлах (flat-file), поэтому есть сайты, где это неприемлемо. В первую очередь это те сайты, где точно необходимы база данных, например Интернет-магазин или требуется учёт пользователей. Такие системы, по моему мнению, следует проектировать индивидуально, чтобы учесть все потребности в структуре базы.

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

Вывод записей в блоге как правило в хронологическом порядке — это считается типовым поведением блога.

Блог можно расширить на «обычный сайт» (условно) с тем, чтобы предложить возможность публикации разного рода типов страниц. То есть идея в том, что некоторые страницы сайта можно сгруппировать особым образом. Например сделать подборку избранных страниц. Или страниц, где размещены только фото. По сути тип страниц нужен только для группировки записей. Традиционно считается что это рубрики и метки, но это больше элементы навигации, а типы страниц это больше для выборки и группировки. Понятно, что и типы, и рубрики, и метки — это произвольные варианты.

Модульный сайт — это когда мы можем вывести страницы произвольными блоками. Например на главной сделать блок фото, блок избранного, блок по какой-то метке или рубрике, блок в случайном порядке, блок в указанном порядке, блок произвольного текста и т.д. Такой сайт может выполнять роль сайта документации или просто быть определённой тематики.

Ну и конечно, это лендинги. Произвольные по дизайну и структуре. Особенностью может быть то, что лендинг может использовать css-код (css-фреймворк), который вообще никак не связан с основным дизайном сайта. Сейчас много готовых открытых лендингов в html-формате и система должна позволить их использовать в исходном виде (ну может кроме правки url-путей).

Блог/сайт и лендинги — это основные задачи, которые должна решать Albireo CMS.

Удобный блогинг

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

Ну и Ctrl+S в обязательном порядке.

Парсер текста TextSimple близок к MarkDown, но что-то хорошее взято из TextLite. Своих плюшек тоже много. Основная задача в том, чтобы упростить написание текста, но при этом сохранить возможность генерации управляемого html-кода. Ну типа, указать классы или стили. Другие парсеры этого просто не умеют.

Сразу из коробки такие плюшки к sitemap.xml, rss.xml, OpenGraph, полноценный favicon, сжатие html-кода, преобразование html-сущностей в PRE и CODE, защита содержимого STYLE и SCRIPT, подсчет статистики просмотра страниц. Всё это работает сразу, но легко управляется через конфигурацию или прямо в полях страницы.

Изображения

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

Все изображения можно автоматом конвертировать в Webp. Это вообще базовый формат для Интернета. Схема такая — мышкой перетаскиваем сколько нужно файлов (например jpg) в окно браузера, система автоматом их конвертирует в нужный размер и качество. Всё настраивается тут же. При этом исходные файлы просто удаляются и на сервере остаются только webp-файлы.

При этом сразу не делаются никаких миниатюр — это задача возложена на этап физического вывода изображения, где указывается исходное и разные параметры, того, что нужно в итоге.

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

Другая задача — конвертирование уже загруженных (например по ftp) изображений в webp. Прямо в теле страницы вызываем convertToWebp() с адресом каталога и система сама всё сконвертирует.

Недавно я переносил старенький сайт на Albireo CMS (она в процессе разработки, поэтому пока нет версий), так исходный объем изображений с 120Мб сократился до 49Мб. Это очень существенная экономия.

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

Гибкость

Произвольные адреса страниц и их http-методы. Произвольные вставки в HEAD и BODY. Сама система будет предлагаться с готовым шаблоном, где уже будут реализованы практически все базовые потребности блогера. Идея в том, что часть подключаемых файлов управляется с помощью полей записи. Например нужны Bootstrap Icons, просто указываем

use.bootstrap-icons: +

Или нужен FontAwesome 5:

use.fontawesome5: +

Почему эти? Мой опыт подсказывает, что этого достаточно.

Точно также подключаются лайтбокс, слайдер, рейтинги, выводы навигации, иерархия страниц и грид-галерея, подсветка кода, альпина, css-грамм и т.д.

Когда у блогера возникает потребность что-то подключить в HEAD или Lazy, то его действия просты. Либо он может прописать подключения прямо в теле страницы, либо, если это используется повторно, он размещает файл в каталоге head, lazy, content и т.п. Дальше указывает опцию и включает его как поле страницы. И опять же все именования произвольны.

Структура страниц

Все страницы имеют базовый каталог (pages), а дальше гуляй по самое «нехочу». Можно использовать подкаталоги, которые будут формировать url-адрес. Либо просто в файле можно указать произвольный slug или его шаблон/паттерн.

Если стоит задача, то можно разместить изображения рядом с файлом записи. Это удобно для случаев, когда требуется переносная документация или какие-то примеры. То есть не нужно разделять файлы текста от файлов изображений в uploads.

Рубрики, метки и любые другие группировки произвольны. Критерии группировки выбирает автор.

Шаблоны сайта

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

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

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

Отдельно сниппеты и модули шапок и подвалов — это произвольные данные. В MaxSite CMS компоненты более сложны, поскольку требуют обслуживания через админку, а в Albireo CMS намного проще — правь в самом файле, либо в его конфиге.

Сайдбар настраивается отдельно и отдельно указываются виджеты. Управляются через конфигурационный файл.

Это базовые возможности. Да есть ещё одна фишка, которой нет в других CMS — шаблон сайта может быть произвольным для любой страницы. Просто указывается в поле записи. То есть страницы сайта могут использовать разные шаблоны.

Нулевая установка. Обновление

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

Обновление предполагается как инкрементное. То есть для обновления будет достаточно только загрузить изменения от стабильной версии. Смысл в том чтобы исключить возможную перезапись изменённых файлов, например конфигурацию. Причём файлы системы будут распространяться в виде всего одного-двух phar-файлов. То есть обновление ядра системы будет прямо поверх старых файлов.

Файлы сайта принадлежат вам

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

В Albireo CMS — все файлы записей принадлежат вам. Это обычный текст без обработок. Все изображения также принадлежат вам. Все загрузки по ftp автоматом принимаются за актуальные версии и мгновенно отображаются на сайте. То есть работать с сайтом можно на локальном компьютере, а потом просто синхронизировать с сервером. Скажем с помощью WinSCP буквально в пару кликов.

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

Комментарии

Не каждая Flat-file CMS предлагает комментарии. Обычно просят использовать сторонний сервис. В Albireo CMS — комментарии есть. Они простые, работают с анонимными комментаторами, данные сохраняются в текстовых файлах. Поэтому редактирование и их обслуживание ничем не отличается от обычных страницы. Уведомления админа стандартно — по email, для остальных есть rss-подписка на комментарии (читать например в Thunderbird).

Управление доступом. Регистрация пользователей

Поскольку Albireo CMS не соцсеть, то в ней нет самостоятельной регистрации пользователей (в целях безопасности и нет такой необходимости; технически же это сделать не проблема). Вместо этого админ сайта может вручную создать пользователей в отдельной конфигурации. Указывается логин, пароль, срок действия учетной записи, а также произвольные разрешения.

Такой подход позволяет создавать на сайте что-то вроде платной подписки, когда часть контента скрывается от простого посетителя. Скрытие контента реализуется очень просто с помощью поля, где следует указать уровень доступа, а в тексте разметить управляющие блоки. В комплекте сразу несколько спиппетов, которые плавно скрывают текст защищённого блока. Важно ещё и то, что скрытие происходит на самом деле, а не как это часто встречается с помощью css-свойств и обычный Ctrl+U позволяет прочитать якобы скрытый текст. Здесь текст скрывается по настоящему.

Система не использует куки, а работает на php-сессиях (формально это всё-таки одна кука-идентификатор). Это сильно упрощает взаимодействие с посетителем.

В комплекте все формы и примеры подписки.

Безопасность. Редиректы

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

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

Также указать 301-редиректы для любых адресов. Это выручает, если страницы меняют свой адрес, а терять трафик не хочется. Хотя, если строго, то можно просто указать второй адрес страницы прямо в поле записи. То есть она будет доступна сразу по нескольким адресам.

Из коробки полноценная работа с AJAX. Её особенность в том, что есть два способа работы с post-запросами. Первый — это обычная страница, только обрабатывается как пустой шаблон (так сейчас в Albireo Framework), а второй — указание специального обработчика — handler, который работает как простой php-скрипт. Система сама проводит нужные проверки безопасности, оставляя обработчику непосредственную работу с запросом. Если сайт использует AlpineJS, то можно использовать готовую заголовку для Ajax-форм.

Расширяемость

Принцип довольно простой. Если чего-то не хватает, то можно разместить свои файлы с функциями в отдельном каталоге. Система их автоматом подхватит. Точно также поддерживается psr4-автозагрузка, а также каталог композера vendor.

Схемы плагинов как таковой нет, поскольку это тупиковый вариант. Но есть система событий events, которые срабатывают в определённых функциях. Можно к ним прицепиться.

TPL-Шаблонизатор

Функционально он близок к Blade, но использует более привычный синтаксис фигурных скобок. В отличие от других php-шаблонизаторов, в Albireo CMS он очень быстрый, использует static-кэширование, а также не запрещает использование нативного php-кода. Кроме этого мой шаблонизатор умеет отлавливать не только исключения, но и ошибки файла шаблона. Это же относится и к некоторым другим подключениям php-файлов — они выполняются изолированно, что позволяет избежать краха системы (бывают такие ситуации).

Отладка

При разработке я часто использую функцию pr(), известную пользователям MaxSite CMS. Здесь она уже доведена до ума и расширена. Например можно указать сразу несколько переменных для вывода.

Также есть специальная функция alert(), когда нужно вывести какое-то заметное сообщение, чтобы на него обратили внимание. Часто помогает отловить ошибки уже на этапе работы сайта.

И есть отладочные функции с инверсной работой — это когда функция вызывается в самых разных частях системы, но для их отладки можно прописать debug() в самой функции. Основана на стандартной отладочной функции PHP debug_backtrace(). Позволяет очень круто отслеживать все запросы к функции и отлавливать что-то нестандартное.

Ядро

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

«Free Admin»

Взял в кавычки, поскольку ещё не придумал ка правильно назвать. Это админка, которая работает в рамках самого сайта. Кто помнит, изначально в Albireo Framework админка была выполнена как часть обычных страниц сайта. Эту идею я когда-то разработал для своего LPF (Landing page framework) где-то в 2014 году. Проблема такого подхода в том, что такие страницы становятся сильно «жирными», поскольку, как ни крути им нужен дополнительный функционал.

Потом в Albireo Framework я вынес её отдельно и примерно в таком виде она работала в Albireo CMS. После того, как ядро системы в целом оказалось отработано, то выяснилось, что специфичных для админ-панели функций совсем немного. Причём, даже если сравнивать с другими CMS, страниц (пунктов меню) для админки получается не так много. Нужны дашборд, списки страниц, комментарии, изображения, статистика, логи, текстовый редактор, конфиги и может ещё один-два пункта. Раздувать систему, вынося эти страницы отдельно мне бы не хотелось.

С другой стороны админ-страницы всё равно оказываются «жирными», а также они требуют дополнительного обслуживания. И тогда я придумал компромиссный вариант — функционал админки использовать в самом ядре (там просто), но сами страницы, работают как обычные страницы.

Таким образом всё, что нужно пользователю настраивается через конфиг-файл, а сама админка для пользователя занимает один подкаталог суммарным объёмом 4,5Кб. При обновлении ядра, автоматом обновляется админка, но при этом у пользователя есть возможность самостоятельно добавить любую админ-страницу под свои задачи.

CMS для людей

В сухом остатке вот что получается. Компактность кода обеспечивается за счёт возможностей PHP 8, а так же уже отработанных мной алгоритмов. Система шаблонов взяла лучшее из MF, но оставила за бортом всё то, что использовалось для совместимости и неудачных реализаций. Скорость работы системы ничем не уступает (скорее превосходит) любую другую CMS. Отсутствие установки делает её привлекательной для любого хостинга и пользователя.

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

Возможности Albireo CMS уже сейчас близки к WordPress или даже MaxSite CMS. Причём некоторые вещи, например интеграция с произвольными библиотеками, здесь реализована намного удобней.

Основная идея, которую я вкладываю в Albireo CMS — это быть системой управления сайтом для людей.

Слава Украине! Смерть рашистам!