Merge branch '2.6' into 2.7

* 2.6:
  [Book][Routing] Change example to match multiple methods
  Fixed RST table syntax
  Reverted an unneeded change
  Remove the old voter article
  Rewrite new section
  Move access decision strategy section
  Minor reword
  Improved the explanation about the verbosity levels of the console

Author: weaverryan

book/routing.rst

@@ -830,36 +830,36 @@ be accomplished with the following route configuration:
         class MainController extends Controller
         {
             /**
-             * @Route("/contact")
+             * @Route("/news")
              * @Method("GET")
              */
-            public function contactAction()
+            public function newsAction()
             {
-                // ... display contact form
+                // ... display your news
             }
 
             /**
              * @Route("/contact")
-             * @Method("POST")
+             * @Method({"GET", "POST"})
              */
-            public function processContactAction()
+            public function contactFormAction()
             {
-                // ... process contact form
+                // ... display and process a contact form
             }
         }
 
     .. code-block:: yaml
 
         # app/config/routing.yml
-        contact:
-            path:     /contact
-            defaults: { _controller: AppBundle:Main:contact }
+        news:
+            path:     /news
+            defaults: { _controller: AppBundle:Main:news }
             methods:  [GET]
 
-        contact_process:
+        contact_form:
             path:     /contact
-            defaults: { _controller: AppBundle:Main:processContact }
-            methods:  [POST]
+            defaults: { _controller: AppBundle:Main:contactForm }
+            methods:  [GET, POST]
 
     .. code-block:: xml
 
@@ -870,12 +870,12 @@ be accomplished with the following route configuration:
             xsi:schemaLocation="http://symfony.com/schema/routing
                 http://symfony.com/schema/routing/routing-1.0.xsd">
 
-            <route id="contact" path="/contact" methods="GET">
-                <default key="_controller">AppBundle:Main:contact</default>
+            <route id="news" path="/news" methods="GET">
+                <default key="_controller">AppBundle:Main:news</default>
             </route>
 
-            <route id="contact_process" path="/contact" methods="POST">
-                <default key="_controller">AppBundle:Main:processContact</default>
+            <route id="contact_form" path="/contact" methods="GET|POST">
+                <default key="_controller">AppBundle:Main:contactForm</default>
             </route>
         </routes>
 
@@ -886,13 +886,13 @@ be accomplished with the following route configuration:
         use Symfony\Component\Routing\Route;
 
         $collection = new RouteCollection();
-        $collection->add('contact', new Route('/contact', array(
+        $collection->add('news', new Route('/news', array(
             '_controller' => 'AppBundle:Main:contact',
         ), array(), array(), '', array(), array('GET')));
 
-        $collection->add('contact_process', new Route('/contact', array(
-            '_controller' => 'AppBundle:Main:processContact',
-        ), array(), array(), '', array(), array('POST')));
+        $collection->add('contact_form', new Route('/contact', array(
+            '_controller' => 'AppBundle:Main:contactForm',
+        ), array(), array(), '', array(), array('GET', 'POST')));
 
         return $collection;
 

book/security.rst

@@ -994,10 +994,10 @@ other users. Also, as the admin user, you yourself want to be able to edit
 
 To accomplish this you have 2 options:
 
-* :doc:`Voters </cookbook/security/voters_data_permission>` allow you to
-  use business logic (e.g. the user can edit this post because they were
-  the creator) to determine access. You'll probably want this option - it's
-  flexible enough to solve the above situation.
+* :doc:`Voters </cookbook/security/voters>` allow you to use business logic
+  (e.g. the user can edit this post because they were the creator) to determine
+  access. You'll probably want this option - it's flexible enough to solve the
+  above situation.
 
 * :doc:`ACLs </cookbook/security/acl>` allow you to create a database structure
   where you can assign *any* arbitrary user *any* access (e.g. EDIT, VIEW)
@@ -1378,7 +1378,7 @@ Learn More from the Cookbook
 
 * :doc:`Forcing HTTP/HTTPS </cookbook/security/force_https>`
 * :doc:`Impersonating a User </cookbook/security/impersonating_user>`
-* :doc:`/cookbook/security/voters_data_permission`
+* :doc:`/cookbook/security/voters`
 * :doc:`Access Control Lists (ACLs) </cookbook/security/acl>`
 * :doc:`/cookbook/security/remember_me`
 * :doc:`/cookbook/security/multiple_user_providers`

components/console/introduction.rst

@@ -175,22 +175,18 @@ Verbosity Levels
    The ``VERBOSITY_VERY_VERBOSE`` and ``VERBOSITY_DEBUG`` constants were introduced
    in version 2.3
 
-The console has 5 levels of verbosity. These are defined in the
+The console has five verbosity levels. These are defined in the
 :class:`Symfony\\Component\\Console\\Output\\OutputInterface`:
 
-=======================================  ==================================
-Mode                                     Value
-=======================================  ==================================
-OutputInterface::VERBOSITY_QUIET         Do not output any messages
-OutputInterface::VERBOSITY_NORMAL        The default verbosity level
-OutputInterface::VERBOSITY_VERBOSE       Increased verbosity of messages
-OutputInterface::VERBOSITY_VERY_VERBOSE  Informative non essential messages
-OutputInterface::VERBOSITY_DEBUG         Debug messages
-=======================================  ==================================
-
-You can specify the quiet verbosity level with the ``--quiet`` or ``-q``
-option. The ``--verbose`` or ``-v`` option is used when you want an increased
-level of verbosity.
+===========================================  ==================================  =====================
+Value                                        Meaning                             Console option
+===========================================  ==================================  =====================
+``OutputInterface::VERBOSITY_QUIET``         Do not output any messages          ``-q`` or ``--quiet``
+``OutputInterface::VERBOSITY_NORMAL``        The default verbosity level         (none)
+``OutputInterface::VERBOSITY_VERBOSE``       Increased verbosity of messages     ``-v``
+``OutputInterface::VERBOSITY_VERY_VERBOSE``  Informative non essential messages  ``-vv``
+``OutputInterface::VERBOSITY_DEBUG``         Debug messages                      ``-vvv``
+===========================================  ==================================  =====================
 
 .. tip::
 

cookbook/map.rst.inc

@@ -177,7 +177,6 @@
 * :doc:`Security Authorization (Denying Access) </cookbook/security/index>`
 
   * :doc:`/cookbook/security/voters`
-  * :doc:`/cookbook/security/voters_data_permission`
   * :doc:`/cookbook/security/acl`
   * :doc:`/cookbook/security/acl_advanced`
   * :doc:`/cookbook/security/force_https`

cookbook/security/acl.rst

@@ -14,7 +14,7 @@ the ACL system comes in.
     Using ACL's isn't trivial, and for simpler use cases, it may be overkill.
     If your permission logic could be described by just writing some code (e.g.
     to check if a Blog is owned by the current User), then consider using
-    :doc:`voters </cookbook/security/voters_data_permission>`. A voter is passed the object
+    :doc:`voters </cookbook/security/voters>`. A voter is passed the object
     being voted on, which you can use to make complex decisions and effectively
     implement your own ACL. Enforcing authorization (e.g. the ``isGranted``
     part) will look similar to what you see in this entry, but your voter

cookbook/security/index.rst

@@ -31,7 +31,6 @@ Authorization (Denying Access)
     :maxdepth: 2
 
     voters
-    voters_data_permission
     acl
     acl_advanced
     force_https