Merge branch '5.4' into 6.2

* 5.4:
  [Form] Removed jQuery in favour of vanilla Javascript
  [HttpCache] Explain how to extend the HttpCache class

Author: OskarStark

http_cache/cache_invalidation.rst

@@ -47,8 +47,9 @@ the word "PURGE" is a convention, technically this can be any string) instead
 of ``GET`` and make the cache proxy detect this and remove the data from the
 cache instead of going to the application to get a response.
 
-Here is how you can configure the Symfony reverse proxy (See :doc:`/http_cache`)
-to support the ``PURGE`` HTTP method::
+Here is how you can configure the :ref:`Symfony reverse proxy <symfony-gateway-cache>`
+to support the ``PURGE`` HTTP method. First create a caching kernel that overrides the
+:method:`Symfony\\Component\\HttpKernel\\HttpCache\\HttpCache::invalidate` method::
 
     // src/CacheKernel.php
     namespace App;
@@ -84,6 +85,58 @@ to support the ``PURGE`` HTTP method::
         }
     }
 
+Then, register the class as a service that :doc:`decorates </service_container/service_decoration>`
+``http_cache``::
+
+.. configuration-block::
+
+    .. code-block:: yaml
+
+        # config/services.yaml
+        services:
+            App\CacheKernel:
+                decorates: http_cache
+                arguments:
+                    - '@kernel'
+                    - '@http_cache.store'
+                    - '@?esi'
+
+    .. code-block:: 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"
+            xsi:schemaLocation="http://symfony.com/schema/dic/services
+                https://symfony.com/schema/dic/services/services-1.0.xsd"
+        >
+            <service id="App\CacheKernel" decorates="http_cache">
+                <argument type="service" id="kernel"/>
+                <argument type="service" id="http_cache.store"/>
+                <argument type="service" id="esi" on-invalid="null"/>
+            </service>
+        </container>
+
+    .. code-block:: php
+
+        // config/services.php
+        namespace Symfony\Component\DependencyInjection\Loader\Configurator;
+
+        use App\CacheKernel;
+
+        return function (ContainerConfigurator $containerConfigurator) {
+            $services = $containerConfigurator->services();
+
+            $services->set(CacheKernel::class)
+                ->decorate('http_cache')
+                ->args([
+                    service('kernel'),
+                    service('http_cache.store'),
+                    service('esi')->nullOnInvalid(),
+                ])
+            ;
+        };
+
 .. caution::
 
     You must protect the ``PURGE`` HTTP method somehow to avoid random people

reference/forms/types/collection.rst

@@ -86,114 +86,6 @@ existing addresses. Adding new addresses is possible by using the `allow_add`_
 option (and optionally the `prototype`_ option) (see example below). Removing
 emails from the ``emails`` array is possible with the `allow_delete`_ option.
 
-Adding and Removing Items
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If `allow_add`_ is set to ``true``, then if any unrecognized items are submitted,
-they'll be added seamlessly to the array of items. This is great in theory,
-but takes a little bit more effort in practice to get the client-side JavaScript
-correct.
-
-Following along with the previous example, suppose you start with two
-emails in the ``emails`` data array. In that case, two input fields will
-be rendered that will look something like this (depending on the name of
-your form):
-
-.. code-block:: html
-
-    <input type="email" id="form_emails_0" name="form[emails][0]" value="foo@foo.com"/>
-    <input type="email" id="form_emails_1" name="form[emails][1]" value="bar@bar.com"/>
-
-To allow your user to add another email, just set `allow_add`_ to ``true``
-and - via JavaScript - render another field with the name ``form[emails][2]``
-(and so on for more and more fields).
-
-To help make this easier, setting the `prototype`_ option to ``true`` allows
-you to render a "template" field, which you can then use in your JavaScript
-to help you dynamically create these new fields. A rendered prototype field
-will look like this:
-
-.. code-block:: html
-
-    <input type="email"
-        id="form_emails___name__"
-        name="form[emails][__name__]"
-        value=""
-    />
-
-By replacing ``__name__`` with some unique value (e.g. ``2``),
-you can build and insert new HTML fields into your form.
-
-Using jQuery, a simple example might look like this. If you're rendering
-your collection fields all at once (e.g. ``form_row(form.emails)``), then
-things are even easier because the ``data-prototype`` attribute is rendered
-automatically for you (with a slight difference - see note below) and all
-you need is this JavaScript code:
-
-.. code-block:: javascript
-
-    // add-collection-widget.js
-    jQuery(document).ready(function () {
-        jQuery('.add-another-collection-widget').click(function (e) {
-            var list = jQuery(jQuery(this).attr('data-list-selector'));
-            // Try to find the counter of the list or use the length of the list
-            var counter = list.data('widget-counter') || list.children().length;
-
-            // grab the prototype template
-            var newWidget = list.attr('data-prototype');
-            // replace the "__name__" used in the id and name of the prototype
-            // with a number that's unique to your emails
-            // end name attribute looks like name="contact[emails][2]"
-            newWidget = newWidget.replace(/__name__/g, counter);
-            // Increase the counter
-            counter++;
-            // And store it, the length cannot be used if deleting widgets is allowed
-            list.data('widget-counter', counter);
-
-            // create a new list element and add it to the list
-            var newElem = jQuery(list.attr('data-widget-tags')).html(newWidget);
-            newElem.appendTo(list);
-        });
-    });
-
-And update the template as follows:
-
-.. code-block:: html+twig
-
-    {{ form_start(form) }}
-        {# ... #}
-
-        {# store the prototype on the data-prototype attribute #}
-        <ul id="email-fields-list"
-            data-prototype="{{ form_widget(form.emails.vars.prototype)|e }}"
-            data-widget-tags="{{ '<li></li>'|e }}"
-            data-widget-counter="{{ form.emails|length }}">
-        {% for emailField in form.emails %}
-            <li>
-                {{ form_errors(emailField) }}
-                {{ form_widget(emailField) }}
-            </li>
-        {% endfor %}
-        </ul>
-
-        <button type="button"
-            class="add-another-collection-widget"
-            data-list-selector="#email-fields-list">Add another email</button>
-
-        {# ... #}
-    {{ form_end(form) }}
-
-    <script src="add-collection-widget.js"></script>
-
-.. tip::
-
-    If you're rendering the entire collection at once, then the prototype
-    is automatically available on the ``data-prototype`` attribute of the
-    element (e.g. ``div`` or ``table``) that surrounds your collection.
-    The only difference is that the entire "form row" is rendered for you,
-    meaning you wouldn't have to wrap it in any container element as it
-    was done above.
-
 Field Options
 -------------