Fixing broken references throughout the docs

Author: weaverryan

book/http_fundamentals.rst

@@ -459,7 +459,7 @@ regardless of how your project is developed. To name a few:
 * `Form`_ - A full-featured and flexible framework for creating forms and
   handing form submissions;
 
-* `Validation`_ A system for creating rules about data and then validating
+* `Validator`_ A system for creating rules about data and then validating
   whether or not user-submitted data follows those rules;
 
 * `ClassLoader`_ An autoloading library that allows PHP classes to be used
@@ -509,7 +509,7 @@ sensible defaults. For more advanced users, the sky is the limit.
 .. _`HttpFoundation`: https://github.com/symfony/HttpFoundation
 .. _`Routing`: https://github.com/symfony/Routing
 .. _`Form`: https://github.com/symfony/Form
-.. _`Validation`: https://github.com/symfony/Validation
+.. _`Validator`: https://github.com/symfony/Validator
 .. _`ClassLoader`: https://github.com/symfony/ClassLoader
 .. _`Templating`: https://github.com/symfony/Templating
 .. _`Security`: https://github.com/symfony/Security

book/internals.rst

@@ -23,7 +23,7 @@ on top of the previous one.
 
     Autoloading is not managed by the framework directly; it's done
     independently with the help of the
-    :class:`Symfony\\Component\\HttpFoundation\\UniversalClassLoader` class
+    :class:`Symfony\\Component\\ClassLoader\\UniversalClassLoader` class
     and the ``src/autoload.php`` file. Read the :doc:`dedicated chapter
     </cookbook/tools/autoloader>` for more information.
 
@@ -117,8 +117,8 @@ name (a "class::method" string, like
 .. tip::
 
     The default implementation uses the
-    :class:`Symfony\\Bundle\\FrameworkBundle\\RequestListener` to define the
-    ``_controller`` Request attribute (see :ref:`kernel-core_request`).
+    :class:`Symfony\\Bundle\\FrameworkBundle\\EventListener\\RouterListener`
+    to define the ``_controller`` Request attribute (see :ref:`kernel-core_request`).
 
 The
 :method:`Symfony\\Component\\HttpKernel\\Controller\\ControllerResolverInterface::getArguments`
@@ -250,7 +250,7 @@ the event. In this case, all other listeners won't be called.
 
 This event is used by ``FrameworkBundle`` to populate the ``_controller``
 ``Request`` attribute, via the
-:class:`Symfony\\Bundle\\FrameworkBundle\\RequestListener`. RequestListener
+:class:`Symfony\\Bundle\\FrameworkBundle\\EventListener\\RouterListener`. RequestListener
 uses a :class:`Symfony\\Component\\Routing\\RouterInterface` object to match
 the ``Request`` and determine the Controller name (stored in the
 ``_controller`` ``Request`` attribute).
@@ -328,7 +328,7 @@ The purpose of this event is to allow other systems to modify or replace the
 
 The ``FrameworkBundle`` registers several listeners:
 
-* :class:`Symfony\\Component\\HttpKernel\\Profiler\\EventListener\\ProfilerListener`:
+* :class:`Symfony\\Component\\HttpKernel\\EventListener\\ProfilerListener`:
   collects data for the current request;
 
 * :class:`Symfony\\Bundle\\WebProfilerBundle\\EventListener\\WebDebugToolbarListener`:
@@ -352,7 +352,7 @@ The ``FrameworkBundle`` registers several listeners:
 *Event Class*: :class:`Symfony\\Component\\HttpKernel\\Event\\GetResponseForExceptionEvent`
 
 ``FrameworkBundle`` registers a
-:class:`Symfony\\Bundle\\FrameworkBundle\\Controller\\ExceptionListener` that
+:class:`Symfony\\Component\\HttpKernel\\EventListener\\ExceptionListener` that
 forwards the ``Request`` to a given Controller (the value of the
 ``exception_listener.controller`` parameter -- must be in the
 ``class::method`` notation).

book/page_creation.rst

@@ -229,7 +229,9 @@ page in this case).
 
 Congratulations! After creating only a route and a controller, you already
 have a fully-functional page! If you've setup everything correctly, your
-application should greet you::
+application should greet you:
+
+.. code-block:: text
 
     http://localhost/app_dev.php/hello/Ryan
 
@@ -413,18 +415,22 @@ use a Kernel class, ``AppKernel``, to bootstrap the application.
 
 .. tip::
 
-   Having a front controller means different and more flexible URLs than
-   are used in a typical flat PHP application. When using a front controller,
-   URLs are formatted in the following way:
+    Having a front controller means different and more flexible URLs than
+    are used in a typical flat PHP application. When using a front controller,
+    URLs are formatted in the following way:
+   
+    .. code-block:: text
 
-       http://localhost/app.php/hello/Ryan
+        http://localhost/app.php/hello/Ryan
 
-   The front controller, ``app.php``, is executed and the URI ``/hello/Ryan``
-   is routed internally using the routing configuration. By using Apache
-   ``mod_rewrite`` rules, you can force the ``app.php`` file to be executed without
-   needing to specify it in the URL::
+    The front controller, ``app.php``, is executed and the URI ``/hello/Ryan``
+    is routed internally using the routing configuration. By using Apache
+    ``mod_rewrite`` rules, you can force the ``app.php`` file to be executed without
+    needing to specify it in the URL:
+   
+    .. code-block:: text
 
-    http://localhost/hello/Ryan
+        http://localhost/hello/Ryan
 
 Though front controllers are essential in handling every request, you'll
 rarely need to modify or even think about them. We'll mention them again
@@ -783,12 +789,16 @@ A Symfony2 project generally begins with three environments (``dev``, ``test``
 and ``prod``), though creating new environments is easy. You can view your
 application in different environments simply by changing the front controller
 in your browser. To see the application in the ``dev`` environment, access
-the application via the development front controller::
+the application via the development front controller:
+
+.. code-block:: text
 
     http://localhost/app_dev.php/hello/Ryan
 
 If you'd like to see how your application will behave in the production environment,
-call the ``prod`` front controller instead::
+call the ``prod`` front controller instead:
+
+.. code-block:: text
 
     http://localhost/app.php/hello/Ryan
 

book/security.rst

@@ -706,7 +706,7 @@ For each incoming request, Symfony2 tries to find a matching access control
 rule (the first one wins). If the user isn't authenticated yet, the authentication
 process is initiated (i.e. the user is given a chance to login). However,
 if the user *is* authenticated but doesn't have the required role, an
-:class:`Symfony\\Component\Security\\Core\\Exception\\AccessDeniedException`
+:class:`Symfony\\Component\\Security\\Core\\Exception\\AccessDeniedException`
 exception is thrown, which you can handle and turn into a nice "access denied"
 error page for the user. See :doc:`/cookbook/controller/error_pages` for
 more information.

cookbook/form/twig_form_customization.rst

@@ -55,7 +55,7 @@ What are Form Themes?
 
 When any part of a form is rendered - field labels, errors, ``input`` text fields,
 ``select`` tags, etc - Symfony uses the markup from a base Twig template file
-that ships with Symfony. This template, `div_layout.html.twig`_, contains
+that ships with Symfony. This template, `form_div_layout.html.twig`_, contains
 Twig blocks that define each and every part of a form that can be rendered.
 This template represents the default form "theme" and in the next section,
 you'll learn how to import your own set of customized form blocks (i.e. themes).
@@ -69,7 +69,7 @@ For example, when the widget of a ``text`` type field is rendered, an ``input``
 
     <input type="text" id="form_name" name="form[name]" required="required" value="foo" />
 
-Internally, Symfony uses the ``text_widget`` block from the `div_layout.html.twig`_
+Internally, Symfony uses the ``text_widget`` block from the `form_div_layout.html.twig`_
 template to render the field. This is because the field type is ``text`` and
 you're rendering its ``widget`` (as opposed to its ``label`` or ``errors``).
 The default implementation of the ``text_widget`` block looks like this:
@@ -82,7 +82,7 @@ The default implementation of the ``text_widget`` block looks like this:
     {% endblock text_widget %}
 
 As you can see, this block itself renders another block - ``field_widget``
-that lives in `div_layout.html.twig`_:
+that lives in `form_div_layout.html.twig`_:
 
 .. code-block:: html+jinja
 
@@ -91,7 +91,7 @@ that lives in `div_layout.html.twig`_:
         <input type="{{ type }}" {{ block('attributes') }} value="{{ value }}" />
     {% endblock field_widget %}
 
-The point is, the blocks inside `div_layout.html.twig`_ dictate the HTML
+The point is, the blocks inside `form_div_layout.html.twig`_ dictate the HTML
 output of each part of a form. To customize form output, you just need to
 identify and override the correct block. When any number of these form block
 customizations are put into a template, that template is known as a from "theme".
@@ -221,7 +221,7 @@ Referencing Base Form Blocks
 ----------------------------
 
 So far, to override a particular form block, the best method is to copy
-the default block from `div_layout.html.twig`_, paste it into a different template,
+the default block from `form_div_layout.html.twig`_, paste it into a different template,
 and the customize it. In many cases, you can avoid doing this by referencing
 the base block when customizing it.
 
@@ -236,9 +236,9 @@ the form:
 
 .. code-block:: jinja
 
-    {% use 'div_layout.html.twig' with text_widget as base_text_widget %}
+    {% use 'form_div_layout.html.twig' with text_widget as base_text_widget %}
 
-Now, when the blocks from `div_layout.html.twig`_ are imported, the ``text_widget``
+Now, when the blocks from `form_div_layout.html.twig`_ are imported, the ``text_widget``
 block is called ``base_text_widget``. This means that when you redefine the
 ``text_widget`` block, you can reference the default markup via ``base_text_widget``:
 
@@ -260,7 +260,7 @@ the base block by using the ``parent()`` Twig function:
 
     {# src/Acme/DemoBundle/Resources/views/Form/fields.html.twig #}
 
-    {% extends 'div_layout.html.twig' %}
+    {% extends 'form_div_layout.html.twig' %}
 
     {% block text_widget %}
         <div class="text_widget">
@@ -285,7 +285,7 @@ template and then importing it inside your application configuration:
         twig:
             form:
                 resources:
-                    - 'div_layout.html.twig'
+                    - 'form_div_layout.html.twig'
                     - 'AcmeStoreBundle:Form:fields.html.twig'
             # ...
 
@@ -294,7 +294,7 @@ template and then importing it inside your application configuration:
         <!-- app/config/config.xml -->
         <twig:config ...>
                 <twig:form>
-                    <resource>div_layout.html.twig</resource>
+                    <resource>form_div_layout.html.twig</resource>
                     <resource>AcmeStoreBundle:Form:fields.html.twig</resource>
                 </twig:form>
                 <!-- ... -->
@@ -305,7 +305,7 @@ template and then importing it inside your application configuration:
         // app/config/config.php
         $container->loadFromExtension('twig', array(
             'form' => array('resources' => array(
-                'div_layout.html.twig',
+                'form_div_layout.html.twig',
                 'AcmeStoreBundle:Form:fields.html.twig',
              ))
             // ...
@@ -507,7 +507,7 @@ form, modify the ``use`` tag and add the following:
 
 .. code-block:: html+jinja
 
-    {% use 'div_layout.html.twig' with field_label as base_field_label %}
+    {% use 'form_div_layout.html.twig' with field_label as base_field_label %}
 
     {% block field_label %}
         {{ block('base_field_label') }}
@@ -522,7 +522,7 @@ following:
 
 .. code-block:: html+jinja
 
-    {% extends 'div_layout.html.twig' %}
+    {% extends 'form_div_layout.html.twig' %}
 
     {% block field_label %}
         {{ parent() }}
@@ -545,7 +545,7 @@ form, modify the ``use`` tag and add the following:
 
 .. code-block:: html+jinja
 
-    {% use 'div_layout.html.twig' with field_widget as base_field_widget %}
+    {% use 'form_div_layout.html.twig' with field_widget as base_field_widget %}
 
     {% block field_widget %}
         {{ block('base_field_widget') }}
@@ -560,7 +560,7 @@ following:
 
 .. code-block:: html+jinja
 
-    {% extends 'div_layout.html.twig' %}
+    {% extends 'form_div_layout.html.twig' %}
 
     {% block field_widget %}
         {{ parent() }}
@@ -579,4 +579,4 @@ To render a help message below a field, pass in a ``help`` variable:
 .. tip::
     See :ref:`cookbook-form-twig-two-methods` for how to apply this customization.
 
-.. _`div_layout.html.twig`: https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Twig/Resources/views/Form/div_layout.html.twig
+.. _`form_div_layout.html.twig`: https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Twig/Resources/views/Form/form_div_layout.html.twig

cookbook/logging/monolog.rst

@@ -39,7 +39,7 @@ your controller::
 .. tip::
 
     Using only the methods of the
-    :class:`Symfony\Component\HttpKernel\Log\LoggerInterface` interface
+    :class:`Symfony\\Component\\HttpKernel\\Log\\LoggerInterface` interface
     allows to change the logger implementation without changing your code.
 
 Using several handlers

cookbook/performance/bootstrap_files.rst

@@ -26,4 +26,4 @@ file since there will be less files to monitor for changes. Of course if this
 feature is disabled in the byte code cache (e.g. ``apc.stat=0`` in APC), there
 is no longer a reason to use a bootstrap file.
 
-.. _`bootstrap file`: https://github.com/symfony/symfony-standard/blob/master/bin/build_bootstrap
+.. _`bootstrap file`: https://github.com/sensio/SensioDistributionBundle/blob/master/Resources/bin/build_bootstrap.php

reference/forms/types/datetime.rst

@@ -28,7 +28,7 @@ data can be a ``DateTime`` object, a string, a timestamp or an array.
 +----------------------+-----------------------------------------------------------------------------+
 | Parent type          | :doc:`form</reference/forms/types/form>`                                    |
 +----------------------+-----------------------------------------------------------------------------+
-| Class                | :class:`Symfony\\Component\\Form\\Extension\\Core\\Type\\DatetimeType`      |
+| Class                | :class:`Symfony\\Component\\Form\\Extension\\Core\\Type\\DateTimeType`      |
 +----------------------+-----------------------------------------------------------------------------+
 
 Options

reference/forms/types/entity.rst

@@ -27,7 +27,7 @@ objects from the database.
 +----------------------+------------------------------------------------------------------+
 | Parent type          | :doc:`choice</reference/forms/types/choice>`                     |
 +----------------------+------------------------------------------------------------------+
-| Class                | :class:`Symfony\Bridge\Doctrine\Form\Type\\EntityType`           |
+| Class                | :class:`Symfony\\Bridge\\Doctrine\\Form\\Type\\EntityType`       |
 +----------------------+------------------------------------------------------------------+
 
 Basic Usage

reference/forms/types/integer.rst

@@ -33,7 +33,7 @@ Options
 * ``rounding_mode`` [type: integer, default: ``IntegerToLocalizedStringTransformer::ROUND_DOWN``]
     By default, if the user enters a non-integer number, it will be rounded
     down. There are several other rounding methods, and each is a constant
-    on the :class:`Symfony\\Component\\Form\\DataTransformer\\IntegerToLocalizedStringTransformer`:
+    on the :class:`Symfony\\Component\\Form\\Extension\\Core\\DataTransformer\\IntegerToLocalizedStringTransformer`:
 
     * ``IntegerToLocalizedStringTransformer::ROUND_DOWN``
         Rounding mode to round towards zero.

reference/forms/types/number.rst

@@ -37,7 +37,7 @@ Options
 * ``rounding_mode`` [type: integer, default: ``IntegerToLocalizedStringTransformer::ROUND_DOWN``]
     If a submitted number needs to be rounded (based on the ``precision``
     option), you have several configurable options for that rounding. Each
-    option is a constant on the :class:`Symfony\\Component\\Form\\DataTransformer\\IntegerToLocalizedStringTransformer`:
+    option is a constant on the :class:`Symfony\\Component\\Form\\Extension\\Core\\DataTransformer\\IntegerToLocalizedStringTransformer`:
 
     * ``IntegerToLocalizedStringTransformer::ROUND_DOWN``
         Rounding mode to round towards zero.

reference/forms/types/timezone.rst

@@ -4,8 +4,6 @@
 timezone Field Type
 ===================
 
-See :class:`Symfony\\Component\\Form\\Type\\TimezoneType`.
-
 The ``timezone`` type is a subset of the ``ChoiceType`` that allows the user
 to select from all possible timezones.