Merge branch '2.3' into 2.4

Conflicts:
	reference/forms/types/integer.rst
	reference/forms/types/number.rst

Author: weaverryan

README.markdown

@@ -8,9 +8,9 @@ Contributing
 
 >**Note**
 >Unless you're documenting a feature that's new to a specific version of Symfony
->(e.g. Symfony 2.3), all pull requests must be based off of the **2.2** branch, 
+>(e.g. Symfony 2.3), all pull requests must be based off of the **2.2** branch,
 >**not** the master or 2.3 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)

book/controller.rst

@@ -726,7 +726,7 @@ the ``notice`` message:
 
     .. code-block:: html+php
 
-        <?php foreach ($view['session']->getFlashBag()->get('notice') as $message): ?>
+        <?php foreach ($view['session']->getFlash('notice') as $message): ?>
             <div class="flash-notice">
                 <?php echo "<div class='flash-error'>$message</div>" ?>
             </div>

book/forms.rst

@@ -1360,7 +1360,7 @@ form with many ``Product`` sub-forms). This is done by using the ``collection``
 field type.
 
 For more information see the ":doc:`/cookbook/form/form_collections`" cookbook
-entry and  the :doc:`collection </reference/forms/types/collection>` field type reference.
+entry and the :doc:`collection </reference/forms/types/collection>` field type reference.
 
 .. index::
    single: Forms; Theming

book/http_cache.rst

@@ -904,12 +904,12 @@ matter), Symfony2 uses the standard ``render`` helper to configure ESI tags:
 
         <?php echo $view['actions']->render(
             new ControllerReference('...:news', array('max' => 5)),
-            array('renderer' => 'esi'))
+            array('strategy' => 'esi'))
         ?>
 
         <?php echo $view['actions']->render(
             $view['router']->generate('latest_news', array('max' => 5), true),
-            array('renderer' => 'esi'),
+            array('strategy' => 'esi'),
         ) ?>
 
 By using the ``esi`` renderer (via the ``render_esi`` Twig function), you

book/installation.rst

@@ -44,7 +44,7 @@ have curl installed, it's as easy as:
 
 .. code-block:: bash
 
-    curl -s https://getcomposer.org/installer | php
+    $ curl -s https://getcomposer.org/installer | php
 
 .. note::
 
@@ -135,7 +135,7 @@ Updating Vendors
 
 At this point, you've downloaded a fully-functional Symfony project in which
 you'll start to develop your own application. A Symfony project depends on
-a number of external libraries. These are downloaded into the `vendor/` directory
+a number of external libraries. These are downloaded into the ``vendor/`` directory
 of your project via a library called `Composer`_.
 
 Depending on how you downloaded Symfony, you may or may not need to update
@@ -146,7 +146,7 @@ Step 1: Get `Composer`_ (The great new PHP packaging system)
 
 .. code-block:: bash
 
-    curl -s http://getcomposer.org/installer | php
+    $ curl -s http://getcomposer.org/installer | php
 
 Make sure you download ``composer.phar`` in the same folder where
 the ``composer.json`` file is located (this is your Symfony project
@@ -169,8 +169,8 @@ Symfony itself - into the ``vendor/`` directory.
 
     .. code-block:: bash
 
-        php installer
-        php composer.phar install
+        $ php installer
+        $ php composer.phar install
 
 .. tip::
 
@@ -231,7 +231,7 @@ If there are any issues, correct them now before moving on.
         $ rm -rf app/cache/*
         $ rm -rf app/logs/*
 
-        $ APACHEUSER=`ps aux | grep -E '[a]pache|[h]ttpd' | grep -v root | head -1 | cut -d\  -f1`
+        $ APACHEUSER=`ps aux | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data' | grep -v root | head -1 | cut -d\  -f1`
         $ sudo chmod +a "$APACHEUSER allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs
         $ sudo chmod +a "`whoami` allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs
 
@@ -246,7 +246,7 @@ If there are any issues, correct them now before moving on.
 
     .. code-block:: bash
 
-		$ APACHEUSER=`ps aux | grep -E '[a]pache|[h]ttpd' | grep -v root | head -1 | cut -d\  -f1`
+		$ APACHEUSER=`ps aux | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data' | grep -v root | head -1 | cut -d\  -f1`
 		$ sudo setfacl -R -m u:"$APACHEUSER":rwX -m u:`whoami`:rwX app/cache app/logs
 		$ sudo setfacl -dR -m u:"$APACHEUSER":rwX -m u:`whoami`:rwX app/cache app/logs
 

book/page_creation.rst

@@ -42,10 +42,10 @@ also load specific bundles based on the selected environment. For example,
 Symfony2 comes with the WebProfilerBundle (described below), enabled only
 in the ``dev`` and ``test`` environments.
 
-Symfony2 comes with two web-accessible front controllers: ``app_dev.php`` 
+Symfony2 comes with two web-accessible front controllers: ``app_dev.php``
 provides the ``dev`` environment, and ``app.php`` provides the ``prod`` environment.
 All web accesses to Symfony2 normally go through one of these front controllers.
-(The ``test`` environment is normally only used when running unit tests, and so 
+(The ``test`` environment is normally only used when running unit tests, and so
 doesn't have a dedicated front controller. The console tool also provides a
 front controller that can be used with any environment.)
 
@@ -555,7 +555,7 @@ You'll learn more about each of these directories in later chapters.
 
     When Symfony is loading, a special file - ``vendor/autoload.php`` - is
     included. This file is created by Composer and will autoload all
-    application files living in the `src/` folder as well as all
+    application files living in the ``src/`` folder as well as all
     third-party libraries mentioned in the ``composer.json`` file.
 
     Because of the autoloader, you never need to worry about using ``include``
@@ -864,18 +864,18 @@ Default Configuration Dump
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 You can dump the default configuration for a bundle in YAML to the console using
-the ``config:dump-reference`` command.  Here is an example of dumping the default
+the ``config:dump-reference`` command. Here is an example of dumping the default
 FrameworkBundle configuration:
 
-.. code-block:: text
+.. code-block:: bash
 
-    app/console config:dump-reference FrameworkBundle
+    $ app/console config:dump-reference FrameworkBundle
 
 The extension alias (configuration key) can also be used:
 
-.. code-block:: text
+.. code-block:: bash
 
-    app/console config:dump-reference framework
+    $ app/console config:dump-reference framework
 
 .. note::
 

book/performance.rst

@@ -60,7 +60,7 @@ command line, and might become part of your deploy process:
 
 .. code-block:: bash
 
-    php composer.phar dump-autoload --optimize
+    $ php composer.phar dump-autoload --optimize
 
 Internally, this builds the big class map array in ``vendor/composer/autoload_classmap.php``.
 

book/propel.rst

@@ -134,7 +134,7 @@ Creating the Database Tables/Schema
 Now you have a usable ``Product`` class and all you need to persist it. Of
 course, you don't yet have the corresponding ``product`` table in your
 database. Fortunately, Propel can automatically create all the database tables
-needed for every known model in your application.  To do this, run:
+needed for every known model in your application. To do this, run:
 
 .. code-block:: bash
 
@@ -153,7 +153,7 @@ Persisting Objects to the Database
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Now that you have a ``Product`` object and corresponding ``product`` table,
-you're ready to persist data to the database.  From inside a controller, this
+you're ready to persist data to the database. From inside a controller, this
 is pretty easy. Add the following method to the ``DefaultController`` of the
 bundle::
 
@@ -406,7 +406,7 @@ Fetching Related Objects
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 When you need to fetch associated objects, your workflow looks just like it did
-before.  First, fetch a ``$product`` object and then access its related
+before. First, fetch a ``$product`` object and then access its related
 ``Category``::
 
     // ...
@@ -435,7 +435,7 @@ Lifecycle Callbacks
 -------------------
 
 Sometimes, you need to perform an action right before or after an object is
-inserted, updated, or deleted.  These types of actions are known as "lifecycle"
+inserted, updated, or deleted. These types of actions are known as "lifecycle"
 callbacks or "hooks", as they're callback methods that you need to execute
 during different stages of the lifecycle of an object (e.g. the object is
 inserted, updated, deleted, etc).

book/security.rst

@@ -1593,59 +1593,6 @@ Now, all authentication mechanisms will use the ``chain_provider``, since
 it's the first specified. The ``chain_provider`` will, in turn, try to load
 the user from both the ``in_memory`` and ``user_db`` providers.
 
-.. tip::
-
-    If you have no reasons to separate your ``in_memory`` users from your
-    ``user_db`` users, you can accomplish this even more easily by combining
-    the two sources into a single provider:
-
-    .. configuration-block::
-
-        .. code-block:: yaml
-
-            # app/config/security.yml
-            security:
-                providers:
-                    main_provider:
-                        memory:
-                            users:
-                                foo: { password: test }
-                        entity:
-                            class: Acme\UserBundle\Entity\User,
-                            property: username
-
-        .. code-block:: xml
-
-            <!-- app/config/security.xml -->
-            <config>
-                <provider name=="main_provider">
-                    <memory>
-                        <user name="foo" password="test" />
-                    </memory>
-
-                    <entity class="Acme\UserBundle\Entity\User"
-                        property="username" />
-                </provider>
-            </config>
-
-        .. code-block:: php
-
-            // app/config/security.php
-            $container->loadFromExtension('security', array(
-                'providers' => array(
-                    'main_provider' => array(
-                        'memory' => array(
-                            'users' => array(
-                                'foo' => array('password' => 'test'),
-                            ),
-                        ),
-                        'entity' => array(
-                        'class' => 'Acme\UserBundle\Entity\User',
-                        'property' => 'username'),
-                    ),
-                ),
-            ));
-
 You can also configure the firewall or individual authentication mechanisms
 to use a specific provider. Again, unless a provider is specified explicitly,
 the first provider is always used:

book/templating.rst

@@ -1088,7 +1088,7 @@ Global Template Variables
 -------------------------
 
 During each request, Symfony2 will set a global template variable ``app``
-in both Twig and PHP template engines by default.  The ``app`` variable
+in both Twig and PHP template engines by default. The ``app`` variable
 is a :class:`Symfony\\Bundle\\FrameworkBundle\\Templating\\GlobalVariables`
 instance which will give you access to some application specific variables
 automatically:
@@ -1361,7 +1361,7 @@ this classic example:
 
 Imagine the user enters the following code for their name:
 
-.. code-block:: text
+.. code-block:: html
 
     <script>alert('hello!')</script>