Flag of Ukraine
SymfonyCasts stands united with the people of Ukraine
This tutorial has a new version, check it out!

parameters.yml & %kernel.root_dir%

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 $12.00

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

Login Subscribe

There are some really special parameters I need to tell you about. In this big list that debug:container gave us, find the group that starts with kernel.. You won't find these defined anywhere: they're baked right into Symfony and are some of the most useful parameters.

Notice kernel.debug - whether or not we're in debug mode - and kernel.environment. But the best ones to know about are kernel.cache_dir - where Symfony stores its cache - and kernel.root_dir - which is actually the app/ directory where the AppKernel class lives. Anytime you need to reference a path in your project, use kernel.root_dir and build the path from it.

Earlier, just to show off, we configured the DoctrineCacheBundle to store the markdown cache in /tmp/doctrine_cache:

... lines 1 - 73
type: %cache_type%
directory: /tmp/doctrine_cache

Referencing absolute paths is a little weird: why not just store this stuff in Symfony's cache dir? Ok, ok, the bundle actually did this by default, before we started messing with the configuration. But we're learning people! So let's use one of these new kernel. parameters to fix this.

How? Just change the directory to %kernel.cache_dir% then /markdown_cache:

... lines 1 - 73
type: %cache_type%
directory: %kernel.cache_dir%/markdown_cache

It's totally ok to mix the parameters inside larger strings.

Clear the cache in the prod environment:

./bin/console cache:clear --env=prod

And switch to the prod tab to try this all out. Now, in the terminal:

ls var/cache/prod/

And there's our cached markdown.

Why is parameters.yml Special?

I have a question: if config.yml imports parameters.yml, then why bother having this file at all? Why not just put all the parameters at the top of config.yml?

Here's why: parameters.yml holds any configuration that will be different from one machine where the code is deployed to another.

For example, your database password is most likely not the same as my database password and hopefully not the same as the production database password. But if we put that password right in the middle of config.yml, that would be a nightmare! In that scenario I would probably commit my password to git and then you would have to change it to your password but then try to not commit that change. Gross.

Instead of that confusing mess of seaweed, we use parameters in config.yml. This allows us to isolate all the machine-specific configuration to parameters.yml. And here's the final key: parameters.yml is not committed to the repository - you can see there's an entry for it in .gitignore:

17 lines .gitignore
... lines 2 - 17

Of course, if I just cloned this project, and I won't have a parameters.yml file: I have to create it manually. Actually, this is the exact reason for this other file: parameters.yml.dist:

# This file is a "template" of what your parameters.yml file should look like
# Set parameters here that may be different on each deployment target of the app, e.g. development, staging, production.
# http://symfony.com/doc/current/best_practices/configuration.html#infrastructure-related-configuration
database_port: ~
database_name: symfony
database_user: root
database_password: ~
# You should uncomment this if you want use pdo_sqlite
# database_path: "%kernel.root_dir%/data.db3"
mailer_transport: smtp
mailer_user: ~
mailer_password: ~
# A secret key that's used to generate certain security-related tokens
secret: ThisTokenIsNotSoSecretChangeIt

This is not read by Symfony, it's just a template of all of the parameters this project needs. If you add or remove things from the parameters.yml, be sure to add or remove them from parameters.yml.dist. You do commit this file to git.


Due to a post-install command in your composer.json, after running composer install, Symfony will read parameters.yml.dist and ask you to fill in any values that are missing from parameters.yml.

Let's put this into practice. What if our app does not need to send emails. That means we don't need SwiftmailerBundle. And that means we don't need any of these mailer_ parameters: these are used in config.yml under swiftmailer. We could keep this stuff, but why not get rid of the extra stuff?

In AppKernel, start by removing the SwiftmailerBundle line completely:

... lines 1 - 5
class AppKernel extends Kernel
public function registerBundles()
$bundles = array(
... lines 11 - 14
//new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(),
... lines 16 - 22
... lines 24 - 32
... lines 34 - 53

Because that's gone, you'll need to remove the entire swiftmailer section in config.yml. And finally, we don't need the mailer_ parameters anymore, so delete them from parameters.yml and parameters.yml.dist so other devs won't worry about adding them. Awesome!

Head over to the terminal and run:

./bin/console debug:container mailer

Cool - the app still runs, but there are no services that match mailer anymore.

Leave a comment!

Login or Register to join the conversation
Tonislav A. Avatar
Tonislav A. Avatar Tonislav A. | posted 5 years ago

Hey guys, I have this issue. I deleted the swiftmailer bundle from AppKernel. Removed it from all config files and dist file, but still when I run debug:container mailer I receive "mailer is an alias of swiftmailer.mailer.default". Then if I try to run the same command but with swiftmailer as argument, I get the list with matching services. Any ideas? Thanks. I'm using Symfony 3.1.4


Hey Tonislav A. ,

Hm, could you make sure it's not due to some cache? Please, clear the cache and try again. Btw, what do you use instead of Swiftmailer? Or you don't send any emails in your application at all?


Tonislav A. Avatar
Tonislav A. Avatar Tonislav A. | Victor | posted 5 years ago | edited

Hi victor
I am strictly following the tutorial and the application does not send any emails. I've cleared the cache before posting. I moved along with the course as this was not needed to progress. I try the same now (after my PC had been rebooted) and it works - there's no swiftmailer service. I reversed back my actions and added the swiftmailer bundle and configuration and it is ok again. Idk what happened. Reminds me of the IT Crowd "Hello, IT, have you tried turning it off and on again?" xD



Hey Tonislav A.,

Haha, well, clearing the cache is almost always the same as turn it off and on :D
OK, glad it work well now!

P.S. I suppose you're on Windows? Just curious about it. Sometimes weird things happen there :)



Can we add custom params to `kernel`, for example `kernel.my_param`?
Is there any valid reason to do so?


Hey boykodev

A kernel parameter is just like any other parameter but those are prefixed with the word "kernel" only for organization reasons, so, in theory you can define a parameter named "kernel.your-param" but it would confuse anyone who is reading your code.

If you are curious, here you can see how kernel parameters are being set: https://github.com/symfony/...


1 Reply
Default user avatar
Default user avatar Richie Hamburg | posted 5 years ago

So what is the recommended way to split out parameters for dev vs prod? simply create a parameters_dev.yml and import that into config_dev.yml after the import of config.yml?


Hey Richie,

No, you don't have to create a separate "parameters" files for each environment - you already have config.yml, config_dev.yml and config_test.yml files, which already are imported out of the box, so just put any environment-related parameters inside of those files under the `parameters:` key. BUT if you have server-specific parameters, you need to put them into the special `parameters.yml` file (and also don't forget to add a parameter key with dummy value in your parameters.yml.dist file), i.e. those parameters which can be different on different servers: production, development, CI, etc. I think this article may be interesting for you: http://symfony.com/doc/curr...



Great tuto, but I have a little question since sf 3.1 it is drepreacated to use % indicator in config.yml.
So how can we do?
Thanks again for your great job.



Hey Greg,

Symfony deprecates using % symbol without quotes, but of course you still can use parameters in YAML config files. So just wrap all your parameters which starts and ends with % with a single or double quotes and that's it! It's easy fix!

P.S. Thanks for your kind words.



Ok effectively it is very simple ;)
Thanks for your answer.


You're welcome! BTW, fixing deprecations beforehand is a good idea, keep it up! )

Cat in space

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

What PHP libraries does this tutorial use?

// composer.json
    "require": {
        "php": ">=5.5.9",
        "symfony/symfony": "3.1.*", // v3.1.4
        "doctrine/orm": "^2.5", // v2.7.2
        "doctrine/doctrine-bundle": "^1.6", // 1.6.4
        "doctrine/doctrine-cache-bundle": "^1.2", // 1.3.0
        "symfony/swiftmailer-bundle": "^2.3", // v2.3.11
        "symfony/monolog-bundle": "^2.8", // 2.11.1
        "symfony/polyfill-apcu": "^1.0", // v1.2.0
        "sensio/distribution-bundle": "^5.0", // v5.0.22
        "sensio/framework-extra-bundle": "^3.0.2", // v3.0.16
        "incenteev/composer-parameter-handler": "^2.0", // v2.1.2
        "composer/package-versions-deprecated": "^1.11", // 1.11.99
        "knplabs/knp-markdown-bundle": "^1.4" // 1.4.2
    "require-dev": {
        "sensio/generator-bundle": "^3.0", // v3.0.7
        "symfony/phpunit-bridge": "^3.0" // v3.1.3