In the software development world, living on the bleeding-edge means that at some point, you will bleed.

We are developing a very cool application (you will know more about it soon!) on top of Symfony2. It has been a lot of fun and don’t regret it. You are probably asking yourself why we bother? Why not simply use symfony 1.4? It is after all, the stable and recommended option. Well, for most projects I would agree with that. But this is an internal project which we know we will have to live with it, and grow with it for a very long time. If we had decided to go with 1.4 and upgrading to Symfony2 after we go live, it would have been nearly impossible, and we really want to use all the new features of Symfony2, PHP 5.3 and MongoDB.

Additionally, we wanted to learn to use Symfony2. One of our goals is making sure customers get up and running fast with their symfony apps so we need to be ready on day one when a stable release of Symfony2 becomes available (reports say it will happen next March 2011). This is the perfect project to get us ready.  <evil laugh>Our knowledge on Symfony2 will be unrivaled among hosting providers.</evil laugh>

We have been working with one of the earlier preview releases and decided it was time to upgrade to Preview Release 3. This is an attempt to keep a journal of changes that you may expect to do if you decide to do something similar.

Before starting with detailed changes, what really helped was to create a new application based on the new sandbox PR3 and compare the new configurations and new php files against our existing application. For other more complex things, it was required to go deep into the Symfony2 code and check out the new classes and configuration.

Step 1: Backup

As always, backup your code before upgrading anything, and know that what worked for us might not necessarily work for you. Keep your stuff backed up so you can revert if things don’t work out. I know that this is routine for most of you, but we work in a hosting company and get our fair share of panicked “I made some changes to my (live) site and now nothing works” emails. Backup, backup and backup. We use git for source control, which means we created a new branch for the upgrade and chug away, not fearing massive changes in code since we had the possibility of reverting back. Remember: Github is your friend (SVN too).

Framework standards

One thing that required massive changes is the fact that we initially did not follow the recommended naming convention for bundles. When things stopped working we decided to comply and follow the recommendations. Lesson 1: if you play by the framework rules there will be less chances of major breaks down the road.

We have several 100’s of classes and files, so doing updating is no easy task. Using unix commands for search/replace really helped. Something like this worked well:

find ./ -type f -exec sed -i ’s/string1/string2/’ {} \;

Core changes

There have been several changes in the Symfony2 core. Classes moved from one namespace to another. There is a consolidation of features in bundles, even major features of Symfony2 are included in the FrameworkBundle. This means that some common classes that we were using like Symfony\Bundle\FrameworkBundle\Command\Command and Symfony\Bundle\FrameworkBundle\Console\Application are now in this bundle. This change also meant that the extended kernel class needed to change to reflect all the new namespaces.

Since Symfony2 uses Zend_Logger,we were using it as well for some background/daemon style applications. PR3 introduces \Symfony\Framework\ZendBundle\Logger\Logger. Luckly, we were use our own extended logger so the change was super easy.

Lesson 2: If you use a class a lot, it is not a bad idea to extend the class and create one in your own namespace, that way you would only need to change the original namespace one time in your class declaration.


There were also some significant configuration changes. In PR3 there is the new Profiler which is absolutely awesome. In the new sandbox you can find all the new config options, like:

    toolbar: true
    intercept_redirects: true

Controllers, views and helpers

Helpers are now accessible using the $view[‘router’] syntax, so this required changing helper calls everywhere. Luckly it did not mean a major change, just the way we were calling it.

Doctrine2 MongoDB ODM

We are using MongoDB in this new application. It is amazing how much simpler is to write a complex application like this one using a document oriented DB.

Since we rely on Doctrine2 MongoDB ODM quite heavily, we have been using the trunk from github. This has helped us to get all the shiny features and bug fixes right away without needing to wait for a new release of the Symfony2 sandbox or bundles.

When we upgraded to PR3 we did find a problem. The DoctrineMongoDBBundle is still not very flexible configuration-wise, so before our document classes where inside a Documents namespace/directory. The updated bundle changed so it now looks in Document (singular), this meant changing our classes to the singular namespace. Again, find/sed saved the day. We surely were able to hack the bundle to look in Documents if we wanted to, but we prefer to adhere to the standards. The updated bundle also included the new default_database configuration option, so make sure you change the db name ‘default’ to your needs.

These were some of the major changes we had to do. We found several other small problems thanks to the fact that we use PHPUnit for unit testing of our code. In a matter of minutes we were able to identify issues and fix them.

As you can see, it is not that difficult, but if you decide to go with Symfony2 (or any other solution for that matter) before it becomes stable, you need to keep an open and flexible mind, allow time for those upgrades and as we said, be ready to bleed. If you are working for a client, it’s probably best to stick with the stable releases for now.

Are you on the bleeding edge too? Did you bleed? We want to hear about it.