Since a few months all the PHP developer’s community is quite in turmoil about everything that’s going on. PHP 5.3 is becoming very standard, Zend is in heavy development for his new version and Symfony2 is on the point to release his final version.

What’s happening?

Before going further, I must make a quick overview of what’s happening in the world of PHP developers.
The news coming frameworks are reaching a new step in professionalization of PHP developments. And this one is very huge! The provision of modern design patterns such as SOC (separation of concerns), DI (Dependency Injection) or Annotations (even if it not really a design pattern) pulled the Frameworks to new high quality standards. Note that Java and Microsoft worlds joined this state years ago, PHP is just catching up.

And this catching up is really fast! Essentially thanks to GitHub which allows the lead development team to be easily helped by thousands of voluntary developers all around the world. Really, GitHub community amazes me every day.

Consequently, new generation PHP Frameworks relegate past frameworks to an old way of developing. “Yea my Framework does MVC! So don’t I have some kind of a modern architecture?” Of course not! I am quite bored of this excuse which leads to poor development quality. Take for example the Symfony1.4 Framework. It uses obviously MVC, but outside of the views and controllers all the rest stays messy.

What I realized last months is that PHP development became a language where you can really develop an expertise based on framework but also on architecture and best practices. And it feels right. You cannot tell anymore that you master PHP just because you understand the language and a Framework.

Fact: PHP is becoming a very professional and valuable technology, just next to Java and .NET.

PHP and some"modern" Frameworks
PHP and some"modern" Frameworks

Learn a new Framework

What I did in the beginning of 2011 is the migration a full featured website from symfony1.4 to Symfony2.

First of all, I must say that symfony1.4 is a tremendous Framework. It is reliable and well-conceived. I learned a lot using it. If you like it and are using it on current projects, you should definitely keep it.
But when I saw Symfony2 at the end of 2010, I couldn’t help myself but to be thrilled about it. Symfony1.4 is nice, but Symfony2 is so much better!

You have several advantages to learn and use Symfony2. You will learn and use new philosophies and best practices that are very valuable. Functionalities and performances are better. Team development is enforced with a much decoupled framework. And you can easily leverage the GitHub community which tests and improve the Framework every day or provided Bundles for every need.

You should learn Symfony2, but the road is not easy.

Symfony1.4 to Symfony2

Yes, the architecture is completely different. And despite the fact that the name stays the same, you will have to recode everything again. This is why we advise to keep current symfony1.4 project the way they are.

Of course, you will get some kind of a step by step tutorial to migrate the code. But at the end you will recode everything.

The general architecture

The main difference is that this time you won’t code into the framework (remember the model directory for example). You will have to create a Bundle.
A Bundle is some kind of a library that has the ability to be plugged into Symfony2. Bundles are very independent one from another and are at the core of your application. Note that Symfony2 is itself built on Bundles. Also, old plugins are now Bundles.

A Bundle could be your model, your frontend, a web service, a template engine, an ORM, a search engine, an integration of TinyMCE… so Bundle is a very large notion in the Symfony2 framework. The main interest it that they can be very easily plugged, updated and configured.

It took me several months to fully understand what the implications of using Bundles are. But once you’ll get it, you won’t want to leave it.
Also Symfony2 relies on the concept of dependency injection. It is very important to understand why it is build this way, what the container is and what it implies. When you’ll know how it works, the Framework will become very easier to understand.


Doctrine2 works differently.

The first thing you’ll notice is that Doctrine does not rely on code generation. Now you will have to code your objects yourself. Hopefully the command can help you to build your first objects, but you should rapidly code your files directly.

Consequently, your objects are not using any base class. They are lighter but they don’t have any access to the ORM, and should not contain the saving logic anymore.
You might also use annotation, which are very powerful and have the merit to explicitly set relationships.
What I like with Doctrine2 is that your model is now very light and explicit. You won’t have the WTF effect any more when a relation or column is not loaded/stored correctly because of a wrong “schema.yml” file.

The Controllers

Controllers may contain the same kind of logic; the way they work is different. Now you have to consume services. And so you will learn the notion of services and begin to use one of the core items of the Symfony2 architecture: the container. No more static classes, you will rely on real instances that are parameterized via all the dependency injection and services logic.

Really, services, dependency injection and the container are very nice things. They allow your code to be more decoupled and more robust.

The views

Twig is one of the most powerful stuffs in Symfony2. You may don’t want to use it, but I strongly encourage you to do so.

The syntax is less verbose, and you can have a lot of nice functionalities. Auto escaping, easy access to variables, template inheritance, easy test structures (which can be boring in php, such as testing the existence of a value, or test even/odd occurrences in a loop), filters (truncate, text replacement, capitalization)… and so on.

Twig is a language dedicated to designers, so that you won’t have to teach them PHP.

Also Twig will impose you to have only view logic in your view. And that is great! You designer can concentrate on creating a nice interface without messing with your business logic.

The routing

Really, the routing looks like to be the least changed component. It became a little simpler than before, can be used with annotations and has some nice new functionalities such as the param converter.


Forms completely changed. It is a brand new form Framework which works like a mix of MVVM and Converter design patterns (very common in .NET). You will have to go through all your forms in terms of composition, validation, and process.

As far as I can see, the new Form framework is not so easy to master. It is also one of the last stable components in Symfony2. As long as I can see, when it comes to functionalities, there is no major improvement.

But when you get how to use them, they become very powerful and fast to use. Especially thanks to the validation that can use annotations, and the very clean process of form construction.


The security component is certainly the hardest to master. The first time I had to use it, it was very painful. You will have to understand many new concepts, such as the provider, the firewalls, the encoders…
But you will have a very powerful tool to really control every aspect of your web application security and authorization mechanisms.


The translation of your views is very clean and perfectly integrated in the twig syntax. The forms won’t get you any trouble.

But there is no out of the box process for the translation of your doctrine object. You will have to install the doctrine extensions, which are kind of official and not very hard plug, in order to support this feature.

On the bright side you can now have your translations in xliff files, but also php, yaml, and more.

Extending the framework

This last point is certainly one of the most important. Because complete parts of the framework are Bundles, it is very easy to build new bundle and makes them do whatever you want! Also it allows you to override very easily the way the framework behaves.

Because Bundles are kind of standalone, you can share them and plug them very easily. You can already find very popular bundles with very powerful stuffs in it. I am thinking about the KnpUserBundle, the SonataAdminBundle, the StofExtensionBundle or the ImagineBundle.

What will happen?

The first thing you might want to do is to download the Symfony2 package, configure your web server, and see what comes out. But it is not so easy. You first have to choose a distribution, get the “vendors”, maybe by using git…

Just after that you will go through the doc, and see that you have so many things to read, with some kind of an arbitrary order. Also they are a lot of cookbooks that contains so many features to discover. You will just want to know everything in order to make the right decisions. But you will still want to code.

You will be overwhelmed by the Framework and feel kind of lost. Almost I did.

You will “loose” time reading doc, learning new ways of doing stuffs that were working perfectly on your last framework. You will be stuck again common issues, and some other tricky functionalities will work very smoothly. At last you will learn to watch Github regularly to follow the development of some bundles, read the doc hosted there, and so on. You might not want to do that at the beginning (it is not what you came for)… but you will do.

The truth is that your first Bundle (application) will be crappy. Sure it will work, but you’ll be frustrated to miss some new features along the way. So you might refactor several times before getting all the potential of Symfony2.

During my migration I did not just recode everything. I had to refactor my forms two times, my security and the import of the assets one time. My controllers were permanently recoded to follow these changes. And so on.

The same thing happened to me when I discovered Symfony1.4. But, as always, you will feel some kind of betrayed by the Framework. You will have to overcome many frustrations and disappointments. And it might last for some months, but you had the strength to learn symfony1.4 so the learning of Symfony2 will be incredibly fast!

After all you will be a kid again, playing with big toys. You will surely miss your old ones, miss some functionality. But when you will know how to use them, they will become very pleasant tools.

The change curve
The change curve

What you’ll miss

Symfony2 is not so extraordinarily good. It is still very young, and it is thus missing some functionalities that symfony1.4 has.

You can forget about the admin generator for the moment. Symfony2 should get one, but not now. You can still compensate by using the SonataAdminBundle or the WhiteOctoberAdminBundle.

The Framework is too much flexible at first. You can do almost any file architecture. You can use xml, yaml, php or annotation as configuration. It seems nice, but sometimes it is kind of confusing to have a permissive Framework, especially after using symfony1.4.

No Jobeet. No Jobeet. No Jobeet. Sadly it is not coming soon. I have seen some projects to migrate the Jobeet project to Symfony2, but it is not very conclusive yet.

The magic. You will have to code your assessors yourself (or use a helper command), you will have to explicitly route your controllers and templates…

What you’ll like

The performance! Nothing more to say.

The new debug toolbar which is more powerful.

The documentation. It has no Jobeet, but it becomes more complete every day and you won’t have a specific documentation for the 1.0 to 1.4/Doctrine/Propel versions of the Framework. It wasn’t the case a month ago, but now the Symlfony2 documentation is more complete that the Symfony1.4 one. Thanks to the documentation team and the Github contributors that do a tremendous work.

Everything is explicit. “No more magic” can look like a nice easy thing to say, but is a very apparent and useful. Now the templates are called because you wrote it, your assessors are explicitly written, logic is not hidden into base classes that belong or are generated by the Framework, your configuration is loaded because you referenced it… No more “finger crossed” effect.

The community. The Symfony community has never been so active. You have lot developers ready to help you whatever your problem is. Moreover your will find a lot of nice Bundles on Github provided by the community.

You will learn a lot! You will use valuable practices and standards. You will build powerful, robust and nice web applications. And finally you will become a better developer than ever.

Some extras

Of course Symfony2 comes with some killers features. Let’s talk about some of these.

The management of assets is incredibly neat. The pre-packaged AsseticBundle can handle in a very elegant way all your assets. They can be images, css or js. But it can also compile on the fly coffee script, sass, lesscss or more, minifies tem, combine them and cache them!

You can do more by using the ImagineBundle that will handle your images. It will generate thumbnails, apply filters or watermark on the fly depending on what you ask in your templates. And it is cached.

Yes, my designer is very happy!

The cache has never been so powerful. Symfony2 uses the http headers (what a weird nice idea) coupled with a reversed proxy to reduce drastically what your application need to compute. Also it integrates in an almost transparent way the handling of ESI cache (if you don’t know it, you should at least look at this:

Functional and unit tests are completely integrated into phpunit so that you can leverage a true PHP unit test framework.

Because everything is decoupled in bundles and only accessed via the container, your classes are loaded just when you use them. And it results in a very lightweight Framework compared to what symfony1.4 was.

The management of updates. It was not so easy at the beginning, but the core development team came with a script that can update your entire framework and dependency bundle just by reading a “deps.ini” file. Because your code is in a completely isolated Bundle you won’t have to do more than update the “deps.ini” file and run a simple command (which wasn’t really the case with symfony1.4 where your code were placed everywhere in the Framework).

What did I get?

I already told some of the reason why you should learn Symfony2. But there is more to say.

Again, Symfony2 will teach you many new nice things. You will learn. You will be a better developer than ever. And you will be more valuable.

Also your application will become much more powerful, fast and reliable. And that not nothing! I never felt so confident about my development and my websites.

At last you might enjoy it! Many new features of Symfony2 allow you to do so powerful stuffs without all the boring code. I am thinking about ESI, Assets management, Twig, Annotations, Bundles…

At the beginning you will hate learning Symfony2, but at last you won’t regret it.


6 thoughts on “A symfony1.4 to Symfony2 migration: Why you should learn Symfony2

  1. Very stimulating article. I am learning Symfony2 also and it boosts me to read stuff like that. I also feel like, by learning Symfony2, I learn the right way to do thing, the right way to build stuff.

    This principles that are deeply included and used in Symfony2 (as you said, SOC, DI, Annotations) are a knowledge that is permanent and can be re-used in every PHP project, and even in non-PHP project.

    And I like the way you talk about github community. This is true that it is very easy to contribute to a project hosted on github. And the way github is built encourages people to contribute. Github made contributing to open-source projects fun.

  2. Thanks for your feedback, I’ve made the choice of using sf1.4 instead of 2 a few months ago and I’m starting to wonder if it was the right choice.

    However don’t you think that all the available plugins for sf 1.x (sfGuard…) are missing ? Maybe they’re not necessary anymore because of their integration in the framework itself ?

    1. Thank you for you comment and also sharing your experience.

      In fact you are pointing a very delicate issue. Plugins are also not compatible from symfony1.4 to Symfony2. And you had lots of very useful plugins before.
      So yes, a lot of features provided by the plugins before are not available yet.
      On the bright side, Bundle are much easier to create, easier wire to an existent project, and can do more things than plugins.
      So, if you consider the most famous plugins (sfGuard for instance), it already has a nice equivalent with FOSUserBundle that is easier to use, and is more powerful.

      90% of my previous favorite plugins have an equivalent in a Bundle. Event if I still need to code the remain 10%, it is a pretty good thing!

  3. thx so much,never see such a very detailed article for the developer migrate from 1.4 to 2!ever!U helps me a lot!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s