Merge branch '2.2' into 2.3

Conflicts:
	cookbook/form/form_collections.rst

Author: weaverryan

book/doctrine.rst

@@ -1087,7 +1087,7 @@ in a way that makes sense for your needs. The fact that the data needs to
 be persisted to a database is always secondary.
 
 Now, look at the metadata above the ``$category`` property on the ``Product``
-class. The information here tells doctrine that the related class is ``Category``
+class. The information here tells Doctrine that the related class is ``Category``
 and that it should store the ``id`` of the category record on a ``category_id``
 field that lives on the ``product`` table. In other words, the related ``Category``
 object will be stored on the ``$category`` property, but behind the scenes,
@@ -1285,7 +1285,7 @@ More Information on Associations
 
 This section has been an introduction to one common type of entity relationship,
 the one-to-many relationship. For more advanced details and examples of how
-to use other types of relations (e.g. ``one-to-one``, ``many-to-many``), see
+to use other types of relations (e.g. one-to-one, many-to-many), see
 Doctrine's `Association Mapping Documentation`_.
 
 .. note::

book/forms.rst

@@ -1475,7 +1475,7 @@ Form Fragment Naming
 ~~~~~~~~~~~~~~~~~~~~
 
 In Symfony, every part of a form that is rendered - HTML form elements, errors,
-labels, etc - is defined in a base theme, which is a collection of blocks
+labels, etc. - is defined in a base theme, which is a collection of blocks
 in Twig and a collection of template files in PHP.
 
 In Twig, every block needed is defined in a single template file (`form_div_layout.html.twig`_)

components/console/helpers/dialoghelper.rst

@@ -141,8 +141,8 @@ in the last argument. Using ``false`` means the amount of attempts is infinite.
 The user will be asked as long as he provides an invalid answer and will only
 be able to proceed if her input is valid.
 
-Hiding the User's Response
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+Validating a Hidden Response
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. versionadded:: 2.2
     The ``askHiddenResponseAndValidate`` method was added in Symfony 2.2.

cookbook/configuration/pdo_session_storage.rst

@@ -16,7 +16,7 @@ configuration format of your choice):
 
 .. versionadded:: 2.1
     In Symfony 2.1 the class and namespace are slightly modified. You can now
-    find the session storage classes in the `Session\\Storage` namespace:
+    find the session storage classes in the ``Session\Storage`` namespace:
     ``Symfony\Component\HttpFoundation\Session\Storage``. Also
     note that in Symfony 2.1 you should configure ``handler_id`` not ``storage_id`` like in Symfony 2.0.
     Below, you'll notice that ``%session.storage.options%`` is not used anymore.

cookbook/doctrine/event_listeners_subscribers.rst

@@ -157,15 +157,15 @@ entity), you should check for the entity's class type in your method
 Creating the Subscriber Class
 -----------------------------
 
-A doctrine event subscriber must implement the ``Doctrine\Common\EventSubscriber``
+A Doctrine event subscriber must implement the ``Doctrine\Common\EventSubscriber``
 interface and have an event method for each event it subscribes to::
 
     // src/Acme/SearchBundle/EventListener/SearchIndexerSubscriber.php
     namespace Acme\SearchBundle\EventListener;
 
     use Doctrine\Common\EventSubscriber;
     use Doctrine\ORM\Event\LifecycleEventArgs;
-    // for doctrine 2.4: Doctrine\Common\Persistence\Event\LifecycleEventArgs;
+    // for Doctrine 2.4: Doctrine\Common\Persistence\Event\LifecycleEventArgs;
     use Acme\StoreBundle\Entity\Product;
 
     class SearchIndexerSubscriber implements EventSubscriber

cookbook/doctrine/file_uploads.rst

@@ -13,15 +13,15 @@ If you choose to, you can also integrate the file upload into your entity
 lifecycle (i.e. creation, update and removal). In this case, as your entity
 is created, updated, and removed from Doctrine, the file uploading and removal
 processing will take place automatically (without needing to do anything in
-your controller);
+your controller).
 
 To make this work, you'll need to take care of a number of details, which
 will be covered in this cookbook entry.
 
 Basic Setup
 -----------
 
-First, create a simple ``Doctrine`` Entity class to work with::
+First, create a simple Doctrine entity class to work with::
 
     // src/Acme/DemoBundle/Entity/Document.php
     namespace Acme\DemoBundle\Entity;
@@ -427,7 +427,7 @@ call to ``$document->upload()`` should be removed from the controller::
 .. caution::
 
     The ``PreUpdate`` and ``PostUpdate`` callbacks are only triggered if there
-    is a change in one of the entity's field that are persisted. This means
+    is a change in one of the entity's fields that are persisted. This means
     that, by default, if you modify only the ``$file`` property, these events
     will not be triggered, as the property itself is not directly persisted
     via Doctrine. One solution would be to use an ``updated`` field that's

cookbook/doctrine/multiple_entity_managers.rst

@@ -200,7 +200,7 @@ You can now use Doctrine just as you did before - using the ``default`` entity
 manager to persist and fetch entities that it manages and the ``customer``
 entity manager to persist and fetch its entities.
 
-The same applies to repository call::
+The same applies to repository calls::
 
     class UserController extends Controller
     {
@@ -225,3 +225,4 @@ The same applies to repository call::
             ;
         }
     }
+

cookbook/doctrine/registration_form.rst

@@ -90,7 +90,7 @@ the class.
 
 .. sidebar:: Why the 4096 Password Limit?
 
-    Notice that the ``plainPassword`` has a max length of ``4096`` characters.
+    Notice that the ``plainPassword`` field has a max length of 4096 characters.
     For security purposes (`CVE-2013-5750`_), Symfony limits the plain password
     length to 4096 characters when encoding it. Adding this constraint makes
     sure that your form will give a validation error if anyone tries a super-long
@@ -139,8 +139,8 @@ Next, create the form for the ``User`` model::
     }
 
 There are just two fields: ``email`` and ``plainPassword`` (repeated to confirm
-the entered password). The ``data_class`` option tells the form the name of
-data class (i.e. your ``User`` entity).
+the entered password). The ``data_class`` option tells the form the name of the
+underlying data class (i.e. your ``User`` entity).
 
 .. tip::
 
@@ -224,7 +224,7 @@ Next, create the form for this ``Registration`` model::
         }
     }
 
-You don't need to use special method for embedding the ``UserType`` form.
+You don't need to use a special method for embedding the ``UserType`` form.
 A form is a field, too - so you can add this like any other field, with the
 expectation that the ``Registration.user`` property will hold an instance
 of the ``User`` class.
@@ -260,7 +260,7 @@ controller for displaying the registration form::
         }
     }
 
-and its template:
+And its template:
 
 .. code-block:: html+jinja
 
@@ -352,6 +352,8 @@ Update your Database Schema
 Of course, since you've added a ``User`` entity during this tutorial, make
 sure that your database schema has been updated properly:
 
+.. code-block:: bash
+
    $ php app/console doctrine:schema:update --force
 
 That's it! Your form now validates, and allows you to save the ``User``

cookbook/doctrine/reverse_engineering.rst

@@ -167,9 +167,9 @@ entity in the ``BlogComment`` entity class.
 
 .. note::
 
-    If you want to have a ``oneToMany`` relationship, you will need to add
-    it manually into the entity or to the generated ``xml`` or ``yml`` files.
-    Add a section on the specific entities for ``oneToMany`` defining the
+    If you want to have a one-to-many relationship, you will need to add
+    it manually into the entity or to the generated XML or YAML files.
+    Add a section on the specific entities for one-to-many defining the
     ``inversedBy`` and the ``mappedBy`` pieces.
 
 The generated entities are now ready to be used. Have fun!

cookbook/form/dynamic_form_modification.rst

@@ -348,7 +348,7 @@ it with :ref:`dic-tags-form-type`.
         services:
             acme.form.friend_message:
                 class: Acme\DemoBundle\Form\Type\FriendMessageFormType
-                arguments: [@security.context]
+                arguments: ["@security.context"]
                 tags:
                     -
                         name: form.type

cookbook/form/form_collections.rst

@@ -555,7 +555,7 @@ we talk about next!).
             }
         }
 
-    If you have a ``OneToMany`` relationship, then the workaround is similar,
+    If you have a one-to-many relationship, then the workaround is similar,
     except that you can simply call ``setTask`` from inside ``addTag``.
 
 .. _cookbook-form-collections-remove:
@@ -652,11 +652,11 @@ the relationship between the removed ``Tag`` and ``Task`` object.
     ``Tag`` is properly removed.
 
     In Doctrine, you have two side of the relationship: the owning side and the
-    inverse side. Normally in this case you'll have a ``ManyToMany`` relation
+    inverse side. Normally in this case you'll have a many-to-many relation
     and the deleted tags will disappear and persist correctly (adding new
     tags also works effortlessly).
 
-    But if you have an ``OneToMany`` relation or a ``ManyToMany`` with a
+    But if you have an one-to-many relation or a many-to-many with a
     ``mappedBy`` on the Task entity (meaning Task is the "inverse" side),
     you'll need to do more work for the removed tags to persist correctly.
 
@@ -703,7 +703,7 @@ the relationship between the removed ``Tag`` and ``Task`` object.
                     // remove the Task from the Tag
                     $tag->getTasks()->removeElement($task);
 
-                    // if it were a ManyToOne relationship, remove the relationship like this
+                    // if it were a many-to-one relationship, remove the relationship like this
                     // $tag->setTask(null);
 
                     $em->persist($tag);
@@ -723,7 +723,7 @@ the relationship between the removed ``Tag`` and ``Task`` object.
         }
 
     As you can see, adding and removing the elements correctly can be tricky.
-    Unless you have a ManyToMany relationship where Task is the "owning" side,
+    Unless you have a many-to-many relationship where Task is the "owning" side,
     you'll need to do extra work to make sure that the relationship is properly
     updated (whether you're adding new tags or removing existing tags) on
     each Tag object itself.

cookbook/profiler/matchers.rst

@@ -101,7 +101,7 @@ Then, you need to configure the service:
         services:
             acme_demo.profiler.matcher.super_admin:
                 class: "%acme_demo.profiler.matcher.super_admin.class%"
-                arguments: [@security.context]
+                arguments: ["@security.context"]
 
     .. code-block:: xml
 

cookbook/security/acl_advanced.rst

@@ -53,8 +53,10 @@ tables are ordered from least rows to most rows in a typical application:
 
 - *acl_security_identities*: This table records all security identities (SID)
   which hold ACEs. The default implementation ships with two security
-  identities: ``RoleSecurityIdentity``, and ``UserSecurityIdentity``
-- *acl_classes*: This table maps class names to a unique id which can be
+  identities:
+  :class:`Symfony\\Component\\Security\\Acl\\Domain\\RoleSecurityIdentity` and
+  :class:`Symfony\\Component\\Security\\Acl\\Domain\\UserSecurityIdentity`.
+- *acl_classes*: This table maps class names to a unique ID which can be
   referenced from other tables.
 - *acl_object_identities*: Each row in this table represents a single domain
   object instance.
@@ -173,12 +175,13 @@ Process for Reaching Authorization Decisions
 The ACL class provides two methods for determining whether a security identity
 has the required bitmasks, ``isGranted`` and ``isFieldGranted``. When the ACL
 receives an authorization request through one of these methods, it delegates
-this request to an implementation of PermissionGrantingStrategy. This allows
-you to replace the way access decisions are reached without actually modifying
-the ACL class itself.
+this request to an implementation of
+:class:`Symfony\\Component\\Security\\Acl\\Domain\\PermissionGrantingStrategy`.
+This allows you to replace the way access decisions are reached without actually
+modifying the ACL class itself.
 
-The PermissionGrantingStrategy first checks all your object-scope ACEs if none
-is applicable, the class-scope ACEs will be checked, if none is applicable,
+The ``PermissionGrantingStrategy`` first checks all your object-scope ACEs. If none
+is applicable, the class-scope ACEs will be checked. If none is applicable,
 then the process will be repeated with the ACEs of the parent ACL. If no
 parent ACL exists, an exception will be thrown.
 

cookbook/security/custom_authentication_provider.rst

@@ -281,7 +281,7 @@ The Factory
 
 You have created a custom token, custom listener, and custom provider. Now
 you need to tie them all together. How do you make your provider available
-to your security configuration? The answer is by using a ``factory``. A factory
+to your security configuration? The answer is by using a *factory*. A factory
 is where you hook into the Security component, telling it the name of your
 provider and any configuration options available for it. First, you must
 create a class which implements
@@ -528,7 +528,7 @@ the ``addConfiguration`` method.
     }
 
 Now, in the ``create`` method of the factory, the ``$config`` argument will
-contain a 'lifetime' key, set to 5 minutes (300 seconds) unless otherwise
+contain a ``lifetime`` key, set to 5 minutes (300 seconds) unless otherwise
 set in the configuration. Pass this argument to your authentication provider
 in order to put it to use.
 

cookbook/security/custom_provider.rst

@@ -276,7 +276,7 @@ users, e.g. by filling in a login form. You can do this by adding a line to the
 
 The value here should correspond with however the passwords were originally
 encoded when creating your users (however those users were created). When
-a user submits her password, the password is appended to the salt value and
+a user submits her password, the salt value is appended to the password and
 then encoded using this algorithm before being compared to the hashed password
 returned by your ``getPassword()`` method. Additionally, depending on your
 options, the password may be encoded multiple times and encoded to base64.

cookbook/security/entity_provider.rst

@@ -237,7 +237,7 @@ then be checked against your User entity records in the database:
 
             role_hierarchy:
                 ROLE_ADMIN:       ROLE_USER
-                ROLE_SUPER_ADMIN: [ ROLE_USER, ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH ]
+                ROLE_SUPER_ADMIN: [ ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH ]
 
             providers:
                 administrators:

cookbook/security/target_path.rst

@@ -19,7 +19,7 @@ class and override the default method named ``setTargetPath()``.
 
 First, override the ``security.exception_listener.class`` parameter in your
 configuration file. This can be done from your main configuration file (in
-`app/config`) or from a configuration file being imported from a bundle:
+``app/config``) or from a configuration file being imported from a bundle:
 
 .. configuration-block::
 

cookbook/security/voters.rst

@@ -114,7 +114,7 @@ Declaring the Voter as a Service
 --------------------------------
 
 To inject the voter into the security layer, you must declare it as a service,
-and tag it as a "security.voter":
+and tag it as a ``security.voter``:
 
 .. configuration-block::
 

cookbook/session/locale_sticky_session.rst

@@ -10,8 +10,8 @@ during a user's request. In this article, you'll learn how to make the locale
 of a user "sticky" so that once it's set, that same locale will be used for
 every subsequent request.
 
-Creating LocaleListener
------------------------
+Creating a LocaleListener
+-------------------------
 
 To simulate that the locale is stored in a session, you need to create and
 register a :doc:`new event listener </cookbook/service_container/event_listener>`.

cookbook/session/proxy_examples.rst

@@ -39,7 +39,7 @@ and decrypt the session as required::
 
         public function read($id)
         {
-            $data = parent::write($id, $data);
+            $data = parent::read($id);
 
             return mcrypt_decrypt(\MCRYPT_3DES, $this->key, $data);
         }

cookbook/symfony1.rst

@@ -63,7 +63,7 @@ places.
 In Symfony2, life is much simpler because *all* Symfony2 code must live in
 a bundle. In the pretend symfony1 project, all the code *could* be moved
 into one or more plugins (which is a very good practice, in fact). Assuming
-that all modules, PHP classes, schema, routing configuration, etc were moved
+that all modules, PHP classes, schema, routing configuration, etc. were moved
 into a plugin, the symfony1 ``plugins/`` directory would be very similar
 to the Symfony2 ``src/`` directory.
 
@@ -176,8 +176,8 @@ from specific directories without defining a dependency:
 
 This means that if a class is not found in the ``vendor`` directory, Composer
 will search in the ``src`` directory before throwing a "class does not exist"
-exception. Read more about configuring the Composer Autoloader in
-`the Composer documentation`_
+exception. Read more about configuring the Composer autoloader in
+`the Composer documentation`_.
 
 Using the Console
 -----------------

cookbook/testing/database.rst

@@ -18,7 +18,7 @@ your test always has the same data to work with.
 Mocking the ``Repository`` in a Unit Test
 -----------------------------------------
 
-If you want to test code which depends on a doctrine ``Repository`` in isolation,
+If you want to test code which depends on a Doctrine repository in isolation,
 you need to mock the ``Repository``. Normally you inject the ``EntityManager``
 into your class and use it to get the repository. This makes things a little
 more difficult as you need to mock both the ``EntityManager`` and your repository
@@ -27,7 +27,7 @@ class.
 .. tip::
 
     It is possible (and a good idea) to inject your repository directly by
-    registering your repository as a :doc:`factory service </components/dependency_injection/factories>`
+    registering your repository as a :doc:`factory service </components/dependency_injection/factories>`.
     This is a little bit more work to setup, but makes testing easier as you
     only need to mock the repository.
 

cookbook/testing/http_authentication.rst

@@ -33,7 +33,7 @@ key in your firewall, along with the ``form_login`` key:
         security:
             firewalls:
                 your_firewall_name:
-                    http_basic:
+                    http_basic: ~
 
     .. code-block:: xml
 

cookbook/testing/insulating_clients.rst

@@ -4,8 +4,8 @@
 How to test the Interaction of several Clients
 ==============================================
 
-If you need to simulate an interaction between different Clients (think of a
-chat for instance), create several Clients::
+If you need to simulate an interaction between different clients (think of a
+chat for instance), create several clients::
 
     $harry = static::createClient();
     $sally = static::createClient();