Mark Story goes over a few reasons of why CakePHP 3.0 breaks compatibility in this blog post.   If you are working with CakePHP or involved in any large system that lives forever, you should read those in detail.  Otherwise, here is an overview:

  • PHP has changed
  • Ideas that didn’t work out so well
  • Outdated implementations
  • Improve consistency

Also, if you are working with CakePHP, you should attend the CakeFest 2014 event next week in Madrid, Spain.

CakeFest 2014 at Madrid, Spain during August 21-24

I am seriously considering going to CakeFest this year.  Madrid is not too far away to fly to.  The event takes place over the weekend, so work stuff can be easily arranged.  And it doesn’t cost too much – a 2-day conference with the 4-star hotel is only $480 USD (early bird prices until July 15th).  That alone is a good deal.

But looking at the schedule, it’s even more tempting.  The upcoming CakePHP v3 coverage, advances queries, testing, debugging, profiling and optimization, using CakePHP with Composer, Twitter Bootstrap, Travis CI, Selenium, AngularJS and more – these are just some of the subjects that will be covered.  And the speakers are on par  including core developers, community leaders, and otherwise interesting people.

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.

Semaphore Bull Memorial

I joined Easy Forex back in 2012 to work on a rather complex project – migrate main website of the company from a really outdated version of DotNetNuke to WordPress.  WordPress, even though it is an absolutely amazing platform, turned out not to be the right tool for the job.  But we’ve managed to deliver anyway.  One of the annoying practices that we had to employ though was a semaphore flag for the database changes – only a single developer could work on the database at any given time.  (Again, this wasn’t a WordPress limitation, but rather specifics of our environment at the time).  That was the time when we introduced the Semaphore Bull to our development process.

Semaphore Bull

 

It worked out quite well.  But being a soft toy, it got abused a lot along the way.  It lost a leg, which was screwed in for a while.  Then it nearly lost the whole butt.  Then the head.  Beaten, barely alive, it still stood its ground and did the job!  At some point it got so bad, that we’ve had to place it into the plastic container, where it survived for a few more month.

Today we’ve finalized our migration of the main website from WordPress to CakePHP.  The system is so simple now that we don’t even need a database  anymore.   And with that, the job of the Semaphore Bull ends.   Gone, but not forgotten though!

Because of its huge contribution to our work, because it saved us from countless painful hours of resolving SQL conflicts, we’ve decided to create a memorial.  Ironically, the memorial to Semaphore Bull is built out Semaphore Bull itself, and the container it lived in.  For the future generations to remember the deed, we’ve printed out the snippet of the developer’s manual and embedded it into the memorial together with the dates.   Here’s how it looks altogether now.

Semaphore Bull memorial

Thank you, Semaphore Bull.  You’ve done us a great service.  Rest in peace.

Searching CakePHP pages

CakePHP framework comes with the default PagesController which is an awesome out of the box way to build a website of mostly static pages.  There is one rather annoying limitation though – no search option.  If you need a website of mostly static pages with search functionality, you are out of luck.  I spent a good chunk of time Googling (searching, eh?) for a solution and even talking to people in #cakephp IRC channel.  The best alternatives, it turned out are listed in this StackOverflow answer:

There is no built in way to search static pages as they are just files on disk.

You have three options

  • Build a model to hold the data somewhat like a CMS so you can use mysql search.
  • google search for sites
  • the more hacky approach of reading the contents of all the pages and using preg_match() or similar on the contents to find matches.

The first option is probably the best depending on your use case. The second option is the easiest if its public facing content. The third option is a horrible idea

Since I need the solution for a public facing website, it looks like I’m gonna go with Google Custom Search Engine option.

CakePHP 2.1.4, 2.2, and a pick into 3.0

There’s been a stream of good news from the CakePHP headquarters recently.  If you are as slow as me on catching up with these things, here is a quick summary.

  • CakePHP 2.1.4 has been release, and that’ll be the last release for the 2.1 branch.  It’s time to move on.
  • CakePHP 2.2 stable has been released, and that’s what you should be using for your projects.
  • CakePHP 3.0 has been mentioned, so if you are interested in contributing early, here is your chance.

CakePHP 3.0 will take a few month to develop.  Mainly, the work is focused around the following:

  • Drop support for PHP 5.2.
  • Add and improve support of PHP 5.4+.
  • Reorganized CakePHP classes to use namespaces to avoid collisions with other libraries and classes.
  • Improve bootstrapping for better control by developers.
  • Rewrite the model layer to support more drivers, object mapping, richer API, etc.
  • Rewrite the routing to work faster and be more flexible.

Overall, it looks like some really healthy activity in CakePHP project.

CakePHP 2.0 released!

I’ve been a bit all over the place these last few days, but I knew that this was coming shortly – CakePHP team released the new and much improved version 2.0 a couple of days ago. There are a lot of changes. And I do mean a lot. Here are some of my favorite:

  • PHP5 support. CakePHP was working with PHP before, of course. But in this release, support for PHP4 was dropped and all code has been updated to utilize PHP5 goodies.
  • Lazy class loading. Previous versions of CakePHP could easily get slow with a lot of models. There were solutions like Containable behavior and others. But it was annoying never the less. CakePHP 2.0 is much improved in this regard. It only loads things that are actually needed and used. That is a huge performance improvement.
  • Improved Console. The new Console is so much better that I’m even considering using CakePHP 2.0 for some of my non-web-based projects. It’s that good!
  • PHPUnit. Previous versions of CakePHP were using SimpleTest framework for unit tests. CakePHP 2.0 switched to the de facto standard PHPUnit. Tests are now easier to write. And integrating CakePHP projects with other Quality Assurance tools should be a breeze.

There are, of course, more changes. These are just the top few that I am particularly glad about.

Also, CakePHP 2.0 release is special to me. It’s been a long while since I participated in the development process of an Open Source project. I usually just report bugs and provide help via forums and blog posts. I did more than that with CakePHP 2.0. I actually wrote a couple of patches that were accepted and merged into this release. They were no rocket science, but a contribution nonetheless.

If you haven’t tried CakePHP before, now is the perfect time to do so. If you have tried older CakePHP versions, you’ll find this one to be much of an improvement. If you have tried it already, please share your thoughts in the comments. Let me know what you think of it.

Pagoda Box – scalable platform for your PHP application

I got my hands on a private beta of Pagoda Box.  It is a platform that you can deploy your PHP applications to.   I gave it a brief look around and I have to say it’s pretty sweet.

Right after you register and get access to your dashboard, you can add applications.  Applications are cloned from GitHub repositories.  Both public and private repositories are supported.  Once you add an application, you can access it at http://your-app-name.pagodabox.com. If you’d rather have your own domain – you can assign it to your application from the dashboard and all that will remain to be done is adding an A-record in your DNS zone.  Super easy!

There is more to it, even at this beta stage.  Pagoda Box supports a number of PHP frameworks, including all major ones – CakePHP, CodeIgniter, Lithium, Symfony, Zend, and more.  You can also optionally have a MySQL database for your application.  They even help you out with outgoing email.

On top of that, you have control as to how many instances of the application you want (the more you have, the more requests you can serve at the same time, and the more you’ll have to pay).  There are statistics of your application performance, requests, and a few other parameters (I’m sure those will grow together with the project).

I’ll admit, I am too used to hosting my projects on my own servers to take immediate advantage of Pagoda Box.  But I am now seriously considering which projects I can move out of my server and into this platform.  It just makes things so much easier.  Deploying and re-deploying works wonders for any GitHub commit of your project.  Initial resources that one usually needs to try an idea out are free of charge.  If the idea picks up, the prices are more than reasonable (and comparable to other hosting solutions).

Out of those things that I consider necessary, I haven’t see any mentioning of files (uploaded via application, for example), support for build systems (such as Phing), and some sort of common library of frequently used code (PEAR modules, for example).  But I’m sure that either I simply didn’t look for these hard enough, or they will be added in the future.

If you are a PHP developer or involved with PHP source on GitHub in any other way, I suggest you try it out.  You can request a private beta invite directly from Pagoda Box website.  Or, if you prefer, I can send you one (I have about 10 of them left for now).  Also watch the demonstration screencasts,  and read through other platform features.

CakePHP GraphViz Models

I have completely and totally rewritten my old script that generates a graph of CakePHP models and their relationships.  Instead of pasting the code in here, I pushed all of its development to GitHub where it now enjoys a new repository.  Please have a look, try it out, and let me know if it does or doesn’t work for you.

The major changes in this version are:

  • Rewritten as CakePHP Shell instead of being a standalone madness script.
  • Got rid of all dot markup. Utilized Image_GraphViz PEAR package instead.
  • Added support for old and new CakePHP versions (1.2, 1.3, and 2.0).
  • Added option for using only real models (via className property of the relationship) or sticking with the old behavior.
  • Added a bunch of options for tweaking GraphViz output.  And now it’s obvious where to edit them, in case you need more.
  • Improved the styling of the graph a bit – fonts and colors.
  • Improved documentation.

As a side effect improvement, now that it is a native CakePHP Shell, it’s trivial to add to your project build process.