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 SubscribeWhen you deploy to production, you're supposed to set all these environment variables correctly. If you look back at index.php:
| ... lines 1 - 9 | |
| // The check is to ensure we don't use .env in production | |
| if (!isset($_SERVER['APP_ENV'])) { | |
| if (!class_exists(Dotenv::class)) { | |
| throw new \RuntimeException('APP_ENV environment variable is not defined. You need to define environment variables for configuration or add "symfony/dotenv" as a Composer dependency to load variables from a .env file.'); | |
| } | |
| (new Dotenv())->load(__DIR__.'/../.env'); | |
| } | |
| ... lines 17 - 40 |
If the APP_ENV environment variable is set already, it knows to skip loading the .env file.
Tip
If you start a new project today, you won't see this APP_ENV logic. It's
been moved to a config/bootstrap.php file.
In reality... in a lot of server environments, setting environment variables can be a pain. You can do it in your Apache virtual host or in PHP-FPM. Oh, and you'll need to make sure it's set at the command line too, so you can run bin/console.
If you use a Platform-as-a-Service like Platform.sh or Heroku, then setting environment variables is super easy! Lucky you!
But if setting environment variable is tough in your situation, well, you could still use the .env file. I mean if we deployed right now, we could create this file, put all the real values inside, and Symfony would use that! Well, if you're planning on doing this, make sure to move the dotenv library from the require-dev section of your composer.json to require by removing and re-adding it:
composer remove symfony/dotenvcomposer require symfony/dotenvThe reason that using .env isn't recommended is mostly because the logic to parse this file isn't optimized: it's not meant for production! So, you'll lose a small amount of performance - probably just a couple of milliseconds, but you can profile it to be sure.
Tip
The performance cost of .env has been shown to be low. It is ok to use
a .env file in production if that's the most convenient way for you to set
environment variables.
But... there is one other limitation of environment variables that affects everyone: environment variables are always strings! But, what if you need an environment variable that's set to true or false? Well... when you read it with the special syntax, "false" will literally be the string "false". Boo!
Don't worry! Environment variables have one more trick! You can cast values by prefixing the name with, for example, string::
| nexy_slack: | |
| endpoint: '%env(string:SLACK_WEBHOOK_ENDPOINT)%' |
Well, this is already a string, but you get the idea!
To show some better examples, Google for Symfony Advanced Environment Variables to find a blog post about this feature. Cooooool. This DATABASE_PORT should be an int so... we cast it! You can also use bool or float.
This is great... but then, the Symfony devs went crazy. First, as you'll see in this blog post, you can set default environment variable values under the parameters key. For example, by adding an env(SECRET_FILE) parameter, you've just defined a default SECRET_FILE environment value. If a real SECRET_FILE environment variable were set, it would override this.
More importantly, there are 5 other prefixes you can use for special processing:
First, resolve:
%foo% things - if you have them inside your environment variable;Second, you can use file: to return the contents of a file,
Third, base64: will base64_decode a value: that's handy if you have a value
base64_encode it to make it easier to set as an environment variable;Fourth, constant: allows you to read PHP constants;
And finally, json: will, yep,
json_decode() a string.And, ready for the coolest part? You can chain these: like, open a file, and then decode its JSON:
app.secrets: '%env(json:file:SECRETS_FILE)%'Actually, sorry, there's more! You can even create your own, custom prefix - like blackhole: and write your own custom processing logic.
Ok, I'll shut up already about environment variables! They're cool, yadda, yadda, yadda.
Let's move on to a super fun, super unknown "extra" with autowiring.
// composer.json
{
"require": {
"php": "^7.1.3",
"ext-iconv": "*",
"knplabs/knp-markdown-bundle": "^1.7", // 1.7.0
"nexylan/slack-bundle": "^2.0,<2.2.0", // v2.0.0
"php-http/guzzle6-adapter": "^1.1", // v1.1.1
"sensio/framework-extra-bundle": "^5.1", // v5.1.4
"symfony/asset": "^4.0", // v4.0.4
"symfony/console": "^4.0", // v4.0.14
"symfony/flex": "^1.0", // v1.9.10
"symfony/framework-bundle": "^4.0", // v4.0.14
"symfony/lts": "^4@dev", // dev-master
"symfony/twig-bundle": "^4.0", // v4.0.4
"symfony/web-server-bundle": "^4.0", // v4.0.4
"symfony/yaml": "^4.0" // v4.0.14
},
"require-dev": {
"easycorp/easy-log-handler": "^1.0.2", // v1.0.4
"symfony/debug-bundle": "^3.3|^4.0", // v4.0.4
"symfony/dotenv": "^4.0", // v4.0.14
"symfony/maker-bundle": "^1.0", // v1.0.2
"symfony/monolog-bundle": "^3.0", // v3.1.2
"symfony/phpunit-bridge": "^3.3|^4.0", // v4.0.4
"symfony/profiler-pack": "^1.0", // v1.0.3
"symfony/var-dumper": "^3.3|^4.0" // v4.0.4
}
}