Merge branch '2.7' into 2.8

* 2.7:
  [#7767] minor rewording
  [#8047] add inline code comment
  Fixed the issue in a different way
  Jquery datePicker syntax update
  [#8104] minor rewording
  Add more precision about automatic provider assignation
  Update data.rst.inc
  Minor reword to explain that path() generates absolute URLs
  Added a caution note about UploadedFile and insulated tests
  Postpone talk about front controllers
  Applied reviewer suggestion
  Minor fix
  Minor reword
  Improved format of message and added missing information.
  Added caution block under delete_empty to warn the developer when he try to activate delete_empty for collections of compound forms.

Author: xabbuh

page_creation.rst

@@ -63,12 +63,7 @@ random) number and prints it. To do that, create a "Controller class" and a
 Before diving into this, test it out! If you are using PHP's internal web server
 go to:
 
-    http://localhost:8000/app_dev.php/lucky/number
-
-.. tip::
-
-    If you're using the built-in PHP web-server, you can omit the ``app_dev.php``
-    part of the URL.
+    http://localhost:8000/lucky/number
 
 If you see a lucky number being printed back to you, congratulations! But before
 you run off to play the lottery, check out how this works. Remember the two steps

reference/forms/types/collection.rst

@@ -278,6 +278,15 @@ form you have to set this option to true. However, existing collection entries
 will only be deleted if you have the allow_delete_ option enabled. Otherwise
 the empty values will be kept.
 
+.. caution::
+
+    The ``delete_empty`` option only removes items when the normalized value is
+    ``null``. If the nested `type`_ is a compound form type, you must either set
+    the ``required`` option to ``false`` or set the ``empty_data`` option to 
+    ``null``. Both of these options can be set inside `options`_. Read about
+    the :ref:`form's empty_data option <reference-form-option-empty-data>`
+    to learn why this is necessary.
+
 entry_options
 ~~~~~~~~~~~~~
 

reference/forms/types/date.rst

@@ -102,12 +102,14 @@ make the following changes::
         'attr' => ['class' => 'js-datepicker'],
     ));
 
-Assuming you're using jQuery, you can initialize the date picker via:
+Then, add the following JavaScript code in your template to initialize the date
+picker:
 
 .. code-block:: html
 
     <script>
         $(document).ready(function() {
+            // configure the bootstrap datepicker
             $('.js-datepicker').datepicker({
                 format: 'yyyy-mm-dd'
             });

reference/forms/types/form.rst

@@ -77,6 +77,8 @@ option on the form.
 
 .. include:: /reference/forms/types/options/data_class.rst.inc
 
+.. _reference-form-option-empty-data:
+
 .. include:: /reference/forms/types/options/empty_data.rst.inc
     :end-before: DEFAULT_PLACEHOLDER
 

reference/forms/types/options/data.rst.inc

@@ -20,5 +20,5 @@ an individual field, you can set it in the data option::
 
     The ``data`` option *always* overrides the value taken from the domain data
     (object) when rendering. This means the object value is also overriden when
-    the form edits an already persisted object, causing it to lose it's
+    the form edits an already persisted object, causing it to lose its
     persisted value when the form is submitted.

routing/scheme.rst

@@ -48,17 +48,18 @@ the URI scheme via schemes:
 The above configuration forces the ``secure`` route to always use HTTPS.
 
 When generating the ``secure`` URL, and if the current scheme is HTTP, Symfony
-will automatically generate an absolute URL with HTTPS as the scheme:
+will automatically generate an absolute URL with HTTPS as the scheme, even when
+using the ``path()`` function:
 
 .. code-block:: twig
 
     {# If the current scheme is HTTPS #}
     {{ path('secure') }}
-    {# generates /secure #}
+    {# generates a relative URL: /secure #}
 
     {# If the current scheme is HTTP #}
     {{ path('secure') }}
-    {# generates https://example.com/secure #}
+    {# generates an absolute URL: https://example.com/secure #}
 
 The requirement is also enforced for incoming requests. If you try to access
 the ``/secure`` path with HTTP, you will automatically be redirected to the

security/multiple_user_providers.rst

@@ -82,9 +82,10 @@ a new provider that chains the two together:
             ),
         ));
 
-Now, all authentication mechanisms will use the ``chain_provider``, since
-it's the first specified. The ``chain_provider`` will, in turn, try to load
-the user from both the ``in_memory`` and ``user_db`` providers.
+Now, all firewalls without an explicitly configured user provider will use
+the ``chain_provider`` since it's the first specified. The ``chain_provider``
+will, in turn, try to load the user from both the ``in_memory`` and ``user_db``
+providers.
 
 You can also configure the firewall or individual authentication mechanisms
 to use a specific provider. Again, unless a provider is specified explicitly,

testing/insulating_clients.rst

@@ -43,3 +43,11 @@ clean PHP process, thus avoiding any side-effects.
 
     As an insulated client is slower, you can keep one client in the main
     process, and insulate the other ones.
+
+.. caution::
+
+    Insulating tests requires some serializing and unserializing operations. If
+    your test includes data that can't be serialized, such as file streams when
+    using the ``UploadedFile`` class, you'll see an exception about
+    *"serialization is not allowed"*. This is a technical limitation of PHP, so
+    the only solution is to disable insulation for those tests.