Login to bookmark this video
Buy Access to Course

Parameters: The Variables of Configuration

Share this awesome video!


Keep on Learning!

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

Login Subscribe

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.

79 lines | app/config/config.yml
// ... 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:

79 lines | app/config/config.yml
// ... lines 1 - 5
# Put parameters here that don't need to change on each machine where the app is deployed
# http://symfony.com/doc/current/best_practices/configuration.html#application-related-configuration
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:

79 lines | app/config/config.yml
// ... 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:

20 lines | app/config/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: ~
// ... 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%:

80 lines | app/config/config.yml
// ... 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:

49 lines | app/config/config_dev.yml
// ... 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.