Standardised link formats, moving html links to references instead of inline

Resources/doc/reference/dashboard.rst

@@ -3,7 +3,7 @@ Dashboard
 
 The dashboard is the main landing page. By default the dashboard lists the different admin areas available.
 The admin list is a block defined by the ``sonata.admin.block.admin_list`` service. More block can be added, just
-follow the instruction in the `BlockBundle documentation <http://sonata-project.org/bundles/block/master/doc/index.html>`_.
+follow the instruction in the `BlockBundle documentation`_.
 
 If you want to customize the dashboard, add the following code to your
 application's config file:
@@ -128,3 +128,5 @@ Display two blocks with different dashboard groups
                 sonata_page3:
                     items:
                         - sonata.page.admin.myitem4
+
+.. _`BlockBundle documentation`:  http://sonata-project.org/bundles/block/master/doc/index.html

Resources/doc/reference/recipe_file_uploads.rst

@@ -303,4 +303,4 @@ as SonataAdmin.
 To learn how to add an image preview to your ImageAdmin take a look at the related cookbook entry.
 
 
-_`uploading files with Doctrine and Symfony`: http://symfony.com/doc/current/cookbook/doctrine/file_uploads.html
+.. _`uploading files with Doctrine and Symfony`: http://symfony.com/doc/current/cookbook/doctrine/file_uploads.html

Resources/doc/reference/security.rst

@@ -25,9 +25,8 @@ There is a little magic in the ``SonataAdminBundle``: if the bundle detects the
 ``SonataUserBundle`` class, then the default ``user_block`` template will be
 changed to use the one provided by the ``SonataUserBundle``.
 
-The install process is available on the dedicated `SonataUserBundle's
-documentation area
-<http://sonata-project.org/bundles/user/master/doc/reference/installation.html>`_
+The install process is available on the dedicated 
+`SonataUserBundle's documentation area`_.
 
 
 Security handlers
@@ -138,8 +137,8 @@ So our ``security.yml`` file may look to something like this:
 
 Note that we also set ``access_strategy`` to unanimous.
 It means that if one voter (for example Sonata) refuses access, access will be denied.
-For more information on this subject, please see `here
-<http://symfony.com/doc/2.2/cookbook/security/voters.html#changing-the-access-decision-strategy>`_
+For more information on this subject, please see `changing the access decision strategy`_ 
+in the Symfony documentation.
 
 Usage
 ~~~~~
@@ -178,8 +177,7 @@ Going further
 ~~~~~~~~~~~~~
 
 Because Sonata role handler supplements Symfony2 security, but does not override it, you are free to do more advanced operations.
-For example, you can `create your own voter
-<http://symfony.com/doc/2.2/cookbook/security/voters.html>`_
+For example, you can `create your own voter`_
 
 Customizing the handler behavior
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -672,4 +670,8 @@ service to use when retrieving your users.
 
     sonata_admin:
         security:
-            acl_user_manager: my_user_manager # The name of your service
+            acl_user_manager: my_user_manager # The name of your service
+
+.. _`SonataUserBundle's documentation area`: http://sonata-project.org/bundles/user/master/doc/reference/installation.html
+.. _`changing the access decision strategy`: http://symfony.com/doc/2.2/cookbook/security/voters.html#changing-the-access-decision-strategy
+.. _`create your own voter`: http://symfony.com/doc/2.2/cookbook/security/voters.html

Resources/doc/reference/translation.rst

@@ -74,7 +74,7 @@ If a translation domain is set at the group level it will cascade down to all
 fields within the group.
 
 Overriding the translation domain is of particular use when using
-:doc:`extensions <extensions>`, where the extension and the translations would
+:doc:`extensions`, where the extension and the translations would
 be defined in one bundle, but implemented in many different Admin instances.
 
 Setting the translation domain on an individual field: