CakePHP 3, here we go again.

As some of you might know, I’m a big fan of CakePHP framework.  I’ve used it on numerous projects since the beginning of times.  I’ve built projects small and large, migrated existing native PHP codebases to CakePHP and even survived a few major CakePHP upgrades – 1.2 to 2.0 comes to mind.

Currently, I am at the start of a couple of projects, which require a bit of the future support.  CakePHP 2.x can handle the job now, but I’m looking more into the next 3-5 years.  And that’s why I’m looking at CakePHP 3, which is still in the early development stage, with an alpha release coming not too long from now (have a look at the CakePHP 3 roadmap document).  Let’s have a look at the high level goals for CakePHP 3:

CakePHP 3.0 represents a significant break in backwards compatibility. One of the largest the project has ever had. We are trying to modify existing methods and classes only where it is required. However, modernizing the ORM has caused a significant ripple effect in other parts of the framework. When making changes we are working towards a few goals:

• Adopt broader PHP community standards. Tools like composer, and PSR-0, PSR-1 have proven to be useful tools for improving interoperability. CakePHP should embrace these community standards where possible.
• Increase modularity. CakePHP has had history of being tightly coupled. We’re trying to reduce coupling and make more standalone libraries. For example the new Collections library, and Events system have no dependencies on the rest of the framework.
• Use PHP 5.4. When we started on CakePHP 3.0, this seemed ambitious. However, with the release of PHP 5.5, and impending release of PHP 5.6, it feels right on target now.
• Modernize and simplify the framework. CakePHP has accumulated numerous features over the years. By removing some features that are better implemented as plugins we make CakePHP simpler and smaller for everyone. Separating features into plugins allows greater community involvement and more rapid iteration on features.

That sounds like a lot.  In times like these, migration guides are useful.  With no code to migrate, such documents help migrate the knowledge. They usually answer the questions of what changed, what new stuff was added, what was removed, and where, in general, this whole thing is heading.  Reading through the migration guide, here’s what I picked up for myself:

• CakePHP 3 supports Composer.  This is a very welcome change!
• All of the source code has been reorganized to support PSR-4 autoloading specification.  Yes, that means changes namespaces, lots and lots of backslashes, and moving files around.
• ORM has been completely rewritten.  I didn’t have much trouble with the old ORM, but I guess there are better ways of doing things.  Now, the Model is gone and it has been replaced with Table objects and Entities.  These are somewhat logical.  Table objects provide access to collections of records, while Entities provide access to individual records.  More or less.  It’s more flexible than that.
• Immutable configurations for logs and caching.  Again, logical.  Instead of changing things on the fly, unload one configuration and load another one.
• Named parameters in routing are gone now.  Apparently, it was a very complicated piece of code which caused a lot of headaches.  I somewhat enjoyed them in a few projects though, but can live without.  Not a biggy.  Furthermore, all of the routing has been reworked and will be much faster, using scoped routes, which I need to learn more about myself.
• Asset.filter is gone now.  This should be handled via a plugin.  Have a look at Mark Story’s Asset Compress, for example.
• Scaffolding is removed also.  That’s a pity, actually, as I used it for quick prototyping a lot.  There is a possibility of a standalone plugin to provide this functionality. There will be a much more powerful Crud plugin instead.
• A few changes around encryption things.  It looks like anyone brave enough to migrate an application from CakePHP 2 to CakePHP 3 will also have to decrypt/encrypt some data as well.  Gladly, this is not my case currently.
• FormHelper and HtmlHelper are now much flexible with the HTML that they produce.  These are great news indeed, as I’ve been a few times through pulling a CSS framework (like Twitter Bootstrap) over the CakePHP, and while it’s very possible, I had no fun at all.
• I18n is possibly being pushed more towards better support of PHP’s intl extension. (It’s still a maybe, particularly due to intl extension not being installed universally.)
• Tests are pushed more towards PHPUnit compliance.

Overall, that’s a monster of a change and it will take some reading and playing around to get used to the new ways.  The earlier, the better, I guess.