Concrete5

(Note: this is a post about the underlying changes to concrete5 that will affect – and hopefully delight – PHP developers. If you're interested in some of the user facing changes coming to concrete5 in version 5.7, check out this blog post)

As many PHP developers probably know, a lot of nice things have been happening in the PHP world over the past couple years. PHP 5.3 (and beyond) have brought some great advances to the language; package managers like Composer have helped normalize the re-use of code; organizations like the PHP Framework Interoperability Group have grown, comprised of members from many different open source projects, in an effort to agree on certain framework standards. It's never been a better time to be a PHP developer.

concrete5 has always prided itself on having smart, well-architected code (if not always the most consistently documented). Unfortunately, we haven't been able to take advantage of these advancements, as we've made the conscious choice to stick with PHP 5.2. However, with the impending release of concrete5 5.7, we made the choice to begin requiring PHP 5.3. For months, all that meant was that new code could take advantage of 5.3 features like late static binding. We had no plans to refactor or rework old code.

However, as 5.7's release date began to slip, and it became clear that that we weren't going to be as easily backward compatible as in the past, it became obvious what we had to do: if we did a release that wasn't backward compatible, it was going to be exceedingly difficult to do another release later that took advantage of these new features, and make [b]that[/b] release also not backward compatible. That wasn't going to work. We had to move it all into 5.7; if you have to pull the bandaid off, do it all at once.

With that in mind, here are some of the substantive changes for developers in 5.7:

• Completely reorganized code. No more arbitrary "models" and "libraries" and "helpers" directory. Instead there is one "core" directory.
• Completely namespaced code throughout concrete5 entirely, including the core directory and blocks, attributes, packages, etc...
• Completely new routing system, based on the Symfony2 Routing Component. This will be used to power all new 5.7 interfaces. concrete5 internal dialogs and panels are now using this new routing and MVC component. Tools files are officially deprecated (although there are still lots of them.) Ultimate Goal? Move all UI and processing into views and controllers, and remove tools.
• Completely new Request system, based on the Symfony2 Request component.
• Completely rearchitected concrete5 MVC system, and the removal of lots of weird no longer necessary hacks (on_page_view() methods in blocks, etc...)
• No more empty classes in the concrete/ directory. No more empty block controllers that extend other classes.
• Removed Loader::model and Loader::helper. Hell, remove the need for Loader entirely. Autoloading is standard based on a concrete5 modified PSR-4 autoloading (from the PHP-FIG Group)
• Completely rearchitected dispatcher, including the cleanup of years of configuration code.
• The beginnings – the barest, barest beginnings – of test driven development surrounding some of the new code (although I don't think it currently passes – and I know the old tests don't.)
• New Assets system, which lets you group assets and require asset groups. Useful for core and add-on developers to ensure that assets are included when they ought to be, and not duplicated.
• Dispatcher extends the Laravel IoC Container, allowing for sensible binding of services (which replace helpers) for lazy loading and overriding.
• Alas – and it does kind of make me sad to say it – there is no more ADODB in concrete5. Anywhere. We have integrated Doctrine DBAL and Doctrine ORM. We have the BlockType class running through Doctrine ORM as a proof of concept, but mostly we're still doing direct database access. I'd love to see what people can do with this. We have kept backward compatibility by writing a compatibility layer for Doctrine that extends their core classes. We also have a custom AXMLS parser for old blocks and packages. That actually didn't take that long to write.
• No more site_events.php, site_autoload.php, site_post.php. Instead, there's one "app.php" in your config directory that can contain anything. Put your class overrides, your theme path overrides, custom event definitions in it.
• The Events class extends the Symfony2 Event Dispatcher library, which is a much more structured and full-featured event framework. Events can be stopped from propagating, and work with custom event objects.
• A new Session class replaces direct access to the $_SESSION array, which should make it much more testable, and make database-backed sessions much easier to get working (in fact, I'd like to see someone do just that.)
• We have moved all overrides into an application/ directory. This looks cleaner and I'm sure smart developers will find a way to do something with this that I haven't anticipated yet.
• Certain static facade classes are available all throughout your sites, like Request, Session, Core (which creates classes) and more – you don't have to instantiate them with calls like Request::getInstance().
• All third party libraries are being fetched and kept in sync with Composer. This means many of them have been updated without even knowing it.
• New Response library for edit requests, based on the Symfony2 Response library. Much easier JSON-based development for core and add-on developers.
• New Cookie library based on the Symfony2 Cookie component.
• Much improved JavaScript throughout the code, including the use of underscore templating and better coding practices. Much old concrete5 JavaScript code has been upgraded and reworked.

There's probably more to it than even that, but my fingers are tired and I think we're definitely into "TL;DR" material.

What's Next?

1. We are going to continue developing 5.7 and 5.6.3, and release 5.7 when it's ready.
2. We would love your help cleaning up all the issues surrounding 5.7. There are still a few dashboard pages that don't work at all, and a fair number that aren't adhering to the new style guide. There are lots of other spots in the core that are also probably broken due to incomplete namespace integration.
3. We will offer a solution for engaging more with the community in getting this help. Whether that is Github Issues or an alternate issue tracker I don't know. It's not going to be concrete5.org's bug tracker yet – it's not quite ready for that. I don't think Github's issues are up to snuff so I'm looking forward to turning them off once we have a place to direct people to.
4. I will post a series of deeper looks into some of this functionality on my personal website, with the idea that these articles will eventually make it into concrete5.org when our new 5.7-centric site is unveiled.
5. I will also post a migration guide for a very simple package from the marketplace. I downloaded a free add-on that had a block and a couple dashboard pages, and figured out what was required to get it working.

Please – give us your thoughts. concrete5 5.7 alpha is available on Github in our new 5.7 repository:

http://github.com/concrete5/concrete5-5.7.0/

It's exciting to have the underlying foundation of concrete5 looking as pretty as the exterior.