Merge branch '2.3' into 2.4

Conflicts:
	book/translation.rst
	cookbook/configuration/pdo_session_storage.rst

Author: weaverryan

cookbook/assetic/apply_to_option.rst

@@ -119,7 +119,7 @@ work as the regular JavaScript files will not survive the CoffeeScript compilati
 
 This problem can be avoided by using the ``apply_to`` option in the config,
 which allows you to specify that a filter should always be applied to particular
-file extensions. In this case you can specify that the Coffee filter is
+file extensions. In this case you can specify that the ``coffee`` filter is
 applied to all ``.coffee`` files:
 
 .. configuration-block::

cookbook/assetic/asset_management.rst

@@ -352,7 +352,7 @@ in your source, you'll likely just see something like this:
 
 .. code-block:: html
 
-    <script src="/app_dev.php/js/abcd123.js"></script>
+    <script src="/js/abcd123.js"></script>
 
 Moreover, that file does **not** actually exist, nor is it dynamically rendered
 by Symfony (as the asset files are in the ``dev`` environment). This is on

cookbook/assetic/uglifyjs.rst

@@ -104,7 +104,7 @@ your JavaScripts:
     It should output a folder on your system, inside which you should find
     the UglifyJS executable.
 
-    If you installed UglifyJS locally, you can find the bin folder inside
+    If you installed UglifyJS locally, you can find the ``bin`` folder inside
     the ``node_modules`` folder. It's called ``.bin`` in this case.
 
 You now have access to the ``uglifyjs2`` filter in your application.
@@ -175,7 +175,7 @@ and :ref:`dump your assetic assets <cookbook-asetic-dump-prod>`.
 .. tip::
 
     Instead of adding the filter to the asset tags, you can also globally
-    enable it by adding the apply-to attribute to the filter configuration, for
+    enable it by adding the ``apply_to`` attribute to the filter configuration, for
     example in the ``uglifyjs2`` filter ``apply_to: "\.js$"``. To only have
     the filter applied in production, add this to the ``config_prod`` file
     rather than the common config file. For details on applying filters by

cookbook/assetic/yuicompressor.rst

@@ -156,9 +156,9 @@ apply this filter when debug mode is off.
 .. tip::
 
     Instead of adding the filter to the asset tags, you can also globally
-    enable it by adding the apply-to attribute to the filter configuration, for
-    example in the yui_js filter ``apply_to: "\.js$"``. To only have the filter
-    applied in production, add this to the config_prod file rather than the
+    enable it by adding the ``apply_to`` attribute to the filter configuration, for
+    example in the ``yui_js`` filter ``apply_to: "\.js$"``. To only have the filter
+    applied in production, add this to the ``config_prod`` file rather than the
     common config file. For details on applying filters by file extension,
     see :ref:`cookbook-assetic-apply-to`.
 

cookbook/bundles/best_practices.rst

@@ -56,7 +56,7 @@ class name.
 .. note::
 
     Symfony2 core Bundles do not prefix the Bundle class with ``Symfony``
-    and always add a ``Bundle`` subnamespace; for example:
+    and always add a ``Bundle`` sub-namespace; for example:
     :class:`Symfony\\Bundle\\FrameworkBundle\\FrameworkBundle`.
 
 Each bundle has an alias, which is the lower-cased short version of the bundle

cookbook/bundles/extension.rst

@@ -70,7 +70,7 @@ The second method has several specific advantages:
 * Much more powerful than simply defining parameters: a specific option value
   might trigger the creation of many service definitions;
 
-* Ability to have configuration hierarchy
+* Ability to have configuration hierarchy;
 
 * Smart merging when several configuration files (e.g. ``config_dev.yml``
   and ``config.yml``) override each other's configuration;

cookbook/bundles/installation.rst

@@ -36,7 +36,7 @@ this happens, you can try a different version.
 Now you can add the bundle to your ``composer.json`` file and update the
 dependencies. You can do this manually:
 
-1. **Add it to the composer.json file:**
+1. **Add it to the ``composer.json`` file:**
 
    .. code-block:: json
 
@@ -132,7 +132,7 @@ Other Setup
 -----------
 
 At this point, check the ``README`` file of your brand new bundle to see
-what do to next.
+what to do next.
 
 .. _their documentation: http://getcomposer.org/doc/00-intro.md
 .. _Packagist:           https://packagist.org

cookbook/bundles/remove.rst

@@ -56,7 +56,7 @@ Remove the ``_acme_demo`` entry at the bottom of this file.
 
 Some bundles contain configuration in one of the ``app/config/config*.yml``
 files. Be sure to remove the related configuration from these files. You can
-quickly spot bundle configuration by looking at a ``acme_demo`` (or whatever
+quickly spot bundle configuration by looking for a ``acme_demo`` (or whatever
 the name of the bundle is, e.g. ``fos_user`` for the FOSUserBundle) string in
 the configuration files.
 

cookbook/configuration/apache_router.rst

@@ -45,14 +45,14 @@ Symfony2 to use the ``ApacheUrlMatcher`` instead of the default one:
 
     Note that :class:`Symfony\\Component\\Routing\\Matcher\\ApacheUrlMatcher`
     extends :class:`Symfony\\Component\\Routing\\Matcher\\UrlMatcher` so even
-    if you don't regenerate the url_rewrite rules, everything will work (because
+    if you don't regenerate the mod_rewrite rules, everything will work (because
     at the end of ``ApacheUrlMatcher::match()`` a call to ``parent::match()``
     is done).
 
 Generating mod_rewrite rules
 ----------------------------
 
-To test that it's working, let's create a very basic route for demo bundle:
+To test that it's working, let's create a very basic route for the AcmeDemoBundle:
 
 .. configuration-block::
 
@@ -77,7 +77,7 @@ To test that it's working, let's create a very basic route for demo bundle:
             '_controller' => 'AcmeDemoBundle:Demo:hello',
         )));
 
-Now generate **url_rewrite** rules:
+Now generate the mod_rewrite rules:
 
 .. code-block:: bash
 
@@ -95,7 +95,7 @@ Which should roughly output the following:
     RewriteCond %{REQUEST_URI} ^/hello/([^/]+?)$
     RewriteRule .* app.php [QSA,L,E=_ROUTING__route:hello,E=_ROUTING_name:%1,E=_ROUTING__controller:AcmeDemoBundle\:Demo\:hello]
 
-You can now rewrite `web/.htaccess` to use the new rules, so with this example
+You can now rewrite ``web/.htaccess`` to use the new rules, so with this example
 it should look like this:
 
 .. code-block:: apache
@@ -114,10 +114,10 @@ it should look like this:
 
 .. note::
 
-   Procedure above should be done each time you add/change a route if you want to take full advantage of this setup
+   The procedure above should be done each time you add/change a route if you want to take full advantage of this setup.
 
 That's it!
-You're now all set to use Apache Route rules.
+You're now all set to use Apache routes.
 
 Additional tweaks
 -----------------

cookbook/configuration/environments.rst

@@ -333,10 +333,10 @@ includes the following:
 * ``appDevDebugProjectContainer.php`` - the cached "service container" that
   represents the cached application configuration;
 
-* ``appdevUrlGenerator.php`` - the PHP class generated from the routing
+* ``appDevUrlGenerator.php`` - the PHP class generated from the routing
   configuration and used when generating URLs;
 
-* ``appdevUrlMatcher.php`` - the PHP class used for route matching - look
+* ``appDevUrlMatcher.php`` - the PHP class used for route matching - look
   here to see the compiled regular expression logic used to match incoming
   URLs to different routes;
 

cookbook/configuration/external_parameters.rst

@@ -133,8 +133,8 @@ in the container. The following imports a file named ``parameters.php``.
     closure resources are all supported by the ``imports`` directive.
 
 In ``parameters.php``, tell the service container the parameters that you wish
-to set. This is useful when important configuration is in a nonstandard
-format. The example below includes a Drupal database's configuration in
+to set. This is useful when important configuration is in a non-standard
+format. The example below includes a Drupal database configuration in
 the Symfony service container.
 
 .. code-block:: php

cookbook/configuration/front_controllers_and_kernel.rst

@@ -141,7 +141,7 @@ independently (for example, the admin UI, the frontend UI and database migration
 The Environments
 ----------------
 
-We just mentioned another method the ``AppKernel`` has to implement -
+As just mentioned, the ``AppKernel`` has to implement another method -
 :method:`Symfony\\Component\\HttpKernel\\KernelInterface::registerContainerConfiguration`.
 This method is responsible for loading the application's
 configuration from the right *environment*.

cookbook/configuration/pdo_session_storage.rst

@@ -127,7 +127,7 @@ database for the session data.
 
 But if you'd like to store the session data in the same database as the rest
 of your project's data, you can use the connection settings from the
-parameter.ini by referencing the database-related parameters defined there:
+``parameters.yml`` file by referencing the database-related parameters defined there:
 
 .. configuration-block::
 

cookbook/configuration/web_server_configuration.rst

@@ -40,7 +40,7 @@ are:
 
     For performance reasons, you will probably want to set
     ``AllowOverride None`` and implement the rewrite rules in the ``web/.htaccess``
-    into the virtualhost config.
+    into the ``VirtualHost`` config.
 
 If you are using **php-cgi**, Apache does not pass HTTP basic username and
 password to PHP by default. To work around this limitation, you should use the
@@ -53,7 +53,7 @@ following configuration snippet:
 .. caution::
 
     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:
+    and hence you need to modify your ``Directory`` permission settings as follows:
 
         .. code-block:: apache
 

cookbook/console/console_command.rst

@@ -5,8 +5,8 @@ How to create a Console Command
 ===============================
 
 The Console page of the Components section (:doc:`/components/console/introduction`) covers
-how to create a Console command. This cookbook article covers the differences
-when creating Console commands within the Symfony2 framework.
+how to create a console command. This cookbook article covers the differences
+when creating console commands within the Symfony2 framework.
 
 Automatically Registering Commands
 ----------------------------------

cookbook/console/logging.rst

@@ -184,15 +184,15 @@ method, where exception handling should happen:
     }
 
 In the code above, you disable exception catching so the parent ``run`` method
-will throw all exceptions. When an exception is caught, you simple log it by
+will throw all exceptions. When an exception is caught, you simply log it by
 accessing the ``logger`` service from the service container and then handle
 the rest of the logic in the same way that the parent ``run`` method does
 (specifically, since the parent :method:`run <Symfony\\Bundle\\FrameworkBundle\\Console\\Application::run>`
 method will not handle exceptions rendering and status code handling when
 ``catchExceptions`` is set to false, it has to be done in the overridden
 method).
 
-For the extended Application class to work properly with in console shell mode,
+For the extended ``Application`` class to work properly with in console shell mode,
 you have to do a small trick to intercept the ``autoExit`` setter and store the
 setting in a different property, since the parent property is private.
 

cookbook/console/usage.rst

@@ -11,7 +11,7 @@ stack framework, some additional global options are available as well.
 By default, console commands run in the ``dev`` environment and you may want
 to change this for some commands. For example, you may want to run some commands
 in the ``prod`` environment for performance reasons. Also, the result of some commands
-will be different depending on the environment. for example, the ``cache:clear``
+will be different depending on the environment. For example, the ``cache:clear``
 command will clear and warm the cache for the specified environment only. To
 clear and warm the ``prod`` cache you need to run:
 

cookbook/email/dev_environment.rst

@@ -136,13 +136,6 @@ Instead, you can set the ``intercept_redirects`` option to ``true`` in the
 ``config_dev.yml`` file, which will cause the redirect to stop and allow
 you to open the report with details of the sent emails.
 
-.. tip::
-
-    Alternatively, you can open the profiler after the redirect and search
-    by the submit URL used on previous request (e.g. ``/contact/handle``).
-    The profiler's search feature allows you to load the profiler information
-    for any past requests.
-
 .. configuration-block::
 
     .. code-block:: yaml
@@ -171,3 +164,10 @@ you to open the report with details of the sent emails.
         $container->loadFromExtension('web_profiler', array(
             'intercept_redirects' => 'true',
         ));
+
+.. tip::
+
+    Alternatively, you can open the profiler after the redirect and search
+    by the submit URL used on the previous request (e.g. ``/contact/handle``).
+    The profiler's search feature allows you to load the profiler information
+    for any past requests.

cookbook/form/create_custom_field_type.rst

@@ -16,7 +16,7 @@ Defining the Field Type
 
 In order to create the custom field type, first you have to create the class
 representing the field. In this situation the class holding the field type
-will be called `GenderType` and the file will be stored in the default location
+will be called ``GenderType`` and the file will be stored in the default location
 for form fields, which is ``<BundleName>\Form\Type``. Make sure the field extends
 :class:`Symfony\\Component\\Form\\AbstractType`::
 

cookbook/form/create_form_type_extension.rst

@@ -178,7 +178,7 @@ database)::
 Your form type extension class will need to do two things in order to extend
 the ``file`` form type:
 
-#. Override the ``setDefaultOptions`` method in order to add an image_path
+#. Override the ``setDefaultOptions`` method in order to add an ``image_path``
    option;
 #. Override the ``buildForm`` and ``buildView`` methods in order to pass the image
    URL to the view.

cookbook/form/data_transformers.rst

@@ -20,8 +20,8 @@ This is where Data Transformers come into play.
 Creating the Transformer
 ------------------------
 
-First, create an `IssueToNumberTransformer` class - this class will be responsible
-for converting to and from the issue number and the Issue object::
+First, create an ``IssueToNumberTransformer`` class - this class will be responsible
+for converting to and from the issue number and the ``Issue`` object::
 
     // src/Acme/TaskBundle/Form/DataTransformer/IssueToNumberTransformer.php
     namespace Acme\TaskBundle\Form\DataTransformer;
@@ -129,17 +129,16 @@ issue field in some form.
 
             public function setDefaultOptions(OptionsResolverInterface $resolver)
             {
-                $resolver->setDefaults(array(
-                    'data_class' => 'Acme\TaskBundle\Entity\Task',
-                ));
-
-                $resolver->setRequired(array(
-                    'em',
-                ));
-
-                $resolver->setAllowedTypes(array(
-                    'em' => 'Doctrine\Common\Persistence\ObjectManager',
-                ));
+                $resolver
+                    ->setDefaults(array(
+                        'data_class' => 'Acme\TaskBundle\Entity\Task',
+                    ))
+                    ->setRequired(array(
+                        'em',
+                    ))
+                    ->setAllowedTypes(array(
+                        'em' => 'Doctrine\Common\Persistence\ObjectManager',
+                    ));
 
                 // ...
             }
@@ -234,7 +233,7 @@ In the above example, you applied the transformer to a normal ``text`` field.
 This was easy, but has two downsides:
 
 1) You need to always remember to apply the transformer whenever you're adding
-a field for issue numbers
+a field for issue numbers.
 
 2) You need to worry about passing in the ``em`` option whenever you're creating
 a form that uses the transformer.

cookbook/form/dynamic_form_modification.rst

@@ -83,9 +83,9 @@ flexibility to your forms.
 Adding An Event Subscriber To A Form Class
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-So, instead of directly adding that "name" widget via your ProductType form
+So, instead of directly adding that "name" widget via your ``ProductType`` form
 class, let's delegate the responsibility of creating that particular field
-to an Event Subscriber::
+to an event subscriber::
 
     // src/Acme/DemoBundle/Form/Type/ProductType.php
     namespace Acme\DemoBundle\Form\Type;
@@ -237,7 +237,7 @@ done in the constructor::
 Customizing the Form Type
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Now that you have all the basics in place you an take advantage of the ``securityContext``
+Now that you have all the basics in place you can take advantage of the ``SecurityContext``
 and fill in the listener logic::
 
     // src/Acme/DemoBundle/FormType/FriendMessageFormType.php

cookbook/form/form_collections.rst

@@ -237,7 +237,7 @@ When the user submits the form, the submitted data for the ``tags`` field are
 used to construct an ``ArrayCollection`` of ``Tag`` objects, which is then set
 on the ``tag`` field of the ``Task`` instance.
 
-The ``Tags`` collection is accessible naturally via ``$task->getTags()``
+The ``tags`` collection is accessible naturally via ``$task->getTags()``
 and can be persisted to the database or used however you need.
 
 So far, this works great, but this doesn't allow you to dynamically add new
@@ -407,7 +407,7 @@ one example:
 
 .. note::
 
-    It is better to separate your javascript in real JavaScript files than
+    It is better to separate your JavaScript in real JavaScript files than
     to write it inside the HTML as is done here.
 
 Now, each time a user clicks the ``Add a tag`` link, a new sub form will