Checkpoint №2 по Albireo CMS

Это второй Checkpoint по Albireo CMS. С момента первого чекпоинта прошло больше полугода, поэтому есть с чем сравнивать.

Нулевая установка. Синхронизация. Бэкапы

Всё также система не требует инсталляции.

Для синхронизации локальный/удалённый сайт используется FTP. Если использовать WinSCP, то процесс можно автоматизировать. Если стоит задача синхронизации без учета времени, то используется php-скрипт, в котором прописываются каталоги, исключенные файлы и т.п.

Этот файл загружается на сервера (удалённый и локальный) и на локальном запускается как консольная команда. Скрипт сформирует bat-файл для запуска WinSCP. Он читаемый, поэтому можно проверить что и куда будет копироваться. Этот bat-файл запустит WinSCP в консольном режиме, где нужно будет ввести пароль. То есть достаточно один раз настроить скрипт и параметры доступа, дальше все работает автоматом.

Также есть специальный файл zip.php, с помощью которого можно быстро сделать полный бэкап сайта. Поскольку в Albireo CMS всё хранится в файлах, то с помощью этого скрипта можно быстро получить готовый zip-архив под текущую дату. Скрипт также настраивается: каталоги/файлы для добавления, исключения, парольная защита.

Компактность

Текущее ядро — примерно 140 функций, суммарным объемом примерно 450Кб, включая админку. PSR4 библиотеки — 11 шт. на 230Кб. Но пользователь получает просто два phar-файла суммарным размером 150Кб + файл лицензии.

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

Админ-панель

Админка постоянно дорабатывается и улучшается.

Текстовый редактор обзавелся автосохранением, списком «соседних» записей. Меню функций теперь работает как стандартно в Windows, где комбинируется hover & click. Также теперь, если файл не сохранен, при переходе на другую страницу или закрытие вкладки, браузер будет запрашивать подтверждение.

Доработал страницу всех файлов. Раньше это были просто списки файлов, теперь details-списки с учетом вложенности каталогов. Состояние списков сохраняется в LocalStorage.

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

То есть идея в том, что часть конфигурации можно редактировать в более удобном, чем php-код, формате.

На скриншотах видна админ-страница ToDo. Это демо-страница, которая полностью располагается в каталоге pages. Ей я хотел продемонстрировать, как пользователь может добавить произвольную страницу в админку. Посмотрите код, который сделает любую страницу админской:

/**
title: ToDo
slug: admin/todo
file-page-data: admin.php
**/

if (noUserAccess(extras: 'access-denied.php')) return;

albireo_admin_menu('todo');

// дальше свой код ...

Возможно ли придумать что-то более простое?

Сама админка настраивается через config-файл, причем так, что можно указывать только изменённые по сравнению с default, настройки. Катомизируется довольно многое, включая шрифты, стили редактора, пункты меню и т.п.

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

Формы. Валидация данных

Работа с формами тоже немного изменилась. Можно делать как и прежде, то есть самостоятельно решать как именно обрабатывать post/ajax, но можно воспользоваться уже готовым решением.

Если использовать Alpine.JS, то я написал отдельную js-функцию albireoForm(), которая упрощает отправку POST-запроса, а также анализирует ответ сервера. Фишка в том, что отслеживается состояние error (ошибки формы), а также http-код ответа (например редирект), а также можно возвращать и выполнять js-код. Обычно это запрещено, но часто бывает очень полезно.

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

Про валидацию данных я уже писал.

Ещё одна существенная доработка касается указания обработчика формы (handler). Есть три варианта.

Первый - это отдельная страница, которая будет иметь адрес и принимать http-метод. Это старый вариант, доступный еще со времен Albireo Framework.

Второй вариант — это использовать системный url для приёма ajax-запросов. В форме формируется скрытое поле, где кодируется php-файл, который и будет подключен как handler. Это позволяет не заморачиваться с адресам и работать с php-файлом обработчика «в чистую».

Третий вариант — это указать в форме имя функции обработчика. В этом случае система сама выполнит эту функцию. Конечно это возможно при условии, что она существует. Но, опять же, делается это достаточно просто: просто создаём php-файл в service/functions и Albireo CMS автоматом подключит его при загрузке системы.

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

Новое кэширование. Новый вариант получения записей

Про эту переделку я рассказывал раньше, суть её в том, что если раньше кэш строился просто как php-массив, то теперь кэш — это структурированные данные. Поскольку кэш все равно хранится в sqlite-базе, то есть смысл использовать её по прямому назначению.

Поэтому теперь кэш — это часть системы.

Соответственно изменился и сам подход к получению записей. Раньше — это была работа с большим php-массивом, теперь выборочные sql-запросы к базе.

Код для пользователя стал ещё короче и удобней, а скорость выборки будет напрямую зависеть от мощности сервера. Потребляемая php-память теперь менее 1Мб.

Готовые данные

Albireo CMS будет поставляться с демо-данными — это 70 страниц из Википедии.

Также будет возможность получить сразу 27 готовых профессиональных лендингов (они open source). Через них я хочу показать насколько просто адаптировать любые сторонние html/css/js-файлы к Albireo CMS.

Кроме этого в системе сразу будут страницы: рубрик, меток, контакты, последние комментарии, карта сайта, страница условия использования. Будут динамические RSS записей, RSS комментариев и sitemap.xml. Также будет файл обслуживающий post-запрос браузера csp-report.

Шаблон

Изменения по шаблону эволюционные. Где-то мелкие улучшения по коду, где-то улучшения по структуре css-кода.

В целом получилась более логичная организация файлов.

За счёт использования Berry CSS шаблон сразу имеет 19 тем цветового оформления. Также есть два css-файла для дизайна с полями браузера и без полей. То есть идея в том, чтобы предоставить пользователю сразу готовые решения по модульной сетке сайта.

Из сторонних модулей я включил в комплект jQuery 2 и 3, Bootstrap CSS 4 и 5 — они часто используются в лендингах.

Модули шаблона. Расширение шаблона

Сам шаблон содержит 10 модульных сеток под разные задачи.

Есть 4 подвала, 12 шапок, 4 настраиваемых модуля вывода главной и 8 разных блоков.

Вывод записей происходит через tpl-файлы шаблонизатора. Сейчас есть 19 готовых вариантов вывода.

Остальные tpl-файлы отвечают за вывод меток, навигации, пагинации и т.п.

Чтобы не трогать файлы шаблона, можно разместить свои файлы в специальном каталоге service/my. Система сама поймёт эти файлы и подключит их как файлы самого шаблона.

Это чисто практический подход, потому что в 99% случаев файл шапки или подвала нужно будет редактировать под свои данные. И вместо того, чтобы редактировать исходный файл, можно просто скопировать наиболее подходящий в свой каталог и там уже его отредактировать. Именно таким образом предполагается расширение default шаблона. Это немного похоже на child-theme, когда шаблон использует другой шаблон. Только у меня не нужно делать лишние телодвижения — используются только точечные изменения.

Идеология Albireo CMS

В какой-то мере я уже могу очертить общую идеологию системы. Albireo CMS — это инструмент. У неё есть область применения. У неё есть различные функциональные возможности. Естественно она отражает моё видение того, как можно создавать и вести сайты. Она отражает моё видение текущего состояния разработки. Я против раздутого кода, поэтому в системе всё очень компактно и аккуратно. Основной мотив развития Albireo CMS — это сделать нужную функциональность самым оптимальным способом/кодом.

У меня нет цели сделать систему похожей на любую другую. Когда я рассматриваю другие системы, то всегда задаю себе вопросы: «Зачем они так сделали? Какая в этом заключена функциональность? Удобно ли это для пользователя?». Таким образом формируется список возможностей системы. То что в других системах требует дополнительных модулей/плагинов, у меня уже есть «из коробки».

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