Configuration

Configuration usually involves different application parts (such as infrastructure
and security credentials) and different environments (development, production).
That's why Symfony recommends that you split the application configuration into
three parts.

These options aren't defined inside the app/config/config.yml file because
they have nothing to do with the application's behavior. In other words, your
application doesn't care about the location of your database or the credentials
to access to it, as long as the database is correctly configured.

Define all your application's parameters in the
app/config/parameters.yml.dist file.

Since version 2.3, Symfony includes a configuration file called parameters.yml.dist,
which stores the canonical list of configuration parameters for the application.

Whenever a new configuration parameter is defined for the application, you
should also add it to this file and submit the changes to your version control
system. Then, whenever a developer updates the project or deploys it to a server,
Symfony will check if there is any difference between the canonical
parameters.yml.dist file and your local parameters.yml file. If there
is a difference, Symfony will ask you to provide a value for the new parameter
and it will add it to your local parameters.yml file.

The config.yml file contains the options used by the application to modify
its behavior, such as the sender of email notifications, or the enabled
feature toggles. Defining these values in parameters.yml file would
add an extra layer of configuration that's not needed because you don't need
or want these configuration values to change on each server.

The configuration options defined in the config.yml file usually vary from
one environment to another. That's
why Symfony already includes app/config/config_dev.yml and app/config/config_prod.yml
files so that you can override specific values for each environment.

One of the most common errors when defining application configuration is to
create new options for values that never change, such as the number of items for
paginated results.

Best Practice

Best Practice

Use constants to define configuration options that rarely change.

The traditional approach for defining configuration options has caused many
Symfony apps to include an option like the following, which would be used
to control the number of posts to display on the blog homepage:

1
2
3

# app/config/config.ymlparameters:homepage.num_items:10

If you've done something like this in the past, it's likely that you've in fact
never actually needed to change that value. Creating a configuration
option for a value that you are never going to configure just isn't necessary.
Our recommendation is to define these values as constants in your application.
You could, for example, define a NUM_ITEMS constant in the Post entity:

The main advantage of defining constants is that you can use their values
everywhere in your application. When using parameters, they are only available
from places with access to the Symfony container.

The name of your configuration parameters should be as short as possible and
should include a common prefix for the entire application.

Using app. as the prefix of your parameters is a common practice to avoid
collisions with Symfony and third-party bundles/libraries parameters. Then, use
just one or two words to describe the purpose of the parameter:

1
2
3
4
5
6
7
8
9
10

# app/config/config.ymlparameters:# don't do this: 'dir' is too generic and it doesn't convey any meaningapp.dir:'...'# do this: short but easy to understand namesapp.contents_dir:'...'# it's OK to use dots, underscores, dashes or nothing, but always# be consistent and use the same format for all the parametersapp.dir.contents:'...'app.contents-dir:'...'

As explained in How to Load Service Configuration inside a Bundle article, Symfony bundles
have two choices on how to handle configuration: normal service configuration
through the services.yml file and semantic configuration through a special
*Extension class.

Although semantic configuration is much more powerful and provides nice features
such as configuration validation, the amount of work needed to define that
configuration isn't worth it for bundles that aren't meant to be shared as
third-party bundles.

When dealing with sensitive options, like database credentials, we also recommend
that you store them outside the Symfony project and make them available
through environment variables. Learn how to do it in the following article:
How to Set external Parameters in the Service Container.