Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
today i tested the possibity to mirate some of our symfony2 bundles to a drupal8 module. i noticed that i can simply copy all of our bundles in the module folder and we are done. i only needed to patch a few lines in the drupal booting:
registerModuleNamespaces
registerBundles
currently we have only:
<module>/lib/Drupal/<module>/<module>Bundle.php
the symfony2 way:
<module>/src/SomeSubNamespace/Folder/xxxBundle.php
<module>/src/Folder/xxxBundle.php
by the way, autoloading "bundleless" files will work also:
<module>/src/Stuff/MyNiceClass.php
so now we have a registered bundle and from here we can do some more magic stuff...
i can optimize the code and provide a diff, if there is any interesting person.
Comment | File | Size | Author |
---|---|---|---|
#1 | 0001-every-module-can-provide-a-src-folder-for-recursive-.patch | 9.16 KB | Haehnchen |
Comments
Comment #1
Haehnchen CreditAttribution: Haehnchen commentedso here is the patch with some additional test cases.
Comment #2
dawehnerhey i'm hungry now ;( Kudos for writing tests!
Let's first discuss how we actually want it to behave and then fix the code-style-issues etc.
It seems to make sense for me to have a new component in Drupal beside modules/themes/profiles, though a bundle wouldn't fit 100% into the previous 3 examples,
because it will not have an info file. In general it would be nice, to get the two worlds connected even more.
What about adding a new "bundles" folder to make it clear where to put your stuff.
Comment #3
dawehnerAdapting the components.
Comment #5
dawehner#1: 0001-every-module-can-provide-a-src-folder-for-recursive-.patch queued for re-testing.
Comment #6
Haehnchen CreditAttribution: Haehnchen commentedWe can use the SystemListing to search for .info files which should find the themes also, currently this is only done on .profile and .module. by the way we can than provide the lib/Drupal structure also for themes.
i would not rename the src folder to bundle, because in the src folder we have an autoloader fallback. so we can put there any namespaced class which is than known by the classloader. i dont found any discuss about the /lib/Drupal/ namespace structure, but currently i can not see any possibility to reuse or write psr-0 styled code, without the Drupal prefix.
whats about registering the lib folder as autoloader fallback too and provide a bundles folder? or put the bundles into lib? provide a .bundle file?
would it be nice if the .info can also provider some autoloader folders? so any psr-0 lib can simply implemented without changes!
by the way the registerModuleNamespaces() misses an is_dir check, so way search in lib folders which are not there?
pls some decisions; we need more psr-0.
i can then provide some more patches.
Comment #7
dawehnerI thought about using bundles/src instead of modules/src
Maybe people like crell and other people should be first involved in the issue
Comment #8
Crell CreditAttribution: Crell commentedHm. Actually, I don't this is Drupal's job to manage at all. At least not directly.
A well designed bundle is just glue code between a component/library and Symfony. If what you want is that component, just stick that component in Packagist using Composer and then use Drush Composer to pull it in. That will take care of the autoloading.
If you really do want a bundle... the bundle should *also* be in Packagist so the same thing applies. Now there's still the problem of core not supporting 3rd party Composer usage directly, but that's another issue (that should still get solved).
So if all you want is the code, Composer should deal with it for you, end of story.
If you want the Bundle itself "as" a bundle, not just as a bunch of autoloadable code... there are compatibility issues there that I don't think we've resolved. We're not using the Symfony Config component, so I suspect most bundles won't actually run. Sure they could pull in the Config component I suppose, but I have no idea how well that will work given that Drupal makes no attempt to do anything with Symfony config files I question if that would do anything useful.
I'm not sure how (or if) we want to resolve that question.
Comment #9
Eronarn CreditAttribution: Eronarn commentedThe use case I have is a module that wants to pull in a generic Symfony bundle (performance monitoring for HTTPKernel). Here's what I've done to get it to work (and it now works fine in D8):
I think this is a very bad approach even apart from the bundle loading nonsense because modifying core's composer.json should be treated like hacking core. Unfortunately, since module composer.json files aren't part of a package, that's not a solution - they won't be recursively included on a run of core's composer.json. Running them as composer.json files independently is out of the question - there's not even any reason to use Composer if you're going to break dependency management like that.
We need to think ahead and provide at least a basic framework for how a module can require bundles. It's OK if we wait for contrib to do the implementation since it's a rarer use case, but something like Composer Manager won't work in D8 without thought of how it will integrate with core's composer.json. IMO a module featuring a Symfonic bundle needs to be able to do the following without requiring a command line tool or hacking core:
3 is its own issue, so I'll skip it for now. 1 and 2 come together. But, if we want to get 4 and 5 too, I think we want something like this:
Unfortunately, right now this can't be done because Composer's 'archive' repository type assumes that local filesystem packages are .zips in a folder, rather than nested locations within it. But with that (frustratingly minor) upstream change, we could allow modules to have fairly arbitrary composer.json includes with proper dependency handling...
Comment #10
steveoliver CreditAttribution: steveoliver commentedFWIW: In searching "drupal 8 symfony 2 bundle" I found "TraceView’s Oboe Symfony No. 2", a blog post about the performance monitoring bundle mentioned in #9. Thanks, Eronarn. I am still trying to figure out how Symfony2 bundles should/could be integrated with Drupal modules.
Comment #11
aspilicious CreditAttribution: aspilicious commentedThey can't...
Seriously Drupal is build on some Symfony components not the entire symfony suite. We even removed the ModuleBundle file to make it visual that you can't install Symfony Bundles.
Comment #12
Eronarn CreditAttribution: Eronarn commentedIt's already possible to install Symfony bundles, so the only question is how difficult we want to make it. I think it's a bit short-sighted to take a walled garden approach to this question. What's the point of adopting Symfony code into core if we're going to prevent contrib from bringing in more of it without jumping through hoops?
Comment #12.0
Eronarn CreditAttribution: Eronarn commentedcode highlight
Comment #13
andypostSo what is a proposed way to use custom Bundles in contrib modules?
Comment #14
dawehnerI don't will will support this given that Drupal does not use symfony fullstack at all.
Comment #15
Crell CreditAttribution: Crell commentedThe way to do this is to encourage the bundle author to make the code into a stand-alone library and the bundle just a bit of glue-code to attach to Symfony. Then make a Drupal module that depends on the same library using Composer. As a bonus, the code becomes more decoupled from Symfony which just about everyone in Symfonyland views as a good thing.
Since we're not using the Symfony Config component, there's likely very few bundles that would work without heavy modification anyway.
Comment #16
jhedstromLooks like consensus is to not address this, closing for now.