Configurations and Environments
When building an application, it's helpful to have a configuration system that allows you to specify settings to be used throughout your application.
For insight into the kind of configurations an app uses, skim through the files in the
/config folder in your Laravel app. Note how each file contains an array of configuration values.
These values are accessible throughout your application using Laravel's
# *all* the mail related configs dump(config('mail')); # One specific config from the mail configs dump(config('mail.host'));
Many of the configs that ship with Laravel are used by Laravel when your application is run. For example, Laravel's Mail functionality will refer/use the configs when sending email from your application.
You can also utilize the configs when writing your application code (we'll see examples of this in upcoming material).
Define your own configs
You can add new configs for your application as needed. For example, in the
mail.php config array, you might define what the support address is for your site:
# config/mail.php return [ [...] 'supportEmail' => 'email@example.com', [...] ];
After adding a new config, run
php artisan config:clear to ensure your application recognizes the change.
Now, whenever you want to display this address, you can pull it from the config:
Questions? Email us at <?=config('mail.supportEmail')?>
Using configs in this way gives you consistency (ensures you're using the same address everywhere) and flexibility (if your address changes, you only have to change it in one spot).
In addition to adding configurations to existing config files, you can also create entirely new config files as needed.
Building a web application often entails running that application in different environments that have different configuration needs.
For example, when running your application locally on your computer, you would define this as a local environment and it would have specific configuration needs, for example:
- Turn on all error reporting
- Connect to a local, development database
- Route outgoing mail through a service like MailTrap.io
On the flip side, you also have your application running on a live/production server, which you would define as a production environment that may have these specific configuration needs:
- Turn off all error reporting to the page
- Connect to a live database
- Send outgoing mail using a service like MailGun
local and production are the two most common environments, but you may have other ones like staging, testing, or more.
Additionally, each developer working on your project might also have their own local environment configurations.
Working with environments
Laravel utilizes the DotEnv PHP library. Here's how it works:
There are global configurations defined in
config/ and then each specific environment can overwrite those configurations on a as-needed basis via a custom
Let's look at an example— your debugging configurations. When debugging is on, exceptions and errors are displayed in the browser. This is useful in local environments.
When debugging is off, exceptions and errors are suppressed and the user is shown a generic error page. This is useful in production environments.
If you open
/config/app.php, you'll see where the
debug config is set:
/* |-------------------------------------------------------------------------- | Application Debug Mode |-------------------------------------------------------------------------- | | When your application is in debug mode, detailed error messages with | stack traces will be shown on every error that occurs within your | application. If disabled, a simple generic error page is shown. | */ 'debug' => env('APP_DEBUG', false),
Here we see the env helper function which takes two parameters:
- Environment-specific variable you're looking for (in this case,
- What default value to use if that variable does not exist (in this case,
Environment-specific variables are set in
.env files at the root of your project. This file contains a series of key value pairs like so:
APP_ENV=local APP_KEY=base64:4/cxKRroiQ62kyW8zJgVDeJ2jbZaz1heYSrXWLV3LRM= APP_DEBUG=true APP_URL=http://foobooks.loc [...]
Convention calls for each key to be written using the same style PHP constants use—
A constant is an identifier (name) for a simple value. As the name suggests, that value cannot change during the execution of the script [...]. A constant is case-sensitive by default. By convention, constant identifiers are always uppercase. -ref
Notice the third variable,
APP_DEBUG, is set to
And so, revisiting this line in your app config...
'debug' => env('APP_DEBUG', false),
...we can conclude that when the application is running in the local environment, app debugging will be on (
APP_DEBUG was not defined in the .env file where the application is running, it would default to
.env file is not tracked via git, it's possible that
APP_DEBUG can be set to different values in different contexts (e.g. local v.s production).
Not all configurations use the env helper method, for example in
/config/session.php the config
encrypt is “hardcoded” to
'encrypt' => false,
This makes sense, because there's typically not a reason you would need to change this configuration in different environments.
However, if there is some reason you need to do just that, just edit the line to look like this:
'encrypt' => env('SESSION_ENCRYPT', false),
encrypt it will default to
false but you have the option of overwriting it by setting
SESSION_ENCRYPT in an environment's
Applying the above information, you should open the
.env files on your production server for each application you're building to make sure appropriate values are set. (I did show this process in Week 5 when we first deployed a Laravel application to production, but it wouldn't hurt to double check the settings now).
APP_ENV should be set to
APP_DEBUG should be set to
APP_URL should also match whatever address you're using to access your work on production.
Here's an example taken from foobook's production
APP_ENV=production APP_KEY=[your-unique-key-will-be-here] APP_DEBUG=false APP_URL=http://foobooks.dwa15.me
In addition to examining your configuration files, you can see what specific configs are set to using the the global
config helper function.
dump(config('mail.driver')); # Dump *all* of the mail configs dump(config('mail'));
What's my current environment?
You can find out the environment your application is currently running in using the Artisan
$ php artisan env Current application environment: local
Or you can output the environment using the App facade's