Merge branch '2.0' into 2.1

weaverryan · weaverryan · commit 0196aaa76003 · 2012-10-23T18:14:44.000-05:00
Conflicts:
	book/templating.rst
diff --git a/README.markdown b/README.markdown
@@ -7,8 +7,10 @@ Contributing
 ------------
 
 >**Note** 
->Unless you're documenting a feature that's new to Symfony 2.1, all pull
->requests must be based off of the **2.0** branch, **not** the master branch.
+>Unless you're documenting a feature that's new to a specific version of Symfony 
+>(e.g. Symfony 2.1), all pull requests must be based off of the **2.0** branch, 
+>**not** the master or 2.1 branch.
 
 We love contributors! For more information on how you can contribute to the
-Symfony documentation, please read [Contributing to the Documentation](http://symfony.com/doc/current/contributing/documentation/overview.html) 
+Symfony documentation, please read 
+[Contributing to the Documentation](http://symfony.com/doc/current/contributing/documentation/overview.html) 
diff --git a/book/templating.rst b/book/templating.rst
@@ -128,16 +128,17 @@ Throughout this chapter, template examples will be shown in both Twig and PHP.
     and benefit from this distinction. And of course, you'll be loved by
     web designers everywhere.
 
-    Twig can also do things that PHP can't, such as whitespace control, sandboxing,
-    and the inclusion of custom functions and filters that only affect templates.
-    Twig contains little features that make writing templates easier and
-    more concise. Take the following example, which combines a loop with
-    a logical ``if`` statement:
+    Twig can also do things that PHP can't, such as whitespace control,
+    sandboxing, automatic and contextual output escaping, and the inclusion of
+    custom functions and filters that only affect templates. Twig contains
+    little features that make writing templates easier and more concise. Take
+    the following example, which combines a loop with a logical ``if``
+    statement:
 
     .. code-block:: html+jinja
 
         <ul>
-            {% for user in users %}
+            {% for user in users if user.active %}
                 <li>{{ user.username }}</li>
             {% else %}
                 <li>No users found</li>
diff --git a/components/process.rst b/components/process.rst
@@ -60,7 +60,8 @@ instead::
 
     $process = new PhpProcess(<<<EOF
         <?php echo 'Hello World'; ?>
-    EOF);
+    EOF
+    );
     $process->run();
 
 .. versionadded:: 2.1
diff --git a/cookbook/configuration/override_dir_structure.rst b/cookbook/configuration/override_dir_structure.rst
@@ -46,7 +46,7 @@ in the ``AppKernel`` class of you application::
 is the current environment (i.e. ``dev``). In this case we have changed 
 the location of the cache directory to ``app/{environment}/cache``.
 
-.. warning::
+.. caution::
 
     You should keep the ``cache`` directory different for each environment,
     otherwise some unexpected behaviour may happen. Each environment generates
diff --git a/cookbook/security/acl_advanced.rst b/cookbook/security/acl_advanced.rst
@@ -34,7 +34,7 @@ Object Identities
 The ACL system is completely decoupled from your domain objects. They don't
 even have to be stored in the same database, or on the same server. In order
 to achieve this decoupling, in the ACL system your objects are represented
-through object identity objects. Everytime, you want to retrieve the ACL for a
+through object identity objects. Everytime you want to retrieve the ACL for a
 domain object, the ACL system will first create an object identity from your
 domain object, and then pass this object identity to the ACL provider for
 further processing.
diff --git a/cookbook/security/custom_authentication_provider.rst b/cookbook/security/custom_authentication_provider.rst
@@ -454,7 +454,7 @@ Configuration
 ~~~~~~~~~~~~~
 
 You can add custom options under the ``wsse`` key in your security configuration.
-For instance, the time allowed before expiring the Created header item,
+For instance, the time allowed before expiring the ``Created`` header item,
 by default, is 5 minutes. Make this configurable, so different firewalls
 can have different timeout lengths.
 
diff --git a/cookbook/security/force_https.rst b/cookbook/security/force_https.rst
@@ -7,7 +7,7 @@ How to force HTTPS or HTTP for Different URLs
 You can force areas of your site to use the ``HTTPS`` protocol in the security
 config. This is done through the ``access_control`` rules using the ``requires_channel``
 option. For example, if you want to force all URLs starting with ``/secure``
-to use ``HTTPS`` then you could use the following config:
+to use ``HTTPS`` then you could use the following configuration:
 
 .. configuration-block::
 
@@ -33,7 +33,7 @@ to use ``HTTPS`` then you could use the following config:
                 ),
             ),
 
-The login form itself needs to allow anonymous access otherwise users will
+The login form itself needs to allow anonymous access, otherwise users will
 be unable to authenticate. To force it to use ``HTTPS`` you can still use
 ``access_control`` rules by using the ``IS_AUTHENTICATED_ANONYMOUSLY`` 
 role:
diff --git a/cookbook/security/form_login.rst b/cookbook/security/form_login.rst
@@ -105,10 +105,11 @@ Redirecting after Success
 You can change where the login form redirects after a successful login using
 the various config options. By default the form will redirect to the URL the
 user requested (i.e. the URL which triggered the login form being shown).
-For example, if the user requested ``http://www.example.com/admin/post/18/edit``
-then after he/she will eventually be sent back to ``http://www.example.com/admin/post/18/edit`` 
-after successfully logging in. This is done by storing the requested URL
-in the session. If no URL is present in the session (perhaps the user went
+For example, if the user requested ``http://www.example.com/admin/post/18/edit``,
+then after she successfully logs in, she will eventually be sent back to
+``http://www.example.com/admin/post/18/edit``.
+This is done by storing the requested URL in the session.
+If no URL is present in the session (perhaps the user went
 directly to the login page), then the user is redirected to the default page,
 which is  ``/`` (i.e. the homepage) by default. You can change this behavior
 in several ways.
@@ -163,7 +164,7 @@ the following config:
             ),
         ));
 
-Now, when no URL is set in the session users will be sent to ``/admin``.
+Now, when no URL is set in the session, users will be sent to ``/admin``.
 
 Always Redirect to the Default Page
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -341,7 +342,7 @@ option to another value.
 Redirecting on Login Failure
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-In addition to redirect the user after a successful login, you can also set
+In addition to redirecting the user after a successful login, you can also set
 the URL that the user should be redirected to after a failed login (e.g. an
 invalid username or password was submitted). By default, the user is redirected
 back to the login form itself. You can set this to a different URL with the
diff --git a/cookbook/testing/http_authentication.rst b/cookbook/testing/http_authentication.rst
@@ -14,7 +14,7 @@ as server variables to ``createClient()``::
 
 You can also override it on a per request basis::
 
-    $client->request('DELETE', '/post/12', array(), array(
+    $client->request('DELETE', '/post/12', array(), array(), array(
         'PHP_AUTH_USER' => 'username',
         'PHP_AUTH_PW'   => 'pa$$word',
     ));
