symfony
diff --git a/‎best_practices/business-logic.rst
+2-5 b/‎best_practices/business-logic.rst
+2-5
diff --git a/‎best_practices/forms.rst
+3-9 b/‎best_practices/forms.rst
+3-9
diff --git a/‎best_practices/security.rst
+4-2 b/‎best_practices/security.rst
+4-2
@@ -140,12 +140,9 @@ the class namespace as a parameter:
     # app/config/services.yml
 
     # service definition with class namespace as parameter
-    parameters:
-        slugger.class: AppBundle\Utils\Slugger
-
     services:
         app.slugger:
-            class: "%slugger.class%"
+            class: AppBundle\Utils\Slugger
 
 This practice is cumbersome and completely unnecessary for your own services:
 
@@ -335,7 +332,7 @@ in a matter of seconds.
 
 .. _`full definition`: http://en.wikipedia.org/wiki/Business_logic
 .. _`Doctrine project`: http://www.doctrine-project.org/
-.. _`fixture class`: http://symfony.com/doc/master/bundles/DoctrineFixturesBundle/index.html#writing-simple-fixtures
+.. _`fixture class`: http://symfony.com/doc/current/bundles/DoctrineFixturesBundle/index.html#writing-simple-fixtures
 .. _`PSR-1`: http://www.php-fig.org/psr/psr-1/
 .. _`PSR-2`: http://www.php-fig.org/psr/psr-2/
 .. _`the Symfony Code Standards`: http://symfony.com/doc/current/contributing/code/standards.html
 
@@ -15,9 +15,7 @@ Building Forms
 The Form component allows you to build forms right inside your controller
 code. Honestly, unless you need to reuse the form somewhere else, that's
 totally fine. But for organize and reuse, we recommend that you define each
-form in its own PHP class:
-
-.. code-block:: php
+form in its own PHP class::
 
     namespace AppBundle\Form;
 
@@ -51,9 +49,7 @@ form in its own PHP class:
         }
     }
 
-To use the class, use ``createForm`` and instantiate the new class:
-
-.. code-block:: php
+To use the class, use ``createForm`` and instantiate the new class::
 
     use AppBundle\Form\PostType;
     // ...
@@ -110,9 +106,7 @@ directly in your form class, this would effectively limit the scope of that form
 
 This form *may* have been designed for creating posts, but if you wanted
 to reuse it for editing posts, the button label would be wrong. Instead,
-some developers configure form buttons in the controller:
-
-.. code-block:: php
+some developers configure form buttons in the controller::
 
     namespace AppBundle\Controller\Admin;
 
 
@@ -75,7 +75,7 @@ Authorization (i.e. Denying Access)
 Symfony gives you several ways to enforce authorization, including the ``access_control``
 configuration in :doc:`security.yml </reference/configuration/security>` the
 :ref:`@Security annotation <best-practices-security-annotation>` and using
-:ref:`isGranted <best-practices-directy-isGranted>` on the ``security.context``
+:ref:`isGranted <best-practices-directly-isGranted>` on the ``security.context``
 service directly.
 
 .. best-practice::
@@ -206,7 +206,7 @@ Now you can reuse this method both in the template and in the security expressio
         <a href=""> ... </a>
     {% endif %}
 
-.. _best-practices-directy-isGranted:
+.. _best-practices-directly-isGranted:
 
 Checking Permissions without @Security
 --------------------------------------
@@ -352,5 +352,7 @@ develop :doc:`your own user provider </cookbook/security/custom_provider>` and
 
 .. _`ParamConverter`: http://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/converters.html
 .. _`@Security annotation`: http://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/security.html
+.. _`security voter`: http://symfony.com/doc/current/cookbook/security/voters_data_permission.html
+.. _`ACL's`: http://symfony.com/doc/current/cookbook/security/acl.html
 .. _`expression`: http://symfony.com/doc/current/components/expression_language/introduction.html
 .. _`FOSUserBundle`: https://github.com/FriendsOfSymfony/FOSUserBundle