Еще одна коробочная CMS — знакомство с FFCMS

Добрый день, читатели и авторы habrahabr! Сегодня я хочу рассказать вам о еще одной небольшой коробочной системе управления содержимым сайта FFCMS, разработкой которой (ранее — для собственных проектов, а теперь и для всего сообщества) я занимаюсь чуть более года. В данной статье я хочу кратко рассказать о том, что умеет данная система, кратко коснуться освещения возможностей основных интерфейсов системы и немного рассказать о технических деталях.

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

1. Что это за система?

Многие, сразу вероятно сделают вывод «ну вот, очередной же велосипед...» и возможно, они будут правы, но позвольте мне все же рассказать вам о системе управления содержимым сайта «FFCMS».

FFCMS (от англ. «Fast flexibility content management system») — быстрая, расширяемая система управления содержимым сайта, написанная на php с использованием баз данных сервера mysql. При разработке данной системы я ставил себе несколько условий:

1. Быстрота работы и низкое потребление ресурсов — данный вопрос зачастую является самым сложным: приходиться выбирать между удобством разработки, избыточностью кода и скоростью работы конечного приложения. Много раз я задавал себе вопрос — может следует взять symphony и отказаться от необходимости реализации логики работы и вспомогательных методов? В итоге я остановился на модели простейших реализаций с использованием паттерна singleton (что конечно не всегда уместно, но всегда просто).


2. Возможность быстрого прототипирования интерфейсов — здесь решением стало использование шаблонизатора twig и знакомого большинству bootstrap CSS фреймворка.


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


4. Возможность ведения мультиязычных версий сайта (расширенная мультизычность из коробки) — данный вопрос особо актуален в наше время, когда возникает необходимость доносить информацию с сайта на нескольких языках: будь то сайт компании, предоставляющей услуги или товары, или информационное агентство, транслирующее информацию на нескольких языках.

Для работы с базой данных была выбрана стандартная возможность php — PHP::PDO с отключенными EMULATE_PREPARES для обеспечения безопасности sql-запросов. В качестве стандартных визуальных редакторов системы используются CKeditor (html) и wysibb (bbcode). Версификацию обновлений системы на определенных стадиях разработки я решил классифицировать в соответствии со спецификацией SemVer (major.minor.path).

2. Интерфейсы системы

При реализации различных моделей взаимодействия пользователя и сайта было принято решение разделить все интерфейсы системы на 4 основных типа в зависимости от источника взаимодействия и назначения выполняемых операций. Так появились: интерфейс пользователя, интерфейс установщика системы, интерфейс администратора и интерфейс API приложений.

Интерфейс пользователя

Данный интерфейс предоставляет реализации для взаимодействия между пользователем и собственно алгоритмами сайта. Все пользовательские запросы к сайту будут обработаны именно в рамках пользовательского интерфейса(за исключением AJAX взаимодействия — в данном случае будет использоваться интерфейс api).

После стандартной установки данный интерфейс выглядит следующим образом:

Интерфейс администратора

В свою очередь данный интерфейс предоставляет возможности взаимодействия между содержимым сайта и администратором — функции управления.

После авторизации на сайте и перехода в административную панель данный интерфейс выглядит следующим образом:

Интерфейс установщика и API

Интерфейс установщика предоставляет возможности упрощенной установки системы на ваше оборудование. Так же в данном интерфейсе реализованы возможности обновления системы со старых до более новых версий системы.

В свою очередь интерфейс API не имеет шаблонной реализации — его задача это реализация некого подобия на REST API. Основной целью данного интерфейса является обработка запросов и по мере востребованности возвращение результата обработки — хорошим примером является AJAX взаимодействие.

3. Расширения системы

Как я уже ранее отмечал, все расширения системы представлены 3мя основными типами, однако общее количество типов реализаций — 5, среди которых:

• Компоненты — генерация содержимого сайта в зависимости от внутреннего URI запроса.


• Модули — работа с шаблонными позициями.


• Хуки — реализация методов взаимодействия между расширениями системы, сторонним кодом и сервисами.


• ApiCallback — реализация простых REST API для взаимодействия внутри и вне системы при использовании системного интерфейса API.


• Cron — реализация дополнений к расширениям, позволяющие выполнять задания по расписанию (Cron task).

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

Данные о расширениях в системе хранятся в специальной таблице в базе данных (_extensions), в которой обозначены: тип расширения, директория реализации, конфигурации, версия, совместимость а так же информация о правилах путей работы данного расширения (исключительно для модулей — роутинг компонента ведется в зависимости от названия директории реализации).

Компоненты, модули и хуки могут содержать 2 набора реализаций:

• front: логика работы расширения для интерфейса пользователя


• back: логика работы расширения для интерфейса администратора(управление содержимым, настройки, прочее)

* Хочется отметить — я понимаю, что зачастую для программиста понятия «front» и «back» чаще ассоциируются с областью выполнения приложения (клиент или сервер), однако в данном случае данные значения классифицируют целевой интерфейс взаимодействия внутри системы.

О расширениях я планирую рассказать вам в отдельной статье — от логики их работы и взаимодействия и до реализации готового примера.

4. Небольшая презентация

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

5. Ссылки и послесловие

В первую очередь хотелось бы поблагодарить команду habrahabr за поддержку столь малозначимого (по масштабам) проекта одного разработчика и одобрение участия в программе помощи стартап-ам.

Официальный сайт проекта: ffcms.ru (прощу прощения за качество английской версии сайта).

Проект на github: git@github.com:zenn1989/ffcms.git.

Каталог расширений: каталог ffcms (буду рад вашему участию).

Немного о себе и «от себя»: зовут меня Пятинский Михаил, я являюсь жителем скромного города Керчь (Крым). К сожалению, не имею высшего образования, связанного с программированием. В нашем городе серьезно программированием занимаются единицы, а веб-разработкой и подавно (мне неизвестна ни одна веб-студия в нашем городе), поэтому большинство опыта разработки (в том числе какой-никакой командной) я получил в виртуальной среде (удаленная разработка). Я понимаю, что мой код и его качество очень далеки от идеала и я не в коем случае не ставлю его в уровень с yii, symphonyили другими замечательными CMF фреймворками, однако именно вы можете поучаствовать в разработке и улучшить проект и качество его кода. Я всегда открыт к диалогу.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.