Back to Blog
May 31st, 2015

How we Upgraded to Symfony 2.7 (+ deprecation notices)

Written by weaverryan, and Leannapelham

Edit
How we Upgraded to Symfony 2.7 (+ deprecation notices)

Go Deeper!

When you're ready, also check out How to Upgrade to Symfony 2.8, then 3.0!

Symfony 2.7 - the next LTS release - came out on Saturday, with bells and whistles like 100+ new features/enhancements and a surprise new bridge component to PSR-7.

So, we decided to upgrade immediately and report back. Let's go!

Upgrading composer.json

Since Symfony protects backwards-compatibility, upgrading is mostly easy, but we did hit a few minor things. Btw, there's a new upgrade section on the docs - tell your friends!

Start by updating your composer.json changes to allow for 2.7.*:

{
    "require": {
        "php": ">=5.3.3",
        "symfony/symfony" : "2.7.*",
        "...": "..."
    }
}

Now update this with composer. The command may surprise you:

composer update symfony/symfony sensio/distribution-bundle --with-dependencies

This will upgrade your project, but there are two important things happening:

1. You need to upgrade sensio/distribution-bundle

The version doesn't matter, just any new tag, 2.3.14 or higher. Why? Symfony 2.7 comes with deprecation warnings, which are awesome for knowing what deprecated features you're using. But, it also means that you need to silence E_USER_DEPRECATED warnings. The latest version of sensio/distribution-bundle builds an app/bootstrap.php.cache file that silences E_USER_DEPRECATED warnings for you. Don't worry: you'll still see the deprecated warnings in your web debug toolbar (see the image on this post).

So, if you see a friend who's getting a lot messages that look like this:

Deprecated: The Definition::setFactoryMethod method is deprecated since
version 2.6 and will be removed in 3.0.

Tell them to upgrade their sensio/distribution-bundle. And of course, to eventually fix these deprecated calls.

2. You Need --with-dependencies

This flag tells composer to update symfony/symfony and all libraries that it depends on. You may not need this, but without it, we got a dependency error involving twig/twig. The version of Twig in our project was not compatible with Symfony and needed to be upgraded. To allow for this, you have two options: use --with-dependencies, or explicitly upgrade the library in question (e.g. twig/twig):

composer update symfony/symfony twig/twig sensio/distribution-bundle

So What Broke?

Yay, you upgraded! Now, what broke? In our case, not much: in fact, only things in third-party bundles.

Upgrading FOSUserBundle

A new enhancement in Symfony 2.7 caused an accidental bug in FOSUserBundle. This was fixed two months ago, but you'll need to upgrade FOSUserBundle to get it.

If you're using a 1.3 release, just run the update command below (a tag was just released with the fix). If you're using the master (or 2.0) branch, that's not stable yet, and has no tag. Make sure your composer.json file has something like "friendsofsymfony/user-bundle": "~2.0@dev". Then let composer work its magic:

composer update friendsofsymfony/user-bundle

But check the UPGRADE log on the bundle to see what might have changed.

Fixing Behat 2.5

We're using Behat 2.5, which suffered from a minor BC break in Symfony 2.7. If you get this error:

Runtime Notice: Declaration of InputDefinition::getSynopsis()
should be compatible with InputDefinition::getSynopsis($short = false)  

then welcome to the club! Fortunately, this issue has been fixed (thanks to Stof for the fast release), so you just need to upgrade:

composer update behat/behat

If you're using the symfony2 driver, Behat may also explode on the new deprecated notices. To fix this, add the following at the top of your FeatureContext class::

define('BEHAT_ERROR_REPORTING', E_ALL & ~E_USER_DEPRECATED);

Back to the tests! And welcome to Symfony 2.7.

If you hit other issues, comment below and maybe we can help others.

Cheers!

25 Comments

Sort By
Login or Register to join the conversation
Default user avatar Christophe Coevoet 7 years ago

Note that the Behat hack is not needed anymore. I just released Behat 2.5.5 with the fix included in it.

2 | Reply |

Fast! And I've updated the post to reflect that. Thanks!

1 | Reply |
Default user avatar craig heydenburg 7 years ago

thanks for this post. Until I read this, I was still confused about the toolbar ("Don’t worry: you’ll still see the deprecated warnings in your web debug toolbar"). So, the methods that are being used in session/distribution-bundle and even the new Symfony 2.7.1 are designed to suppress the writing of these errors to the log, but not to prevent them from appearing in the toolbar? Is there a way to prevent the latter? In prod mode, my app works pretty well, but in dev mode (with the toolbar) the app often times out due to excessive error reporting. Since many of these errors come from sources I cannot control (e.g. Symfony itself), I would prefer to just prevent them entirely at this point I guess (unless there are better solutions).

2 | Reply |

Hey Craig!

Based on your 2.7.1 comment, I can see you have been watching this topic closely :). With 2.7.1, all trigger_error calls have the @trigger_error in front of them. Obviously, this silences them. BUT, you can still have your own custom error handler that hooks into these errors (even though they're silenced). That's what the web profiler is doing. Well actually, it's the Debug component, which logs all notices through the logger, and then a data collector which puts this into the WDT. I think it probably *is* possible to stop logging only E_USER_DEPRECATED, but it looks tricky enough (look at the ErrorHandler class).

How many deprecation warnings are you getting that causes the timeout? And is the count only high when the container is being built? Even if these are coming from inside of Symfony, Symfony itself doesn't use deprecated functionality (or only in a few small places - the test suite actually tests for this). So, the warnings must be coming from a result of your code or other third-party code, both which you should be able to fix (even the third-party libraries should be making new releases with the deprecated calls gone).

Cheers!