Configuring Symfony (and environment)


Symfony program is composed of a set of bundles "responsible for presenting all functions and possibilities". Each bundle can be customized through configuration files in YAML, XML or PHP format. The default main configuration file is in the app/config/ directory, which can be config.yml, config.xml or config.php, depending on your preference:

YAML:# app/config/config.ymlimports:
    - { resource: parameters.yml }
    - { resource: security.yml }framework:
    secret:          "%secret%"
    router:          { resource: "%kernel.root_dir%/config/routing.yml" }
    # ... # Twig Configurationtwig:
    debug:            "%kernel.debug%"
    strict_variables: "%kernel.debug%" # ...
XML:<!-- app/config/config.xml --><?xml version="1.0" encoding="UTF-8" ?><container xmlns="http://symfony.com/schema/dic/services"    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    xmlns:framework="http://symfony.com/schema/dic/symfony"    xmlns:twig="http://symfony.com/schema/dic/twig"    xsi:schemaLocation="http://symfony.com/schema/dic/services        http://symfony.com/schema/dic/services/services-1.0.xsd        http://symfony.com/schema/dic/symfony        http://symfony.com/schema/dic/symfony/symfony-1.0.xsd        http://symfony.com/schema/dic/twig        http://symfony.com/schema/dic/twig/twig-1.0.xsd">     <imports>
        <import resource="parameters.yml" />
        <import resource="security.yml" />
    </imports>     <framework:config secret="%secret%">
        <framework:router resource="%kernel.root_dir%/config/routing.xml" />
        <!-- ... -->
    </framework:config>     <!-- Twig Configuration -->
    <twig:config debug="%kernel.debug%" strict-variables="%kernel.debug%" />     <!-- ... --></container>
PHP:// app/config/config.php$this->import('parameters.yml');$this->import('security.yml'); $container->loadFromExtension('framework', array(
    'secret' => '%secret%',
    'router' => array(
        'resource' => '%kernel.root_dir%/config/routing.php',
    ),
    // ...)); // Twig Configuration$container->loadFromExtension('twig', array(
    'debug'            => '%kernel.debug%',
    'strict_variables' => '%kernel.debug%',)); // ...

In the environment section below, you will specify how files in each format are loaded.

Each root node, such as framework or twig, defines the configuration information of the corresponding bundle. For example, the framework key defines the configuration information of the FrameworkBundle used in the Symfony core, including routing configuration, template configuration, and other kernel configurations.

Now, there is no need to worry about specific configuration options under each root node. The configuration file comes preloaded with some meaningful default configurations. As you study and explore each part of Symfony in detail, you will understand the meaning of specific configuration options for each feature.

Configuration file

All configuration information routines in this chapter will be displayed in three formats (YAML, XML and PHP). Each has its own pros and cons, it’s up to you to choose:

  • YAML: simple, clear, and highly readable. (Learn more through YAML components)

  • XML: Sometimes more powerful than YAML, and supports IDE code auto-completion.

  • PHP: Very powerful, but less readable than standard configuration formats.

Stripping of default configuration information ¶

You can strip out the default configuration information in the YAML format of the specified bundle through the command line config:dump-referenceCommand. The following is an example of stripping the default configuration information of the FrameworkBundle:

$  php bin/console config:dump-reference FrameworkBundle

Extended private pseudonyms (root nodes in the configuration file) can also be used:

$  php bin/console config:dump-reference framework

Please refer to the cookbook article How to load the configuration information of the service in a bundle to obtain the relevant content of "adding configuration information to your own bundle".

Environment ¶

A set of programs can run in multiple environments. Different environments share the same PHP code (except for the front-end controller), but use different configuration files. For example, in the dev environment, warning and error level logs will be recorded, but in the prod environment, only error information will be recorded. In the dev environment, some files are rebuilt on every request (for the convenience of developers), but are cached when they arrive in the prod environment. All environments coexist on the same machine and execute the same programs.

Generally speaking, a Symfony project has three environments (dev, test and prod), but creating a new environment is simple. You can see how your program performs in different environments by switching front-end controllers in the browser. To see the dev environment, visit the development version of the program front controller:

localhost/app_dev.php/random/10

If you want to see the execution of the program in the production environment, change to the prod version Front-end controller:

localhost/app_dev.php/random/10

prod The environment is optimized for speed, and configuration information, routing and Twig templates are compiled into native PHP classes and cached. When you need to see changes in the prod environment, you need to clear these cache files and rebuild them:

$  php bin/console cache:clear --env=prod --no-debug

If you open web/app. php file, you can see that the prod environment is explicitly configured:

$kernel = new AppKernel('prod', false);

You can create a new front-end controller for a new environment, copy the above line of code and replace prod with another value.

test environment is used for automatic testing and cannot be accessed directly through the browser. Refer to the Testing chapter in the "Framework Guide" to learn more.

When using the server:run command to start the server, localhost:8000/ is using your program dev front-end controller in .

Environment configuration

AppKernel class is responsible for loading the configuration file you specify:

// app/AppKernel.phppublic function registerContainerConfiguration(LoaderInterface $loader){
    $loader->load(
        __DIR__.'/config/config_'.$this->getEnvironment().'.yml'
    );}

You already know.yml# The ## suffix can be changed to .xml or .php if you are willing to use XML or PHP to complete the configuration. Note that each environment loads its own configuration file. Take a look at the configuration file in the dev environment:

YAML:# app/config/config_dev.ymlimports:
    - { resource: config.yml }framework:
    router:   { resource: "%kernel.root_dir%/config/routing_dev.yml" }
    profiler: { only_exceptions: false } # ...
XML:<!-- app/config/config_dev.xml --><?xml version="1.0" encoding="UTF-8" ?><container xmlns="http://symfony.com/schema/dic/services"    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    xmlns:framework="http://symfony.com/schema/dic/symfony"    xsi:schemaLocation="http://symfony.com/schema/dic/services        http://symfony.com/schema/dic/services/services-1.0.xsd        http://symfony.com/schema/dic/symfony        http://symfony.com/schema/dic/symfony/symfony-1.0.xsd">     <imports>
        <import resource="config.xml" />
    </imports>     <framework:config>
        <framework:router resource="%kernel.root_dir%/config/routing_dev.xml" />
        <framework:profiler only-exceptions="false" />
    </framework:config>     <!-- ... --></container>
PHP:// app/config/config_dev.php$loader->import('config.php'); 
$container->loadFromExtension('framework', array(    'router' => array(        'resource' => '%kernel.root_dir%/config/routing_dev.php',    ),  
  'profiler' => array('only-exceptions' => false),)); 
// ...

import root key, similar to PHP’s include statement, ensuring the main force The configuration file (config.yml) is loaded first. The remainder of this file is used to adjust the default configuration, enhance the logging function, and other settings that are beneficial to the development environment.

Whether it is a

prod or a test environment, the same model is followed: each environment first imports the basic configuration file, and then adjusts its configured values ​​​​to suit each environment. specific environment. But this is just a convention, allowing you to reuse most of the content in the configuration file and customize local configurations for different environments.