Patch based 2.7

bundles/inheritance.rst

@@ -92,8 +92,8 @@ The same goes for routing files and some other resources.
 
     The overriding of resources only works when you refer to resources with
     the ``@FOSUserBundle/Resources/config/routing/security.xml`` method.
-    If you refer to resources without using the ``@BundleName`` shortcut, they
-    can't be overridden in this way.
+    You need to use the ``@BundleName`` shortcut when refering to resources
+    so they can be successfully overridden.
 
 .. caution::
 

bundles/installation.rst

@@ -49,7 +49,7 @@ version, include it as the second argument of the `composer require`_ command:
 B) Enable the Bundle
 --------------------
 
-At this point, the bundle is installed in your Symfony project (in
+At this point, the bundle is installed in your Symfony project (e.g. 
 ``vendor/friendsofsymfony/``) and the autoloader recognizes its classes.
 The only thing you need to do now is register the bundle in ``AppKernel``::
 
@@ -108,14 +108,14 @@ via the ``config:dump-reference`` command:
 
 .. code-block:: bash
 
-    $ app/console config:dump-reference AsseticBundle
+    $ bin/console config:dump-reference AsseticBundle
 
 Instead of the full bundle name, you can also pass the short name used as the root
 of the bundle's configuration:
 
 .. code-block:: bash
 
-    $ app/console config:dump-reference assetic
+    $ bin/console config:dump-reference assetic
 
 The output will look like this:
 

bundles/override.rst

@@ -37,7 +37,7 @@ If the controller is a service, see the next section on how to override it.
 Services & Configuration
 ------------------------
 
-In order to override/extend a service, there are two options. First, you can
+In order to override or extend a service you have two options. First, you can
 set the parameter holding the service's class name to your own class by setting
 it in ``app/config/config.yml``. This of course is only possible if the class name is
 defined as a parameter in the service config of the bundle containing the
@@ -105,17 +105,16 @@ associations. Learn more about this feature and its limitations in
 Forms
 -----
 
-In order to override a form type, it has to be registered as a service (meaning
-it is tagged as ``form.type``). You can then override it as you would override any
-service as explained in `Services & Configuration`_. This, of course, will only
-work if the type is referred to by its alias rather than being instantiated,
-e.g.::
+Form types are referred to by their fully-qualified class name::
 
-    $builder->add('name', 'custom_type');
+    $builder->add('name', CustomType::class);
 
-rather than::
+This means that you cannot override this by creating a sub-class of ``CustomType``
+and registering it as a service and tagging it with ``form.type`` (you *could*
+do this in an earlier version).
 
-    $builder->add('name', new CustomType());
+Instead, you should use a "form type extension" to modify the existing form type.
+For more information, see :doc:`/form/create_form_type_extension`.
 
 .. _override-validation:
 
@@ -126,7 +125,7 @@ Symfony loads all validation configuration files from every bundle and
 combines them into one validation metadata tree. This means you are able to
 add new constraints to a property, but you cannot override them.
 
-To override this, the 3rd party bundle needs to have configuration for
+To overcome this, the 3rd party bundle needs to have configuration for
 :doc:`validation groups </validation/groups>`. For instance, the FOSUserBundle
 has this configuration. To create your own validation, add the constraints
 to a new validation group:

bundles/prepend_extension.rst

@@ -2,7 +2,7 @@
    single: Configuration; Semantic
    single: Bundle; Extension configuration
 
-How to Simplify Configuration of multiple Bundles
+How to Simplify Configuration of Multiple Bundles
 =================================================
 
 When building reusable and extensible applications, developers are often
@@ -12,9 +12,9 @@ users to choose to remove functionality they are not using. Creating multiple
 bundles has the drawback that configuration becomes more tedious and settings
 often need to be repeated for various bundles.
 
-Using the below approach, it is possible to remove the disadvantage of the
-multiple bundle approach by enabling a single Extension to prepend the settings
-for any bundle. It can use the settings defined in the ``app/config/config.yml``
+It is possible to remove the disadvantage of the multiple bundle approach 
+by enabling a single Extension to prepend the settings for any bundle.
+It can use the settings defined in the ``app/config/config.yml``
 to prepend settings just as if they had been written explicitly by
 the user in the application configuration.