Release FFCMS 3.0.0 - a new recycled system

Good day inhabitant of habrahabr, today I want to tell you about the new release of ffcms - 3.0.0 and briefly highlight the dramatic changes that the system has undergone since the previous release - 2.0.4 .

The system retained the free distribution model and open source code (MIT), but the source code was completely rewritten under the MVC architecture and the PSR-0 autoload. Many "bikes" were removed from the system, and their place was taken by popular components: symfony http foundation, laravel eloquent, and many others.

Recycling system architecture

Discussing the second version of the system, many habrahabr users advised to significantly rework the system with current trends: add the dependency manager and composer versions, enter the established MVC architecture, and bring the code to a single PSR-1/2 style. The code of the 2nd version really had a rather low quality and it was possible to break a leg about it ( or both ). It was also noted that the development model of the 2nd version of the extensions is very confusing and redundant, and together with the api kernel syntax, this caused mental pain for some users.
')
It was absolutely necessary to introduce modern tools and principles of application development, but it was almost impossible to rewrite the existing code - so it was decided to rework the system architecture from scratch.

The system was divided into several functional parts: the basic structure, core, console. A repository was created for each part, a composer was set up and the project was published on packagist. All parts are linked using dependencies in the base component composer.json.

Giving up bikes

In recent years of application development, I have become familiar with most of the popular frameworks, such as symfony, laravel, yii, and codeigniter. Most of the “interaction ideas” that I tried to independently implement in my CMS, if not strange , have already been implemented in popular frameworks - where they are monstrously complex, where they are too simple and not sufficiently functional. I liked many of them and use them to this day, incorporating them into ffcms.

So, the following own parts of the “bicycle” were replaced by the already well-established popular components:

• Networking: symfony http foundation
• Work with database (DB manager): laravel eloquent
• HTML code security: HTML purifier
• Work with the console: symfony console
• Caching core: php fast cache
• Debugging: debugBar
• Mail Handling (Mailer): swiftmailer
• oAuth 2.0 authorization: hybridauth

For some of the components used, "descendants" were written, extending or simplifying the functionality of the component for the needs of the system. The use of these components made it possible to sufficiently simplify the basic core of the system and reduce the entry threshold for other developers.

Performance and compatibility

And if we do not introduce support for php-5.2 and whether to use polyfill? No no and one more time no. Now, in the wake of php 7.1 release and movement towards deprecated 5.5, there is absolutely no point in supporting outdated php versions. The temptation to use a polyfill is, of course, great, but one can also refuse from it in order not to complicate an already complex system.

FFCMS 3 will work on any php interpreter starting from version 5.5, in the nginx bundle - php-fpm, apache2 - php or any other bundles (provided that the uri rewriting rules are rewritten).

The performance of the system was not significantly affected, although the consumption of resources became somewhat larger than in version 2 (it is not surprising), but still it was not possible to reach the level of bitrix . The page loading is still <0.1sec, the memory consumption is <7mb (for php 5.6 without opcache). The latest performance test can be found on google.docs along with a test box under the virtualbox.

Templates ( or bare php? )

In this dispute, the fighters broke quite a few swords, but there is no consensus on the question. Many people believe that php syntax itself is enough for templating, and some without twig and blade do not see their life. In the 2nd version of the system, twig was used, but I decided to limit myself to the classic php syntax for generating html code in views.


With UI, everything remains as before - jquery & bootstrap is a time-tested bundle.

DB, Queries and ActiveRecords

There are many different ways to interact with a database within PHP. Someone working with a bare PDO, someone with Doctrine and QueryBuilders. FFCMS uses the laravel eloquent library, which allows you to interact with the database using Query builder tools as well as using the ActiveRecords approach.

ActiveRecords are very convenient to work with the database and greatly simplifies and shortens the syntax of queries. Of course, this is not a full-fledged Doctrine ORM, but for CMS it is quite enough.

Migrations

Without migrations and their further "deployment" now is nowhere. No, there are of course people using mysqldump / pg_dump, but we will not follow this path. In ffcms 3 there is a standard implementation of migrations - classes with 3 methods up (), seed () and down (), the ability to create, use and rollback migrations. Standard migrations are stored in / Private / Migrations, but using MigrationsManager, migrations from any directories can be implemented.

Debugging

For convenience, quick debugging and profiling of requests in ffcms built phpdebugbar functionality. This mechanism allows you to debug in a hurry when there is no opportunity or time to connect xdebug / zenddebug. The debugger looks like a panel and is available for inclusion in the admin panel settings.

Testing

Manual testing of product performance is not a trend of modern development. For the purposes of automatic testing of the system code and UI, a system of automatic tests was introduced - codeception, which combines standard unit-testing and acceptance testing of interfaces.

Tests can be run from the root using the codecept run command, after running the selenium with the driver for chrome or another browser. It is also necessary to edit the configuration of the test environment (/ tests/acceptance.suite.yml) under your layer. To set up tests there is a small document with instructions for use (the document was not originally intended for "all eyes", forgive me).

Extensions

In view of the presence of PSR-0 autoload, the extension system has been revised. Now all extensions are divided into 2 types - applications and widgets, the first ones occupy a certain root URI depending on the controller and process actions with the help of actions; the second ones are intended to be displayed in any place of the views by directly referring to the widget class.

In addition, the entire set of "implementations" can be wrapped in one package and with the help of git and composer, observing the autoloader standard can be distributed as a self-sufficient implementation. A prime example is the implementation of a forum or demo package .

Well, my story was long enough, but perhaps it’s impossible to fit everything into one article. I will be glad to answer your questions and listen to your wishes.

→ Official website: ffcms.org (mirror: ffcms.ru )
→ Project on github: phpffcms
→ Administrator and developer documentation: doc.ffcms.ru (in the process of finalizing).