Merge branch '3.2' into 3.3

* 3.2:
  Use Twig's namespaced paths
  Minor reword
  Clearify setup of basic auth for test environment
  rearrange how workflow events are presented

Author: weaverryan

profiler/data_collector.rst

@@ -117,7 +117,7 @@ block and set the value of two variables called ``icon`` and ``text``:
 
 .. code-block:: html+twig
 
-    {% extends 'WebProfilerBundle:Profiler:layout.html.twig' %}
+    {% extends '@WebProfiler/Profiler/layout.html.twig' %}
 
     {% block toolbar %}
         {% set icon %}

testing/http_authentication.rst

@@ -30,14 +30,16 @@ firewall, but only in the configuration file used by tests:
         # app/config/config_test.yml
         security:
             firewalls:
-                your_firewall_name:
+                # replace 'main' by the name of your own firewall
+                main:
                     http_basic: ~
 
     .. code-block:: xml
 
         <!-- app/config/config_test.xml -->
         <security:config>
-            <security:firewall name="your_firewall_name">
+            <!-- replace 'main' by the name of your own firewall -->
+            <security:firewall name="main">
               <security:http-basic />
            </security:firewall>
         </security:config>
@@ -47,7 +49,8 @@ firewall, but only in the configuration file used by tests:
         // app/config/config_test.php
         $container->loadFromExtension('security', array(
             'firewalls' => array(
-                'your_firewall_name' => array(
+                // replace 'main' by the name of your own firewall
+                'main' => array(
                     'http_basic' => array(),
                 ),
             ),

workflow/usage.rst

@@ -189,53 +189,79 @@ Each step has three events that are fired in order:
 * An event for the workflow concerned;
 * An event for the workflow concerned with the specific transition or place name.
 
-The following events are dispatched:
+When a state transition is initiated, the events are dispatched in the following
+order:
 
-* ``workflow.guard``
-* ``workflow.[workflow name].guard``
-* ``workflow.[workflow name].guard.[transition name]``
+``workflow.guard``
+    Validate whether the transition is allowed at all (:ref:`see below <workflow-usage-guard-events>`).
+
+    The three events being dispatched are:
+
+    * ``workflow.guard``
+    * ``workflow.[workflow name].guard``
+    * ``workflow.[workflow name].guard.[transition name]``
+
+``workflow.leave``
+    The object is about to leave a place.
+
+    The three events being dispatched are:
+
+    * ``workflow.leave``
+    * ``workflow.[workflow name].leave``
+    * ``workflow.[workflow name].leave.[place name]``
+
+``workflow.transition``
+    The object is going through this transition.
 
-* ``workflow.leave``
-* ``workflow.[workflow name].leave``
-* ``workflow.[workflow name].leave.[place name]``
+    The three events being dispatched are:
 
-* ``workflow.transition``
-* ``workflow.[workflow name].transition``
-* ``workflow.[workflow name].transition.[transition name]``
+    * ``workflow.transition``
+    * ``workflow.[workflow name].transition``
+    * ``workflow.[workflow name].transition.[transition name]``
 
-* ``workflow.enter``
-* ``workflow.[workflow name].enter``
-* ``workflow.[workflow name].enter.[place name]``
+``workflow.enter``
+    The object entered a new place. This is the first event where the object
+    is marked as being in the new place.
 
-* ``workflow.entered``
-* ``workflow.[workflow name].entered``
-* ``workflow.[workflow name].entered.[place name]``
+    The three events being dispatched are:
 
-* ``workflow.announce``
-* ``workflow.[workflow name].announce``
-* ``workflow.[workflow name].announce.[transition name]``
+    * ``workflow.enter``
+    * ``workflow.[workflow name].enter``
+    * ``workflow.[workflow name].enter.[place name]``
 
-When a state transition is initiated, the events are fired in the following order:
+``work.flow.entered``
 
-- guard: Validate whether the transition is allowed at all (:ref:`see below <workflow-usage-guard-events>`);
-- leave: The object is about to leave a place;
-- transition: The object is going through this transition;
-- enter: The object entered a new place. This is the first event where the object' is marked as being in the new place;
-- announce: Triggered once for each workflow that now is available for the object.
+    Similar to ``workflow.enter``, except the marking store is updated before this
+    event (making it a good place to flush data in Doctrine). 
+
+    The three events being dispatched are:
+
+    * ``workflow.entered``
+    * ``workflow.[workflow name].entered``
+    * ``workflow.[workflow name].entered.[place name]``
+
+``workflow.announce``
+    Triggered once for each workflow that now is available for the object.
+
+    The three events being dispatched are:
+
+    * ``workflow.announce``
+    * ``workflow.[workflow name].announce``
+    * ``workflow.[workflow name].announce.[transition name]``
 
 Here is an example how to enable logging for every time a the "blog_publishing" workflow leaves a place::
 
     use Psr\Log\LoggerInterface;
     use Symfony\Component\EventDispatcher\EventSubscriberInterface;
     use Symfony\Component\Workflow\Event\Event;
-    
+
     class WorkflowLogger implements EventSubscriberInterface
     {
         public function __construct(LoggerInterface $logger)
         {
             $this->logger = $logger;
         }
-    
+
         public function onLeave(Event $event)
         {
             $this->logger->alert(sprintf(
@@ -246,7 +272,7 @@ Here is an example how to enable logging for every time a the "blog_publishing"
                 implode(', ', $event->getTransition()->getTos())
             ));
         }
-    
+
         public static function getSubscribedEvents()
         {
             return array(
@@ -257,14 +283,14 @@ Here is an example how to enable logging for every time a the "blog_publishing"
 
 .. _workflow-usage-guard-events:
 
-Guard events
+Guard Events
 ~~~~~~~~~~~~
 
-There are a special kind of events called "Guard events". Their event listeners 
-are invoked every time a call to ``Workflow::can``, ``Workflow::apply`` or 
+There are a special kind of events called "Guard events". Their event listeners
+are invoked every time a call to ``Workflow::can``, ``Workflow::apply`` or
 ``Workflow::getEnabledTransitions`` is executed. With the guard events you may
-add custom logic to decide what transitions that are valid or not. Here is a list 
-of the guard event names. 
+add custom logic to decide what transitions that are valid or not. Here is a list
+of the guard event names.
 
 * ``workflow.guard``
 * ``workflow.[workflow name].guard``