How to Override any Part of a Bundle

This document is a quick reference for how to override different parts of
third-party bundles.

Tip

The bundle overriding mechanism means that you cannot use physical paths to
refer to bundle's resources (e.g. __DIR__/config/services.xml). Always
use logical paths in your bundles (e.g. @AppBundle/Resources/config/services.xml)
and call the locateResource() method
to turn them into physical paths when needed.

Routing is never automatically imported in Symfony. If you want to include
the routes from any bundle, then they must be manually imported from somewhere
in your application (e.g. app/config/routing.yml).

The easiest way to "override" a bundle's routing is to never import it at
all. Instead of importing a third-party bundle's routing, simply copy
that routing file into your application, modify it, and import it instead.

Assuming the third-party bundle involved uses non-service controllers (which
is almost always the case), you can easily override controllers via bundle
inheritance. For more information, see How to Use Bundle Inheritance to Override Parts of a Bundle.
If the controller is a service, see the next section on how to override it.

If a bundle defines its entity mapping in configuration files instead of
annotations, you can override them as any other regular bundle configuration
file. The only caveat is that you must override all those mapping configuration
files and not just the ones you actually want to override.

If a bundle provides a mapped superclass (such as the User entity in the
FOSUserBundle) you can override its attributes and associations. Learn more
about this feature and its limitations in the Doctrine documentation.

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 overcome this, the 3rd party bundle needs to have configuration for
validation groups. For instance, the FOSUserBundle
has this configuration. To create your own validation, add the constraints
to a new validation group:

Translations are not related to bundles, but to domains. That means that you
can override the translations from any translation file, as long as it is in
the correct domain.

Caution

Translation files are not aware of bundle inheritance.
If you want to override translations from the parent bundle or another bundle,
make sure that the bundle containing your translations is loaded after any
bundle whose translations you're overriding. This is done in AppKernel.

Finally, translations located in app/Resources/translations will override
all the other translations since those files are always loaded last.