Collect the best of two worlds - frameworks and CMS (part 1)
Four years is in IT already unfinished. It took so much, and even a little more time, it took me to bring CleverStyle CMS to version 1.0, to the state when the architecture was fixed, there is enough functionality and integrity of the system as such, all the bugs found are fixed, and the main scripts work without problems.
It turned out to create something in between the framework and, in fact, CMS, just what you need for the developer, and I want to share it with the community.
I am sure that many people lacked just such a decision, this is confirmed by numerous questions on the same Toaster and long comment threads under them.
')
Complexity, redundancy, flexibility, functionality and speed.
I did not find a solution that would have a satisfactory balance of these parameters for me (security, too, but this is obviously implied by itself initially).
CleverStyle CMS is not a CMS in the usual sense, it is CMF, higher than the framework in terms of architecture, but lower and more flexible CMS.
In connection with this positioning, a very convenient solution was obtained primarily for the development of unique functionality, since there are most of the necessary tools, for which you don’t have to go far, don’t need to be customized, but you can immediately use and get the result.
Differences in comparison with the framework:
In comparison with CMS:
I always didn’t like the following files:
This is slightly less than a completely useless file that does not carry any payload, this is a template, and templates should be implied by default, if you do not change the template, you don’t need to create it.
Therefore, CleverStyle CMS doesn’t need such sample things, you only write code when it does something useful.
As an example - you almost never need to manually register the connection of CSS / JS / HTML files on the pages - you can specify which pages you need in simple JSON - the system will do it automatically, but you can not specify - then the files will be connected on all pages of the site ( which sometimes is also quite an option).
Want
There are no infinite configs - there is one small basic setting for accessing the database, storage, cache, the basic time zone, the basic language of the site, and the keys that are used for the password salt and for encryption — the critical parameters that are needed to start the kernel.
Parameters are set at the installation stage, most are generated / determined automatically.
All other possible parameters are configured in the graphical interface and stored in the database.
The settings of the components are also stored in the database, and cleared when the component is deleted, there is an extremely simple internal API for managing the configuration of the component - the parameters are set as object properties.
Routes also work as simple as possible, in general, it looks like this: api | admin / Module_name / level_1 / level_2, while everything except Module_name is optional and is used only when needed.
At each route level there is a responsible file that works out its level, but if processing is needed only at the next level, you can skip the work at the current level.
The levels themselves are described by a one-or two-dimensional array in JSON format:
When you open the admin / Module_name / level_1 / sublevel_1 page, the following files will work if available:
For reasons of simplicity and convenience, third-party components were also selected, for example:
Out of the box, the system understands that there are several databases, they can be different, they have mirrors, can randomly balance requests between mirrors (you can send write requests to the master, and read to the mirrors). Similarly supported by several repositories for statics.
Multilingual interface and content are supported, the kernel (and basic components, below) out of the box uses this wherever applicable.
There are users of the user group, permissions that can be assigned both to groups and to individual users, communication between users is maintained (simple contact system).
There is an interface for sending mail, including attachments and other necessary features.
Ubiquitous caching - in the overwhelming majority of requests, the kernel does not even connect to the database, since everything that makes sense to cache is cached.
JQuery, UIkit, Polymer (+ WebComponents.js) are connected on the frontend, they are configured to work together (this is not always trivial, considering web components).
Web components are used along with regular CSS / JS code, the system understands HTML imports, you can use Paper Elements and any third-party ready-made components with ease.
The dependencies between the components (mandatory and not so) automatically affect the order of inclusion of CSS / JS / HTML files on the page, so that you always have a predictable and correct order of file initialization.
CSS / JS / HTML files are minified, combined, pressed using gzip into separate files, which are still connected taking into account dependencies, the system does everything itself, including setting headers for correct caching of files by the browser and / or CDN.
All created files and records in the database are controlled, thus the performance is controlled and predictable. This gives a comfortable feeling of control over the state of the site.
Also, the correct meta tags are generated in order to explain to the search engines in which languages the address is still accessible to this page (in a multilingual configuration), the Open Graph meta tags are generated.
Components are assembled into distributions via either a graphical interface or from the command line, installed / updated from the admin in the graphical interface (the kernel can also be installed from the command line).
In fact, yes, for example and for convenience, several components have been created that either carry useful functionality by themselves or, more importantly, are easily integrated into other components.
Right now ready:
In addition to the standard design theme, which is mainly used only for the admin panel, there are two more, also third-party porting is easier than ever, because the design theme is a simple HTML file containing content and some other data (there are two examples of porting to GitHub with step-by-step commits from the original of the template, to the state when it is the CleverStyle CMS design theme).
The core of CleverStyle CMS is only 2 MiB and consists of about 280 files (this already includes all third-party libraries), has everything you need to develop the vast majority of various sites ranging from business cards to scalable into several servers.
All tools are ready to use right after installation (consisting of one step), and do not need to be configured, but can be reconfigured if necessary.
The architecture was designed from scratch, changed somewhat over time, taking into account the experience of practical use in production, and settled down in the form in which it is now.
The kernel uses both ready-made third-party libraries and specially written ones, some were written specifically for CleverStyle CMS and then separated into independent projects.
The code is available on GitHub under the MIT license: https://github.com/nazar-pc/CleverStyle-CMS
Despite the fact that the system should be considered rather as a monolith - many parts can either be torn off immediately or with little effort and used separately - for example, minifying and combining CSS / HTML files, implementing a pseudo-file system in the cache (essentially supporting tags) for APC and Memcached, and whatnot, code under the MIT license, can be used.
There is a wiki with a description of the device and the interaction of various parts of the system: https://github.com/nazar-pc/CleverStyle-CMS/wiki
There are several sites on the base of the engine, there are mobile applications, so the functionality is live and working, it is used in combat conditions.
A demo with a publicly accessible site is poorly supported - someone will change the password, set something up, and it's not difficult to break it with full admin access if desired.
Due to the fact that the latest versions support the build and installation in the command line mode, it became possible to prepare an image for Docker with the automatically updated and always the latest git version of the system.
Runs like this:
After that, you can open
--rm will delete the container after stopping (you can stop it using Ctrl + C).
It turned out to create something in between the framework and, in fact, CMS, just what you need for the developer, and I want to share it with the community.
I am sure that many people lacked just such a decision, this is confirmed by numerous questions on the same Toaster and long comment threads under them.
')
It is necessary to explain why
Complexity, redundancy, flexibility, functionality and speed.
I did not find a solution that would have a satisfactory balance of these parameters for me (security, too, but this is obviously implied by itself initially).
CleverStyle CMS is not a CMS in the usual sense, it is CMF, higher than the framework in terms of architecture, but lower and more flexible CMS.
In connection with this positioning, a very convenient solution was obtained primarily for the development of unique functionality, since there are most of the necessary tools, for which you don’t have to go far, don’t need to be customized, but you can immediately use and get the result.
Differences in comparison with the framework:
Hidden text
There is a great article on a topic that sheds some light on my attitude to them. Why I hate frameworks
- substantially less abstraction layers
- as a result, the structure is simpler and more transparent
- as a result, higher performance and less memory consumption (the core runs for 2-4 ms and eats about 1 MiB of memory in peak, the rest depends on the developer of the final functionality)
- does not involve assembling from a variety of components - everything is already assembled and adequately configured
- there is no centralized config of routes, each component keeps everything in itself
- simplicity - thanks to a lower level of abstract code, the entry threshold is significantly lower
- all parts of the kernel are fitted, patched if necessary, and are guaranteed to work together, this is not just a set of arbitrary libraries, but a single functional unit
In comparison with CMS:
- no specific functionality out of the box, only the kernel and nothing else
- as a result only necessary functionality is added.
- as a result, higher performance and less memory consumption
- so much more flexibility - everything is customizable and hacking
- there is practically no kind of site that cannot be made due to architectural constraints
- support for things more characteristic of frameworks, for example composer is picked up, there is a Restful API
Complexity, redundancy
I always didn’t like the following files:
<?php namespace Acme\DemoBundle; use Symfony\Component\HttpKernel\Bundle\Bundle; class AcmeDemoBundle extends Bundle { } This is slightly less than a completely useless file that does not carry any payload, this is a template, and templates should be implied by default, if you do not change the template, you don’t need to create it.
Therefore, CleverStyle CMS doesn’t need such sample things, you only write code when it does something useful.
As an example - you almost never need to manually register the connection of CSS / JS / HTML files on the pages - you can specify which pages you need in simple JSON - the system will do it automatically, but you can not specify - then the files will be connected on all pages of the site ( which sometimes is also quite an option).
Want
Hello, world! - directly and write to index.html, put the file in the module folder, turn on the module in the admin area, it is ready to go. No need for heaps of nested folders, template controllers, and so on - just a file with content.There are no infinite configs - there is one small basic setting for accessing the database, storage, cache, the basic time zone, the basic language of the site, and the keys that are used for the password salt and for encryption — the critical parameters that are needed to start the kernel.
Parameters are set at the installation stage, most are generated / determined automatically.
All other possible parameters are configured in the graphical interface and stored in the database.
The settings of the components are also stored in the database, and cleared when the component is deleted, there is an extremely simple internal API for managing the configuration of the component - the parameters are set as object properties.
Routes also work as simple as possible, in general, it looks like this: api | admin / Module_name / level_1 / level_2, while everything except Module_name is optional and is used only when needed.
At each route level there is a responsible file that works out its level, but if processing is needed only at the next level, you can skip the work at the current level.
The levels themselves are described by a one-or two-dimensional array in JSON format:
{ "level_1" : [ "sublevel_1", "sublevel_2" ] } When you open the admin / Module_name / level_1 / sublevel_1 page, the following files will work if available:
- admin / index.php
- admin / level_1.php
- admin / level_1 / sublevel_1.php
For reasons of simplicity and convenience, third-party components were also selected, for example:
- PHPMailer is the only file that has everything to send mail, one more file is needed for SMTP support
- PHPT tests - run from a single file, writing and reading tests is simple (knowingly they are used in the development of PHP itself, and, for example, in a modified form in HHVM), unlike the PHPUnit monster
Functionality, speed
Out of the box, the system understands that there are several databases, they can be different, they have mirrors, can randomly balance requests between mirrors (you can send write requests to the master, and read to the mirrors). Similarly supported by several repositories for statics.
Multilingual interface and content are supported, the kernel (and basic components, below) out of the box uses this wherever applicable.
There are users of the user group, permissions that can be assigned both to groups and to individual users, communication between users is maintained (simple contact system).
There is an interface for sending mail, including attachments and other necessary features.
Ubiquitous caching - in the overwhelming majority of requests, the kernel does not even connect to the database, since everything that makes sense to cache is cached.
JQuery, UIkit, Polymer (+ WebComponents.js) are connected on the frontend, they are configured to work together (this is not always trivial, considering web components).
Web components are used along with regular CSS / JS code, the system understands HTML imports, you can use Paper Elements and any third-party ready-made components with ease.
The dependencies between the components (mandatory and not so) automatically affect the order of inclusion of CSS / JS / HTML files on the page, so that you always have a predictable and correct order of file initialization.
CSS / JS / HTML files are minified, combined, pressed using gzip into separate files, which are still connected taking into account dependencies, the system does everything itself, including setting headers for correct caching of files by the browser and / or CDN.
All created files and records in the database are controlled, thus the performance is controlled and predictable. This gives a comfortable feeling of control over the state of the site.
Also, the correct meta tags are generated in order to explain to the search engines in which languages the address is still accessible to this page (in a multilingual configuration), the Open Graph meta tags are generated.
Components are assembled into distributions via either a graphical interface or from the command line, installed / updated from the admin in the graphical interface (the kernel can also be installed from the command line).
In fact, there is not only the core
In fact, yes, for example and for convenience, several components have been created that either carry useful functionality by themselves or, more importantly, are easily integrated into other components.
Right now ready:
- Blogs - a blog (single and multiplayer), the organization is partially drawn from habrabra
- Comments - Comments, integrates into other components.
- Disqus is similar to Comments, but using the same-name service, it is integrated in the same way as Comments, you can choose either one or the other.
- Cron - a simple crontab manager (wrap over console commands)
- Deferred tasks - allows you to delay the execution of the task, speeding up the server response, performing the task in the background
- Feedback - simple feedback
- Photo gallery - photo gallery
- fotorama.js - jQuery photo slideshow plugin for photos and more, integrates with other components
- Plupload - HTML5 file uploader, integrates into other components, works with both a click and dragging files onto an object (Drag & Drop)
- TinyMCE is a visual HTML editor that integrates into other components.
- OAuth2 - OAuth2 server, for example, allows you to connect mobile applications to the site
- HybridAuth - access to the site through a wide variety of social networks and other services
- Content - the creation of simple content elements with the ability to edit in place, integrates with other components, can be used by itself
- Static pages - the ability to create simple static pages
In addition to the standard design theme, which is mainly used only for the admin panel, there are two more, also third-party porting is easier than ever, because the design theme is a simple HTML file containing content and some other data (there are two examples of porting to GitHub with step-by-step commits from the original of the template, to the state when it is the CleverStyle CMS design theme).
miscellanea
The core of CleverStyle CMS is only 2 MiB and consists of about 280 files (this already includes all third-party libraries), has everything you need to develop the vast majority of various sites ranging from business cards to scalable into several servers.
All tools are ready to use right after installation (consisting of one step), and do not need to be configured, but can be reconfigured if necessary.
The architecture was designed from scratch, changed somewhat over time, taking into account the experience of practical use in production, and settled down in the form in which it is now.
The kernel uses both ready-made third-party libraries and specially written ones, some were written specifically for CleverStyle CMS and then separated into independent projects.
The code is available on GitHub under the MIT license: https://github.com/nazar-pc/CleverStyle-CMS
Despite the fact that the system should be considered rather as a monolith - many parts can either be torn off immediately or with little effort and used separately - for example, minifying and combining CSS / HTML files, implementing a pseudo-file system in the cache (essentially supporting tags) for APC and Memcached, and whatnot, code under the MIT license, can be used.
There is a wiki with a description of the device and the interaction of various parts of the system: https://github.com/nazar-pc/CleverStyle-CMS/wiki
There are several sites on the base of the engine, there are mobile applications, so the functionality is live and working, it is used in combat conditions.
How to try
A demo with a publicly accessible site is poorly supported - someone will change the password, set something up, and it's not difficult to break it with full admin access if desired.
Due to the fact that the latest versions support the build and installation in the command line mode, it became possible to prepare an image for Docker with the automatically updated and always the latest git version of the system.
Runs like this:
docker run --rm -p 8888:8888 nazarpc/cleverstyle-cms After that, you can open
localhost:8888 localhost:8888 and watch (login admin, password 1111), all components are initially disabled, but are available in the admin panel.--rm will delete the container after stopping (you can stop it using Ctrl + C).
Source: https://habr.com/ru/post/244311/
All Articles