Merge branch '2.3' into 2.7

Conflicts:
	reference/twig_reference.rst

Author: xabbuh

best_practices/configuration.rst

@@ -128,7 +128,7 @@ from places with access to the Symfony container.
 Constants can be used for example in your Twig templates thanks to the
 `constant() function`_:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     <p>
         Displaying the {{ constant('NUM_ITEMS', post) }} most recent results.

best_practices/forms.rst

@@ -137,7 +137,7 @@ This is also an important error, because you are mixing presentation markup
 always a good practice to follow, so put all the view-related things in the
 view layer:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     {{ form_start(form) }}
         {{ form_widget(form) }}
@@ -157,7 +157,7 @@ One of the simplest ways - which is especially useful during development -
 is to render the form tags and use ``form_widget()`` to render all of the
 fields:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     {{ form_start(form, {'attr': {'class': 'my-form-class'} }) }}
         {{ form_widget(form) }}

best_practices/web-assets.rst

@@ -16,7 +16,7 @@ the application assets are in one location.
 Templates also benefit from centralizing your assets, because the links are
 much more concise:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     <link rel="stylesheet" href="{{ asset('css/bootstrap.min.css') }}" />
     <link rel="stylesheet" href="{{ asset('css/main.css') }}" />
@@ -54,7 +54,7 @@ of compiling assets developed with a lot of different frontend technologies
 like LESS, Sass and CoffeeScript. Combining all your assets with Assetic is a
 matter of wrapping all the assets with a single Twig tag:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     {% stylesheets
         'css/bootstrap.min.css'

book/controller.rst

@@ -659,7 +659,7 @@ read any flash messages from the session::
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {% for flash_message in app.session.flashbag.get('notice') %}
             <div class="flash-notice">

book/forms.rst

@@ -142,7 +142,7 @@ helper functions:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {# app/Resources/views/default/new.html.twig #}
         {{ form_start(form) }}
@@ -450,7 +450,7 @@ corresponding errors printed out with the form.
 
    .. configuration-block::
 
-       .. code-block:: html+jinja
+       .. code-block:: html+twig
 
            {# app/Resources/views/default/new.html.twig #}
            {{ form(form, {'attr': {'novalidate': 'novalidate'}}) }}
@@ -798,7 +798,7 @@ of code. Of course, you'll usually need much more flexibility when rendering:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {# app/Resources/views/default/new.html.twig #}
         {{ form_start(form) }}
@@ -840,7 +840,7 @@ output can be customized on many different levels.
 
     .. configuration-block::
 
-        .. code-block:: jinja
+        .. code-block:: twig
 
             {{ form.vars.value.task }}
 
@@ -862,7 +862,7 @@ used the ``form_row`` helper:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {{ form_start(form) }}
             {{ form_errors(form) }}
@@ -914,7 +914,7 @@ specify it:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {{ form_label(form.task, 'Task Description') }}
 
@@ -930,7 +930,7 @@ field:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {{ form_widget(form.task, {'attr': {'class': 'task_field'}}) }}
 
@@ -946,7 +946,7 @@ to get the ``id``:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {{ form.task.vars.id }}
 
@@ -959,7 +959,7 @@ the ``full_name`` value:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {{ form.task.vars.full_name }}
 
@@ -1016,7 +1016,7 @@ to the ``form()`` or the ``form_start()`` helper:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {# app/Resources/views/default/new.html.twig #}
         {{ form_start(form, {'action': path('target_route'), 'method': 'GET'}) }}
@@ -1390,7 +1390,7 @@ Render the ``Category`` fields in the same way as the original ``Task`` fields:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {# ... #}
 
@@ -1459,7 +1459,7 @@ do this, create a new template file that will store the new markup:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {# app/Resources/views/form/fields.html.twig #}
         {% block form_row %}
@@ -1488,7 +1488,7 @@ renders the form:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {# app/Resources/views/default/new.html.twig #}
         {% form_theme form 'form/fields.html.twig' %}
@@ -1672,7 +1672,7 @@ to define form output.
     In Twig, you can also customize a form block right inside the template
     where that customization is needed:
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {% extends 'base.html.twig' %}
 

book/from_flat_php_to_symfony2.rst

@@ -710,7 +710,7 @@ called `Twig`_ that makes templates faster to write and easier to read.
 It means that the sample application could contain even less code! Take,
 for example, the list template written in Twig:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     {# app/Resources/views/blog/list.html.twig #}
     {% extends "layout.html.twig" %}
@@ -732,7 +732,7 @@ for example, the list template written in Twig:
 
 The corresponding ``layout.html.twig`` template is also easier to write:
 
-.. code-block:: html+jinja
+.. code-block:: html+twig
 
     {# app/Resources/views/layout.html.twig #}
     <!DOCTYPE html>

book/http_cache.rst

@@ -1073,7 +1073,7 @@ matter), Symfony uses the standard ``render`` helper to configure ESI tags:
 
 .. configuration-block::
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {# app/Resources/views/static/about.html.twig #}
 

book/page_creation.rst

@@ -374,7 +374,7 @@ a ``number.html.twig`` file inside of it:
 
 .. configuration-block::
 
-    .. code-block:: jinja
+    .. code-block:: twig
 
         {# app/Resources/views/lucky/number.html.twig #}
         {% extends 'base.html.twig' %}

book/routing.rst

@@ -1534,7 +1534,7 @@ a template helper function:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         <a href="{{ path('blog_show', {'slug': 'my-blog-post'}) }}">
           Read this blog post.
@@ -1567,7 +1567,7 @@ to ``generate()``:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         <a href="{{ url('blog_show', {'slug': 'my-blog-post'}) }}">
           Read this blog post.

book/security.rst

@@ -888,7 +888,7 @@ the built-in helper function:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {% if is_granted('ROLE_ADMIN') %}
             <a href="...">Delete</a>
@@ -910,7 +910,7 @@ covers all URLs (as shown before in this chapter).
     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
+    .. code-block:: html+twig
 
         {% if app.user and is_granted('ROLE_ADMIN') %}
 
@@ -1085,7 +1085,7 @@ key:
 
 .. configuration-block::
 
-    .. code-block:: html+jinja
+    .. code-block:: html+twig
 
         {% if is_granted('IS_AUTHENTICATED_FULLY') %}
             <p>Username: {{ app.user.username }}</p>