Merge branch '4.1'

* 4.1:
  [testing] tell about self::$container
  Fix typo in the Twig article
  Removed some whitespace
  Reworded the tip contents
  Add Tip to using  MailHog during developement
  Added a small note about dynamic role hierarchies
  Added a note about command aliases and services

Author: javiereguiluz

console/commands_as_services.rst

@@ -119,6 +119,12 @@ Or set the ``command`` attribute on the ``console.command`` tag in your service
             ->addTag('console.command', array('command' => 'app:sunshine'))
         ;
 
+.. note::
+
+    If the command defines aliases (using the
+    :method:`Symfony\\Component\\Console\\Command\\Command::getAliases` method)
+    you must add one ``console.command`` tag per alias.
+
 That's it. One way or another, the ``SunshineCommand`` will be instantiated
 only when the ``app:sunshine`` command is actually called.
 

email/dev_environment.rst

@@ -241,3 +241,12 @@ the report with details of the sent emails.
     by the submit URL used on the previous request (e.g. ``/contact/handle``).
     The profiler's search feature allows you to load the profiler information
     for any past requests.
+
+.. tip::
+
+    In addition to the features provided by Symfony, there are applications that
+    can help you test emails during application development, like `MailCatcher`_
+    and `MailHog`_.
+
+.. _`MailCatcher`: https://github.com/sj26/mailcatcher
+.. _`MailHog`: https://github.com/mailhog/MailHog

reference/configuration/twig.rst

@@ -129,7 +129,7 @@ format
 The format used by the ``date`` filter to display values when no specific format
 is passed as argument.
 
-internal_format
+interval_format
 ...............
 
 **type**: ``string`` **default**: ``%d days``

security.rst

@@ -1282,6 +1282,13 @@ In the above configuration, users with ``ROLE_ADMIN`` role will also have the
 ``ROLE_USER`` role. The ``ROLE_SUPER_ADMIN`` role has ``ROLE_ADMIN``, ``ROLE_ALLOWED_TO_SWITCH``
 and ``ROLE_USER`` (inherited from ``ROLE_ADMIN``).
 
+.. note::
+
+    The value of the ``role_hierarchy`` option is defined statically, so you
+    can't for example store the role hierarchy in a database. If you need that,
+    create a custom :doc:`security voter </security/voters>` that looks for the
+    user roles in the database.
+
 Final Words
 -----------
 

testing.rst

@@ -508,18 +508,28 @@ You can also get the objects related to the latest request::
 Accessing the Container
 ~~~~~~~~~~~~~~~~~~~~~~~
 
+.. versionadded:: 4.1
+    The ``self::$container`` property was introduced in Symfony 4.1.
+
 It's highly recommended that a functional test only tests the response. But
-under certain very rare circumstances, you might want to access some internal
-objects to write assertions. In such cases, you can access the Dependency
-Injection Container::
+under certain very rare circumstances, you might want to access some services
+to write assertions. Given that services are private by default, test classes
+define a property that stores a special container created by Symfony which
+allows fetching both public and all non-removed private services::
 
-    // will be the same container used in your test, unless you're using
+    // gives access to the same services used in your test, unless you're using
     // $client->insulate() or using real HTTP requests to test your application
-    $container = $client->getContainer();
+    $container = self::$container;
 
 For a list of services available in your application, use the ``debug:container``
 command.
 
+.. tip::
+
+    The special container that gives access to private services exists only in
+    the ``test`` environment and is itself a service that you can get from the
+    real container using the ``test.service_container`` id.
+
 .. tip::
 
     If the information you need to check is available from the profiler, use