Некоторые мысли по поводу MaxSite CMS

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

Поскольку у MaxSite CMS есть уже своя устоявшаяся аудитория, то мне бы не хотелось делать резких движений. Поэтому я примерно определил возможные варианты развития системы.

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

Если провести небольшое сравнение, то в шаблонах MaxSite CMS используется main-файл, но в рамках type-файла. Type-файл, в свою очередь, зависит от типа данных (фактически это часть URL), например для главной это будет один файл, а для одиночной записи, другой.

В Albireo CMS чуть проще — здесь нет type-файлов, поскольку у страницы может быть произвольный URL, но есть main-файл (только он называется layout-файл), внутри которого и происходит вывод записи.

То есть я изначально взял идею из MaxSite CMS, но сделал её на порядок проще и удобней. Теперь нет вообще никакой потребности завязываться на type-файлы.

Точно также было влияние из Albireo CMS (Framework, а до этого LPF/Landing Page Framework). Это касается кучи модулей, компонентов, верстки, CSS, js-библиотек и т.п.

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

Принципиальное отличие систем в способе хранения данных. Albireo CMS — это текстовые php-файлы и файлы SQLite. MaxSite CMS — это база данных MySQL.

Наверное я упоминал, что изначально Albireo CMS я хотел сделать так, что она могла одновременно работать на базе данных и на файлах, как сейчас. Там вопрос только в роутинге и «хитрой» схеме базы данных. У меня уже есть отработанная схема роутинга и базы, но потом я отказался от этой идеи, поскольку мне хотелось сохранить Albireo CMS именно как flat-file system. Но технически это вполне возможно.

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

С другой стороны у MaxSite CMS есть большой «технический долг». В первую очередь, конечно же, — это CodeIgniter 2.2.6, а это примерно 2015 год. Когда вышла третья версия, я было начал делать переход, но быстро выяснилось, что версия, хоть и отмечена новой цифрой, по сути ничего нового не даёт, но при этом ломает совместимость. Потом, как вы помните, была чехарда с 4-й версией и когда она вышла, то я, опять же, задумался о переходе. И, опять же, я не увидел ничего принципиально нового — да, был обновлен код под новые версии PHP, но по функционалу версия повторяла всё тот же CodeIgniter 2 версии. Какой тогда смысл обновляться?

Тонкость ещё в том, что MaxSite CMS использует очень немного возможностей CodeIgniter. Когда я только начинал делать систему, то CodeIgniter был великолепным стартом, но он всё равно даёт свои ограничения. Для меня они стали совершенно огромадными, после того, как я сделал Albireo CMS.

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

Но если сравнивать систему с Albireo CMS, то я вижу все эти ограничения, и меня, как автора этих систем, гложет чувство некоторой «недоработки», потому что можно сделать лучше и больше.

Если рассмотреть гипотетическую линию развития MaxSite CMS, то я бы её обрисовал так:

• Отказ от CodeIgniter и вообще любых сторонних фреймворков в пользу отдельных php-библиотек.
• Перенести базу из MySQL в SQLite (это снимает все вопросы обслуживания базы).
• Переделать схему шаблонов на Albireo CMS (это даст очень хорошую гибкость).
• Сделать такой роутинг, чтобы можно было использовать для страниц любые адреса.

CodeIgniter

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

Также из CodeIgniter используются некоторые библиотеки, но они без труда заменяются своими или аналогичными сторонними.

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

База SQLite

Обслуживание SQLite намного проще. Поскольку это простой файл, то нет проблем сделать бэкап или синхронизировать два сайта. SQL-запросы принципиально не различаются с MySQL, но MySQL — это отдельный сервер, а SQLite доступен из коробки.

Что касается скорости работы, то лично я не вижу принципиальной разницы. С учетом того, что на серверах сейчас поголовно SSD и гигабайты памяти, то SQLite может работать даже быстрее, чем MySQL,

Почему не оставить MySQL или хотя бы дать выбор? Ответ — сложность обслуживания. Придётся делать прослойку, которая будет смотреть какая именно база и под неё строить sql-запросы. Оно того просто не стоит.

Шаблоны Albireo CMS

Дело даже не в шаблонах, как таковых, а в том, как именно выводить данные страницы. В системах аля-WordPress мы всегда работаем от адреса страницы. Просто по тому, что так работает роутинг. Но в Albireo CMS шаблон вообще никак не завязывается на адреса, роутинг, типы данных и т.п. Это «чистейшее» решение, когда просто выводятся данные, а откуда они были получены решается совсем на другом уровне. Поэтому такой шаблон может быть любой сложности и гибкости.

Роутинг

Роутинг с базой немного сложнее, чем роутинг по файлам, поскольку база будет состоять из нескольких таблиц и нужно будет понять какие из них могут содержать столбец «slug». То есть такой роутинг сразу лезет в базу и на выходе должен отдавать не все данные, а лишь некий «path» или флаг «страница найдена» и уже передавать управление куда-то ниже.

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

Админка

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

Итого

Пока я вижу два пути. Первый — ничего не трогать. Пока я потихонечку «пилю» Albireo CMS, там может родиться какая-то идея по расширению системы на базу данных, как я планировал изначально. Тогда MaxSite CMS не трогаем, пусть работает как сейчас.

Второй путь — это всё-таки заняться серьезной переделкой MaxSite CMS. Пока война, я этим точно заниматься не буду, но потом может быть. Но здесь важный момент ещё в том, что нужны ли эти переделки пользователям системы? Их и так немного, но если все менять, то это болезненно ударит по совместимости. Стоит ли оно того, совершенно не понятно...