Cover of the book Symfony 5: The Fast Track

Symfony 5: The Fast Track is the best book to learn modern Symfony development, from zero to production. +300 pages showcasing Symfony with Docker, APIs, queues & async tasks, Webpack, SPAs, etc.

Symfony2: Getting easier

With the release of the first beta approaching fast, our main focus has switched from adding new features to polishing existing ones.

Symfony2 has many great features. But sometimes, configuration feels a bit too complex, or the error messages are not friendly enough. We care a lot about these problems as these issues can lead to a lot of frustration.

Recently, Ryan and I have spent our time tweaking error messages, simplifying the code and the configuration, adding more documentation, and making things more consistent throughout the framework. The goal is to ease the learning curve and make things that people will need on a day to day basis simpler.

Let's see some examples of what we've done so far.

Better Twig Error Messages

Twig is a great time saver thanks to its concise syntax and its great automatic output escaping feature. Each time I need to edit an "old" template written in PHP, I'm really happy that this is just about legacy code (and apparently I'm not the only one)

One problem you might have encounter though is when something goes wrong during template compilation or at runtime. Sometimes, the exception message does not mention the original template name, nor the line where the problem happened; and of course, the PHP stack trace only has information about the cached PHP file. That makes debugging harder than it has to be. This has been "fixed" recently. Now, Twig tries very hard to always tell you where the error occurred in the original template file.

And on a totally unrelated note, Twig now also enjoys native support in PHPStorm.

Better Configuration Error Messages

What I've described above also apply to configuration errors. Here, we are talking about configuration files (in XML or YAML) instead of Twig templates. For instance, if you use a non-defined parameter in a service definition, you will have the following error message:

The service "%s" has a dependency on a non-existent parameter "foo".

And here is the old one:

You have requested a non-existent parameter "foo".

The new message instantly tells you what you need to look for.

Simpler Doctrine Configuration

Most projects will ever only use one database. But the Doctrine configuration syntax is "optimized" for when you need to be able to manage several database connections. This makes the configuration verbose, non-trivial to understand, and hard to teach:

                dbname:   dbname
                user:     root
                password: ~

As of today, if you only need one database connection, you can use this simpler syntax:

        dbname:   sfweb
        user:     root
        password: ~

Configuring the ORM is also a pain point as every time you add a third-party bundle, you must remember to add it to the Doctrine mapping configuration. If you forget, you will have an error that won't really help you understand what you need to do to fix it.

If you only use one entity manager (which is again the most common use case), you can now just tell Doctrine to automatically load all bundle's mapping configuration:

    auto_mapping: true

For the record, here is the "old" minimal ORM configuration:

                    BlogBundle: ~

The good news is that you can still fallback to the old syntax for the rare occasions where you need more than one database connection or more than one entity manager.

This post is really just a sample of what we are doing on a day to day basis. The good news is that *you** can help us make the framework better. Whenever you hit a wall because an error message is not clear, or because a syntax looks awkward, please tell us about it; write an email to the Symfony developer mailing-list and we will try to work together to make things better and easier. Expect more similar changes in the coming weeks.

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.


Simplification of the configuration (too verbose) is a very good choice to recast, glad you are working on this. Thanks a lot.
Hi Fabien, I have recently download the latest preview release, and it seems like some components, ie some bundles have been removed completely - to do with annotations for the routes, I have tried to put together a working package but I feel like guessing most of the time which bundles should be downloaded for the normal operation to match documentation that is provided on the website. My question is when are you expecting the framework to stabilize, so that it could be used for development,

it may be useful to include a link to a forum page that finds or creates a thread for the most generic form of the error message.

As well as maybe a counter image for how many times the error has ever occurred to gather aggregate stats for the most error prone parts of the framework.

I realize this is a lot easier to type than it is to make happen, but could prove interesting.
I am happy to see you working on this. You and Ryan and all the others involved do a fantastic job!
Symfony2 is very flexible and powerful by now. Now it is time to optimise for the common use cases.
Keep up the good work!
This is great news! I have been missing "the easy(default) way" in Symfony2. I'll keep an eye and help whenever I can.
I'm very glad to see the direction you guys are taking lately. Symfony2 is not out yet, but it already has the reputation of being verbose, very complex, and using too much configuration. Your work on error messages and documentation smoothes the edges and is greatly appreciated.
I just wanted to say that I love the new architecture in Symfony 2. It is already very usable, for such a powerful and flexible framework. I picked CI as my first framework (some years ago) due to its simplicity, clear docs, and my lack of OOP knowledge. But this is a totally different world, everything feels perfect, can't wait to see it finished.
Please don't remove any feature just to make it simpler.
**Great stuff**! I applaud this direction.

Is there any chance the location for Doctrine schema files could be shortened? I made files like this for each entity:


But I'm like, "are you serious? What happened to `config/schema.yml`?"

I like Larry Wall's philosophy about Perl - "make easy things easy and hard things possible".

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.