[RFR] Misc. minor fixes mostly related to formatting issues

book/doctrine.rst

@@ -413,12 +413,12 @@ doesn't replace your existing methods).
 
     With the ``doctrine:generate:entities`` command you can:
 
-        * generate getters and setters;
+    * generate getters and setters;
 
-        * generate repository classes configured with the
-            ``@ORM\Entity(repositoryClass="...")`` annotation;
+    * generate repository classes configured with the
+        ``@ORM\Entity(repositoryClass="...")`` annotation;
 
-        * generate the appropriate constructor for 1:n and n:m relations.
+    * generate the appropriate constructor for 1:n and n:m relations.
 
     The ``doctrine:generate:entities`` command saves a backup of the original
     ``Product.php`` named ``Product.php~``. In some cases, the presence of

book/http_cache.rst

@@ -1034,7 +1034,7 @@ Cache Invalidation
 ------------------
 
     "There are only two hard things in Computer Science: cache invalidation
-    and naming things." --Phil Karlton
+    and naming things." — Phil Karlton
 
 You should never need to invalidate cached data because invalidation is already
 taken into account natively in the HTTP cache models. If you use validation,

book/routing.rst

@@ -850,7 +850,9 @@ uses a simple string pattern called the *logical controller name*, which
 Symfony maps to a specific PHP method and class. The pattern has three parts,
 each separated by a colon:
 
-    **bundle**:**controller**:**action**
+.. code-block:: text
+
+    bundle:controller:action
 
 For example, a ``_controller`` value of ``AcmeBlogBundle:Blog:show`` means:
 

book/templating.rst

@@ -75,19 +75,17 @@ to web designers and, in several ways, more powerful than PHP templates:
         </body>
     </html>
 
-Twig defines two types of special syntax:
+Twig defines three types of special syntax:
 
 * ``{{ ... }}``: "Says something": prints a variable or the result of an
   expression to the template;
 
 * ``{% ... %}``: "Does something": a **tag** that controls the logic of the
   template; it is used to execute statements such as for-loops for example.
 
-.. note::
-
-   There is a third syntax used for creating comments: ``{# this is a comment #}``.
-   This syntax can be used across multiple lines like the PHP-equivalent
-   ``/* comment */`` syntax.
+* ``{# ... #}``: "Comment something": it's the equivalent of the PHP
+  ``/* comment */`` syntax. It's used to add single or multi-line comments.
+  The content of the comments isn't included in the rendered pages.
 
 Twig also contains **filters**, which modify content before being rendered.
 The following makes the ``title`` variable all uppercase before rendering
@@ -399,14 +397,14 @@ lives in a specific location:
   template for a specific page. The three parts of the string, each separated
   by a colon (``:``), mean the following:
 
-    * ``AcmeBlogBundle``: (*bundle*) the template lives inside the
-      ``AcmeBlogBundle`` (e.g. ``src/Acme/BlogBundle``);
+  * ``AcmeBlogBundle``: (*bundle*) the template lives inside the
+    ``AcmeBlogBundle`` (e.g. ``src/Acme/BlogBundle``);
 
-    * ``Blog``: (*controller*) indicates that the template lives inside the
-      ``Blog`` subdirectory of ``Resources/views``;
+  * ``Blog``: (*controller*) indicates that the template lives inside the
+    ``Blog`` subdirectory of ``Resources/views``;
 
-    * ``index.html.twig``: (*template*) the actual name of the file is
-      ``index.html.twig``.
+  * ``index.html.twig``: (*template*) the actual name of the file is
+    ``index.html.twig``.
 
   Assuming that the ``AcmeBlogBundle`` lives at ``src/Acme/BlogBundle``, the
   final path to the layout would be ``src/Acme/BlogBundle/Resources/views/Blog/index.html.twig``.

cookbook/configuration/environments.rst

@@ -287,12 +287,12 @@ The new environment is now accessible via::
 
 .. note::
 
-   Some environments, like the ``dev`` environment, are never meant to be
-   accessed on any deployed server by the general public. This is because
-   certain environments, for debugging purposes, may give too much information
-   about the application or underlying infrastructure. To be sure these environments
-   aren't accessible, the front controller is usually protected from external
-   IP addresses via the following code at the top of the controller:
+    Some environments, like the ``dev`` environment, are never meant to be
+    accessed on any deployed server by the general public. This is because
+    certain environments, for debugging purposes, may give too much information
+    about the application or underlying infrastructure. To be sure these environments
+    aren't accessible, the front controller is usually protected from external
+    IP addresses via the following code at the top of the controller:
 
     .. code-block:: php
 
@@ -315,8 +315,12 @@ However, each environment caches its own set of files:
 
 .. code-block:: text
 
-    app/cache/dev   - cache directory for the *dev* environment
-    app/cache/prod  - cache directory for the *prod* environment
+    <your-project>/
+    ├─ app/
+    │  ├─ cache/
+    │  │  ├─ dev/   // cache directory for the *dev* environment
+    │  │  └─ prod/  // cache directory for the *prod* environment
+    │  ├─ ...
 
 Sometimes, when debugging, it may be helpful to inspect a cached file to
 understand how something is working. When doing so, remember to look in

cookbook/configuration/web_server_configuration.rst

@@ -55,13 +55,13 @@ following configuration snippet:
     In Apache 2.4, ``Order allow,deny`` has been replaced by ``Require all granted``,
     and hence you need to modify your ``Directory`` permission settings as follows:
 
-        .. code-block:: apache
+    .. code-block:: apache
 
-            <Directory /var/www/project/web>
-                # enable the .htaccess rewrites
-                AllowOverride All
-                Require all granted
-            </Directory>
+        <Directory /var/www/project/web>
+            # enable the .htaccess rewrites
+            AllowOverride All
+            Require all granted
+        </Directory>
 
 Nginx
 -----

cookbook/form/data_transformers.rst

@@ -109,49 +109,49 @@ Using the Transformer
 Now that you have the transformer built, you just need to add it to your
 issue field in some form.
 
-    You can also use transformers without creating a new custom form type
-    by calling ``addModelTransformer`` (or ``addViewTransformer`` - see
-    `Model and View Transformers`_) on any field builder::
+You can also use transformers without creating a new custom form type
+by calling ``addModelTransformer`` (or ``addViewTransformer`` - see
+`Model and View Transformers`_) on any field builder::
 
-        use Symfony\Component\Form\FormBuilderInterface;
-        use Acme\TaskBundle\Form\DataTransformer\IssueToNumberTransformer;
+    use Symfony\Component\Form\FormBuilderInterface;
+    use Acme\TaskBundle\Form\DataTransformer\IssueToNumberTransformer;
 
-        class TaskType extends AbstractType
+    class TaskType extends AbstractType
+    {
+        public function buildForm(FormBuilderInterface $builder, array $options)
         {
-            public function buildForm(FormBuilderInterface $builder, array $options)
-            {
-                // ...
-
-                // this assumes that the entity manager was passed in as an option
-                $entityManager = $options['em'];
-                $transformer = new IssueToNumberTransformer($entityManager);
-
-                // add a normal text field, but add your transformer to it
-                $builder->add(
-                    $builder->create('issue', 'text')
-                        ->addModelTransformer($transformer)
-                );
-            }
+            // ...
 
-            public function setDefaultOptions(OptionsResolverInterface $resolver)
-            {
-                $resolver
-                    ->setDefaults(array(
-                        'data_class' => 'Acme\TaskBundle\Entity\Task',
-                    ))
-                    ->setRequired(array(
-                        'em',
-                    ))
-                    ->setAllowedTypes(array(
-                        'em' => 'Doctrine\Common\Persistence\ObjectManager',
-                    ));
-
-                // ...
-            }
+            // this assumes that the entity manager was passed in as an option
+            $entityManager = $options['em'];
+            $transformer = new IssueToNumberTransformer($entityManager);
+
+            // add a normal text field, but add your transformer to it
+            $builder->add(
+                $builder->create('issue', 'text')
+                    ->addModelTransformer($transformer)
+            );
+        }
+
+        public function setDefaultOptions(OptionsResolverInterface $resolver)
+        {
+            $resolver
+                ->setDefaults(array(
+                    'data_class' => 'Acme\TaskBundle\Entity\Task',
+                ))
+                ->setRequired(array(
+                    'em',
+                ))
+                ->setAllowedTypes(array(
+                    'em' => 'Doctrine\Common\Persistence\ObjectManager',
+                ));
 
             // ...
         }
 
+        // ...
+    }
+
 This example requires that you pass in the entity manager as an option
 when creating your form. Later, you'll learn how you could create a custom
 ``issue`` field type to avoid needing to do this in your controller::