symfony · ThomasLandauer · Jun 28, 2015 · Jun 30, 2015 · Jul 2, 2015 · Jul 2, 2015
diff --git a/book/doctrine.rst b/book/doctrine.rst
@@ -951,8 +951,6 @@ To relate the ``Category`` and ``Product`` entities, start by creating a
                 products:
                     targetEntity: Product
                     mappedBy: category
-            # don't forget to init the collection in the __construct() method
-            # of the entity
 
     .. code-block:: xml
 
@@ -1094,7 +1092,7 @@ table, and ``product.category_id`` column, and new foreign key:
 
 .. note::
 
-    This task should only be really used during development. For a more robust
+    This command should only be used during development. For a more robust
     method of systematically updating your production database, read about
     `migrations`_.
 
@@ -1185,7 +1183,7 @@ You can also query in the other direction::
         // ...
     }
 
-In this case, the same things occurs: you first query out for a single ``Category``
+In this case, the same things occur: you first query out for a single ``Category``
 object, and then Doctrine makes a second query to retrieve the related ``Product``
 objects, but only once/if you ask for them (i.e. when you call ``->getProducts()``).
 The ``$products`` variable is an array of all ``Product`` objects that relate

diff --git a/book/forms.rst b/book/forms.rst
@@ -97,7 +97,7 @@ from inside a controller::
                 ->getForm();
 
             return $this->render('default/new.html.twig', array(
-                'form' => $form->createView(),
+                'form' => $form->createView()
             ));
         }
     }
@@ -212,7 +212,7 @@ Handling Form Submissions
 
 The second job of a form is to translate user-submitted data back to the
 properties of an object. To make this happen, the submitted data from the
-user must be written into the form. Add the following functionality to your
+user must be written into ``$form``. Add the following functionality to your
 controller::
 
     // ...
@@ -669,9 +669,12 @@ the documentation for each type.
     The most common option is the ``required`` option, which can be applied to
     any field. By default, the ``required`` option is set to ``true``, meaning
     that HTML5-ready browsers will apply client-side validation if the field
-    is left blank. If you don't want this behavior, either set the ``required``
-    option on your field to ``false`` or
-    :ref:`disable HTML5 validation <book-forms-html5-validation-disable>`.
+    is left blank. If you don't want this behavior, either
+    :ref:`disable HTML5 validation <book-forms-html5-validation-disable>`
+    or set the ``required`` option on your field to ``false``:
+
+      ->add('dueDate', 'date', array('widget' => 'single_text',
+      'required' => false))
 
     Also note that setting the ``required`` option to ``true`` will **not**
     result in server-side validation to be applied. In other words, if a
@@ -910,7 +913,7 @@ specify it:
 
 Some field types have additional rendering options that can be passed
 to the widget. These options are documented with each type, but one common
-options is ``attr``, which allows you to modify attributes on the form element.
+option is ``attr``, which allows you to modify attributes on the form element.
 The following would add the ``task_field`` class to the rendered input text
 field:
 

diff --git a/book/templating.rst b/book/templating.rst
@@ -201,7 +201,7 @@ First, build a base layout file:
         <!DOCTYPE html>
         <html>
             <head>
-                <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+                <meta charset="UTF-8">
                 <title>{% block title %}Test Application{% endblock %}</title>
             </head>
             <body>
@@ -226,7 +226,7 @@ First, build a base layout file:
         <!DOCTYPE html>
         <html>
             <head>
-                <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+                <meta charset="UTF-8">
                 <title><?php $view['slots']->output('title', 'Test Application') ?></title>
             </head>
             <body>
@@ -311,7 +311,7 @@ output might look like this:
     <!DOCTYPE html>
     <html>
         <head>
-            <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+            <meta charset="UTF-8">
             <title>My cool blog posts</title>
         </head>
         <body>
@@ -370,6 +370,19 @@ When working with template inheritance, here are some tips to keep in mind:
           {{ parent() }}
       {% endblock %}
 
+* Blocks can be nested. For better overview, you can add the block name to the
+  ``{% endblock %}`` tag like this:
+
+  .. code-block:: html+jinja
+
+      {% block foo %}
+          {# ... #}
+          {% block bar %}
+              {# ... #}
+          {% endblock bar %}
+          {# ... #}
+      {% endblock foo %}
+
 .. index::
    single: Templating; Naming conventions
    single: Templating; File locations

diff --git a/cookbook/form/form_customization.rst b/cookbook/form/form_customization.rst
@@ -282,7 +282,7 @@ can now re-use the form customization across many templates:
 
 .. code-block:: html+jinja
 
-    {# app/Resources/views/Form/fields.html.twig #}
+    {# src/AppBundle/Resources/views/Form/fields.html.twig #}
     {% block integer_widget %}
         <div class="integer_widget">
             {% set type = type|default('number') %}