What's new for developers in Concrete5 CMS v5.7

Concrete CMS Inc. is preparing to release version 5.7 of its content management system. This version is almost completely rewritten and architecturally different from the current version 5.6. At the moment, the development of version 5.7 is not finished yet and the version for developers is available, let's talk about it.

Some time ago, Andrew published on his website an article about what “threatens” developers with release of version 5.7. I offer you a free presentation of this material. For those who speak English - direct link .

1. Finally, they refused to support PHP 5.2, this is positive and opens up a bunch of new features.
2. The bad news: 5.7 is not API compatible with 5.6.x. Those. extensions will need significant rework. With simple extensions, everything is simple, there are even 2 lessons in How-To's on the official website about how to take an extension for 5.6 and convert it into an extension for 5.7. But with complex, I suspect, not everything is so simple.
3. Completely reorganized CMS code. No more directories such as models, libraries or helpers. Instead, there is one directory, core, in which the entire kernel resides.
4. We wave our pen with declarative programming, for example, the line we are used to: defined ('C5_EXECUTE') or die ("Access Denied.") ;. Now inside the CMS, all code is organized into the Concrete namespace (namespaces), including modules, attributes, packages, etc.
5. In 5.6, classes from the Zend Framework were actively used (lay in concrete / libraries / 3rdparty / Zend). 5.7 equally actively uses Symfony2 (routing, system of requests and responses, sessions, cookies and events, etc.).
6. Redesigned MVC. In particular, in 5.7, we finally give up on tools (for example, for action games called by ajax). Now we are doing all the actions inside the corresponding controller (this can now be done), and the interface in view.php (by the way, you can use several different mappings depending on the need, we still use it).
7. Removed from the code all sorts of strange hacks (for example: using the on_page_view () method in the module controller to connect custom css and js, now everything can be done in the view () method).
8. We wave the handle to the Loader class, which was responsible for loading the kernel classes and not only. Autoload taxis (PSR-4 autoloading).
9. There is a desire to encourage test driven development, i.e. make it easier to write unit-tests to your code during development (we are writing now, but this is not particularly supported in the current version of C5, such as in Drupal, where the developer cannot add an extension not covered in tests to the extension store).
10. New Assets system, which will be useful for system kernel extensions. Now the kernel extension is done through class overlaps by placing its implementation of the desired kernel class in the appropriate directories of the site's root directory, which allows you to safely update the CMS code without affecting your changes in the kernel.
11. Laravel IoC Container is used - a powerful tool for managing class dependencies. Dependency injection is a way to eliminate hardcoded class relationships. Instead, dependencies are defined at run time, which gives more flexibility due to the fact that they can be easily changed.
    Understanding the Laravel IoC Container is essential for those building large and powerful applications. For us, a very useful thing.
12. We wave the ADODB handle used to access the database in the current version of CMS. In 5.7, Doctrine DBAL and Doctrine ORM are integrated (long overdue). Now there is a BlockType class working through Doctrine ORM, as proof of concept, although in the current version there are still many facts of direct access to the database. In this part, by the way, backward compatibility is preserved. A compatibility layer was written. There is also an AXMLS analyzer for old blocks and packages (for analyzing db.xml and others like them). But to live this gasket, most likely, not for long.
13. There are no more config / site_events.php, config / site_autoload.php and config / site_post.php files. Instead, there is one application / config / app.php, which can contain anything.
14. As it was already possible to notice from point 13, now all overrides (and I suppose addons) live in the application / directory
15. Lots of old javascript code has been updated and revised.
16. The good news is that for some time two branches 5.6.x and 5.7 will be maintained and developed in parallel.

')
In general, something like that. All these changes make Concrete5 an even more convenient tool for developing Internet solutions at any level.

Link to GitHub repository version 5.7: github.com/concrete5/concrete5-5.7.0