Another boxed CMS - familiarity with FFCMS

Good afternoon, readers and authors of habrahabr! Today I want to tell you about another small boxed content management system for the FFCMS website, which I have been developing (previously for my own projects, and now for the whole community) for just over a year. In this article I want to briefly describe what this system is able to do, briefly touch on the coverage of the capabilities of the main interfaces of the system and tell a little about technical details.

Disclaimer: I do not pretend to be the developer of an “innovation system” and I don’t sell anything, but just want to present an open content management system that may make life easier for the developer and webmaster. The system is not based on any popular framework - only minimal methods are implemented for interaction between extensions, routing and template views.

1. What is this system?

Many will probably immediately conclude "well, another bicycle ..." and maybe they will be right, but let me still tell you about the content management system "FFCMS".

FFCMS (from English “Fast flexibility content content management system”) is a fast, expandable content management system written in php using the mysql server databases. When developing this system, I set myself several conditions:
')

1. Quick work and low resource consumption - this question is often the most difficult: you have to choose between design convenience, code redundancy and the speed of the final application. Many times I asked myself a question - maybe you should take symphony and abandon the need to implement work logic and auxiliary methods? As a result, I stopped at the model of the simplest implementations using the singleton pattern (which is of course not always appropriate, but always simple).
2. The ability to quickly prototype interfaces - here the solution was to use the twig template engine and the framework familiar to most of the bootstrap CSS.
3. The possibility of rapid expansion of functionality - it was decided to divide the interaction logic into 3 main types of extensions: components, modules and hooks, which I briefly describe below.
4. The possibility of conducting multilingual versions of the site (extended multilingual out of the box) - this issue is particularly relevant in our time, when there is a need to convey information from the site in several languages: whether it is the site of a company providing services or goods, or an information agency that broadcasts information in several languages .

To work with the database, the standard feature php - PHP :: PDO was selected with EMULATE_PREPARES disabled for securing sql queries. CKeditor (html) and wysibb (bbcode) are used as standard visual editors of the system. I decided to categorize the system updates at certain stages of development according to the SemVer specification (major.minor.path).

2. System Interfaces

When implementing various models of user and site interaction, it was decided to divide all system interfaces into 4 main types depending on the source of interaction and the purpose of the operations performed. So there were: user interface, system installer interface, administrator interface and application API interface.

User interface

This interface provides implementations for interaction between the user and the site algorithms themselves. All user requests to the site will be processed within the user interface (with the exception of the AJAX interaction - in this case, the api interface will be used).

After standard installation, this interface looks like this:

Admin interface

In turn, this interface provides the possibility of interaction between the site content and the administrator - management functions.
After logging in to the site and going to the administrative panel, this interface looks like this:

Installer Interface and API

The installer interface provides simplified system installation capabilities for your equipment. Also in this interface, the system upgrade capabilities from the old to the newer versions of the system are implemented.
In turn, the API has no template implementation - its task is the implementation of a certain similarity in the REST API. The main purpose of this interface is to process requests and, as far as demand is concerned, the return of the processing result is a good example of AJAX interaction.

3. System extensions

As I noted earlier, all system extensions are represented by 3 main types, but the total number of implementation types is 5, including:

• Components - generation of site content depending on the internal request URI.
• Modules - work with template positions.
• Hooks - the implementation of methods of interaction between system extensions, third-party code and services.
• ApiCallback is an implementation of simple REST APIs for interacting inside and outside the system using the system API.
• Cron - implementation of add-ons to extensions that allow you to perform tasks on a schedule (Cron task).

We can talk about the structure of extensions and their implementations for quite a long time - after all, each type of extension is intended for a particular implementation, depending on the purpose of such an implementation.

Data on extensions in the system are stored in a special table in the database (_extensions), in which are indicated: extension type, implementation directory, configuration, version, compatibility as well as information about the rules for the operation of this extension (only for modules - component routing is conducted in depending on the name of the implementation directory).

Components, modules and hooks can contain 2 sets of implementations:

• front: user interface extension logic
• back: the logic of the extension for the administrator interface (content management, settings, etc.)

* I would like to note - I understand that for a programmer, the concepts of “front” and “back” are often associated with the application execution area (client or server), but in this case these values ​​classify the target interaction interface within the system.

I plan to tell you about extensions in a separate article - from the logic of their work and interaction to the implementation of the finished example.

4. Small presentation

I have prepared a short introductory presentation on the structure of the system and its capabilities. In the presentation, in some places, the material that I have outlined above is a little wider.

5. References and afterword

First of all, I would like to thank the habrahabr team for supporting such an insignificant (in scale) project of one developer and approving participation in the startup assistance program.

Official site of the project: ffcms.ru (I apologize for the quality of the English version of the site).

The project on github: git@github.com: zenn1989 / ffcms.git .

Extension directory : ffcms directory (I will be glad to your participation).

A little about myself and "from myself": My name is Pyatinsky Mikhail, I am a resident of the modest city of Kerch (Crimea). Unfortunately, I do not have higher education related to programming. In our city, units are seriously programming, and web development is even more so (I don’t know any web studios in our city), so most of the development experience (including any command one) I got in a virtual environment (remote development). I understand that my code and its quality are very far from ideal and I do not in any way put it on a level with yii, symphony or other wonderful CMF frameworks, but you can participate in the development and improve the project and the quality of its code. I am always open to dialogue.