Fixed some *.yml file extensions

Author: javiereguiluz

bundles/best_practices.rst

@@ -363,13 +363,13 @@ The end user can provide values in any configuration file:
 
     .. code-block:: yaml
 
-        # app/config/config.yml
+        # config/services.yaml
         parameters:
             acme_blog.author.email: '[email protected]'
 
     .. code-block:: xml
 
-        <!-- app/config/config.xml -->
+        <!-- config/services.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"
@@ -384,7 +384,7 @@ The end user can provide values in any configuration file:
 
     .. code-block:: php
 
-        // app/config/config.php
+        // config/services.php
         $container->setParameter('acme_blog.author.email', '[email protected]');
 
 Retrieve the configuration parameters in your code from the container::

bundles/override.rst

@@ -26,7 +26,7 @@ Routing
 
 Routing is never automatically imported in Symfony. If you want to include
 the routes from any bundle, then they must be manually imported from somewhere
-in your application (e.g. ``config/routes.yml``).
+in your application (e.g. ``config/routes.yaml``).
 
 The easiest way to "override" a bundle's routing is to never import it at
 all. Instead of importing a third-party bundle's routing, simply copy
@@ -101,7 +101,7 @@ to a new validation group:
 
     .. code-block:: yaml
 
-        # src/Acme/UserBundle/Resources/config/validation.yml
+        # src/Acme/UserBundle/Resources/config/validation.yaml
         FOS\UserBundle\Model\User:
             properties:
                 plainPassword:

bundles/prepend_extension.rst

@@ -12,11 +12,10 @@ users to choose to remove functionality they are not using. Creating multiple
 bundles has the drawback that configuration becomes more tedious and settings
 often need to be repeated for various bundles.
 
-It is possible to remove the disadvantage of the multiple bundle approach
-by enabling a single Extension to prepend the settings for any bundle.
-It can use the settings defined in the ``app/config/config.yml``
-to prepend settings just as if they had been written explicitly by
-the user in the application configuration.
+It is possible to remove the disadvantage of the multiple bundle approach by
+enabling a single Extension to prepend the settings for any bundle. It can use
+the settings defined in the ``config/*`` files to prepend settings just as if
+they had been written explicitly by the user in the application configuration.
 
 For example, this could be used to configure the entity manager name to use in
 multiple bundles. Or it can be used to enable an optional feature that depends
@@ -50,7 +49,7 @@ prepend settings to a bundle extension developers can use the
 :method:`Symfony\\Component\\DependencyInjection\\ContainerBuilder::prependExtensionConfig`
 method on the :class:`Symfony\\Component\\DependencyInjection\\ContainerBuilder`
 instance. As this method only prepends settings, any other settings done explicitly
-inside the ``app/config/config.yml`` would override these prepended settings.
+inside the ``config/*`` files would override these prepended settings.
 
 The following example illustrates how to prepend
 a configuration setting in multiple bundles as well as disable a flag in multiple bundles
@@ -73,7 +72,7 @@ in case a specific other bundle is not registered::
                         // acme_something and acme_other
                         //
                         // note that if the user manually configured
-                        // use_acme_goodbye to true in app/config/config.yml
+                        // use_acme_goodbye to true in config/services.yaml
                         // then the setting would in the end be true and not false
                         $container->prependExtensionConfig($name, $config);
                         break;
@@ -96,14 +95,15 @@ in case a specific other bundle is not registered::
     }
 
 The above would be the equivalent of writing the following into the
-``app/config/config.yml`` in case AcmeGoodbyeBundle is not registered and the
-``entity_manager_name`` setting for ``acme_hello`` is set to ``non_default``:
+``config/packages/acme_something.yaml`` in case AcmeGoodbyeBundle is not
+registered and the ``entity_manager_name`` setting for ``acme_hello`` is set to
+``non_default``:
 
 .. configuration-block::
 
     .. code-block:: yaml
 
-        # app/config/config.yml
+        # config/packages/acme_something.yaml
         acme_something:
             # ...
             use_acme_goodbye: false
@@ -115,7 +115,7 @@ The above would be the equivalent of writing the following into the
 
     .. code-block:: xml
 
-        <!-- app/config/config.xml -->
+        <!-- config/packages/acme_something.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"
@@ -134,7 +134,7 @@ The above would be the equivalent of writing the following into the
 
     .. code-block:: php
 
-        // app/config/config.php
+        // config/packages/acme_something.php
         $container->loadFromExtension('acme_something', array(
             // ...
             'use_acme_goodbye' => false,

configuration/configuration_organization.rst

@@ -78,7 +78,7 @@ Mix and Match Configuration Formats
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Configuration files can import files defined with any other built-in configuration
-format (``.yml``, ``.xml``, ``.php``, ``.ini``):
+format (``.yaml`` or ``.yml``, ``.xml``, ``.php``, ``.ini``):
 
 .. configuration-block::
 

doctrine/custom_dql_functions.rst

@@ -86,7 +86,7 @@ In Symfony, you can register your custom DQL functions as follows:
 
         .. code-block:: yaml
 
-            # app/config/config.yml
+            # config/packages/doctrine.yaml
             doctrine:
                 orm:
                     # ...
@@ -99,7 +99,7 @@ In Symfony, you can register your custom DQL functions as follows:
 
         .. code-block:: xml
 
-            # app/config/config.xml
+            <!-- config/packages/doctrine.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"
@@ -127,7 +127,7 @@ In Symfony, you can register your custom DQL functions as follows:
 
         .. code-block:: php
 
-            // app/config/config.php
+            // config/packages/doctrine.php
             use App\DQL\DatetimeFunction;
 
             $container->loadFromExtension('doctrine', array(

doctrine/dbal.rst

@@ -117,7 +117,7 @@ mapping type:
 
     .. code-block:: yaml
 
-        # config/packages/doctrine.yml
+        # config/packages/doctrine.yaml
         doctrine:
             dbal:
                mapping_types:

doctrine/registration_form.rst

@@ -147,7 +147,7 @@ With some validation added, your class may look something like this::
     }
 
 The :class:`Symfony\\Component\\Security\\Core\\User\\UserInterface` requires
-a few other methods and your ``security.yml`` file needs to be configured
+a few other methods and your ``security.yaml`` file needs to be configured
 properly to work with the ``User`` entity. For a more complete example, see
 the :ref:`Entity Provider <security-crete-user-entity>` article.
 
@@ -277,7 +277,7 @@ encoder in the security configuration:
 
     .. code-block:: yaml
 
-        # config/packages/security.yml
+        # config/packages/security.yaml
         security:
             encoders:
                 App\Entity\User: bcrypt
@@ -364,7 +364,7 @@ return the ``email`` property::
         // ...
     }
 
-Next, just update the ``providers`` section of your ``security.yml`` file
+Next, just update the ``providers`` section of your ``security.yaml`` file
 so that Symfony knows how to load your users via the ``email`` property on
 login. See :ref:`authenticating-someone-with-a-custom-entity-provider`.
 

reference/configuration/framework.rst

@@ -649,7 +649,7 @@ type
 
 The type of the resource to hint the loaders about the format. This isn't
 needed when you use the default routers with the expected file extensions
-(``.xml``, ``.yml`` / ``.yaml``, ``.php``).
+(``.xml``, ``.yml`` or ``.yaml``, ``.php``).
 
 http_port
 .........

routing/hostname_pattern.rst

@@ -393,7 +393,7 @@ You can also set the host option on imported routes:
 
         # config/routes.yaml
         app_hello:
-            resource: '@ThirdPartyBundle/Resources/config/routing.yml'
+            resource: '@ThirdPartyBundle/Resources/config/routing.yaml'
             host:     "hello.example.com"
 
     .. code-block:: xml

security/remember_me.rst

@@ -84,7 +84,7 @@ The ``remember_me`` firewall defines the following configuration options:
 
 ``secret`` (**required**)
     The value used to encrypt the cookie's content. It's common to use the
-    ``secret`` value defined in the ``app/config/parameters.yml`` file.
+    ``secret`` value defined in the ``APP_SECRET`` environment variable.
 
 ``name`` (default value: ``REMEMBERME``)
     The name of the cookie used to keep the user logged in. If you enable the

serializer/custom_encoders.rst

@@ -52,7 +52,7 @@ Registering it in your app
 --------------------------
 
 If you use the Symfony Framework. then you probably want to register this encoder
-as a service in your app. If you're using the :ref:`default services.yml configuration <service-container-services-load-example>`,
+as a service in your app. If you're using the :ref:`default services.yaml configuration <service-container-services-load-example>`,
 that's done automatically!
 
 .. tip::

templating/debug.rst

@@ -53,7 +53,7 @@ The same mechanism can be used in Twig templates thanks to ``dump()`` function:
     {% endfor %}
 
 By design, the ``dump()`` function is only available if the ``kernel.debug``
-setting (in ``config.yml``) is ``true``, to avoid leaking sensitive information
-in production. In fact, trying to use the ``dump()`` function when ``kernel.debug``
-is ``false`` (for example in the ``prod`` environment) will result in an
-application error.
+setting is ``true`` (which is usually set via the ``APP_DEBUG`` environment
+variable), to avoid leaking sensitive information in production. In fact, trying
+to use the ``dump()`` function when ``kernel.debug`` is ``false`` (for example
+in the ``prod`` environment) will result in an application error.

testing/http_authentication.rst

@@ -27,7 +27,7 @@ firewall, but only in the configuration file used by tests:
 
     .. code-block:: yaml
 
-        # app/config/config_test.yml
+        # config/packages/test/security.yaml
         security:
             firewalls:
                 # replace 'main' by the name of your own firewall
@@ -36,7 +36,7 @@ firewall, but only in the configuration file used by tests:
 
     .. code-block:: xml
 
-        <!-- app/config/config_test.xml -->
+        <!-- config/packages/test/security.xml -->
         <security:config>
             <!-- replace 'main' by the name of your own firewall -->
             <security:firewall name="main">
@@ -46,7 +46,7 @@ firewall, but only in the configuration file used by tests:
 
     .. code-block:: php
 
-        // app/config/config_test.php
+        // config/packages/test/security.php
         $container->loadFromExtension('security', array(
             'firewalls' => array(
                 // replace 'main' by the name of your own firewall

translation.rst

@@ -157,7 +157,7 @@ different formats, XLIFF being the recommended format:
 
     .. code-block:: yaml
 
-        # translations/messages.fr.yml
+        # translations/messages.fr.yaml
         Symfony is great: J'aime Symfony
 
     .. code-block:: php

translation/lint.rst

@@ -15,7 +15,7 @@ translation file using the ``lint:yaml`` and ``lint:xliff`` commands:
 .. code-block:: terminal
 
     # lint a single file
-    $ ./bin/console lint:yaml translations/messages.en.yml
+    $ ./bin/console lint:yaml translations/messages.en.yaml
     $ ./bin/console lint:xliff translations/messages.en.xlf
 
     # lint a whole directory

validation.rst

@@ -259,7 +259,7 @@ previous configuration by the following:
 
     .. code-block:: yaml
 
-        # config/packages/framework.yml
+        # config/packages/framework.yaml
         framework:
             validation: { enable_annotations: true }
 
@@ -439,7 +439,7 @@ options can be specified in this way.
 
     .. code-block:: yaml
 
-        # config/validator/validation.yml
+        # config/validator/validation.yaml
         App\Entity\Author:
             properties:
                 genre: