Merge branch '2.3' into 2.5

best_practices/templates.rst

@@ -153,7 +153,7 @@ name is irrelevant because you never use it in your own code):
         app.twig.app_extension:
             class:     AppBundle\Twig\AppExtension
             arguments: ["@markdown"]
-            public: false
+            public:    false
             tags:
                 - { name: twig.extension }
 

book/forms.rst

@@ -1854,7 +1854,7 @@ an array.
     You can also access POST values (in this case "name") directly through
     the request object, like so::
 
-        $this->get('request')->request->get('name');
+        $request->request->get('name');
 
     Be advised, however, that in most cases using the ``getData()`` method is
     a better choice, since it returns the data (usually an object) after

book/routing.rst

@@ -173,8 +173,10 @@ file:
         <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">
+            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">
 
             <framework:config>
                 <!-- ... -->
@@ -649,7 +651,9 @@ be added for each parameter. For example:
         // ...
 
         /**
-         * @Route("/blog/{page}", defaults={"page": 1}, requirements={"page": "\d+"})
+         * @Route("/blog/{page}", defaults={"page": 1}, requirements={
+         *     "page": "\d+"
+         * })
          */
         public function indexAction($page)
         {
@@ -737,7 +741,9 @@ URL:
         class MainController extends Controller
         {
             /**
-             * @Route("/{_locale}", defaults={"_locale": "en"}, requirements={"_locale": "en|fr"})
+             * @Route("/{_locale}", defaults={"_locale": "en"}, requirements={
+             *     "_locale": "en|fr"
+             * })
              */
             public function homepageAction($_locale)
             {
@@ -1018,8 +1024,12 @@ routing system can be:
             /**
              * @Route(
              *     "/articles/{_locale}/{year}/{title}.{_format}",
-             *     defaults: {"_format": "html"}
-             *     requirements: {"_locale": "en|fr", "_format": "html|rss", "year": "\d+"}
+             *     defaults: {"_format": "html"},
+             *     requirements: {
+             *         "_locale": "en|fr",
+             *         "_format": "html|rss",
+             *         "year": "\d+"
+             *     }
              * )
              */
             public function showAction($_locale, $year, $title)
@@ -1096,7 +1106,7 @@ a slash. URLs matching this route might look like:
     This example also highlights the special ``_format`` routing parameter.
     When using this parameter, the matched value becomes the "request format"
     of the ``Request`` object. Ultimately, the request format is used for such
-    things such as setting the ``Content-Type`` of the response (e.g. a ``json``
+    things as setting the ``Content-Type`` of the response (e.g. a ``json``
     request format translates into a ``Content-Type`` of ``application/json``).
     It can also be used in the controller to render a different template for
     each value of ``_format``. The ``_format`` parameter is a very powerful way
@@ -1188,7 +1198,7 @@ each is made available as an argument to the controller method::
 
     public function showAction($slug)
     {
-      // ...
+        // ...
     }
 
 In reality, the entire ``defaults`` collection is merged with the parameter
@@ -1263,8 +1273,8 @@ configuration:
 
         $collection = new RouteCollection();
         $collection->addCollection(
-            // second argument is the type, which is required to enable the annotation reader
-            // for this resource
+            // second argument is the type, which is required to enable
+            // the annotation reader for this resource
             $loader->import("@AppBundle/Controller/", "annotation")
         );
 
@@ -1354,7 +1364,7 @@ suppose you want to prefix all routes in the AppBundle with ``/site`` (e.g.
         // app/config/routing.php
         use Symfony\Component\Routing\RouteCollection;
 
-        $app = $loader->import('@AppBundle/Controller/');
+        $app = $loader->import('@AppBundle/Controller/', 'annotation');
         $app->addPrefix('/site');
 
         $collection = new RouteCollection();
@@ -1437,7 +1447,9 @@ system. Take the ``blog_show`` example route from earlier::
     //     '_controller' => 'AppBundle:Blog:show',
     // )
 
-    $uri = $this->get('router')->generate('blog_show', array('slug' => 'my-blog-post'));
+    $uri = $this->get('router')->generate('blog_show', array(
+        'slug' => 'my-blog-post'
+    ));
     // /blog/my-blog-post
 
 To generate a URL, you need to specify the name of the route (e.g. ``blog_show``)
@@ -1505,7 +1517,10 @@ Generating URLs with Query Strings
 The ``generate`` method takes an array of wildcard values to generate the URI.
 But if you pass extra ones, they will be added to the URI as a query string::
 
-    $this->get('router')->generate('blog', array('page' => 2, 'category' => 'Symfony'));
+    $this->get('router')->generate('blog', array(
+        'page' => 2,
+        'category' => 'Symfony'
+    ));
     // /blog/2?category=Symfony
 
 Generating URLs from a Template
@@ -1546,7 +1561,7 @@ method::
 
 From a template, in Twig, simply use the ``url()`` function (which generates an absolute URL)
 rather than the ``path()`` function (which generates a relative URL). In PHP, pass ``true``
-to ``generateUrl()``:
+to ``generate()``:
 
 .. configuration-block::
 

book/security.rst

@@ -209,7 +209,7 @@ user to be logged in to access this URL:
             # ...
             firewalls:
                 # ...
-            
+
             access_control:
                 # require ROLE_ADMIN for /admin*
                 - { path: ^/admin, roles: ROLE_ADMIN }
@@ -432,9 +432,10 @@ If you'd like to load your users via the Doctrine ORM, that's easy! See
 :doc:`/cookbook/security/entity_provider` for all the details.
 
 .. _book-security-encoding-user-password:
+.. _c-encoding-the-users-password:
 
-C) Encoding the Users Password
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+C) Encoding the User's Password
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Whether your users are stored in ``security.yml``, in a database or somewhere
 else, you'll want to encode their passwords. The best algorithm to use is
@@ -676,7 +677,7 @@ URL pattern. You saw this earlier, where anything matching the regular expressio
             # ...
             firewalls:
                 # ...
-            
+
             access_control:
                 # require ROLE_ADMIN for /admin*
                 - { path: ^/admin, roles: ROLE_ADMIN }
@@ -867,9 +868,9 @@ in this chapter).
     Be careful with this in your layout or on your error pages! Because of
     some internal Symfony details, to avoid broken error pages in the ``prod``
     environment, wrap calls in these templates with a check for ``app.user``:
-    
+
     .. code-block:: html+jinja
-    
+
         {% if app.user and is_granted('ROLE_ADMIN') %}
 
 Securing other Services
@@ -1029,7 +1030,7 @@ the User object, and use the ``isGranted`` method (or
 
     // boo :(. Never check for the User object to see if they're logged in
     if ($this->getUser()) {
-        
+
     }
 
 Retrieving the User in a Template
@@ -1048,7 +1049,7 @@ key:
 
     .. code-block:: html+php
 
-        <?php if ($view['security']->isGranted('IS_AUTHENTICATED_FULLY')): ?>        
+        <?php if ($view['security']->isGranted('IS_AUTHENTICATED_FULLY')): ?>
             <p>Username: <?php echo $app->getUser()->getUsername() ?></p>
         <?php endif; ?>
 

book/validation.rst

@@ -847,8 +847,8 @@ the string ``Default``.
     If you have inheritance (e.g. ``User extends BaseUser``) and you validate
     with the class name of the subclass (i.e. ``User``), then all constraints
     in the ``User`` and ``BaseUser`` will be validated. However, if you validate
-    using the base class (i.e. ``BaseUser``), then only the constraints in
-    the ``BaseUser`` group will be validated.
+    using the base class (i.e. ``BaseUser``), then only the default constraints in
+    the ``BaseUser`` class will be validated.
 
 To tell the validator to use a specific group, pass one or more group names
 as the third argument to the ``validate()`` method::

components/config/definition.rst

@@ -566,8 +566,8 @@ Otherwise the result is a clean array of configuration values::
     use Symfony\Component\Config\Definition\Processor;
     use Acme\DatabaseConfiguration;
 
-    $config1 = Yaml::parse(__DIR__.'/src/Matthias/config/config.yml');
-    $config2 = Yaml::parse(__DIR__.'/src/Matthias/config/config_extra.yml');
+    $config1 = Yaml::parse(file_get_contents(__DIR__.'/src/Matthias/config/config.yml'));
+    $config2 = Yaml::parse(file_get_contents(__DIR__.'/src/Matthias/config/config_extra.yml'));
 
     $configs = array($config1, $config2);
 

components/config/resources.rst

@@ -39,7 +39,7 @@ class, which allows for recursively importing other resources::
     {
         public function load($resource, $type = null)
         {
-            $configValues = Yaml::parse($resource);
+            $configValues = Yaml::parse(file_get_contents($resource));
 
             // ... handle the config values
 

components/serializer.rst

@@ -224,7 +224,7 @@ When serializing, you can set a callback to format a specific object property::
         return $dateTime instanceof \DateTime
             ? $dateTime->format(\DateTime::ISO8601)
             : '';
-    }
+    };
 
     $normalizer->setCallbacks(array('createdAt' => $callback));