Merge branch '2.2' into 2.3

Conflicts:
	reference/forms/types/options/attr.rst.inc

Author: weaverryan

book/http_fundamentals.rst

@@ -551,7 +551,7 @@ So then, what *is* the Symfony2 *Framework*? The *Symfony2 Framework* is
 a PHP library that accomplishes two distinct tasks:
 
 #. Provides a selection of components (i.e. the Symfony2 Components) and
-   third-party libraries (e.g. `Swiftmailer`_ for sending emails);
+   third-party libraries (e.g. `Swift Mailer`_ for sending emails);
 
 #. Provides sensible configuration and a "glue" library that ties all of these
    pieces together.
@@ -577,4 +577,4 @@ sensible defaults. For more advanced users, the sky is the limit.
 .. _`Validator`: https://github.com/symfony/Validator
 .. _`Security`: https://github.com/symfony/Security
 .. _`Translation`: https://github.com/symfony/Translation
-.. _`Swiftmailer`: http://swiftmailer.org/
+.. _`Swift Mailer`: http://swiftmailer.org/

book/security.rst

@@ -785,15 +785,15 @@ Take the following ``access_control`` entries as an example:
             # ...
             access_control:
                 - { path: ^/admin, roles: ROLE_USER_IP, ip: 127.0.0.1 }
-                - { path: ^/admin, roles: ROLE_USER_HOST, host: symfony.com }
+                - { path: ^/admin, roles: ROLE_USER_HOST, host: symfony\.com$ }
                 - { path: ^/admin, roles: ROLE_USER_METHOD, methods: [POST, PUT] }
                 - { path: ^/admin, roles: ROLE_USER }
 
     .. code-block:: xml
 
             <access-control>
                 <rule path="^/admin" role="ROLE_USER_IP" ip="127.0.0.1" />
-                <rule path="^/admin" role="ROLE_USER_HOST" host="symfony.com" />
+                <rule path="^/admin" role="ROLE_USER_HOST" host="symfony\.com$" />
                 <rule path="^/admin" role="ROLE_USER_METHOD" method="POST, PUT" />
                 <rule path="^/admin" role="ROLE_USER" />
             </access-control>
@@ -809,7 +809,7 @@ Take the following ``access_control`` entries as an example:
                 array(
                     'path' => '^/admin',
                     'role' => 'ROLE_USER_HOST',
-                    'host' => 'symfony.com',
+                    'host' => 'symfony\.com$',
                 ),
                 array(
                     'path' => '^/admin',

book/testing.rst

@@ -691,7 +691,7 @@ The Client used by functional tests creates a Kernel that runs in a special
 in the ``test`` environment, you can tweak any of your application's settings
 specifically for testing.
 
-For example, by default, the swiftmailer is configured to *not* actually
+For example, by default, the Swift Mailer is configured to *not* actually
 deliver emails in the ``test`` environment. You can see this under the ``swiftmailer``
 configuration option:
 

components/dependency_injection/compilation.rst

@@ -13,7 +13,7 @@ It is compiled by running::
 
     $container->compile();
 
-The compile method uses *Compiler Passes* for the compilation. The *Dependency Injection*
+The compile method uses *Compiler Passes* for the compilation. The Dependency Injection
 component comes with several passes which are automatically registered for
 compilation. For example the :class:`Symfony\\Component\\DependencyInjection\\Compiler\\CheckDefinitionValidityPass`
 checks for various potential issues with the definitions that have been set
@@ -40,7 +40,7 @@ and can be registered with the container with::
 
     $container->registerExtension($extension);
 
-The main work of the extension is done in the ``load`` method. In the load method
+The main work of the extension is done in the ``load`` method. In the ``load`` method
 you can load configuration from one or more configuration files as well as
 manipulate the container definitions using the methods shown in :doc:`/components/dependency_injection/definitions`.
 

components/dependency_injection/definitions.rst

@@ -73,7 +73,7 @@ You can add a new argument to the end of the arguments array using::
     $definition->addArgument($argument);
 
 The argument can be a string, an array, a service parameter by using ``%parameter_name%``
-or a service id by using ::
+or a service id by using::
 
     use Symfony\Component\DependencyInjection\Reference;
 
@@ -122,6 +122,6 @@ You can also replace any existing method calls with an array of new ones with::
 .. note::
 
     The methods here that change service definitions can only be used before
-    the container is compiled, once the container is compiled you cannot
+    the container is compiled. Once the container is compiled you cannot
     manipulate service definitions further. To learn more about compiling
     the container see :doc:`/components/dependency_injection/compilation`.

components/dependency_injection/factories.rst

@@ -12,7 +12,7 @@ For this situation, you can use a factory to create the object and tell the
 service container to call a method on the factory rather than directly instantiating
 the class.
 
-Suppose you have a factory that configures and returns a new NewsletterManager
+Suppose you have a factory that configures and returns a new ``NewsletterManager``
 object::
 
     class NewsletterFactory

components/dependency_injection/parameters.rst

@@ -60,7 +60,7 @@ One use for this is to inject the values into your services. This allows
 you to configure different versions of services between applications or multiple
 services based on the same class but configured differently within a single
 application. You could inject the choice of mail transport into the ``Mailer``
-class directly but by making it a parameter. This makes it easier to change
+class directly. But declaring it as a parameter makes it easier to change
 rather than being tied up and hidden with the service definition:
 
 .. configuration-block::
@@ -343,7 +343,7 @@ Start the string with  ``@`` or ``@?`` to reference a service in Yaml.
     converted into the string ``"@mailer"`` instead of referencing the
     ``mailer`` service.
 
-Xml
+XML
 ~~~
 
 In XML, use the ``service`` type. The behavior if the service does not exist
@@ -352,7 +352,7 @@ is thrown. Valid values for ``on-invalid`` are ``null`` (uses ``null`` in place
 of the missing service) or ``ignored`` (very similar, except if used on a
 method call, the method call is removed).
 
-Php
+PHP
 ~~~
 
 In PHP, you can use the

components/dependency_injection/tags.rst

@@ -27,7 +27,7 @@ To begin with, define the ``TransportChain`` class::
             $this->transports = array();
         }
 
-        public function addTransport(\Swift_Transport  $transport)
+        public function addTransport(\Swift_Transport $transport)
         {
             $this->transports[] = $transport;
         }
@@ -176,7 +176,7 @@ Adding additional attributes on Tags
 ------------------------------------
 
 Sometimes you need additional information about each service that's tagged with your tag.
-For example, you might want to add an alias to each TransportChain.
+For example, you might want to add an alias to each member of the transport chain.
 
 To begin with, change the ``TransportChain`` class::
 

components/dependency_injection/workflow.rst

@@ -64,7 +64,7 @@ Compiler passes to allow Interaction between Bundles
 :ref:`Compiler passes <components-dependency-injection-compiler-passes>` are
 used to allow interaction between different bundles as they cannot affect
 each other's configuration in the extension classes. One of the main uses is
-to process tagged services, allowing bundles to register services to picked
+to process tagged services, allowing bundles to register services to be picked
 up by other bundles, such as Monolog loggers, Twig extensions and Data Collectors
 for the Web Profiler. Compiler passes are usually placed in the bundle's
 ``DependencyInjection/Compiler`` directory.

components/event_dispatcher/introduction.rst

@@ -558,7 +558,7 @@ Or::
 
 Or::
 
-    $response = $dispatcher->dispatch('bar.event', new BarEvent())->getBar();
+    $bar = $dispatcher->dispatch('bar.event', new BarEvent())->getBar();
 
 and so on...
 

components/form/introduction.rst

@@ -334,12 +334,12 @@ and then access it whenever you need to build a form.
 
 .. note::
 
-    In this document, the form factory is always a locally variable called
+    In this document, the form factory is always a local variable called
     ``$formFactory``. The point here is that you will probably need to create
     this object in some more "global" way so you can access it from anywhere.
 
 Exactly how you gain access to your one form factory is up to you. If you're
-using a :term`Service Container`, then you should add the form factory to
+using a :term:`Service Container`, then you should add the form factory to
 your container and grab it out whenever you need to. If your application
 uses global or static variables (not usually a good idea), then you can store
 the object on some static class or do something similar.
@@ -414,7 +414,7 @@ it and :ref:`process the form submission <component-form-intro-handling-submissi
 Setting Default Values
 ~~~~~~~~~~~~~~~~~~~~~~
 
-If you need you form to load with some default values (or you're building
+If you need your form to load with some default values (or you're building
 an "edit" form), simply pass in the default data when creating your form
 builder:
 

components/http_foundation/introduction.rst

@@ -61,7 +61,7 @@ can be accessed via several public properties:
 
 * ``cookies``: equivalent of ``$_COOKIE``;
 
-* ``attributes``: no equivalent - used by your app to store other data (see :ref:`below <component-foundation-attributes>`)
+* ``attributes``: no equivalent - used by your app to store other data (see :ref:`below <component-foundation-attributes>`);
 
 * ``files``: equivalent of ``$_FILES``;
 
@@ -109,7 +109,7 @@ methods to retrieve and update its data:
   parameter by name;
 
 * :method:`Symfony\\Component\\HttpFoundation\\ParameterBag::has`: Returns
-  true if the parameter is defined;
+  ``true`` if the parameter is defined;
 
 * :method:`Symfony\\Component\\HttpFoundation\\ParameterBag::remove`: Removes
   a parameter.
@@ -322,7 +322,7 @@ Sending the response to the client is then as simple as calling
 Setting Cookies
 ~~~~~~~~~~~~~~~
 
-The response cookies can be manipulated though the ``headers`` public
+The response cookies can be manipulated through the ``headers`` public
 attribute::
 
     use Symfony\Component\HttpFoundation\Cookie;
@@ -455,7 +455,7 @@ whether or not the ``X-Sendfile-Type`` header should be trusted and call
 :method:`Symfony\\Component\\HttpFoundation\\BinaryFileResponse::trustXSendfileTypeHeader`
 if it should::
 
-    $response::trustXSendfileTypeHeader();
+    BinaryFileResponse::trustXSendfileTypeHeader();
 
 You can still set the ``Content-Type`` of the sent file, or change its ``Content-Disposition``::
 

components/http_foundation/session_configuration.rst

@@ -119,7 +119,7 @@ be securely controlled from the server side.
 
     The ``cookie_lifetime`` setting is the number of seconds the cookie should live
     for, it is not a Unix timestamp. The resulting session cookie will be stamped
-    with an expiry time of ``time()``+``cookie_lifetime`` where the time is taken
+    with an expiry time of ``time()`` + ``cookie_lifetime`` where the time is taken
     from the server.
 
 Configuring Garbage Collection
@@ -132,7 +132,7 @@ of 5%. Similarly, ``3/4`` would mean a 3 in 4 chance of being called, i.e. 75%.
 
 If the garbage collection handler is invoked, PHP will pass the value stored in
 the ``php.ini`` directive ``session.gc_maxlifetime``. The meaning in this context is
-that any stored session that was saved more than ``maxlifetime`` ago should be
+that any stored session that was saved more than ``gc_maxlifetime`` ago should be
 deleted. This allows one to expire records based on idle time.
 
 You can configure these settings by passing ``gc_probability``, ``gc_divisor``
@@ -173,8 +173,8 @@ example, it is common for banking applications to log the user out after just
 5 to 10 minutes of inactivity. Setting the cookie lifetime here is not
 appropriate because that can be manipulated by the client, so we must do the expiry
 on the server side. The easiest way is to implement this via garbage collection
-which runs reasonably frequently. The cookie ``lifetime`` would be set to a
-relatively high value, and the garbage collection ``maxlifetime`` would be set
+which runs reasonably frequently. The ``cookie_lifetime`` would be set to a
+relatively high value, and the garbage collection ``gc_maxlifetime`` would be set
 to destroy sessions at whatever the desired idle period is.
 
 The other option is to specifically checking if a session has expired after the
@@ -258,7 +258,7 @@ without knowledge of the specific save handler.
 
 .. note::
 
-    Before PHP 5.4, you can only proxy user-land save handlers but not 
+    Before PHP 5.4, you can only proxy user-land save handlers but not
     native PHP save handlers.
 
 .. _`php.net/session.customhandler`: http://php.net/session.customhandler

components/http_foundation/session_testing.rst

@@ -18,7 +18,7 @@ starting one allowing you to test your code without complications. You may also
 run multiple instances in the same PHP process.
 
 The mock storage drivers do not read or write the system globals
-`session_id()` or `session_name()`. Methods are provided to simulate this if
+``session_id()`` or ``session_name()``. Methods are provided to simulate this if
 required:
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\SessionStorageInterface::getId`: Gets the

components/http_foundation/sessions.rst

@@ -62,24 +62,24 @@ as follows divided into a couple of groups.
 Session workflow
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::start`:
-  Starts the session - do not use ``session_start()``.
+  Starts the session - do not use ``session_start()``;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::migrate`:
   Regenerates the session ID - do not use ``session_regenerate_id()``.
   This method can optionally change the lifetime of the new cookie that will
-  be emitted by calling this method.
+  be emitted by calling this method;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::invalidate`:
-  Clears all session data and regenerates session ID. Do not use ``session_destroy()``.
+  Clears all session data and regenerates session ID. Do not use ``session_destroy()``;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::getId`: Gets the
-  session ID. Do not use ``session_id()``.
+  session ID. Do not use ``session_id()``;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::setId`: Sets the
-  session ID. Do not use ``session_id()``.
+  session ID. Do not use ``session_id()``;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::getName`: Gets the
-  session name. Do not use ``session_name()``.
+  session name. Do not use ``session_name()``;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::setName`: Sets the
   session name. Do not use ``session_name()``.
@@ -99,23 +99,23 @@ Session attributes
   Returns true if the attribute exists;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::replace`:
-  Sets multiple attributes at once: takes a keyed array and sets each key => value pair.
+  Sets multiple attributes at once: takes a keyed array and sets each key => value pair;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::remove`:
   Deletes an attribute by key;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::clear`:
-  Clear all attributes;
+  Clear all attributes.
 
 The attributes are stored internally in an "Bag", a PHP object that acts like
 an array. A few methods exist for "Bag" management:
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::registerBag`:
-  Registers a :class:`Symfony\\Component\\HttpFoundation\\Session\\SessionBagInterface`
+  Registers a :class:`Symfony\\Component\\HttpFoundation\\Session\\SessionBagInterface`;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::getBag`:
   Gets a :class:`Symfony\\Component\\HttpFoundation\\Session\\SessionBagInterface` by
-  bag name.
+  bag name;
 
 * :method:`Symfony\\Component\\HttpFoundation\\Session\\Session::getFlashBag`:
   Gets the :class:`Symfony\\Component\\HttpFoundation\\Session\\Flash\\FlashBagInterface`.
@@ -238,7 +238,7 @@ would be displayed immediately on the subsequent page load for that session.
 This is however just one application for flash messages.
 
 * :class:`Symfony\\Component\\HttpFoundation\\Session\\Flash\\AutoExpireFlashBag`
-   This implementation messages set in one page-load will
+   In this implementation, messages set in one page-load will
    be available for display only on the next page load. These messages will auto
    expire regardless of if they are retrieved or not.
 
@@ -302,7 +302,7 @@ Examples of setting multiple flashes::
     $session->getFlashBag()->add('error', 'Failed to update name');
     $session->getFlashBag()->add('error', 'Another error');
 
-Displaying the flash messages might look like this:
+Displaying the flash messages might look as follows.
 
 Simple, display one type of message::
 

components/http_kernel/introduction.rst

@@ -104,7 +104,7 @@ listeners to the events discussed below::
     // by dispatching events, calling a controller, and returning the response
     $response = $kernel->handle($request);
 
-    // echo the content and send the headers
+    // send the headers and echo the content
     $response->send();
 
     // triggers the kernel.terminate event
@@ -461,7 +461,7 @@ because it occurs *after* the ``HttpKernel::handle`` method, and after the
 response is sent to the user. Recall from above, then the code that uses
 the kernel, ends like this::
 
-    // echo the content and send the headers
+    // send the headers and echo the content
     $response->send();
 
     // triggers the kernel.terminate event

components/routing/introduction.rst

@@ -127,7 +127,7 @@ does *not* match, because "foo" fails the month wildcard.
 
 .. tip::
 
-    If you want to match all urls which start with a certain path and end in an
+    If you want to match all URLs which start with a certain path and end in an
     arbitrary suffix you can use the following route definition::
 
         $route = new Route(

components/security/authorization.rst

@@ -26,7 +26,7 @@ An authorization decision will always be based on a few things:
     Each attribute stands for a certain right the user should have, e.g.
     ``ROLE_ADMIN`` to make sure the user is an administrator.
 * An object (optional)
-    Any object on which for which access control needs to be checked, like
+    Any object for which access control needs to be checked, like
     an article or a comment object.
 
 .. _components-security-access-decision-manager:

components/security/firewall.rst

@@ -127,11 +127,11 @@ Flow: Firewall, Authentication, Authorization
 Hopefully you can now see a little bit about how the "flow" of the security
 context works:
 
-#. the Firewall is registered as a listener on the ``kernel.request`` event;
-#. at the beginning of the request, the Firewall checks the firewall map
+#. The Firewall is registered as a listener on the ``kernel.request`` event;
+#. At the beginning of the request, the Firewall checks the firewall map
    to see if any firewall should be active for this URL;
-#. If a firewall is found in the map for this URL, its listeners are notified
-#. each listener checks to see if the current request contains any authentication
+#. If a firewall is found in the map for this URL, its listeners are notified;
+#. Each listener checks to see if the current request contains any authentication
    information - a listener may (a) authenticate a user, (b) throw an
    ``AuthenticationException``, or (c) do nothing (because there is no
    authentication information on the request);