Parameters: The Variables of Configuration
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.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeCongrats! 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 | |
| framework: | |
| // ... 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 | |
| # http://symfony.com/doc/current/best_practices/configuration.html#application-related-configuration | |
| parameters: | |
| 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 | |
| doctrine: | |
| dbal: | |
| // ... 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. | |
| # http://symfony.com/doc/current/best_practices/configuration.html#infrastructure-related-configuration | |
| parameters: | |
| database_host: 127.0.0.1 | |
| 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 | |
| parameters: | |
| // ... line 9 | |
| cache_type: file_system | |
| // ... lines 11 - 73 | |
| doctrine_cache: | |
| providers: | |
| my_markdown_cache: | |
| 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 | |
| parameters: | |
| 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.
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