Обновление сайта
Сделал обновление этого сайта. Теперь он работает на Albireo CMS — это моя вторая система для создания сайтов.
Сразу отвечу на вопрос: «Почему не оставить MaxSite CMS?». Всё очень просто — мне так удобней, никакого подвоха. Я просто уже привык к Albireo CMS и мне сподручней вести сайты на одной системе.
У сайта я изменил дизайн, а также подшаманил раздел документации. Раньше было два раздела: book — для новичков и doc — для остальных, теперь всё будет в одном. В Albireo CMS создание документации уже часть системы и это еще одна из причин почему я использую именно её.
Шаблон сайта — стандартный шаблон Albireo CMS: в нём много разных вариантов и возможностей. Есть скрипт для автоматического переноса данных из MaxSite CMS.
Что касается MaxSite CMS, то я долго думал и пришёл к выводу, что ничего принципиального в ней менять не буду. Система будет, как раньше, обновляться, исправляться и будет полная поддержка. То есть я не намерен отказываться от MaxSite CMS. Так что если вы пользуетесь системой, то ничего для вас не меняется.
В развитии MaxSite CMS есть несколько нюансов.
Долгий цикл обновлений
Положа руку на сердце, я признаюсь, что у меня фактически нет задач, которые нужно решать для MaxSite CMS. Где-то лет 5 назад — это 105 версия, я закрыл весь список задач по системе. То есть ядро системы находится в таком состоянии, что уже не ясно что ещё с ним делать.
После перехода на PHP 7.1, где я сделал задуманный рефакторинг, в принципе уже менять нечего. То есть, конечно же, можно провести ещё один рефакторинг кода, как-то по другому организовать файлы, но с точки зрения функционала ничего не изменится. Вносить такие изменения, где может потеряться совместимость, я не вижу смысла.
Ограничения из-за CodeIgniter
Другой вопрос — это CodeIgniter. Опять же, можно перейти на новую версию, но это не добавит функциональность системы, а вот проблемы с совместимостью обязательно возникнут. Я не думаю, что это нужное направление.
Ограничения по структуре
Задумки, которые я реализовал в Albireo CMS, возникли как раз из-за структурных ограничений MaxSite CMS. Об этом я ниже подробней расскажу, пока только кратко о сути: в текущем варианте MaxSite CMS просто уже не может прыгнуть выше головы. Где-то до версии 86 мы ещё «бились» по функционалу с WordPress (было с чем сравнивать), но с выходом 106-версии, которая основана на шаблоне MF, просто уже не с чем сравнивать. Даже premium-шаблоны WordPress на голову отстают от возможностей дефолтного шаблона MaxSite CMS.
Шаблон MF
MF — это локомотив MaxSite CMS. Дефолтный шаблон, хоть и основан на старой версии MF 12 (сейчас уже вышел MF 15, скоро будет 16-я версия на Berry CSS 5.1), но даёт такую степень свободы, о которой пользователи WordPress могут только мечтать.
Последние несколько лет почти все изменения в MaxSite CMS так или иначе касаются именно работы с шаблоном. Ядро системы за 17 лет развития уже отполировано дальше некуда. Поэтому если для MF стоит какая-то задача, то я могу внести изменения (добавить функцию) в саму систему, чтобы она стала доступна всем пользователям.
Можно сказать, что если и двигаться дальше, то фактически это будет движение в сторону шаблонов системы. Других направлений просто нет. И это при том, что все основные потребности были закрыты больше десяти лет назад.
Получается, что пользователь MaxSite CMS сразу из коробки получает premium-шаблон с высокой степенью кастомизации. Если он может сам что-то поправить, добавить, то делается это достаточно просто. Если нужен больший функционал, то добро пожаловать в полноценный MF.
Актуальность
Много правок приходится вносить из-за новых версий PHP в сам CodeIgniter. Вопросы там больше в синтаксисе, который разработчики PHP делают «устаревшим». В любом случае последняя PHP 8.4 MaxSite CMS поддерживает без проблем.
Откуда ограничения?
Основные ограничения MaxSite CMS возникли из-за архитектуры аля-WordPress. Моя система и создавалась как нормальная альтернатива WordPress и я считаю, что с задачей справился. Но эта архитектура уже не устраивает меня по степени свободы, который я бы хотел видеть в современном сайтостроении.
Одной из проблем является завязка на тип данных. То есть система вначале смотрит какой у запрашиваемого URL тип данных и дальше весь алгоритм строит от этого типа.
В WordPress'е эта схема очень жесткая, фактически зарыта в ядро. В MaxSite CMS тип данных определяется на уровне ядра, но вот получение и вывод данных — это уже часть шаблона. Именно поэтому в MaxSite CMS можно сделать то, что недоступно в WordPress.
Алгоритм, основанный на типе данных, используется практически во всех CMS. Часто она развивается в некие «content types», где вводится еще один уровень ограничения. Из этой же «оперы»: таксономия, фиксированные ЧПУ, завязка на сегменты URL, связка «pattern URL» + «controller» и т.п.
В чём здесь проблема? Здесь нет возможности задания произвольных адресов. Пользователь всегда вынужден строго следовать предопределённым правилам.
Другая загвоздка — это выполнение произвольного PHP-кода. В 99% случаев авторы CMS ограничивают выполнение php-кода пользователем. В лучшем случае есть php-шаблонизатор — это если есть потребность смешивать PHP + HTML. В MaxSite CMS задача более-менее решена удовлетворительно, поскольку система работает через стандартные подключения require без особых ухищрений.
Но всё равно невозможно выполнить php-код в тексте записи. Как бы мы не ухищрялись, выполнение произвольного кода в тексте записи возможно только через eval(). Если система хранит записи в базе данных, то физически невозможно выполнить эту запись как php-код. А это подавляющее большинство CMS.
Важно это потому что запись можно было бы рассматривать как php-код, то есть в нём можно было бы спокойно использовать любую логику и решать любые задачи. PHP, собственно ради этого и создавался, но в текущем состоянии систем он элементарно не может использоваться.
Остальные ограничения вытекают уже из этих.
Несколько примеров для демонстрации
Свои задумки я реализовываю в Albireo CMS, потому что в рамках MaxSite CMS (да и любой другой аля-wp системы) этого сделать невозможно.
В Albireo CMS всё движется от адреса страницы. То есть у любой страницы можно задать любой произвольный адрес. Любая вложенность, любое расширение, например можно сделать страницу admin/my/привет/как-дела.html и это будет работать (я указываю адреса относительно корня сайта). Вы увидели, что есть admin и решили, что это обращение к админ-панели, но в реальности это ничего не значит - просто произвольный адрес.
Другой пример: адреса рубрик обычно имеют какой-то префикс, вроде category. Но что вы скажете на такие примеры адресов рубрик:
astronomy category/astronomy admin/my/привет/рубрика.html ❤️😼
То есть адрес рубрики (и меток, и страниц) могут быть также произвольными.
Ещё вопрос: «Как вы думаете, сколько действий нужно сделать пользователю, чтобы создать такие рубрики?». Обычно есть специальные страницы для создания рубрик в админ-панели, либо что-то вроде быстрого создания — во всех случаях рубрику нужно вначале создать, а потом её указывать. В Albireo CMS можно и так, а можно ничего не создавать — вы просто пишите произвольно рубрику на странице и всё. В любой момент её можно отредактировать и, опять же, нигде ничего менять не нужно.
Что нужно чтобы выполнить произвольный php-код в Albireo CMS? Просто написать его как есть. Больше никаких телодвижений.
Для вывода групп записей, например тех же рубрик, меток, карты и т.п. используется обычная страница и в ней php-код (довольно простой). Отчасти это можно сравнить с type-файлами, когда вы сами решаете что именно должно выводиться. Но type-файл привязывается к типу данных, а здесь вы можете использовать абсолютно любую страницу с любым адресом для любого вывода.
Можно сделать произвольные поля (аля-meta) для любой записи без дополнительных приготовлений. В других системах нужно программирование полей, здесь ничего не нужно — просто указываешь и всё.
Можно сделать произвольную группировку записей. И это не таксономия или жесткие правила: вообще произвольные поля и произвольные выборки, скажем выделить записи в отдельную группу.
Этими примитивными примерами я хотел показать, что степень свободы в современной CMS намного больше, чем в любой другой аля-WordPress системе.
Итого
Конечно же, Albireo CMS намного превосходит любую другую систему, включая и MaxSite CMS. Но MaxSite CMS среди WordPress-подобных систем итак хорошо выглядит, поэтому я не вижу смысла делать резкие движения. Пусть будут две системы: у них разная архитектура и они не мешают друг другу.