Symfony 2.3 LTS: Symfony2 with Long Term Support

Symfony 2.3 LTS (Long Term Support) was finally released yesterday (Monday June 3rd 2013). This is a new Symfony2 version that will be supported for next three years. This is significantly longer than the 8 months that normal releases are maintained for. Longer support means less upgrades and can reduce maintenance costs (although the upgrades will be bigger). Also the promise not to break backward compatibility from this version on is an important one. The complete release process (and the release diagram below) can be found on the Symfony2 release process page of the Symfony website.


Our LeaseWeb Symfony bundles have all received minor version upgrades to support this new Symfony 2.3 release. However, please report any issues you might find with these new versions.

In previous major version upgrades there was an “” (for upgrading from 2.0 to 2.1) and “” (for upgrading from 2.1 to 2.2). This release does not have the file included (probably a mistake), but fortunately you can find “” on the official Github repository and also some upgrade instructions on the official blog. Read it carefully to avoid hitting the issues we found (they are described below).

1: Running LTS with stable versions

To run only stable versions of packagist packages make sure “composer.json” contains the following line:

"minimum-stability": "stable",

It would be strange to run an LTS version with development code wouldn’t it? This is set correctly on a fresh Symfony 2.3 installation, but you should check it locally on your own file to be sure it is set correctly.

2: JMS bundles are missing

When you replace the requirements from your composer.json with the required section from the Symfony 2.3 “composer.json” file, you might get the following error when running the “php composer.phar update”:

PHP Fatal error:  Class 'JMS\AopBundle\JMSAopBundle' not found in app/AppKernel.php on line 19

This happens because there are two lines removed from the composer.json compared to the previous versions:

"jms/security-extra-bundle": "1.2.*",
"jms/di-extra-bundle": "1.1.*",

You should add them again, but with different versions:

"jms/security-extra-bundle": "1.5.*",
"jms/di-extra-bundle": "1.3.*@dev",

Note that in the future, you might want to remove the “@dev” suffix from “jms/di-extra-bundle” that allows the package to run a non-stable version.

Update June 8th 2013: There is a new stable version “jms/di-extra-bundle”, but unfortunately this does not work yet:

"jms/security-extra-bundle": "1.5.*",
"jms/di-extra-bundle": "1.4.*",

This caused by the dependencies on “jms/security-extra-bundle” that have not been adjusted to reflect this new stable version. It complains:

jms/security-extra-bundle 1.5.0 requires jms/di-extra-bundle 1.3.* ...

Update June 9th 2013: There is a new stable version “jms/security-extra-bundle” and all dependencies have been fixed. Thank you!

3: “trust_proxy_headers” option unrecognized

You might run into the issue that the “trust_proxy_headers” option that was already deprecated is removed in Symfony 2.3:

Unrecognized options "trust_proxy_headers" under "framework"

To fix this issue open “app/config/config.yml” and remove the “trust_proxy_headers” option and replace it with an “trusted_proxies” option and specify the list of proxies as described in the FrameworkBundle Configuration documentation.

4: Method “hasFlash” does not exist

You might run into a issue with Flash Messages. Flash Messages are (unrelated to Adobe Flash) the green, blue, yellow or red bars that show up on a page that show the result of the previous page (form) submit. Normally they show messages like “Login successful”, “Error submitting form, please try again” or “Sign-up successful, an email has been sent”.

Method "hasFlash" for object "Symfony\Component\HttpFoundation\Session\Session"
does not exist in ::flash.html.twig at line 1

The “hasFlash” method is deprecated since version 2.1 and removed in 2.3. The book has a good section on how to handle flash messages in different versions. To summarize, if you have this:

{% if app.session.hasFlash('success') %}
  {{ app.session.flash('success') }}
{% endif %}

You need to change that construct into this:

{% for flashMessage in app.session.flashbag.get('success') %}
  {{ flashMessage }}
{% endfor %}

Make sure you also change all “setFlash” calls with the following search/replace action: “setFlash” -> “getFlashBag()->add”.

5: Method “bindRequest” does not exist

Make sure you also change all your “bindRequest” calls to “bind” like this:

$form->bind($request); // was: $form->bindRequest($request);

As was well described in the Form Goodness in Symfony 2.1 post.

6: Change Forms (Types) and Validators

In the Type classes add the following use clause:

use Symfony\Component\OptionsResolver\OptionsResolverInterface;

Step 1: Replace the “getDefaultOptions” function like this:

public function getDefaultOptions(array $options)


public function setDefaultOptions(OptionsResolverInterface $resolver)

Step 2: Replace the return value with a call to the resolver “setDefaults” method like this:

return array('validation_constraint' => $collectionConstraint);


$resolver->setDefaults(array('constraints' => $collectionConstraint));

Step 3: Also in your custom validators replace the function “isValid” like this:

public function isValid($value, Constraint $constraint)


public function validate($value, Constraint $constraint)

7: The method “getEntityManager” is deprecated

Replace the deprecated “getEntityManager” method by “getManager” in your controllers like this:

$em = $this->getDoctrine()->getEntityManager();


$em = $this->getDoctrine()->getManager();

As you can also read in the “Persisting Objects to the Database” chapter of the book.

8: The “Min” and “Max” validators are removed

The Min and Max constraints that are deprecated since version 2.1 are removed in Symfony 2.3. You should use Range validator with the “min” and/or “max” option instead.

9: Yours…

If you run into other issues please post them and I’ll add them to this list. For now enjoy this brand new stable Symfony 2.3!


20 thoughts on “Symfony 2.3 LTS: Symfony2 with Long Term Support”

  1. Yes.. it is fixed… 🙂 …. but i found another issue…. when we select form field type “date” as 3 seperate boxes of days, month and year… month and days are not synchronized… means when i select month 2 days range should be from 1-29….

  2. @Tejas: we did not run into that yet. Can you give a code example?

  3. in form type class:
    ‘format’ => ‘M dd y’,
    ’empty_value’ => array(
    ‘year’ => ‘general.formLabel.dob.year’,
    ‘month’ => ‘general.formLabel.dob.month’,
    ‘day’ => ‘’
    ‘label’ => ‘generallabel.DOB’,
    ‘required’ => false,

    in twig:

    {{ form_widget(, { ‘attr’: { ‘label’: ‘day’} }) }}
    {{ form_widget(form.dob.month, { ‘attr’: { ‘label’: ‘month’} }) }}
    {{ form_widget(form.dob.year, { ‘attr’: { ‘label’: ‘year’} }) }}

    now when i select month “2” i.e. February the selection range in days field should be changed to 1-31 to 1-28/29 … i have not found anything on that so far

  4. I’d thought I would do a quick update to the latest version of symfony before deploying to production for the first time. Someone said it would be easy. I got three different error that I had to fix one at a time. This page solved the last one for me. It also does a great job of other issues. Thanks for putting it up.

  5. @Peter: Thank you for your comment. I am glad it helped you. Regards, Maurits

  6. @Curt: Quick updates are dangerous 😉 Thank you for the comment!

  7. @ripperjack: Thank you for your comments. I am glad you like the post. I took the liberty to combine your comments into one 🙂

  8. @Oriam: I added your code to the demo (clean Symfony install), but cannot reproduce your problem. You forgot a namespace declaration and a use statement, but that cannot cause the problem you described. Please help me to reproduce the problem if you need further help. This is the generated code:

    <div><input type="text" id="some_name_first_name" name="some_name[first_name]" required="required" /></div>

  9. Hi, I am getting this error after updating to 2.3 from 2.2:

    You have requested a non-existent service “event_dispatcher”.

    Composer.json is this:

    “require”: {
    “php”: “>=5.3.3”,
    “symfony/symfony”: “2.3.*@dev”,
    “symfony/framework-bundle”: “2.3.x-dev”,
    “doctrine/doctrine-bundle”: “1.2.*@dev”,
    “twig/extensions”: “1.0.*”,
    “symfony/assetic-bundle”: “2.4.x-dev”,
    “kriswallsmith/assetic”: “1.2.*@dev”,
    “symfony/swiftmailer-bundle”: “2.2.*@dev”,
    “symfony/monolog-bundle”: “2.4.x-dev”,
    “sensio/distribution-bundle”: “2.3.x-dev”,
    “sensio/framework-extra-bundle”: “2.3.x-dev”,
    “sensio/generator-bundle”: “2.3.x-dev”,
    “jms/security-extra-bundle”: “1.5.x-dev”,
    “jms/di-extra-bundle”: “1.4.0”,
    “doctrine/doctrine-fixtures-bundle”: “dev-master”,
    “sonata-project/admin-bundle”: “dev-master”,
    “sonata-project/doctrine-orm-admin-bundle”: “dev-master”,
    “gedmo/doctrine-extensions”: “dev-master”,
    “avalanche123/imagine-bundle”: “dev-master”,
    “stof/doctrine-extensions-bundle”: “~1.1@dev”,
    “lrotherfield/form”: “dev-master”,
    “friendsofsymfony/user-bundle”: “dev-master”

    Any ideas? Someone else must have run into this but can’t find anything on the web for this error.

  10. Great article.
    Even a year later, it’s useful for upgrading an old application when you encounter the “hasFlash does not exist” error.
    Thank you.

  11. @Hervé: Glad it helped! There is no shame in doing it now. It is a major effort on a large code base. Good luck with it.

  12. Well, it certainly is a helpful post. Could we get an update? Symfony is now on version 2.7 and the last comment was last year, 2014, It is now 2015. This looks like one of the more reliable posts/article about symfony so far.

Leave a Reply

Your email address will not be published. Required fields are marked *