New in Symfony 3.4: Deprecated bundle inheritance

Contributed by
Fabien Potencier
in #24160.

One of the biggest changes of the upcoming Symfony 4 version is the removal of bundles to manage the application code. Bundles will still exist as third-party plugins installed in vendor/, but your own code will live by default in the src/ directory and it will use plain PHP namespaces instead of bundles.

In Symfony 3.4 we worked towards simplifying bundles even more. That's why we deprecated bundle inheritance and we'll remove it in Symfony 4.0. This inheritance mechanism was traditionally used to override some templates, controllers and other elements of third-party bundles. In Symfony 4.0 you'll need to use alternative solutions to override those elements:

  • Controllers: define a route with the same path as the controller you want to override and implement your own logic.
  • Templates: use the common template overriding mechanism with the traditional app/Resources/<BundleName>/views/<templateName>.html.twig dir or the new templates/bundles/<BundleName>/<templateName>.html.twig dir on Symfony 3.4 and higher; you can also use Twig namespaces to define new templates under the same namespace as the bundle you want to customize.
  • Routing: don't load the bundle routes or apply the same technique as controllers.
  • Services and Configuration: use compiler passes or service decoration.
  • Entities: not possible unless the bundle provides a mapped superclass.
  • Forms: use form extensions.
  • Validation: not possible unless the bundle provides validation groups.
  • Translations: not related to bundle inheritance; just override the right translation domain.
Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.


Does upcoming changes will be reflected in the documentation soon as 3.4 will appear or until 4.0 ?
We'll work on updating the docs once the "feature freeze" period starts at the end of this week.
Does this mean that you cannot override a controller method if it's not linked to a route ?
It makes sense.
@nicolas which case are you referring to ?
For anyone wondering, the bundle inheritance system was not allowing to override entities, validation rules, forms or translation either (and not services loaded by DI extension either). So overriding these ones does not actually change after the deprecation.
The only actual changes are for routing (where just redefining the route was always possible), templates (where overriding the template without using a child bundle always worked too) and controllers.
@christophe I guess @nicolas refers to controller actions that are rendered from a twig, and int this case if I'm not wrong the solution is to override the "parent" template and render our own controller action in it
Does this means I cannot separate my code (under `/src`) into bundles ?!
And if I want to create a third party bundle that will be installed under `/vendor` how can I do this ?
@Arnaout you can still use bundles for your application code, but it won't be officially recommended and some features may not work as expected (the opposite of today's situation, where bundles are recommended but some people don't use them).

About third-party bundles, nothing changes. You can still create those bundles and they are still installed in vendor/ In fact, a possible solution for your current in-app bundles is to turn them into private third-party bundles and install them in your application.
For advanced cases when you want to override Twig templates, declare a static namespaced path is not enough, but you can declare and register Twig template loaders. This is what we are doing in PrestaShop =>
Is Symfony 3.4 compatible with plain PHP namespaces for application code ? And ... is there any guideline for this move ?
@Pierre-Charles yes, when using Symfony 3.3 or higher with Symfony Flex. See for an example.
@Javier does it means bundles won't work anymore (even thoses in vendor/) and Flex will be the plugable system into Symfony4 applications?
@Mickaël third-party bundles (those installed in vendor/) will work as before because we're not changing anything for them (except the auto-registration and auto-configuration if you use Flex, but that's just some automation).
I use a own `bundles` directory and wire it in composer.

This is a Symfony 3.3.* Skeleton with the Symfony 4 Directory Structure without Flex. (mainly for my own use - and to quicken the bootstrap of certain apps)
I planned to develop large web application based on symfony 4 ... Application will grow by adding/removing/composing features via private bundles.
So we need SensioBundleGenerator command to boost our development ... But It seem they are removed from symfony 4 support tools.
But still, internal bundles are not deprecated, although not recommended in symfony 4 !?
Is flex the new tool concerned by internal private bundles management ? and when will bundles creation be available for developers ?
Much love and +1 for removing Bundles inside of src/

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.