We'll need a test case for this.

@jakzal I modified the TwigExtensionTest to include a test case for this situation.

AppVeyor ran on an outdated commit, might have to be restarted.

@wesleylancel Do you think you can finish this one?

@xabbuh: I wish, as this is something that would be extremely useful for us. But, as pointed out by@ro0NL, bundles can extend infinitely A > B > C > D. My PR currently only checks for one level of extending. Ideally, I would be able to access the bundle map that is part of the kernel, but that's not available at this stage yet. If you could point me towards a possible solution I'd be happy to adjust my code accordingly.

Seeing the related ticket this goes back to 2013. And quite some issues are involved. I've not experienced it myself, but the template problem seems real.

Either way allowing kernel introspection would beextremely useful for everybody. Preferably with an immutable kernel. Practically we can movethis a few lines up. Relying on a synthetic service before compilation.

We also can expose bundles thru parameters, we only need stringish values here.BundleInterface only defines name, path and namespace anyway. So passing a stringish bundle map could work, and seems to make sense as we also provide kernel info already. Any further details can be provided withBundle::build.

But mayve@ogizanagi has more idea's? As i also liked his approach with a contextual builder. Maybe it can be simplified.

Unfortunately#19646 was my only attempt to provide a naive feature for sharing some contextual information while the container is building, avoiding the need to rely on pseudo tmp synthetic services. Along with theBootingKernel andBootingBundle classes, it allowed to solves issues related to this one as a demonstration of the possibilities.
But despite the implementation is simple, it somehow looks overkilled for the few needs.

As you suggested, maybe exposing a simple representation of the bundle map and bundles informations in a kernel parameter could be the way. But I don't remember all the ins and outs and if it was easily feasible at this point. :/

But despite the implementation is simple, it somehow looks overkilled for the few needs.

Agree 👍 I feel the same about my own attempts now. Eventually having a builder with context can be done in userland easily. But it doesnt solve it for SF.

If there arent any other insights, i'd say go for%kernel.bundle_map% 👍

i'd say go for %kernel.bundle_map%

Not sure it's doable. PuttingKernel::$bundleMap in a new kernel parameter would just lead to

Unable to dump a service container if a parameter is an object or a resource.

It's a stringish map, that's actually cached :) we're not passing bundle instances around here.

array(  'name' => ['parent' => 'name2', 'namespace' => 'NS', 'path' => '/bundles/name' ],  'name2' => //)

Something like that i guess.

I mean.. this would lead to a nested<argument> collection in XML right?

Ie. looking at the issues, im not really sure we need true bundle instances here. Only metadata from bundle introspection. To build things properly.

I truly dont hope we're looking for ways to do this since 2013 😆 as it would definitely require theBootingKernel idea from@ogizanagi..

👍 I checked this with the issues described inFriendsOfSymfony/FOSUserBundle#2376 andFriendsOfSymfony/FOSUserBundle#2378 and I can confirm that this patch fixes them.

Status: Reviewed

@xabbuh great news! Could you tell us on which branches this patch will be applied ?

@Kmelia Once merged, this will be available in the next patch releases of each maintained branch (i.e. from 2.7 to 3.2) and the current development version (3.3).

@chalasr thanks!

@stof I've added a separate commit so it's easier to see what I've changed (can be squashed later). A hierarchy of bundles is now built first, after that the paths are added to the loader. I'm not sure if I could simplify the code, especially the building of the hierarchy.

I could improve the test by asserting the array per namespace if that helps for readability?

I think an easier implementation could be to have two loops. The first would collect path information for bundles we override without actually registering them. The second would then first register the additional paths from child bundles followed by paths the bundle provides itself.

@xabbuh: Isn't that what I'm doing now? First the hierarchy is built and then the paths are registered.

👍

Thank you@wesleylancel.

@fabpot Do you have any hint about the new release (containing this fix) date?

@homersimpsons today :) see#21258