Upgrade to Symfony 4.0

With the deprecations gone... yeah! It's time to upgrade to Symfony 4! If you were hoping this was going to be really cool and difficult... sorry. It's super easy... well... mostly easy.

Open composer.json and change symfony/symfony to ^4.0. There are a few other libraries that start with symfony/, but they're independent and follow different release cycles. Oh, except for symfony/phpunit-bridge: change that to ^4.0 also.

68 lines composer.json
... lines 1 - 15
"require": {
... line 17
"symfony/symfony": "^4.0",
... lines 19 - 30
"require-dev": {
... line 33
"symfony/phpunit-bridge": "^4.0",
... lines 35 - 36
... lines 38 - 68

Let's do this! Find your terminal and run:

composer update

Yep, upgrading is just that easy! Except... there are almost definitely some libraries in our composer.json file that are not yet compatible with Symfony 4. The best way to find out is just to try it! And then wait for an explosion!

Removing Alice

Ah! Here is our first! Look closely... this is coming from nelmio/alice: the version in our project is not compatible with Symfony 4. If we did some digging, we would find out that there is a new version of Alice that is compatible. But, that version also contains a lot of changes to Alice... and I don't like the library's new version very much. At least, not at this moment.

So, instead of upgrading, remove alice from composer.json. This will break our fixtures: we'll fix them later.

Update again!

composer update

Removing Outdated Libraries

Our next explosion! This comes from incenteev/composer-parameter-handler. This library helps you manage your parameters.yml file and... guess what? When we finish upgrading, that file will be gone! Yep, we do not need this library anymore.

Remove it from composer.json. Oh, also remove the distribution bundle: it helps support the current directory structure, and isn't needed with Flex. And below, remove the generator bundle. We'll install the new MakerBundle later.

Ok, update again!

composer update

When a Library is not Ready: StofDoctrineExtensionsBundle

It works! I'm just kidding - it totally exploded again. This time the culprit is StofDoctrineExtensionsBundle: the version in our project is not compatible with Symfony

  1. Now... we become detectives! Maybe the library supports it in a new version? Let's find out.

Google for StofDoctrineExtensionsBundle to find its GitHub page. Check out the composer.json file. It does support Symfony 4! Great! Maybe there's a new version that has this! Check out the releases. Oof! No releases for a long, long time.

This means that Symfony 4 support was added, but there is not yet a release that contains that code. Honestly, by the time you're watching this, the bundle probably will have a new release. But this is likely to happen with other libraries.

Actually, another common problem is when a library does not have Symfony 4 support, but there is an open pull request that adds it. In both situations, we have a problem, and you have a choice to make.

First... you can wait. This is the most responsible decision... but the least fun. I hate waiting!

Second, if there is a pull request, you can use that fork as a custom composer repository and temporarily use that until the library merges the pull request and tags a release. For example, imagine this pull request was not merged. We could add this as a vcs repository in composer.json, and then update the version constraint to dev-master, because the branch on the fork is master.

And third, since the pull request is merged, but there is no tag, we can simply change our version to dev-master. Believe me: I am not happy about this. But I'll update it later when there is a release.

70 lines composer.json
... lines 1 - 15
"require": {
... lines 17 - 27
"stof/doctrine-extensions-bundle": "dev-master"
... lines 30 - 70

Try to update again:

composer update

Ha! Look! It's actually working! Say hello to our new Symfony 4 app! Woohoo!

Upgrading old Packages

Oh, but check out that warning: the symfony/swiftmailer-bridge is abandoned. I don't like that! Hmm, I don't see that package in our composer.json file. Run:

composer why symfony/swiftmailer-bridge

Ah! It's required by symfony/swiftmailer-bundle. We're using version 2.3.8, which is apparently compatible with Symfony 4. But I wonder if there's a newer version?


Actually, version 2.3.8 is not compatible with Symfony 4. But due to an old issue with its composer.json file, it appears compatible. Be careful with old libraries!

Google for the package to find its GitHub page. Click releases.

Woh! There is a new version 3 of the bundle. And I bet it fixes that abandoned packages issue. Change our version to ^3.1.

70 lines composer.json
... lines 1 - 15
"require": {
... lines 17 - 21
"symfony/swiftmailer-bundle": "^3.1",
... lines 23 - 28
... lines 30 - 70

And now, update!

composer update

Because we're upgrading to a new major version, you'll want to check out the CHANGELOG on the project to make sure there aren't any major, breaking changes.

Yes! Abandoned package warning gone! And our project is on Symfony 4. Not bad!

But... get ready... because now the real work starts. And the fun! It's time to migrate our project to the Flex project structure!

Leave a comment!

  • 2019-03-20 Victor Bocharsky

    Hey Mark,

    Is it the full output you have? What PHP version do you have? You can check it with "$ php --version" in your terminal. Also, could you show us your dependencies in composer.json?


  • 2019-03-18 Mark Bateman

    I'm at the part where I changed the Symfony version and php bridge to 4.0 and I keep getting.

    $ composer update

    Loading composer repositories with package information

    Updating dependencies (including require-dev)

    Your requirements could not be resolved to an installable set of packages.

    Problem 1

    - Conclusion: don't install symfony/symfony v4.2.4

    - Conclusion: don't install symfony/symfony v4.2.3

    - Conclusion: don't install symfony/symfony v4.2.2

    - Conclusion: don't install symfony/symfony v4.2.1

    - Conclusion: don't install symfony/symfony v4.2.0

    - Conclusion: don't install symfony/symfony v4.1.11

    - Conclusion: don't install symfony/symfony v4.1.10

    - Conclusion: don't install symfony/symfony v4.1.9

    - Conclusion: don't install symfony/symfony v4.1.8

    - Conclusion: don't install symfony/symfony v4.1.7

    - Conclusion: don't install symfony/symfony v4.1.6

    - Conclusion: don't install symfony/symfony v4.1.5

    - Conclusion: don't install symfony/symfony v4.1.4

    - Conclusion: don't install symfony/symfony v4.1.3

    - Conclusion: don't install symfony/symfony v4.1.2

    - Conclusion: don't install symfony/symfony v4.1.1

    - Installation request for phpunit/phpunit ^4.1 -> satisfiable by phpunit/phpunit[4.1.0, 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.1.5, 4.1.6, 4.2.0, 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.2.5, 4.2.6, 4.3.0, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, 4.4.0, 4.4.1, 4.4.2, 4.4.3, 4.4.4, 4.4.5, 4.5.0, 4.5.1, 4.6.0, 4.6.1, 4.6.10, 4.6.2, 4.6.3, 4.6.4, 4.6.5, 4.6.6, 4.6.7, 4.6.8, 4.6.9, 4.7.0, 4.7.1, 4.7.2, 4.7.3, 4.7.4, 4.7.5, 4.7.6, 4.7.7, 4.8.0, 4.8.1, 4.8.10, 4.8.11, 4.8.12, 4.8.13, 4.8.14, 4.8.15, 4.8.16, 4.8.17, 4.8.18, 4.8.19, 4.8.2, 4.8.20, 4.8.21, 4.8.22, 4.8.23, 4.8.24, 4.8.25, 4.8.26, 4.8.27, 4.8.28, 4.8.29, 4.8.3, 4.8.30, 4.8.31, 4.8.32, 4.8.33, 4.8.34, 4.8.35, 4.8.36, 4.8.4, 4.8.5, 4.8.6, 4.8.7, 4.8.8, 4.8.9].

    - Conclusion: don't install symfony/symfony v4.1.0

    - Conclusion: don't install symfony/symfony v4.0.15

    - Conclusion: don't install symfony/symfony v4.0.14

    - Conclusion: don't install symfony/symfony v4.0.13

    - Conclusion: don't install symfony/symfony v4.0.12

    - Conclusion: don't install symfony/symfony v4.0.11

    - Conclusion: don't install symfony/symfony v4.0.10

    - Conclusion: don't install symfony/symfony v4.0.9

    - Conclusion: don't install symfony/symfony v4.0.8

    - Conclusion: don't install symfony/symfony v4.0.7

    - Conclusion: don't install symfony/symfony v4.0.6

    - Conclusion: don't install symfony/symfony v4.0.5

    - Conclusion: don't install symfony/symfony v4.0.4

    - Conclusion: don't install symfony/symfony v4.0.3

    - Conclusion: don't install symfony/symfony v4.0.2

    - Conclusion: don't install symfony/symfony v4.0.1

    - symfony/symfony v4.0.0 conflicts with roave/security-advisories[dev-master].

    - symfony/symfony v4.0.0 conflicts with roave/security-advisories[dev-master].

    - Installation request for symfony/symfony ^4.0 -> satisfiable by symfony/symfony[v4.0.0, v4.0.1, v4.0.10, v4.0.11, v4.0.12, v4.0.13, v4.0.14, v4.0.15, v4.0.2, v4.0.3, v4.0.4, v4.0.5, v4.0.6, v4.0.7, v4.0.8, v4.0.9, v4.1.0, v4.1.1, v4.1.10, v4.1.11, v4.1.2, v4.1.3, v4.1.4, v4.1.5, v4.1.6, v4.1.7, v4.1.8, v4.1.9, v4.2.0, v4.2.1, v4.2.2, v4.2.3, v4.2.4].

    - Installation request for roave/security-advisories dev-master -> satisfiable by roave/security-advisories[dev-master].

  • 2018-05-23 Victor Bocharsky

    Hey toporovvv ,

    Yes, you're right about PHP 7! Well, actually, Symfony 4 requires PHP ^7.1.3, but you have to point platform PHP version to that version you have on production. We just do not have this platform PHP version in our composer.json, but your comment may be useful for people who has. Thanks for sharing it!


  • 2018-05-22 toporovvv

    At the moment I have to change php version in config -> platform -> php section from 5.5.9 to 7.2.5. Then, changed a version of Doctrine ORM to "~2.4,>=2.4.5" (found it here ). stof/doctrine-extensions-bundle is fine now, so it stays as is. The whole composer.json for successful update for this tutorial:

    "name": "symfony/framework-standard-edition",
    "license": "MIT",
    "type": "project",
    "description": "The \"Symfony Standard Edition\" distribution",
    "autoload": {
    "psr-4": { "": "src/" },
    "classmap": [ "app/AppKernel.php", "app/AppCache.php" ]
    "autoload-dev": {
    "psr-4": { "Tests\\": "tests/" },
    "files": [ "vendor/symfony/symfony/src/Symfony/Component/VarDumper/Resources/functions/dump.php" ]
    "require": {
    "php": ">=5.5.9",
    "doctrine/doctrine-bundle": "^1.6",
    "doctrine/doctrine-cache-bundle": "^1.2",
    "doctrine/doctrine-migrations-bundle": "^1.2",
    "doctrine/orm": "~2.4,>=2.4.5",
    "knplabs/knp-markdown-bundle": "^1.5",
    "sensio/framework-extra-bundle": "^3.0.2",
    "stof/doctrine-extensions-bundle": "^1.2",
    "symfony/monolog-bundle": "^3.0.2",
    "symfony/polyfill-apcu": "^1.0",
    "symfony/swiftmailer-bundle": "^3.1",
    "symfony/symfony": "^4.0",
    "twig/twig": "^1.0||^2.0"
    "require-dev": {
    "doctrine/doctrine-fixtures-bundle": "^2.3",
    "symfony/phpunit-bridge": "^4.0"
    "scripts": {
    "symfony-scripts": [
    "post-install-cmd": [
    "post-update-cmd": [
    "config": {
    "platform": {
    "php": "7.2.5"
    "sort-packages": true
    "extra": {
    "symfony-app-dir": "app",
    "symfony-bin-dir": "bin",
    "symfony-var-dir": "var",
    "symfony-web-dir": "web",
    "symfony-tests-dir": "tests",
    "symfony-assets-install": "relative",
    "branch-alias": {
    "dev-master": "3.2-dev"

  • 2018-01-29 Diego Aguiar

    Great! Let us know how it went :)

    Have a nice day

  • 2018-01-29 Thomas

    HI Ryan, thanks a lot for giving this hint. I requested an trial this morning.

  • 2018-01-29 weaverryan

    Hey Thomas!

    That IS very strange and concerning.... and it *is* totally possible there's some sleeping bug in Symfony. I have a recommendation: try profiling with blackfire. You can even use Blackfire to profile a command you run at the command line: I've done this many times, and it works awesome. THIS would be the way to find out what's causing the huge memory. I'd be very interested in knowing :).


  • 2018-01-26 Thomas

    Hi Diego Aguiar,

    2G swap but this is not the cause. If 32G RAM are fully used there must be another issue. I copied yesterday non-symfony-files (only my projectfiles) without configuration to a from-scratch-installation and tried it step by step to fullfill the configuration I need. And ... no issue. I have no clear whats going on but for now thats by dirthy workaround.

  • 2018-01-25 Diego Aguiar

    Hey Thomas

    How much swap memory do you have available? I experienced a somehow similar problem like this one in the past, and I managed to fix it by increasing the swap memory to 4GB

    I hope it helps you. Cheers!

  • 2018-01-25 Thomas

    Hi Victor,

    thanks for suggestions. On DEV machine the memory limit for CLI is disabled and we increased the memory to 32G. Composer is neweset version. xdebug is installed and suggestions did not help also.

    So now I've started from scratch with a new symfony 4 installation and copy related project files one by one and test results. What I saw while profiling is an heavy increase of nested functions while compiling cache. I've set value to 10000 (! default is 256 i mention !) and same issue. I mention that there is sleeping anywhere a small bug in symfony 4 code but I am not sure how to find him.

    For now I will continue with my workaround above and maybe I can reproduce the behaviour and have more clue what file/function/class is causing this one.

  • 2018-01-25 Victor Bocharsky

    Hey Thomas,

    Yes, good step about checking memory limit, so what memory limit do you have? Here's some recommendations from Composer which probably can help: - it worked for me. Also, do you have Xdebug installed? Did you disabled it during installation? See . I'd also recommend you to upgrade to the latest Composer version available, I see it's 1.6.2.

    Let us know if it does not help


  • 2018-01-25 Thomas

    Hi Ryan, thanks a lot for the great upgrade tutorial!

    For me, I don'nt know exactly when it happened first, the cache is broken and it seems to have created an memory leak. If composer is starting clear:cache command the memory usage explode while creating the warmup-cache. I tried it on my local xampp-installation with 8GB Ram and with dev-server with 16GB RAM same issue. My next step was to check the memory_limit. This is fine to.

    Do you have any hints how to debug/solve this?


  • 2018-01-17 weaverryan

    Hey the_nuts!

    Great job on solving this. But BOOOO for needing this :). I hope more and more libraries will start supporting Symfony4! Actually, someone just opened a PR ( - is that you? If so, nice work!


  • 2018-01-17 the_nuts

    Fixed by forking also neutron/temporary-filesystem and alchemy/binary-driver :)

  • 2018-01-17 the_nuts

    Hi, I have a problem...
    I need php-ffmpeg/php-ffmpeg, which require neutron/temporary-filesystem, which allows only symfony/filesystem: ^2.3 || ^3.0
    How could I solve?
    (PHP-FFMpeg was required by pulse00/ffmpeg-bundle, which I already forked to allow SF4)

  • 2018-01-04 Diego Aguiar

    Hey niumis

    Thanks for informing us, I'll ping Ryan about it :)


  • 2018-01-04 niumis

    Hey weaverryan!

    New version is out of stof/doctrine-extensions-bundle. Release is 1.3.0 :)


  • 2017-12-26 weaverryan

    Hey kaizoku!

    Thanks for sharing this :). Yea, I hope FOSUserBundle will be Symfony 4 compat VERY soon - all (or at least most) of the work is done as you correctly saw. Workarounds suck, but yep, you've posted the correct workaround for now!


  • 2017-12-26 kaizoku

    friendsofsymfony/user-bundle (v2.0) is not compatible yet with SF4.
    After doing the way that Ryan suggest for doctrine extension bundle it's working.
    Also I noticed that it's Ryan was a major players into refactoring FOS userbundle for SF4 so it should be soon 'composer ready'.
    Thank Ryan btw.

    So use this line will make your project good to go : "friendsofsymfony/user-bundle": "dev-master"

  • 2017-12-21 Gregory Berger

    I just installed it, I'll give it a try. Thank you very much!

  • 2017-12-20 Diego Aguiar

    Hey Gregory Berger

    There is a plugin for PhpStorm for composer support, it's called "PHP Composer.json support"


  • 2017-12-20 Gregory Berger

    Hello Ryan, could you tell us what PhpStorm plugin gives you the autocompletion on release versions of composer packages in composer.json ?