Move images to _images and group by topic

components/console/helpers/debug_formatter.rst

@@ -13,7 +13,7 @@ instance a process or HTTP request. For example, if you used it to output
 the results of running ``ls -la`` on a UNIX system, it might output something
 like this:
 
-.. image:: /images/components/console/debug_formatter.png
+.. image:: /_images/components/console/debug_formatter.png
    :align: center
 
 Using the debug_formatter

components/console/helpers/processhelper.rst

@@ -23,15 +23,15 @@ a very verbose verbosity (e.g. -vv)::
 
 will result in this output:
 
-.. image:: /images/components/console/process-helper-verbose.png
+.. image:: /_images/components/console/process-helper-verbose.png
 
 It will result in more detailed output with debug verbosity (e.g. ``-vvv``):
 
-.. image:: /images/components/console/process-helper-debug.png
+.. image:: /_images/components/console/process-helper-debug.png
 
 In case the process fails, debugging is easier:
 
-.. image:: /images/components/console/process-helper-error-debug.png
+.. image:: /_images/components/console/process-helper-error-debug.png
 
 Arguments
 ---------

components/console/helpers/progressbar.rst

@@ -7,7 +7,7 @@ Progress Bar
 When executing longer-running commands, it may be helpful to show progress
 information, which updates as your command runs:
 
-.. image:: /images/components/console/progressbar.gif
+.. image:: /_images/components/console/progressbar.gif
 
 To display progress details, use the
 :class:`Symfony\\Component\\Console\\Helper\\ProgressBar`, pass it a total

components/console/helpers/progresshelper.rst

@@ -17,7 +17,7 @@ Progress Helper
 When executing longer-running commands, it may be helpful to show progress
 information, which updates as your command runs:
 
-.. image:: /images/components/console/progress.png
+.. image:: /_images/components/console/progress.png
 
 To display progress details, use the :class:`Symfony\\Component\\Console\\Helper\\ProgressHelper`,
 pass it a total number of units, and advance the progress as your command executes::

components/console/helpers/tablehelper.rst

@@ -16,7 +16,7 @@ Table Helper
 
 When building a console application it may be useful to display tabular data:
 
-.. image:: /images/components/console/table.png
+.. image:: /_images/components/console/table.png
 
 To display a table, use the :class:`Symfony\\Component\\Console\\Helper\\TableHelper`,
 set headers, rows and render::

components/form.rst

@@ -491,7 +491,7 @@ helper functions:
         <input type="submit" />
     {{ form_end(form) }}
 
-.. image:: /images/book/form-simple.png
+.. image:: /_images/form/simple-form.png
     :align: center
 
 That's it! By printing ``form_widget(form)``, each field in the form is

components/form/form_events.rst

@@ -38,13 +38,13 @@ The Form Workflow
 The Form Submission Workflow
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. image:: /images/components/form/general_flow.png
+.. image:: /_images/components/form/general_flow.png
     :align: center
 
 1) Pre-populating the Form (``FormEvents::PRE_SET_DATA`` and ``FormEvents::POST_SET_DATA``)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. image:: /images/components/form/set_data_flow.png
+.. image:: /_images/components/form/set_data_flow.png
     :align: center
 
 Two events are dispatched during pre-population of a form, when
@@ -121,7 +121,7 @@ View data        Normalized data transformed using a view transformer
 2) Submitting a Form (``FormEvents::PRE_SUBMIT``, ``FormEvents::SUBMIT`` and ``FormEvents::POST_SUBMIT``)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. image:: /images/components/form/submission_flow.png
+.. image:: /_images/components/form/submission_flow.png
     :align: center
 
 Three events are dispatched when

components/http_kernel.rst

@@ -28,7 +28,7 @@ Every HTTP web interaction begins with a request and ends with a response.
 Your job as a developer is to create PHP code that reads the request information
 (e.g. the URL) and creates and returns a response (e.g. an HTML page or JSON string).
 
-.. image:: /images/components/http_kernel/request-response-flow.png
+.. image:: /_images/components/http_kernel/request-response-flow.png
    :align: center
 
 Typically, some sort of framework or system is built to handle all the repetitive
@@ -62,7 +62,7 @@ the concrete implementation of :method:`HttpKernelInterface::handle() <Symfony\\
 defines a workflow that starts with a :class:`Symfony\\Component\\HttpFoundation\\Request`
 and ends with a :class:`Symfony\\Component\\HttpFoundation\\Response`.
 
-.. image:: /images/components/http_kernel/01-workflow.png
+.. image:: /_images/components/http_kernel/01-workflow.png
    :align: center
 
 The exact details of this workflow are the key to understanding how the kernel
@@ -138,7 +138,7 @@ layer that denies access).
 The first event that is dispatched inside :method:`HttpKernel::handle <Symfony\\Component\\HttpKernel\\HttpKernel::handle>`
 is ``kernel.request``, which may have a variety of different listeners.
 
-.. image:: /images/components/http_kernel/02-kernel-request.png
+.. image:: /_images/components/http_kernel/02-kernel-request.png
    :align: center
 
 Listeners of this event can be quite varied. Some listeners - such as a security
@@ -150,7 +150,7 @@ to the login page or a 403 Access Denied response.
 If a ``Response`` is returned at this stage, the process skips directly to
 the :ref:`kernel.response <component-http-kernel-kernel-response>` event.
 
-.. image:: /images/components/http_kernel/03-kernel-request-response.png
+.. image:: /_images/components/http_kernel/03-kernel-request-response.png
    :align: center
 
 Other listeners simply initialize things or add more information to the request.
@@ -205,7 +205,7 @@ to your application. This is the job of the "controller resolver" - a class
 that implements :class:`Symfony\\Component\\HttpKernel\\Controller\\ControllerResolverInterface`
 and is one of the constructor arguments to ``HttpKernel``.
 
-.. image:: /images/components/http_kernel/04-resolve-controller.png
+.. image:: /_images/components/http_kernel/04-resolve-controller.png
    :align: center
 
 Your job is to create a class that implements the interface and fill in its
@@ -280,7 +280,7 @@ some part of the system that needs to be initialized after certain things
 have been determined (e.g. the controller, routing information) but before
 the controller is executed. For some examples, see the Symfony section below.
 
-.. image:: /images/components/http_kernel/06-kernel-controller.png
+.. image:: /_images/components/http_kernel/06-kernel-controller.png
    :align: center
 
 Listeners to this event can also change the controller callable completely
@@ -314,7 +314,7 @@ should be passed to that controller. Exactly how this is done is completely
 up to your design, though the built-in :class:`Symfony\\Component\\HttpKernel\\Controller\\ControllerResolver`
 is a good example.
 
-.. image:: /images/components/http_kernel/07-controller-arguments.png
+.. image:: /_images/components/http_kernel/07-controller-arguments.png
    :align: center
 
 At this point the kernel has a PHP callable (the controller) and an array
@@ -345,7 +345,7 @@ of arguments that should be passed when executing that callable.
 
 The next step is simple! ``HttpKernel::handle`` executes the controller.
 
-.. image:: /images/components/http_kernel/08-call-controller.png
+.. image:: /_images/components/http_kernel/08-call-controller.png
    :align: center
 
 The job of the controller is to build the response for the given resource.
@@ -357,7 +357,7 @@ Usually, the controller will return a ``Response`` object. If this is true,
 then the work of the kernel is just about done! In this case, the next step
 is the :ref:`kernel.response <component-http-kernel-kernel-response>` event.
 
-.. image:: /images/components/http_kernel/09-controller-returns-response.png
+.. image:: /_images/components/http_kernel/09-controller-returns-response.png
    :align: center
 
 But if the controller returns anything besides a ``Response``, then the kernel
@@ -384,7 +384,7 @@ another event - ``kernel.view``. The job of a listener to this event is to
 use the return value of the controller (e.g. an array of data or an object)
 to create a ``Response``.
 
-.. image:: /images/components/http_kernel/10-kernel-view.png
+.. image:: /_images/components/http_kernel/10-kernel-view.png
    :align: center
 
 This can be useful if you want to use a "view" layer: instead of returning
@@ -515,7 +515,7 @@ function is wrapped in a try-catch block. When any exception is thrown, the
 ``kernel.exception`` event is dispatched so that your system can somehow respond
 to the exception.
 
-.. image:: /images/components/http_kernel/11-kernel-exception.png
+.. image:: /_images/components/http_kernel/11-kernel-exception.png
    :align: center
 
 Each listener to this event is passed a :class:`Symfony\\Component\\HttpKernel\\Event\\GetResponseForExceptionEvent`
@@ -660,7 +660,7 @@ a page instead of a full page. You'll most commonly make sub-requests from
 your controller (or perhaps from inside a template, that's being rendered by
 your controller).
 
-.. image:: /images/components/http_kernel/sub-request.png
+.. image:: /_images/components/http_kernel/sub-request.png
    :align: center
 
 To execute a sub request, use ``HttpKernel::handle``, but change the second

components/phpunit_bridge.rst

@@ -42,7 +42,7 @@ Once the component installed, it automatically registers a
 called :class:`Symfony\\Bridge\\PhpUnit\\DeprecationErrorHandler`. After
 running your PHPUnit tests, you will get a report similar to this one:
 
-.. image:: /images/components/phpunit_bridge/report.png
+.. image:: /_images/components/phpunit_bridge/report.png
 
 The summary includes:
 

components/serializer.rst

@@ -14,7 +14,7 @@ simple schema.
 .. _component-serializer-encoders:
 .. _component-serializer-normalizers:
 
-.. image:: /images/components/serializer/serializer_workflow.png
+.. image:: /_images/components/serializer/serializer_workflow.png
 
 As you can see in the picture above, an array is used as a man in
 the middle. This way, Encoders will only deal with turning specific

components/var_dumper.rst

@@ -171,7 +171,7 @@ then its dump representation::
     );
     dump($var);
 
-.. image:: /images/components/var_dumper/01-simple.png
+.. image:: /_images/components/var_dumper/01-simple.png
 
 .. note::
 
@@ -188,7 +188,7 @@ then its dump representation::
     $var .= "this string is not UTF-8 valid, thus the `b` prefix.\n";
     dump($var);
 
-.. image:: /images/components/var_dumper/02-multi-line-str.png
+.. image:: /_images/components/var_dumper/02-multi-line-str.png
 
 .. code-block:: php
 
@@ -202,7 +202,7 @@ then its dump representation::
     $var = new PropertyExample();
     dump($var);
 
-.. image:: /images/components/var_dumper/03-object.png
+.. image:: /_images/components/var_dumper/03-object.png
 
 .. note::
 
@@ -220,7 +220,7 @@ then its dump representation::
     $var->undeclaredProperty = 'Runtime added dynamic properties have `"` around their name.';
     dump($var);
 
-.. image:: /images/components/var_dumper/04-dynamic-property.png
+.. image:: /_images/components/var_dumper/04-dynamic-property.png
 
 .. code-block:: php
 
@@ -232,7 +232,7 @@ then its dump representation::
     $var->aCircularReference = $var;
     dump($var);
 
-.. image:: /images/components/var_dumper/05-soft-ref.png
+.. image:: /_images/components/var_dumper/05-soft-ref.png
 
 .. code-block:: php
 
@@ -245,7 +245,7 @@ then its dump representation::
     );
     dump($var);
 
-.. image:: /images/components/var_dumper/06-constants.png
+.. image:: /_images/components/var_dumper/06-constants.png
 
 .. code-block:: php
 
@@ -258,7 +258,7 @@ then its dump representation::
     $var[3][] = "are dumped using `&number` prefixes.";
     dump($var);
 
-.. image:: /images/components/var_dumper/07-hard-ref.png
+.. image:: /_images/components/var_dumper/07-hard-ref.png
 
 .. code-block:: php
 
@@ -268,7 +268,7 @@ then its dump representation::
     $var[] = "properties that describe their internal state.";
     dump($var);
 
-.. image:: /images/components/var_dumper/08-virtual-property.png
+.. image:: /_images/components/var_dumper/08-virtual-property.png
 
 .. code-block:: php
 
@@ -281,6 +281,6 @@ then its dump representation::
     );
     dump($var);
 
-.. image:: /images/components/var_dumper/09-cut.png
+.. image:: /_images/components/var_dumper/09-cut.png
 
 .. _Packagist: https://packagist.org/packages/symfony/var-dumper

contributing/community/releases.rst

@@ -89,7 +89,7 @@ Schedule
 
 Below is the schedule for the first few versions that use this release model:
 
-.. image:: /images/contributing/release-process.jpg
+.. image:: /_images/contributing/release-process.jpg
    :align: center
 
 * **Yellow** represents the Development phase

contributing/documentation/overview.rst

@@ -38,7 +38,7 @@ while you're reading the Symfony documentation.
 **Step 1.** Click on the **edit this page** button on the upper right corner
 and you'll be redirected to GitHub:
 
-.. image:: /images/contributing/docs-github-edit-page.png
+.. image:: /_images/contributing/docs-github-edit-page.png
 
 **Step 2.** Edit the contents, describe your changes and click on the
 **Propose file change** button.
@@ -47,7 +47,7 @@ and you'll be redirected to GitHub:
 (forking the repository first if this is your first contribution) and it will
 also display a preview of your changes:
 
-.. image:: /images/contributing/docs-github-create-pr.png
+.. image:: /_images/contributing/docs-github-create-pr.png
 
 If everything is correct, click on the **Create pull request** button.
 
@@ -161,7 +161,7 @@ Then, click on the big **New pull request** button. As GitHub cannot guess the
 exact changes that you want to propose, select the appropriate branches where
 changes should be applied:
 
-.. image:: /images/contributing/docs-pull-request-change-base.png
+.. image:: /_images/contributing/docs-pull-request-change-base.png
    :align: center
 
 In this example, the **base fork** should be ``symfony/symfony-docs`` and
@@ -241,7 +241,7 @@ Every GitHub Pull Request is automatically built and deployed by `Platform.sh`_
 on a single environment that you can access on your browser to review your
 changes.
 
-.. image:: /images/contributing/docs-pull-request-platformsh.png
+.. image:: /_images/contributing/docs-pull-request-platformsh.png
    :align: center
    :alt:   Platform.sh Pull Request Deployment
 

controller.rst

@@ -76,7 +76,7 @@ your custom code in the controller function:
 Creating a page is as easy as creating a controller (#5) and making a route
 that maps a URL to that controller (#4).
 
-.. image:: /images/http-xkcd-request.png
+.. image:: /_images/http/xkcd-request.png
    :align: center
 
 .. note::

controller/error_pages.rst

@@ -13,14 +13,14 @@ In the :doc:`development environment </configuration/environments>`,
 Symfony catches all the exceptions and displays a special **exception page**
 with lots of debug information to help you quickly discover the root problem:
 
-.. image:: /images/cookbook/controller/error_pages/exceptions-in-dev-environment.png
+.. image:: /_images/controller/error_pages/exceptions-in-dev-environment.png
    :alt: A typical exception page in the development environment
 
 Since these pages contain a lot of sensitive internal information, Symfony won't
 display them in the production environment. Instead, it'll show a simple and
 generic **error page**:
 
-.. image:: /images/cookbook/controller/error_pages/errors-in-prod-environment.png
+.. image:: /_images/controller/error_pages/errors-in-prod-environment.png
    :alt: A typical error page in the production environment
 
 Error pages for the production environment can be customized in different ways