Skip to content

Patch based 2.7 #6985

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions bundles/inheritance.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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::

Expand Down
2 changes: 1 addition & 1 deletion bundles/installation.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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``::

Expand Down
19 changes: 9 additions & 10 deletions bundles/override.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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::
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only true for Symfony >= 2.8.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But we may want to remove this paragraph entirely for the 2.7 docs and only talk about form type extensions.


$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:

Expand All @@ -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:
Expand Down
8 changes: 4 additions & 4 deletions bundles/prepend_extension.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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.

Expand Down