Новая CMS с открытыми исходниками и лицензией “твори что хочешь, только автора упомяни”, похожая на 1С-Битрикс, но без многих его недостатков.
Под катом подробности, немного скриншотов и ссылки на документацию и GitHub.
Последние 2 года или около того я работаю с Битриксом, и не смотря на все его недостатки, система это неплохая. Но уже со второго месяца работы на ней я мечтал устранить некоторые недостатки. Когда чаша терпения переполнилась, в руки был взят NetBeans и игра началась!
Итак, что же хорошего в новой CMS и чем она лучше такого мастодонта, как Битрикс, у которого был без малого десяток лет на совершенствование?
Структура данных
В Битриксе
Сразу после установки, даже если выпилить все лишние модули, мы получим десятки таблиц, со сложными межтабличными связями. Каждый новый модуль добавляет свои таблицы, своё API, не всегда похожее на базовое. При этом все основные данные (базовые поля элементов) хранятся в одной табличке. И я блин не шучу, на одном из наших проектов при общем весе в ~2 Гб. в базе данных эта единственная табличка весит 1.4 Гб.
Кроме того, даже для тех же инфоблоков работы с базовыми полями и пользовательскими отличается – используются разные запросы, это разные сущности.
В HolyCMS
Во-первых, базовых таблицы всего 4 (5, если использовать кэширование в базу). Всё остальное, я повторяю, всё, собрано через базовые сущности – блоки данных (аналоги битриксовых инфоблоков), элементы и папки. Страницы сайта? Блок данных. Пользователи? Блок данных. Настройки сайта? Блок данных. И это позволяет вам использовать одно единое API для работы со ВСЕМ.
Во-вторых, каждый блок данных хранится в отдельной таблице. Папки хранятся в той же таблице, что и элементы, и имеют те же поля (хотя это и настраивается). Более того, можно прямо из интерфейса системы папку превратить в элемент, а элемент – в папку :) Все поля элемента хранятся в одной таблице, включая множественные поля, метатеги и прочее.
С множественными полями, правда, я немного переборщил в плане упрощения – все данные по полю хранятся в этом же поле, отделенные друг от друга точкой с запятой, а сами точки с запятой заменяются на неведомую комбинацию символов. При считывании оно раскладывается в массив, при записи – implodiтся в строку. Страшноватое решение, сейчас подумываю об замене его на сериализацию/десерализацию.
Структура сайта
В Битриксе
Один из неприятнейших (для меня) недостатков Битрикса – файловая структура сайта. Т.е, каждый раздел сайта – это файл с компонентами, причем физически нужно повторять папками структуру сайта. Я в курсе про ЧПУ-режимы компонентов, про возможности редиректами делать иные схемы, сам не раз их применял, но все равно это похоже на костыль. Изначально система заточена именно на редактирование файлов, и это и её счастье, и её проклятие.
В HolyCMS
Как я уже писал выше, страница – элемент в базе данных в одноименном блоке. Это позволяет и автоматические меню строить, и много других приятных вещей делать. Ну и реально одна точка входа в системе – это полезно (про битриксовый init.php я тоже в курсе, и тем не менее, сие не одно и то же). Кроме того, к странице можно привязать “модуль” – php-файл в папке site(или engine)/modules/имя_модуля/index.php. Плюс один и тот же модуль, но с разными параметрами можно привязать к нескольким страницам – со всеми вытекающими.
Скорость работы
Битрикс
Кэширование для битрикса – это необходимость. Без него генерация страницы может занимать заметное время. Да, в наше время при приличной посещаемости без кэширования не обойтись, но тут запрос данных из пары десятков инфоблоков может превратиться в пару сотен не самых коротких SQL-запросов. Да и длина этих запросов тоже уже стала притчей во языцех.
HolyCMS
Простота – залог скорости. Поскольку каждый блок – это отдельная таблица, то запросы просты, предсказуемы и очень, очень быстры. Впрочем, кэширование тоже есть, причем аж на двух уровнях:
1) прозрачное кэширование запросов к базе. Если вы сделаете 50 раз один и тот же select – реально до базы дойдет всего один запрос. Впрочем, запросы на insert/replace/delete кэш этот сбрасывают, так что у вас всегда будут актуальные данные.
2) кэширование блоков на выводе похоже на использование в Битриксе класса CPageCache. Даже вызов его похож:
$cache_component = new HolyCacheOut($news_id, 150, "news");
$result_cache = $cache_component->StartCacheOut();
if ($result_cache) {
//кэшируемый код вывода новостей
//…
$cache_component->EndCacheOut();
};
Частичная чистка второго кэша автоматически происходит при изменении данных в админке, связанных с ним (добавили новость? На сайте сбрасывается весь кэш, связанный с новостями). При этом данный класс – обертка, реально вызывается класс-драйвер. В комплекте два таких – для кэширование вывода в базу (мне почему то раньше эта идея казалось хорошей) и в файлы. Позже допишу варианты для mecache, например. Но никто не мешает и вам дописать нужные лично вам вариант. Не обижусь, если поделитесь ;)
API и плюшки
Битрикс
API мощный, но про недостатки его я уже упоминал выше, конспективно:
1) каждый модуль, будь то работа с рассылкой или форумом привносит своё API, причем иногда диву даёшься – ну почему вот по каким то параметрам можно получить список подписчиков или подписок, а по другим нет?
2) Внутри главнейшего модуля (инфоблоки) – работа с полями пользовательскими и встроенными отличается, постоянно есть какие то нюансы, например, с множественными полями работа отличается, если пользовательские поля вынесены в отдельную таблицу или нет; в определенных случаях множественное поле может возвратить значение, а может и массив из одного элемента; для того, что бы обновить одно поле в элементе нужно использовать одну функцию, если все – другую, если эти поля пользовательские – третью; запрос по нескольким инфоблокам сделать можно, но если использовать фильтр по полю, котрое есть не во всех инфоблоках – отключатся вообще все фильтры… Список можно продолжать, за два года у меня накипело :)
HolyCMS
API похоже и одновременно не похоже на то, что используется в Битрикса, дьявол ведь кроется в мелочах.1) разницы между полями пользовательскими и встроенными нет;
2) множественные поля всегда работают идентично — вы получаете ничто иное, как массив значений, ни больше, ни меньше;
3) все модули работают на базе «блоков данных», а значит API изначально идентично, отличаются только расширения функционала по сравнению с базовым;
4) API очень похож на битриксовый, так что переход будет безболезненным, но имеются и приятные фичи, например:
4.1) Один созданный объект работает с одним блоком данных
$res = new DBlockElement(“news”);
4.2) Есть функции, например, для получения сразу элемента, или готового массива элементов
$res->GetList($filter);
$news=$res->GetFullList(); //получили массив
4.3) Сами фильтры писать проще и наглядней.
$filter[]=Array("folder","=","0");
$filter[]=Array("cost","<=",$_GET['cost_max']);
$filter[]=Array("cost",">=",$_GET['cost_min']);
Или такой запрос:
$filter[]=Array("cost",">=",$_GET['cost_min']);
$filter[]=Array("OR","cost","<=",$_GET['cost_min']); //для второго и далее колонок можно указывать, как он связан с предыдущим - AND или OR.
Плюшка:
$id_array=Array(16,14,19);
$filter[]=Array("id","IN",$id_array); //IN-запрос автоматически раскладывается в строку в SQL запросе
Расширение интерфейса админки
Вам приходилось создавать собственные типы полей в Битриксе? Менять интерфейс в админке? Не очень дружелюбный процесс, правда? Ну и метод “почти все поля в одном месте, и да поможет нам святой SWTICH-CASE” навевает уныние.
В HolyCMS же этот процесс не прост, а очень прост. Каждый тип поля – это отдельный класс, все наследуются от одного базового. Наследуй, поменяй нужные методы, запиши строчку в базу – новый тип готов! Аналогично добавление страниц в систему администрирования, ссылок в верхнее меню системы – всё просто и понятно, простейший массив.
ООП и MVC, компоненты и шаблоны.
Здесь принципы работы так же похожи на битрикс, т.е. никакого MVC, только контроллер (модуль/компонент) и отображение (шаблон). Но без отличий не обошлось.1) В битриксе компоненты хранятся в папке системы. Здесь же для них есть папки site/components и engine/components. В первой хранятся пользовательские компоненты, во второй – стандартные системные. Аналогично с шаблонами сайта, site/templates и engine/templates, знакомые файлики header.php и footer.php.
2) Множественные компоненты НЕ хранят шаблоны вложенных компонентов в своей папке – они просто вызывают другие компоненты. Меня, честно говоря, пути вида /bitrix/templates/main/components/bitrix/news/special/bitrix/news.detail/.default бросают в дрожь. Здесь комплексные компоненты сами по себе, обычные – сами по себе.
3) Страницы сайта. Они работают по следующему принципу: вызывается подключенный к странице модуль, его вывод кэшируется, далее вызывается header.php, выводится сохраненный буферизованный вывод, далее – footer.php нужного шаблона. Как результат – модуль страницы прозрачно влияет на содержимое футера и подвала, заголовок страницы, meta-тэги и прочее. Т.е., опять же похоже, но проще.
Документация
Один демо-сайт (с исходниками, естественно), собравший в себе почти все фичи и возможности. комментарии в классам и функциям в формате PHPDocumentor. Ну и код опять же прокомментированный и открытый, никаких обфускаций. Увы, без костылей не обошлось, но я их число постоянно уменьшаю. Да, здесь битрикс документацией зарулит, но это пока.
Кто использует
Ну и тут конечно мне далеко до фирмы 1С :) HolyCMS кроме меня пока использует только небольшая екатеринбургская веб-студия Advance – 95% их сайтов построено именно на HolyCMS, точнее, на форке – AdvanceCMS, правда, почти все отличие форка на данный момент – в смене названия. Ну да лиха беда начала.
Что внутри
Куча велосипедов, а так же пачка готовых решений, вроде Twitter Bootstrap, jQuery File Upload’ера,elFinder’а, CKeditor’а и других подобных.
Где взять
Исходники системы, стабильная текущая ветка: https://github.com/Newbilius/holycms3/tree/3.1
Исходники системы, текущая рабочая ветка (последнии фичи, но стабильность не гарантированна): https://github.com/Newbilius/holycms3/
Исходники демонстрационного сайта: https://github.com/Newbilius/holycms3_demosite
Сайт системы: http://holy-cms.ru
Немного разработанных мною сайтов на данной CMS (предыдущей версии правда, но там разница не велика): http://siteszone.ru/portfolio/?tags=HolyCMS+2.0
И ещё немного сайтов, там уже не везде я автор: http://advance66.ru/portfolio
Лицензия
BSD3-подобная. Делайте что хотите, только упоминайте автора, и ссылку на мой сайт или мой email указать не забудьте. А так — продавайте, кодируйте исходники, только предыдущее правило исполняйте.
Что будет дальше
Больше ООП, больше классов, больше гибкости. Костяк структуры останется тем же, скажем, ORM скорее всего не будет, а вот PDO, пространства имен, наследование компонентов, нормальные цепочки вызова – обязательно. Новые компоненты, интеграция с 1С, исправленные баги и так далее.
Резюмируя. Если вам хоть чуток нравится Битрикс, но доконали его недостатки – попробуйте HolyCMS. В комплекте уже есть самые-самые базовые компоненты, такие как списки вывода новостей, постраничной навигации, генерации RSS, полный комплект для создания простого интернет магазина (корзина, список подобных товаров, личный кабинет с регистрацией и т.п.), форма обратной связи, компоненты работы с тэгами и т.п.
Если вам не нравится Битрикс – все равно попробуйте. Вдруг простота и прозрачность системы вам приглянется?В комментариях надеюсь услышать конструктивную критику, благо, система ещё только-только начинает своё шествие по сети. И, надеюсь, оно будет победоносным! :)
P.S. понятно, что надо в хаб «я пиарюсь», кармы вот капельку не хватает для перемещения.
Автор: Newbilius
