Buy

Upgrading to Symfony 3!

We are now finally ready to upgrade our project to Symfony 3. How do we do that? It's a simple, 2 step process.

First, in composer.json change the symfony/symfony key, to 3.0.*:

66 lines composer.json
{
... lines 2 - 12
"require": {
... lines 14 - 30
"symfony/symfony" : "3.0.*",
... line 32
},
... lines 34 - 64
}

Or, if you're upgrading to any even new version, use that - like 3.1.*.

Second, run composer update. This time, run it with no arguments:

composer update

We technically only need to upgrade the symfony/symfony package, but since so many libraries depend on this, it's pretty tough to only update Symfony. If you're worried about too much stuff upgrading, make sure you version constraints in composer.json are really tight.

But as we wait for this: I have a surprise! This will almost definitely not work.

Upgrading other Libraries

And just as I say that, huge error! Oh boy, these are a pain to read at first. But if you follow down, eventually you'll find the problem. Ah, there it is: the installation for sensio/distribution-bundle requires symfony/process at version 2.2. In normal English, Composer is saying:

Yo! Your version of sensio/distribution-bundle in composer.json needs symfony/process 2.2. You probably need to upgrade the distribution bundle to a new version that works with symfony/process version 3.

This means we need to update the version for sensio/distribution-bundle in composer.json to something higher. In these cases, I like to open Packagist and search for symfony/framework-standard-edition. This is the project you get when you first download Symfony. We can cheat by looking at its composer.json versions.

Let's see what it looks like at the latest 3.0 version - 3.0.8. Ok - this project requires sensio/distribution-bundle at version ^5.0. Open our composer.json and change it to match: ^5.0:

66 lines composer.json
{
... lines 2 - 12
"require": {
... lines 14 - 25
"sensio/distribution-bundle" : "^5.0",
... lines 27 - 32
},
... lines 34 - 64
}

That's it! Run Composer update again:

composer update

We may get another error about another library, but this is the process: run $ composer update, find the problematic package, update its version and repeat.

Yep: another problem. This time it's from sensio/generator-bundle. Go back to Packagist: the version in the Standard Edition is ^3.0. Update our composer.json:

66 lines composer.json
{
... lines 2 - 33
"require-dev": {
"sensio/generator-bundle": "^3.0"
},
... lines 37 - 64
}

And run Composer again:

composer update

If you get an error from a package that's not part of the Standard Edition, then you'll need to go look up that library in Packagist or on GitHub to find a version that's 3.0-compatible. That's exactly what we did with AsseticBundle.

Et voila! We just downloaded Symfony 3.0.8.

Well, let's see if it works! Refresh! Yes! Everything looks great: a major framework upgrade without breaking your code! Give yourself a congrats. And then, don't forget to run your tests and QA your site to make sure we didn't missing anything.

All right, guys, if you have any questions, let me know.

Seeya next time!

Leave a comment!

  • 2017-11-03 weaverryan

    Yo claire!

    Yes, so I *do* know this error. Let me explain it first (actually it looks like you found the [BC BREAK] item), and then we'll see if we can find the cause! Normally (as you do in your code) when you pass arguments to a service, it looks like this (your example above passes the arguments all on 1 line, but it's equivalent to this multi-line version)


    arguments:
    - foo
    - bar

    But, in Symfony 2, it was legal to do this instead:


    arguments:
    something: foo
    somethingelse: bar

    In this case, you're *naming* the keys to your arguments. This had absolutely *no* effect - the above to examples created identical services. In Symfony 3, we made using string keys like this illegal (we did this because we now allow named arguments https://knpuniversity.com/s....

    So, somewhere in your code, someone is doing this - and using a "container" key. And the problem *is* indeed in the bundle: https://github.com/AlmogBak...

    I think you need to find a new bundle :). A quick search reveals this one: https://github.com/AhmedSam..., though I have never used it. But honestly, the bundle you're using isn't giving you *anything*, besides that *one* service definition - https://github.com/AlmogBak... and this one class: https://github.com/AlmogBak.... You could just copy those into your code very easily :).

    I hope that helps!

  • 2017-11-03 claire

    Had a thought could it be to do with the 'godisco/mailchimp-bundle' , im on the latest version but it seems it not been updated in a while. Looking into this bundles dependency injection I see :

    public function load(array $configs, ContainerBuilder $container)
    {
    $configuration = new Configuration();
    $config = $this->processConfiguration($configuration, $configs);

    $loader = new Loader\YamlFileLoader($container, new FileLocator(__DIR__.'/../Resources/config'));
    $loader->load('services.yml');

    $container->setParameter("mailchimp.api_key", $config['api_key']);
    $container->setParameter("mailchimp.default_list", $config['default_list']);
    }

    Could this be the cause? If so , what would you recommend, maybe finding a replacement bundle?

  • 2017-11-02 claire

    Hey,
    It pretty big so here the snippets which are using mailchimp. But if it helps i can post the whole thing.


    line_fringe.mailchimp_manager:
    class: Line\FringeBundle\Email\MailchimpManager
    arguments: [ '@mailchimp', '@line_fringe.setting_manager' ]
    lazy: true

    line_fringe.user_manager:
    class: Line\FringeBundle\Entity\Manager\UserManager
    arguments: [ '@doctrine.orm.entity_manager', '@security.encoder_factory', '@line_via.line_via_api', '@line_fringe.mailchimp_manager', '@line_fringe.mailer', '@line_fringe.setting_manager']

    Thank you for taking the time to help me Diego Aguiar :)

  • 2017-11-02 Diego Aguiar

    Hey claire

    Can you post your services.yml file? Look like you/or something is injecting the container into the mailchimp service in a deprecated way

    Cheers!

  • 2017-11-02 claire

    Hi,
    After upgrading to symfony 3.0 I'm unable to get pass this error:
    Invalid key "container" found in arguments of method "__construct()" for service "mailchimp": only integer or $named arguments are allowed.
    Is it related to : [BC BREAK] non-numeric keys in methods and constructors arguments have never been supported and are now forbidden. Please remove them if you happen to have one.

    The problem I'm having is locating where this error is happening to solve it.
    Any help would be appreciated, thank you

  • 2017-10-12 axa

    Yes, you are right... Thanks for answer.

  • 2017-10-12 Victor Bocharsky

    Hey axa,

    Actually, I think your idea is partially OK, but it depends, because if we talk about real project - you will have a lot of custom configuration and dependencies. For example, except src/ folder you may have your own dependencies in composer.json, a lot of custom configuration in app/config/*.yml files, etc, so just copying src/ folder does not enough. And probably the most important problem is that this way you lose all your Git history, i.e. you create a new project where you'll need to do "git init" which means you start with empty Git repo. Also, most probably cache and logs from the previous project won't work, so copying them is pointless.

    And btw, do not forget to run your tests before pushing to production (you write tests, right?) :)

    Anyway, your way looks more time consuming as for me.

    Cheers!

  • 2017-10-12 axa

    One question: could we do this on easier way? for example:
    1) install sf 3 (new folder)
    2) copy src (sf 2.7) folder to new symfony 3 (maybe cache and logs files if we want)
    3) fix only our code
    4) if works fine, move to prod server
    On this way we can avoid symfony core and external bundles upgrade issues and focus only on our code (AppBundle).
    Is this good idea :) ?