Looking ahead to concrete5 5.7
There are some big changes ahead for concrete5. Developers take note.
concrete5 version 5.7 was recently released as alpha. There's a lot of new stuff in it, some of which might take a bit of getting used to, especially if you're a developer. It's worth having a look at 5.7 early as it has only recently become apparent it will be significantly more "different" than expected.
Franz has indicated that there's to be no upgrade path from 5.6.3 to 5.7. It seems, that once the possibility of backwards compatibility was dismissed, the core team have taken the opportunity to improve the underlying application in a way they couldn't have previously, whilst required to maintain backwards compatibility.
So, you'll need to "migrate" not "upgrade" if you want to move to 5.7 and, if such a migration involves third party add-ons, it's fair to say this may not be straightforward. Why?
It's my view that many add-ons and themes may not get a 5.7 incarnation: for a number of reasons.
First, there are new technical requirements for package development, which I'll touch on below, and some developers may find this to be a new learning curve. Will it be worth climbing up this curve? In some cases it won't be, not if the add-on in question has achieved relatively low sales volume in it's lifetime. Why bother?
The problem is also exacerbated since Franz has talked in the leaders forum about a strategic repositioning of concrete5 with the release of 5.7. Some fear this could lead to fewer eyeballs on their marketplace items, and I can follow this train of thought. He's also communicated an intention to move in the medium term to a 40:60 split in add-on revenues. Already this has increased from 25:75 to 30:70, so we can expect it to happen.
Without a doubt, these factors combined are going to contribute to developer inertia.
All of that said, there is opportunity here, why not more eyeballs if the repositioning works? Meaning higher revenues despite the less favourable splits? We're guessing. It's all a bit up in the air, so I think the sensible thing to do is get to grips with concrete5 5.7 and see what opportunity we can find. This is what we're doing.
So to the 5.7 application itself. The big stuff for us from a developer perspective is as follows:-
- Full namespacing of PHP classes
- Reorganised directory structures, One "core" directory in place of "models", "libraries" etc, with overrides sitting in an "application" directory
- No more ADODB. 5.7 moves to Doctrine
- No more "loader" static method calls. Autoloading is now included using PSR-4 autoloading
- Config files all assimilated into one app.php file
- Re-architected Events class, based on Symfony2
- New Request and Routing systems, both based on Symfony2
- Third party libraries managed via Composer
There's more than this of course, but these jumped out at us.
Andrew Embler posted a couple of 'how-to' articles on basic block development in the new 5.7. He's also provided a very detailed preview of the forthcoming developer changes on his own blog. These are well worth a read:-
- concrete5 5.7 Preview: Developer Changes, http://andrewembler.com/posts/5-7-preview-developer-changes/
- concrete5 5.7 Add-on Developement, Part 1, http://www.concrete5.org/documentation/how-tos/developers/concrete5-5.7-add-on-development-part-1/
- concrete5 5.7 Add-on Developement, Part 2, http://www.concrete5.org/documentation/how-tos/developers/concrete5-5.7-add-on-development-part-2/
Here's a list of resources you might find useful if you're not familiar with any of the terms used above:-
- PHP Namespaces Explained, http://daylerees.com/php-namespaces-explained
- The Doctrine Project, http://www.doctrine-project.org/
- PHP Class Autoloader (PHP-FIG, PSR-4), http://www.php-fig.org/psr/psr-4/
- Symfony2 - Routing Component, http://symfony.com/components/Routing
- Symfony2 - Event Dispatcher, http://symfony.com/components/EventDispatcher
- Composer, https://getcomposer.org/