FFCMS 3.0.0 Release - New Redesigned System

Published on January 17, 2017

FFCMS 3.0.0 Release - New Redesigned 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 cardinal 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 for the MVC architecture and PSR-0 startup. 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 that the system be substantially redesigned taking into account current trends: add a dependency and composer version manager, introduce an established MVC architecture and bring the code to a single PSR-1/2 style. The code of the 2nd version really was of rather low quality and it was possible to break a leg about it ( or even both ). It was also noted that the development model for extensions of the 2nd version is very confusing and redundant, and along with the kernel api syntax, this caused some pain for some users.

    It was simply necessary to implement modern tools and principles of application development, however, rewriting existing code was almost impossible - therefore, it was decided to redesign the system architecture from scratch.

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

    Abandonment of bicycles


    Over the past years of application development, I have come across 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, oddly enough , were already implemented in popular frameworks - somewhere they are monstrously complex, somewhere they are too simple and not functional enough. I liked many of them and I use them to this day, having implemented them in ffcms.

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

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

    For some of the components used, “descendants” were written, expanding or simplifying the functionality of the component for the needs of the system. Using these components has allowed us to simplify the basic core of the system and lower the threshold for other developers.

    Performance and compatibility


    But should we introduce php-5.2 support and use polyfill? No no and one more time no. Now, in the wake of php 7.1 and the move to deprecated 5.5, there is absolutely no point in supporting outdated php versions. The temptation to use polyfill, of course, is great, but you can also refuse it so as not to complicate an already difficult 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 rules for rewriting uri are rewritten).

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

    Templating ( or bare php? )


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

    A bit of code for sophisticated
    // экшен контроллера:
    public function actionIndex()
    {
        // blablabla
        return $this->view->render('dir/file', [
            'param' => 'my value'
        ]);
    }
    // вьюшка
    <h1>Demo view</h1>
    <p>param value is: <?= $param ?>
    


    Everything remains the same with the UI - jquery & bootstrap is a time-tested bunch.

    DB, Queries, and ActiveRecords


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

    ActiveRecords are very convenient for working with the database and significantly simplifies and reduces the syntax of queries. Of course, this is not a full-fledged Doctrine ORM, but for CMS purposes it is quite enough.

    Migrations


    Without migrations and their further “deployment” nowhere. No, of course there are 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, apply and roll back migrations. Standard migrations are stored in / Private / Migrations, but migrations from any directories can be implemented using the MigrationsManager.

    Debugging


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

    Picture from debugbar


    Testing


    Manual product health testing is not a trend in modern development. For the purpose of automatic testing of 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 selenium with the driver for chrome or another browser. It is also necessary to edit the test environment config (/tests/acceptance.suite.yml) for your layer. To configure the tests, there is a small document with instructions for use (the document was not originally intended for "all eyes", excuse me).

    Motivating gif with tests (5Mb !!!)


    Extensions


    Due to the availability of PSR-0 startup, the extension system has been revised. Now all extensions are divided into 2 types - applications and widgets, the first - occupy a specific root URI depending on the controller and with the help of actions process certain requests; the second ones are intended for displaying representations in any place by directly accessing the widget class.

    In addition, the entire set of "implementations" can be wrapped in one package and, using git and composer, following the autoload standard can be distributed as a self-sufficient implementation. A striking example is the implementation of a forum or a demo package .

    Well, my story dragged on 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
    → Documentation of the administrator and developer: doc.ffcms.ru (in progress).