Flag of Ukraine
SymfonyCasts stands united with the people of Ukraine

Final config/ Migration

Keep on Learning!

If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.

Start your All-Access Pass
Buy just this tutorial for $8.00

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

We are in the Flex home stretch! These last config/ files are the easiest. Start with config_dev.yml.

Dev Environment Parameters

Ok, we have a cache_type parameter. This is meant to override the value that lives in services.yaml whenever we're in the dev environment.

How can we have dev-specific parameters or services in Flex? By creating a new services_dev.yaml file. Copy the parameter, remove it and paste it here.

cache_type: array

Symfony will automatically load this file in the dev environment only.

Migrating config_dev.yml

For the rest of this file... we haven't really changed anything: these are the original default values. So there's a good chance that we can just use the new files without doing anything.

And yea! If you investigated, you would find that the framework config is already represented in the new files. And the profiler... well actually... that's not even installed yet. Let's fix that:

composer require profiler

Go back and remove the framework and web_profiler sections. When Composer finishes... yes! This installed a recipe. The new web_profiler.yaml file contains exactly what we just removed. It even added config for the test environment and loaded the routes it needs. Thanks profiler!

toolbar: true
intercept_redirects: false
profiler: { only_exceptions: false }
toolbar: false
intercept_redirects: false
profiler: { collect: false }
resource: '@WebProfilerBundle/Resources/config/routing/wdt.xml'
prefix: /_wdt
resource: '@WebProfilerBundle/Resources/config/routing/profiler.xml'
prefix: /_profiler

The last key in config_dev.yml is monolog. Monolog is installed... and its recipe added config for the dev and prod environments.

I haven't made any changes to my monolog config that I really care about - just this firephp section, which I could re-add if I want. So I'll use the new default config and just... delete config_dev.yml! We can also delete config_prod.yml.

doctrine Config in config_prod.yml

Oh, by the way, if you have some doctrine caching config in config_prod.yml, I would recommend not migrating it. The DoctrineBundle recipe gives you prod configuration that is great for production out-of-the-box. Booya!

Migrating config_test.yml

Next: config_test.yml. And yea... this is still just default config. But there is one gotcha: in config/packages/test/framework.yaml, uncomment the session config.

... line 2
storage_id: session.storage.mock_file

I mentioned earlier that the session config is not perfect smooth: if you need sessions, you need to uncomment some config in the main framework.yaml and here too.

Ok, delete config_test.yml!

Migrating paramters.yml?

What about parameters.yml? In Flex, this file does not exist. Instead of referencing parameters, we reference environment variables. And in the dev environment, we set these in the .env file.

We also had a parameters.yml.dist file, which kept track of all the parameters we need. In Flex, yea, we've got the same: .env.dist.

The parameters.yml file in this project only holds database config and secret... and both of these are already inside .env and .env.dist.

The only difference between the files is how you reference the config. In doctrine.yaml, instead of using %DATABASE_URL% to reference a paramter, you reference environment variables with a strange config: %env(DATABASE_URL)%.

But other than that, it's the same idea. Oh, the resolve: part is optional: it allows you to put parameters inside of your environment variable values.

So... we're good! Delete parameters.yml and parameters.yml.dist. If you have other keys in parameters.yml, add them to .env and .env.dist and then go update where they're referenced to use the new syntax. Easy peasy.

While we're on the topic, in .env, update your database config: I'll use root with no password and call the database symfony4_tutorial.

Copy that and repeat it in .env.dist: I want this to be my default value.

25 lines .env.dist
... lines 1 - 15
... lines 17 - 25

Migrating routing Files

Back to the mission! What about routing.yml? Copy its contents. I'll close a few directories... then open config/routes.yaml. Paste here!

resource: "@AppBundle/Controller/"
type: annotation
path: /
_controller: AppBundle:Main:homepage

We already have a config/routes/dev/annotations.yaml file that loads annotation routes from src/Controller. But for now, we still need our import because it loads routes from AppBundle.

But we do need to make two small changes. Even though we'll keep the AppBundle directory for now, we are not going to actually register it as a bundle anymore. Yep, AppBundle.php can be deleted: we just don't need bundles anymore.

But to make this work, we need to replace @AppBundle with a normal path: ../src/AppBundle/Controller.

And for the homepage route, remove the weird three-part colon syntax and just use the full class name: AppBundle\Controller\MainController::homepageAction.

resource: "../src/AppBundle/Controller/"
... lines 3 - 4
... line 6
_controller: AppBundle\Controller\MainController::homepageAction

I am so happy to be done with those two Symfony-specific syntaxes! Delete routing.yml. And... routing_dev.yml? Yep, delete it too! The Flex recipes handle this stuff too.

In fact, delete the config/ directory!

Does our app work? Try to list the routes:

./bin/console debug:router

Ha! Yes! We have our routes back!

Next, let's delete some files - that's always fun - and then welcome our new Flex app!

Leave a comment!

Login or Register to join the conversation
Vladimir Z. Avatar
Vladimir Z. Avatar Vladimir Z. | posted 5 years ago

Why are some recipe YAML files installed in the dev, prod and test directories, while others in the top-level packages directory? A good example of it is swiftmailer.yaml, which is found in packages, dev, test but not prod. Is anything that's in packages considered to be a global config and anything in the inner directories overrides it?
Thanks and 73,

1 Reply

Hey Vlad,

Good question! And actually we're answering it in new Symfony 4 screencasts, for example, here: https://knpuniversity.com/s...

So, in shorts, you're correct, everything in config/packages/ level is considered as a global config which is loaded for any environment. But then you can overwrite some configuration using env-specific configs like config/packages/dev/, config/packages/prod/, config/packages/test/, etc.


1 Reply
danielqg93 Avatar
danielqg93 Avatar danielqg93 | posted 11 months ago

Can version 3.4 be upgraded to version 4.4, following the steps shown in this course?


Hey Daniel,

This course only covers upgrading from version 3 to 4, if you're interested in upgrading to version 4 to 5, you can what this other tutorial https://symfonycasts.com/screencast/symfony5-upgrade
Although, it's quite easy to upgrade minor Symfony versions https://symfony.com/doc/current/setup/upgrade_minor.html


MattWelander Avatar
MattWelander Avatar MattWelander | posted 1 year ago | edited

Hi! I didn't use annotations for my routes, I have a separate YML file for each of my bundles (from before, when code were supposed to be compartmentalized into bundles...). The video doesn't cover what to do about those, so I was wondering if I could have a quick hint? So I import my bundle-specific routes like this:


resource: "../src/AppBundle//Resources/config/routing/ExtraOpening/routing.yml"
prefix:   /`

and the contents of that file would be


resource: "@AppBundle/Resources/config/routing/extraopening/extraopening.yml"
prefix:   /extraopening


resource: "@AppBundle/Resources/config/routing/extraopening/price.yml"
prefix:   /price


resource: "@AppBundle/Resources/config/routing/extraopening/debitperiod.yml"
prefix:   /debitperiod`

And each of those would in turn contain the actual controller connections as such


path:     /
defaults: { _controller: "AppBundle:ExtraOpening/ExtraOpening:index" }
methods:  [GET]


path:     /new/{debitPeriod}
defaults: { _controller: "AppBundle:ExtraOpening/ExtraOpening:new", "debitPeriod" : null }
methods:  [GET, POST]


path:     /{id}/edit
defaults: { _controller: "AppBundle:ExtraOpening/ExtraOpening:edit" }
methods:  [GET, POST]`

Perhaps it'd be easier to move to annotation routing, but I'd like to get my app working at all before digging into that project of further refactoring things...


Hey @MattiasWelander!

I agree to get things working first! It doesn't matter much what you do with these routes. You could keep them all as is. Or, could move them all into config/routes (and some sub-directories) and then have them import each other like you do now. Basically, these files never really depended on the bundles: they were just files importing other files. We kept these in our app, then moved them to annotations over time.

For the actual routes themselves (which reference AppBundle:, if you want to remove AppBundle, then refactor these to use the class name of the controller - I think it would be _controller: "App\Controller\ExtraOpening\ExtraOpening::edit".

Let me know if that helps - or if I totally answered the wrong question :).


MattWelander Avatar
MattWelander Avatar MattWelander | weaverryan | posted 1 year ago | edited

I'm giving it a try. Although, with your backslashie format like this:


path:     /
defaults: { _controller: "App\AppBundle\Controller\Poslog\Position::index" }
methods:  GET`

I get this error:

<blockquote> The file "XXX" does not contain valid YAML: Found unknown escape character "\A" at line 5 (near "defaults: { _controller: "App\AppBundle\Controller\Poslog\Position::index" }")</blockquote>

Apparently, YAML doesn't like backslashes? =) It thinks I'm trying to escape a reserved character for some reason

MattWelander Avatar

OK found it, they are no longer supposed to be contained within quotations...

Cristian B. Avatar
Cristian B. Avatar Cristian B. | posted 1 year ago

I have been blocked for a few days with this error that I can not get out. Some idea tranks
You have requested a non-existent parameter "kernel.default_locale".


Hey there,

I believe you forgot to wrap with % the name of the paramter like this "%kernel.default_locale%"


Cat in space

"Houston: no signs of life"
Start the conversation!

What PHP libraries does this tutorial use?

// composer.json
    "require": {
        "php": "^7.1.3",
        "composer/package-versions-deprecated": "^1.11", // 1.11.99
        "doctrine/doctrine-bundle": "^1.6", // 1.8.1
        "doctrine/doctrine-cache-bundle": "^1.2", // 1.3.2
        "doctrine/doctrine-migrations-bundle": "^1.1", // v1.3.1
        "doctrine/orm": "^2.5", // v2.7.2
        "fzaninotto/faker": "^1.7", // v1.7.1
        "knplabs/knp-markdown-bundle": "^1.4", // 1.6.0
        "sensio/framework-extra-bundle": "^5.0", // v5.1.3
        "stof/doctrine-extensions-bundle": "dev-master", // dev-master
        "symfony/asset": "^4.0", // v4.0.1
        "symfony/console": "^4.0", // v4.0.1
        "symfony/flex": "^1.0", // v1.9.10
        "symfony/form": "^4.0", // v4.0.1
        "symfony/framework-bundle": "^4.0", // v4.0.1
        "symfony/lts": "^4@dev", // dev-master
        "symfony/maker-bundle": "^1.0", // v1.0.2
        "symfony/monolog-bundle": "^3.1", // v3.1.2
        "symfony/polyfill-apcu": "^1.0", // v1.6.0
        "symfony/profiler-pack": "^1.0", // v1.0.3
        "symfony/security-bundle": "^4.0", // v4.0.1
        "symfony/security-csrf": "^4.0",
        "symfony/swiftmailer-bundle": "^3.1", // v3.1.6
        "symfony/translation": "^4.0", // v4.0.1
        "symfony/twig-bundle": "^4.0", // v4.0.1
        "symfony/validator": "^4.0", // v4.0.1
        "symfony/web-server-bundle": "^4.0", // v4.0.1
        "symfony/yaml": "^4.0" // v4.0.1
    "require-dev": {
        "symfony/dotenv": "^4.0", // v4.0.1
        "symfony/phpunit-bridge": "^4.0", // v4.0.1
        "doctrine/doctrine-fixtures-bundle": "^3.0" // 3.0.2