Infrastructure-Related Configuration¶

The default parameters.yml file follows this recommendation and defines the options related to the database and mail server infrastructure:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# app/config/parameters.yml
parameters:
    database_driver:   pdo_mysql
    database_host:     127.0.0.1
    database_port:     ~
    database_name:     symfony
    database_user:     root
    database_password: ~

    mailer_transport:  smtp
    mailer_host:       127.0.0.1
    mailer_user:       ~
    mailer_password:   ~

    # ...

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.

Application-Related Configuration¶

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.

1
2
3

# app/config/config.yml
parameters:
    homepage.number_of_items: 10

1
2
3
4
5
6
7
8
9

// src/AppBundle/Entity/Post.php
namespace AppBundle\Entity;

class Post
{
    const NUMBER_OF_ITEMS = 10;

    // ...
}

1
2
3

<p>
    Displaying the {{ constant('NUMBER_OF_ITEMS', post) }} most recent results.
</p>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

namespace AppBundle\Repository;

use Doctrine\ORM\EntityRepository;
use AppBundle\Entity\Post;

class PostRepository extends EntityRepository
{
    public function findLatest($limit = Post::NUMBER_OF_ITEMS)
    {
        // ...
    }
}

Parameter Naming¶

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.yml
parameters:
    # don't do this: 'dir' is too generic and it doesn't convey any meaning
    app.dir: '...'
    # do this: short but easy to understand names
    app.contents_dir: '...'
    # it's OK to use dots, underscores, dashes or nothing, but always
    # be consistent and use the same format for all the parameters
    app.dir.contents: '...'
    app.contents-dir: '...'

Semantic Configuration: Don't Do It¶

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.

Moving Sensitive Options Outside of Symfony Entirely¶

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.

Next: Organizing Your Business Logic