New in Symfony 3.4: Deprecated bundle inheritance

September 28, 2017 • Published by Javier Eguiluz

Warning: This post is about an unsupported Symfony version. Some of this information may be out of date. Read the most recent Symfony Docs.

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.

Published in #Living on the edge

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.

Comments

Piotr Karszny said on Sep 28, 2017 at 12:57

Does upcoming changes will be reflected in the documentation soon as 3.4 will appear or until 4.0 ?

Javier Eguiluz Certified said on Sep 28, 2017 at 13:18

We'll work on updating the docs once the "feature freeze" period starts at the end of this week.

Nicolas Vasse said on Sep 28, 2017 at 13:27

Does this mean that you cannot override a controller method if it's not linked to a route ?

Marko Malović said on Sep 28, 2017 at 14:13

It makes sense.

Christophe Coevoet said on Sep 28, 2017 at 16:42

@nicolas which case are you referring to ?

Christophe Coevoet said on Sep 28, 2017 at 16:45

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.

Miguel Angel Garzón said on Sep 28, 2017 at 22:48

@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

Arnaout Slimen said on Sep 29, 2017 at 06:53

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 ?

Javier Eguiluz Certified said on Sep 29, 2017 at 07:23

@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.

Mickaël Andrieu said on Sep 29, 2017 at 09:22

#10

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 => https://github.com/PrestaShop/PrestaShop/pull/8342/files#diff-51302ce8fc72689a3c2aed19b5e5a13a

Pierre-Charles Bertineau said on Sep 29, 2017 at 10:04

#11

Is Symfony 3.4 compatible with plain PHP namespaces for application code ? And ... is there any guideline for this move ?

Javier Eguiluz Certified said on Sep 29, 2017 at 11:11

#12

@Pierre-Charles yes, when using Symfony 3.3 or higher with Symfony Flex. See https://github.com/symfony/symfony-demo for an example.

Mickaël Andrieu said on Sep 30, 2017 at 13:14

#13

@Javier does it means bundles won't work anymore (even thoses in vendor/) and Flex will be the plugable system into Symfony4 applications?

Javier Eguiluz Certified said on Sep 30, 2017 at 16:09

#14

@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).

Ludwig Ruderstaller said on Oct 6, 2017 at 10:20

#15

I use a own bundles directory and wire it in composer. https://github.com/cwd/cwdStandardEdition/blob/develop/composer.json#L15

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)

Claude Bernard Diesse said on Nov 4, 2017 at 19:05

#16

Hi, 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 ? Regards.