diff --git a/_build/redirection_map b/_build/redirection_map
index 7c4a5188b46..b932501df3e 100644
--- a/_build/redirection_map
+++ b/_build/redirection_map
@@ -428,3 +428,4 @@
/profiler/storage /profiler
/setup/composer /setup
/security/security_checker /setup
+/service_container/parameters /configuration
diff --git a/configuration.rst b/configuration.rst
index b2d9decda7d..6ff2701438e 100644
--- a/configuration.rst
+++ b/configuration.rst
@@ -4,6 +4,9 @@
Configuring Symfony
===================
+Configuration Files
+-------------------
+
Symfony applications are configured with the files stored in the ``config/``
directory, which has this default structure:
@@ -50,7 +53,7 @@ to change these files after package installation
``config:dump-reference`` command.
Configuration Formats
----------------------
+~~~~~~~~~~~~~~~~~~~~~
Unlike other frameworks, Symfony doesn't impose you a specific format to
configure your applications. Symfony lets you choose between YAML, XML and PHP
@@ -64,18 +67,18 @@ there's not even any performance difference between them.
YAML is used by default when installing packages because it's concise and very
readable. These are the main advantages and disadvantages of each format:
-* :doc:`YAML `: simple, clean and readable, but
- requires using a dedicated parser;
-* *XML*: supports IDE autocompletion/validation and is parsed natively by PHP,
- but sometimes it generates too verbose configuration;
-* *PHP*: very powerful and it allows to create dynamic configuration, but the
+* **YAML**: simple, clean and readable, but not all IDEs support autocompletion
+ and validation for it. :doc:`Learn the YAML syntax `;
+* **XML**:autocompleted/validated by most IDEs and is parsed natively by PHP,
+ but sometimes it generates too verbose configuration. `Learn the XML syntax`_;
+* **PHP**: very powerful and it allows to create dynamic configuration, but the
resulting configuration is less readable than the other formats.
Importing Configuration Files
------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Symfony loads configuration files using the :doc:`Config component
-`, which provides advanced features such as importing
+`, which provides advanced features such as importing other
configuration files, even if they use a different format:
.. configuration-block::
@@ -126,15 +129,9 @@ configuration files, even if they use a different format:
// ...
-.. tip::
-
- If you use any other configuration format, you have to define your own loader
- class extending it from :class:`Symfony\\Component\\DependencyInjection\\Loader\\FileLoader`.
- In addition, you can define your own services to load configurations from
- databases or web services.
-
.. _config-parameter-intro:
.. _config-parameters-yml:
+.. _configuration-parameters:
Configuration Parameters
------------------------
@@ -152,9 +149,21 @@ reusable configuration value. By convention, parameters are defined under the
parameters:
# the parameter name is an arbitrary string (the 'app.' prefix is recommended
# to better differentiate your parameters from Symfony parameters).
- # the parameter value can be any valid scalar (numbers, strings, booleans, arrays)
app.admin_email: 'something@example.com'
+ # boolean parameters
+ app.enable_v2_protocol: true
+
+ # array/collection parameters
+ app.supported_locales: ['en', 'es', 'fr']
+
+ # binary content parameters (encode the contents with base64_encode())
+ app.some_parameter: !!binary VGhpcyBpcyBhIEJlbGwgY2hhciAH
+
+ # PHP constants as parameter values
+ app.some_constant: !php/const GLOBAL_CONSTANT
+ app.another_constant: !php/const App\Entity\BlogPost::MAX_ITEMS
+
# ...
.. code-block:: xml
@@ -171,9 +180,27 @@ reusable configuration value. By convention, parameters are defined under the
+ to better differentiate your parameters from Symfony parameters). -->
something@example.com
+
+
+ true
+
+ true
+
+
+
+ en
+ es
+ fr
+
+
+
+ VGhpcyBpcyBhIEJlbGwgY2hhciAH
+
+
+ GLOBAL_CONSTANT
+ App\Entity\BlogPost::MAX_ITEMS
@@ -184,10 +211,37 @@ reusable configuration value. By convention, parameters are defined under the
// config/services.php
// the parameter name is an arbitrary string (the 'app.' prefix is recommended
// to better differentiate your parameters from Symfony parameters).
- // the parameter value can be any valid scalar (numbers, strings, booleans, arrays)
$container->setParameter('app.admin_email', 'something@example.com');
+
+ // boolean parameters
+ $container->setParameter('app.enable_v2_protocol', true);
+
+ // array/collection parameters
+ $container->setParameter('app.supported_locales', ['en', 'es', 'fr']);
+
+ // binary content parameters (use the PHP escape sequences)
+ $container->setParameter('app.some_parameter', 'This is a Bell char: \x07');
+
+ // PHP constants as parameter values
+ use App\Entity\BlogPost;
+
+ $container->setParameter('app.some_constant', GLOBAL_CONSTANT);
+ $container->setParameter('app.another_constant', BlogPost::MAX_ITEMS);
+
// ...
+.. caution::
+
+ When using XML configuration, the values between ```` tags are
+ not trimmed. This means that the value of the following parameter will be
+ ``'\n something@example.com\n'``:
+
+ .. code-block:: xml
+
+
+ something@example.com
+
+
Once defined, you can reference this parameter value from any other
configuration file using a special syntax: wrap the parameter name in two ``%``
(e.g. ``%app.admin_email%``):
@@ -231,6 +285,33 @@ configuration file using a special syntax: wrap the parameter name in two ``%``
// ...
]);
+.. note::
+
+ If some parameter value includes the ``%`` character, you need to escape it
+ by adding another ``%`` so Symfony doesn't consider it a reference to a
+ parameter name:
+
+ .. configuration-block::
+
+ .. code-block:: yaml
+
+ # config/services.yaml
+ parameters:
+ # Parsed as 'https://symfony.com/?foo=%s&bar=%d'
+ url_pattern: 'https://symfony.com/?foo=%%s&bar=%%d'
+
+ .. code-block:: xml
+
+
+
+ http://symfony.com/?foo=%%s&bar=%%d
+
+
+ .. code-block:: php
+
+ // config/services.php
+ $container->setParameter('url_pattern', 'http://symfony.com/?foo=%%s&bar=%%d');
+
.. include:: /components/dependency_injection/_imports-parameters-note.rst.inc
Configuration parameters are very common in Symfony applications. Some packages
@@ -239,8 +320,8 @@ a new ``locale`` parameter is added to the ``config/services.yaml`` file).
.. seealso::
- Read the :ref:`service parameters ` article to
- learn about how to use these configuration parameters in services and controllers.
+ Read the `Accessing Configuration Values`_ section of this article to learn
+ about how to use these configuration parameters in services and controllers.
.. index::
single: Environments; Introduction
@@ -497,38 +578,6 @@ In addition to your own env vars, this ``.env`` file also contains the env vars
defined by the third-party packages installed in your application (they are
added automatically by :doc:`Symfony Flex ` when installing packages).
-Managing Multiple .env Files
-............................
-
-The ``.env`` file defines the default values for all env vars. However, it's
-common to override some of those values depending on the environment (e.g. to
-use a different database for tests) or depending on the machine (e.g. to use a
-different OAuth token in your local machine while developing).
-
-That's why you can define multiple ``.env`` files which override the default env
-vars. These are the files in priority order (an env var found in one file
-overrides the same env var for all the files below):
-
-* ``.env..local`` (e.g. ``.env.test.local``): defines/overrides
- env vars only for some environment and only in your local machine;
-* ``.env.`` (e.g. ``.env.test``): defines/overrides env vars for
- some environment and for all machines;
-* ``.env.local``: defines/overrides env vars for all environments but only in
- your local machine;
-* ``.env``: defines the default value of env vars.
-
-The ``.env`` and ``.env.`` files should be committed to the shared
-repository because they are the same for all developers. However, the
-``.env.local`` and ``.env..local`` and files **should not be
-committed** because only you will use them. In fact, the ``.gitignore`` file
-that comes with Symfony prevents them from being committed.
-
-.. caution::
-
- Applications created before November 2018 had a slightly different system,
- involving a ``.env.dist`` file. For information about upgrading, see:
- :doc:`configuration/dot-env-changes`.
-
.. _configuration-env-var-in-prod:
Configuring Environment Variables in Production
@@ -552,6 +601,17 @@ will load the parsed file instead of parsing the ``.env`` files again:
Update your deployment tools/workflow to run the ``dump-env`` command after
each deploy to improve the application performance.
+.. _configuration-env-var-web-server:
+
+Creating ``.env`` files is the easiest way of using env vars in Symfony
+applications. However, you can also configure real env vars in your servers and
+operating systems.
+
+.. tip::
+
+ SymfonyCloud, the cloud service optimized for Symfony applications, defines
+ some `utilities to manage env vars`_ in production.
+
.. caution::
Beware that dumping the contents of the ``$_SERVER`` and ``$_ENV`` variables
@@ -563,31 +623,194 @@ will load the parsed file instead of parsing the ``.env`` files again:
:doc:`Symfony profiler `. In practice this shouldn't be a
problem because the web profiler must **never** be enabled in production.
-Defining Environment Variables in the Web Server
-................................................
+Managing Multiple .env Files
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ``.env`` file defines the default values for all env vars. However, it's
+common to override some of those values depending on the environment (e.g. to
+use a different database for tests) or depending on the machine (e.g. to use a
+different OAuth token on your local machine while developing).
+
+That's why you can define multiple ``.env`` files to override env vars. The
+following list shows the files loaded in all environments. The ``.env`` file is
+the only mandatory file and each file content overrides the previous one:
+
+* ``.env``: defines the default values of the env vars needed by the application;
+* ``.env.local``: defines machine-specific overrides for env vars on all
+ environments. This file is not committed to the repository, so these overrides
+ only apply to the machine which contains the file (your local computer,
+ production server, etc.);
+* ``.env.`` (e.g. ``.env.test``): overrides env vars only for some
+ environment but for all machines;
+* ``.env..local`` (e.g. ``.env.test.local``): defines machine-specific
+ env vars overrides only for some environment. It's similar to ``.env.local``,
+ but the overrides only apply to some particular environment.
+
+.. note::
+
+ The real environment variables defined in the server always win over the
+ env vars created by the ``.env`` files.
+
+The ``.env`` and ``.env.`` files should be committed to the shared
+repository because they are the same for all developers and machines. However,
+the env files ending in ``.local`` (``.env.local`` and ``.env..local``)
+**should not be committed** because only you will use them. In fact, the
+``.gitignore`` file that comes with Symfony prevents them from being committed.
+
+.. caution::
+
+ Applications created before November 2018 had a slightly different system,
+ involving a ``.env.dist`` file. For information about upgrading, see:
+ :doc:`configuration/dot-env-changes`.
+
+Accessing Configuration Values
+------------------------------
+
+Controllers and services can access all the configuration parameters. This
+includes both the :ref:`parameters defined by yourself `
+and the parameters created by packages/bundles. Run the following command to see
+all the parameters that exist in your application:
+
+.. code-block:: terminal
+
+ $ php bin/console debug:container --parameters
+
+Parameters are injected in services as arguments to their constructors.
+:doc:`Service autowiring ` doesn't work for
+parameters. Instead, inject them explicitly:
+
+.. configuration-block::
+
+ .. code-block:: yaml
+
+ # config/services.yaml
+ parameters:
+ app.contents_dir: '...'
+
+ services:
+ App\Service\MessageGenerator:
+ arguments:
+ $contentsDir: '%app.contents_dir%'
+
+ .. code-block:: xml
+
+
+
+
+
+
+ ...
+
+
+
+
+ %app.contents_dir%
+
+
+
-Using the ``.env`` files explained earlier is the recommended way of using env
-vars in Symfony applications. However, you can also define env vars in the web
-server configuration if you prefer that:
+ .. code-block:: php
+
+ // config/services.php
+ use App\Service\MessageGenerator;
+ use Symfony\Component\DependencyInjection\Reference;
+
+ $container->setParameter('app.contents_dir', '...');
+
+ $container->getDefinition(MessageGenerator::class)
+ ->setArgument('$contentsDir', '%app.contents_dir%');
+
+If you inject the same parameters over and over again, use instead the
+``services._defaults.bind`` option. The arguments defined in that option are
+injected automatically whenever a service constructor or controller action
+define an argument with that exact name. For example, to inject the value of the
+:ref:`kernel.project_dir parameter `
+whenever a service/controller defines a ``$projectDir`` argument, use this:
.. configuration-block::
- .. code-block:: apache
+ .. code-block:: yaml
+
+ # config/services.yaml
+ services:
+ _defaults:
+ bind:
+ # pass this value to any $projectDir argument for any service
+ # that's created in this file (including controller arguments)
+ $projectDir: '%kernel.project_dir%'
-
# ...
- SetEnv DATABASE_URL "mysql://db_user:db_password@127.0.0.1:3306/db_name"
-
+ .. code-block:: xml
- .. code-block:: nginx
+
+
+
- fastcgi_param DATABASE_URL "mysql://db_user:db_password@127.0.0.1:3306/db_name";
+
+
+
+ %kernel.project_dir%
+
-.. tip::
+
+
+
- SymfonyCloud, the cloud service optimized for Symfony applications, defines
- some `utilities to manage env vars`_ in production.
+ .. code-block:: php
+
+ // config/services.php
+ use App\Controller\LuckyController;
+ use Psr\Log\LoggerInterface;
+ use Symfony\Component\DependencyInjection\Reference;
+
+ $container->register(LuckyController::class)
+ ->setPublic(true)
+ ->setBindings([
+ // pass this value to any $projectDir argument for any service
+ // that's created in this file (including controller arguments)
+ '$projectDir' => '%kernel.project_dir%',
+ ])
+ ;
+
+.. seealso::
+
+ Read the article about :ref:`binding arguments by name and/or type `
+ to learn more about this powerful feature.
+
+Finally, if some service needs to access to lots of parameters, instead of
+injecting each of them individually, you can inject all the application
+parameters at once by type-hinting any of its constructor arguments with the
+:class:`Symfony\\Component\\DependencyInjection\\ParameterBag\\ContainerBagInterface`::
+
+ // src/Service/MessageGenerator.php
+ // ...
+
+ use Symfony\Component\DependencyInjection\ParameterBag\ContainerBagInterface;
+
+ class MessageGenerator
+ {
+ private $params;
+
+ public function __construct(ContainerBagInterface $params)
+ {
+ $this->params = $params;
+ }
+
+ public function someMethod()
+ {
+ // get any container parameter from $this->params, which stores all of them
+ $sender = $this->params->get('mailer_sender');
+ // ...
+ }
+ }
Keep Going!
-----------
@@ -602,10 +825,7 @@ part of Symfony individually by following the guides. Check out:
* :doc:`/email`
* :doc:`/logging`
-And the many other topics.
-
-Learn more
-----------
+And all the other topics related to configuration:
.. toctree::
:maxdepth: 1
@@ -613,6 +833,7 @@ Learn more
configuration/*
+.. _`Learn the XML syntax`: https://en.wikipedia.org/wiki/XML
.. _`environment variables`: https://en.wikipedia.org/wiki/Environment_variable
.. _`symbolic links`: https://en.wikipedia.org/wiki/Symbolic_link
.. _`utilities to manage env vars`: https://symfony.com/doc/master/cloud/cookbooks/env.html
diff --git a/controller.rst b/controller.rst
index 35dc6358238..ed393caa375 100644
--- a/controller.rst
+++ b/controller.rst
@@ -553,6 +553,19 @@ response types. Some of these are mentioned below. To learn more about the
``Request`` and ``Response`` (and different ``Response`` classes), see the
:ref:`HttpFoundation component documentation `.
+Accessing Configuration Values
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To get the value of any :ref:`configuration parameter `
+from a controller, use the ``getParameter()`` helper method::
+
+ // ...
+ public function index()
+ {
+ $contentsDir = $this->getParameter('kernel.project_dir').'/contents';
+ // ...
+ }
+
Returning JSON Response
~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/reference/configuration/framework.rst b/reference/configuration/framework.rst
index 423862b54f8..2889c275895 100644
--- a/reference/configuration/framework.rst
+++ b/reference/configuration/framework.rst
@@ -1204,7 +1204,7 @@ and it will rely on the cache control method configured in the
`session.cache-limiter`_ PHP.ini option.
Unlike the other session options, ``cache_limiter`` is set as a regular
-:doc:`container parameter `:
+:ref:`container parameter `:
.. configuration-block::
diff --git a/service_container.rst b/service_container.rst
index d8a354d59a0..1ce394593be 100644
--- a/service_container.rst
+++ b/service_container.rst
@@ -460,23 +460,29 @@ Service Parameters
------------------
In addition to holding service objects, the container also holds configuration,
-called ``parameters``. To create a parameter, add it under the ``parameters`` key
-and reference it with the ``%parameter_name%`` syntax:
+called **parameters**. The main article about Symfony configuration explains the
+:ref:`configuration parameters ` in detail and shows
+all their types (string, boolean, array, binary and PHP constant parameters).
+
+However, there is another type of parameter related to services. In YAML config,
+any string which starts with ``@`` is considered as the ID of a service, instead
+of a regular string. In XML config, use the ``type="service"`` type for the
+parameter and in PHP config use the ``Reference`` class:
.. configuration-block::
.. code-block:: yaml
# config/services.yaml
- parameters:
- admin_email: manager@example.com
-
services:
- # ...
+ App\Service\MessageGenerator:
+ # this is not a string, but a reference to a service called 'logger'
+ arguments: ['@logger']
- App\Updates\SiteUpdateManager:
- arguments:
- $adminEmail: '%admin_email%'
+ # if the value of a string parameter starts with '@', you need to escape
+ # it by adding another '@' so Symfony doesn't consider it a service
+ # (this will be parsed as the string '@securepassword')
+ mailer_password: '@@securepassword'
.. code-block:: xml
@@ -487,15 +493,9 @@ and reference it with the ``%parameter_name%`` syntax:
xsi:schemaLocation="http://symfony.com/schema/dic/services
https://symfony.com/schema/dic/services/services-1.0.xsd">
-
- manager@example.com
-
-
-
-
-
- %admin_email%
+
+
@@ -503,45 +503,38 @@ and reference it with the ``%parameter_name%`` syntax:
.. code-block:: php
// config/services.php
- use App\Updates\SiteUpdateManager;
- $container->setParameter('admin_email', 'manager@example.com');
-
- $container->autowire(SiteUpdateManager::class)
- // ...
- ->setArgument('$adminEmail', '%admin_email%');
+ use App\Service\MessageGenerator;
+ use Symfony\Component\DependencyInjection\Reference;
-Actually, once you define a parameter, it can be referenced via the
-``%parameter_name%`` syntax in *any* other configuration file. Many parameters
-are defined in the ``config/services.yaml`` file.
+ $container->autowire(MessageGenerator::class)
+ ->setAutoconfigured(true)
+ ->setPublic(false)
+ ->setArgument(0, new Reference('logger'));
-You can then fetch the parameter in the service::
+Working with container parameters is straightforward using the container's
+accessor methods for parameters::
- class SiteUpdateManager
- {
- // ...
+ // checks if a parameter is defined (parameter names are case-sensitive)
+ $container->hasParameter('mailer.transport');
- private $adminEmail;
+ // gets value of a parameter
+ $container->getParameter('mailer.transport');
- public function __construct($adminEmail)
- {
- $this->adminEmail = $adminEmail;
- }
- }
+ // adds a new parameter
+ $container->setParameter('mailer.transport', 'sendmail');
-You can also fetch parameters directly from the container::
-
- public function new()
- {
- // ...
+.. caution::
- // this shortcut ONLY works if you extend the base AbstractController
- $adminEmail = $this->getParameter('admin_email');
+ The used ``.`` notation is a
+ :ref:`Symfony convention ` to make parameters
+ easier to read. Parameters are flat key-value elements, they can't
+ be organized into a nested array
- // this is the equivalent code of the previous shortcut:
- // $adminEmail = $this->container->get('parameter_bag')->get('admin_email');
- }
+.. note::
-For more info about parameters, see :doc:`/service_container/parameters`.
+ You can only set a parameter before the container is compiled, not at run-time.
+ To learn more about compiling the container see
+ :doc:`/components/dependency_injection/compilation`.
.. _services-wire-specific-service:
@@ -724,39 +717,6 @@ argument for *any* service defined in this file! You can bind arguments by name
The ``bind`` config can also be applied to specific services or when loading many
services at once (i.e. :ref:`service-psr4-loader`).
-Getting Container Parameters as a Service
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If some service or controller needs lots of container parameters, there's an
-easier alternative to binding all of them with the ``services._defaults.bind``
-option. Type-hint any of its constructor arguments with the
-:class:`Symfony\\Component\\DependencyInjection\\ParameterBag\\ParameterBagInterface`
-or the new :class:`Symfony\\Component\\DependencyInjection\\ParameterBag\\ContainerBagInterface`
-and the service will get all container parameters in a
-:class:`Symfony\\Component\\DependencyInjection\\ParameterBag\\ParameterBag` object::
-
- // src/Service/MessageGenerator.php
- // ...
-
- use Symfony\Component\DependencyInjection\ParameterBag\ParameterBagInterface;
-
- class MessageGenerator
- {
- private $params;
-
- public function __construct(ParameterBagInterface $params)
- {
- $this->params = $params;
- }
-
- public function someMethod()
- {
- // get any param from $this->params, which stores all container parameters
- $sender = $this->params->get('mailer_sender');
- // ...
- }
- }
-
.. _services-autowire:
The autowire Option
diff --git a/service_container/parameters.rst b/service_container/parameters.rst
deleted file mode 100644
index c1c7d570447..00000000000
--- a/service_container/parameters.rst
+++ /dev/null
@@ -1,351 +0,0 @@
-.. index::
- single: DependencyInjection; Parameters
-
-Introduction to Parameters
-==========================
-
-You can define parameters in the service container which can then be used
-directly or as part of service definitions. This can help to separate out
-values that you will want to change more regularly.
-
-Parameters in Configuration Files
----------------------------------
-
-Use the ``parameters`` section of a config file to set parameters:
-
-.. configuration-block::
-
- .. code-block:: yaml
-
- # config/services.yaml
- parameters:
- mailer.transport: sendmail
-
- .. code-block:: xml
-
-
-
-
-
-
- sendmail
-
-
-
- .. code-block:: php
-
- // config/services.php
- $container->setParameter('mailer.transport', 'sendmail');
-
-You can refer to parameters elsewhere in any config file by surrounding them
-with percent (``%``) signs, e.g. ``%mailer.transport%``. One use for this is
-to inject the values into your services. This allows you to configure different
-versions of services between applications or multiple services based on the
-same class but configured differently within a single application. You could
-inject the choice of mail transport into the ``Mailer`` class directly. But
-declaring it as a parameter makes it easier to change rather than being tied up
-and hidden with the service definition:
-
-.. configuration-block::
-
- .. code-block:: yaml
-
- # config/services.yaml
- parameters:
- mailer.transport: sendmail
-
- services:
- App\Service\Mailer:
- arguments: ['%mailer.transport%']
-
- .. code-block:: xml
-
-
-
-
-
-
- sendmail
-
-
-
-
- %mailer.transport%
-
-
-
-
- .. code-block:: php
-
- // config/services.php
- use App\Mailer;
-
- $container->setParameter('mailer.transport', 'sendmail');
-
- $container->register(Mailer::class)
- ->addArgument('%mailer.transport%');
-
-.. caution::
-
- The values between ``parameter`` tags in XML configuration files are
- not trimmed.
-
- This means that the following configuration sample will have the value
- ``\n sendmail\n``:
-
- .. code-block:: xml
-
-
- sendmail
-
-
- In some cases (for constants or class names), this could throw errors.
- In order to prevent this, you must always inline your parameters as
- follow:
-
- .. code-block:: xml
-
- sendmail
-
-.. note::
-
- If you use a string that starts with ``@`` or has ``%`` anywhere in it, you
- need to escape it by adding another ``@`` or ``%``:
-
- .. configuration-block::
-
- .. code-block:: yaml
-
- # config/services.yaml
- parameters:
- # This will be parsed as string '@securepass'
- mailer_password: '@@securepass'
-
- # Parsed as http://symfony.com/?foo=%s&bar=%d
- url_pattern: 'http://symfony.com/?foo=%%s&bar=%%d'
-
- .. code-block:: xml
-
-
-
-
- @securepass
-
-
- http://symfony.com/?foo=%%s&bar=%%d
-
-
- .. code-block:: php
-
- // config/services.php
- // the @ symbol does NOT need to be escaped in XML
- $container->setParameter('mailer_password', '@securepass');
-
- // But % does need to be escaped
- $container->setParameter('url_pattern', 'http://symfony.com/?foo=%%s&bar=%%d');
-
-Getting and Setting Container Parameters in PHP
------------------------------------------------
-
-Working with container parameters is straightforward using the container's
-accessor methods for parameters::
-
- // checks if a parameter is defined (parameter names are case-sensitive)
- $container->hasParameter('mailer.transport');
-
- // gets value of a parameter
- $container->getParameter('mailer.transport');
-
- // adds a new parameter
- $container->setParameter('mailer.transport', 'sendmail');
-
-.. caution::
-
- The used ``.`` notation is a
- :ref:`Symfony convention ` to make parameters
- easier to read. Parameters are flat key-value elements, they can't
- be organized into a nested array
-
-.. note::
-
- You can only set a parameter before the container is compiled: not at run-time.
- To learn more about compiling the container see
- :doc:`/components/dependency_injection/compilation`.
-
-.. _component-di-parameters-array:
-
-Array Parameters
-----------------
-
-Parameters do not need to be flat strings, they can also contain array values.
-For the XML format, you need to use the ``type="collection"`` attribute
-for all parameters that are arrays.
-
-.. configuration-block::
-
- .. code-block:: yaml
-
- # config/services.yaml
- parameters:
- my_mailer.gateways: [mail1, mail2, mail3]
-
- my_multilang.language_fallback:
- en:
- - en
- - fr
- fr:
- - fr
- - en
-
- .. code-block:: xml
-
-
-
-
-
-
-
- mail1
- mail2
- mail3
-
-
-
-
- en
- fr
-
-
-
- fr
- en
-
-
-
-
-
- .. code-block:: php
-
- // config/services.php
- $container->setParameter('my_mailer.gateways', ['mail1', 'mail2', 'mail3']);
- $container->setParameter('my_multilang.language_fallback', [
- 'en' => ['en', 'fr'],
- 'fr' => ['fr', 'en'],
- ]);
-
-Environment Variables and Dynamic Values
-----------------------------------------
-
-See :ref:`config-env-vars`.
-
-.. _component-di-parameters-constants:
-
-Constants as Parameters
------------------------
-
-Setting PHP constants as parameters is also supported:
-
-.. configuration-block::
-
- .. code-block:: yaml
-
- # config/services.yaml
- parameters:
- global.constant.value: !php/const GLOBAL_CONSTANT
- my_class.constant.value: !php/const My_Class::CONSTANT_NAME
-
- .. code-block:: xml
-
-
-
-
-
-
- GLOBAL_CONSTANT
- My_Class::CONSTANT_NAME
-
-
-
- .. code-block:: php
-
- // config/services.php
- $container->setParameter('global.constant.value', GLOBAL_CONSTANT);
- $container->setParameter('my_class.constant.value', My_Class::CONSTANT_NAME);
-
-Binary Values as Parameters
----------------------------
-
-If the value of a container parameter is a binary value, set it as a base64
-encoded value in YAML and XML configs and use the escape sequences in PHP:
-
-.. configuration-block::
-
- .. code-block:: yaml
-
- # config/services.yaml
- parameters:
- some_parameter: !!binary VGhpcyBpcyBhIEJlbGwgY2hhciAH
-
- .. code-block:: xml
-
-
-
-
-
-
- VGhpcyBpcyBhIEJlbGwgY2hhciAH
-
-
-
- .. code-block:: php
-
- // config/services.php
- $container->setParameter('some_parameter', 'This is a Bell char \x07');
-
-PHP Keywords in XML
--------------------
-
-By default, ``true``, ``false`` and ``null`` in XML are converted to the
-PHP keywords (respectively ``true``, ``false`` and ``null``):
-
-.. code-block:: xml
-
-
- false
-
-
-
-
-To disable this behavior, use the ``string`` type:
-
-.. code-block:: xml
-
-
- true
-
-
-
-
-.. note::
-
- This is not available for YAML and PHP, because they already have built-in
- support for the PHP keywords.