This tutorial has a new version, check it out!

Parameters: The Variables of Configuration

Congrats! We've basically mastered Symfony configuration and environment system. But there's just one more trick it has up its sleeve.

Look closely inside config.yml file: one of the settings - default_locale - is set to a strange-looking value: %locale%. Huh.

... lines 1 - 10
... lines 12 - 24
default_locale: "%locale%"
... lines 26 - 79

Scrolling up a bit, there's another root key called parameters with locale: en:

... lines 1 - 5
# Put parameters here that don't need to change on each machine where the app is deployed
locale: en
... lines 10 - 79

You're witnessing the power of a special "variable system" inside config files. Here's how it works: in any of these configuration files, you can have a parameters key. And below that you can create variables like locale and set that to a value. Why is this cool? Because you can then reuse that value in any other file by saying %locale%.

Look under the doctrine key:

... lines 1 - 42
# Doctrine Configuration
... line 46
host: "%database_host%"
port: "%database_port%"
dbname: "%database_name%"
user: "%database_user%"
password: "%database_password%"
... lines 52 - 79

Hey, a bunch more, like %database_host% and %database_port%. These are set just like locale, but in a different file: parameters.yml:

# 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.
database_port: ~
database_name: symfony
database_user: root
database_password: ~
... lines 10 - 20

So that's it! If you add a new key under parameters, you can use that in any other file by saying %parameter_name%.

And just like services, we can get a list of every parameter available. How? Ah, our friend the console of course. Run:

./bin/console debug:container --parameters

Woah, that's a huge list you can take advantage of or even override. Most of these you won't care about, but don't forget this little cheatsheet is there for you.

Creating a new Parameter

We can leverage parameters to do something really cool with our cache setup.

In the prod environment, we use the file_system cache. In dev, we use array. We can improve this. Create a new parameter called cache_type and set that to file_system. Scroll down and set type to %cache_type%:

... lines 1 - 7
... line 9
cache_type: file_system
... lines 11 - 73
type: %cache_type%
... lines 78 - 80

Run over in the terminal to see if the parameter showed up:

./bin/console debug:container --parameters

It's right on top. Cool! Clear the cache in the prod environment so we can double-check everything is still working:

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

Ok good - now refresh using app.php. It's still loading fast - so we haven't broken anything... yet.

Here's where things get interesting. In config_dev.yml, it took a lot of code just to turn caching off. Parameters to the rescue! Copy the parameters key from config.yml and paste it into this file. But now, change its value to array and celebrate by completely removing the doctrine_cache key at the bottom:

... lines 1 - 3
cache_type: array
... lines 6 - 49

That's it! Refresh the browser in the dev environment: great it's still slow, which means it's working.

Leave a comment!

  • 2018-12-03 weaverryan

    Hey Cryptoblob!

    I DO totally understand what you mean - that's a very good detail to notice :). The great thing about the parameters is that the order does NOT matter. Symfony/Drupal loads ALL of the service and parameters in the system first, and THEN, later, it "resolves" those parameter (i.e. replacing the %foo% strings with their true value). So, order does not matter at all - you can reference a parameter WAY before it's actually loaded.


  • 2018-12-02 Cryptoblob

    So in 'config_dev.yml' it loads in the config.yml file then the parameters are set, how does config.yml read those parameters if they were set after it was imported? Don't parameters have to be set before they can be read? If you understand what i mean

  • 2017-05-11 Diego Aguiar

    Hey Ruben!

    That's correct, your app won't break if you dont add quotes to your parameters, but it's not recommended, the time will arrive and you won't be able to upgrade to Symfony 4 smoothly

    Have a nice day!

  • 2017-05-11 Ruben Dario

    "%cache_type%" and %cache_type% are both allowed for now right?

  • 2017-02-01 Brian Morris

    Comment Deleted: Error was unrelated to video content.

  • 2016-05-07 weaverryan

    You're right - how fast the world moves :). You now need to put quotes around the parameters. But, not quoting them will still be allowed until Symfony 4 (so you have a few years to change them).


  • 2016-05-06 Evlad

    Not quoting a scalar starting with the “%” indicator character is deprecated since Symfony 3.1