Closed m-vo closed 7 years ago
What you are describing is actually not related to Contao. You're trying to register a Composer package without providing it on packagist.com. There are tons of ways to achieve that, including the one you mentioned. The bundle is not really reusable though as long as you do not put it on packagist.com.
The managed edition allows for the following:
AppBundle\AppBundle
exists (is found by the Composer autoloader), it will be loaded as the last bundle./src
or wherever else, you need to tell Composer to find the classes. Then you can create a class ContaoManagerPlugin
(in global namespace) to register the bundles according to https://docs.contao.org/books/extending-contao4/managed-edition/plugins.htmlTons of ways locally without having to update on every change? I know that what I wrote does not cover registering it on packagist or even making it available in a repo at that point but it allows for a seamless development (before even releasing it). From a short look in the code I assumed that the managed edition only looks at bundles listed in install.json
which would exclude your second point. This seems to be wrong then.
I tried both of your suggestions before. The AppBundle
must be the wrong way to go (as you can only have one & have to rewrite it to make it reusable). The second one did not work for me and lead to my solution from above. But thanks for pointing it out, I'll try it again. Btw.: Why global namespace? I sticked to the contao bundles which do not use a global namespace either.
There can only be one AppBundle
and one ContaoManagerBundle
per application/installation. The ContaoManagerBundle
can register bundles, e.g. if you require Symfony bundles. See the contao/manager-plugin
: https://github.com/contao/manager-plugin/blob/master/src/PluginLoader.php#L123
Also make sure the class is found by registering it in your composer.json
{
"autoload": {
"classmap": [
"app/ContaoManagerPlugin.php"
],
}
}
Allright, I thought you meant the plugin class for contao manager living inside each bundle.
My version only works for contao bundles. But I think I get the point for the single ContaoManagerPlugin
to restore some AppKernel
functionality. So you basically would implement BundlePluginInterface
/ RoutingPluginInterface
/ ... and so on there to config and load the bundles, right?
Yes, except for the ConfigPluginInterface
. You can also do that, but it does not make much sense because the application can also have an app/config/config.yml
that is automatically loaded.
You're also right, if the bundle is reusable and has it's own composer.json, it should also have it's own plugin.
Also check out our custom Contao edition at https://github.com/terminal42/contao-standard/tree/develop, it has config files and a global manager plugin.
It would be awesome if you could write up all of this as a cookbook article? If you're not familiar with GitHub or the docs repo, you could also rewrite the article for the new info and I can copy that to a markdown document 😎
Thanks for the link to your fork, that looks promising. :-)
I'll write a cookbook article about this as soon as I'll find some time (and am a bit more familiar with how it works). No really, I'll be glad to help 😃.
btw.: The cookbook currently looks pretty Contao 3.5 centric (or earlier / outdated). Are there any plans to restructure this to have the relevant bits together? And as there are not that many topics in there right now does it make sense to keep multiple languages? (It's another thing for the Contao Documentation but this is aimed at devs, isn't it?) Momentan sind die Inhalte auf deutscher/englischer Seite ja komplett verschieden, sodass man i.d.R mehrere Sprachen durchsuchen muss, um etwas zu finden. How about creating a new english-only Contao 4 Cookbook, slowly filling that one up (maybe migrating old stuff) and then at one point dropping/archiving the old one (maybe as soon as the 3.5 LTS runs out mid 2019).
The cookbook is supposed to be only in german. The articles can be anything, that's the point about a cookbook, but you're right there is practically nothing about Contao 4 (because unfortunately almost nobody contributes documentation :( ). The german articles are just leftovers and I didn't want to delete them without a replacement.
The cookbook is supposed to be only in german. [...] The german articles are just leftovers
You mean english, right? :-)
I'm sorry, yes I mean english only :D
closing in favor of #463
I don't know if this fits here but I wanted to document it somehow:
Goal: develop a new reusable bundle (that can be used in the managed edition).
If you are in a standard edition project, you can simply develop somewhere, add an autoload section to your
composer.json
and register the bundle in theAppKernel
. If you want to develop inside a managed edition environment, this does not work as the custom kernel scansinstall.json
and only loads the things in there (and the AppBundle, but we don't want an AppBundle).How to get it done? It's simple but took me a while. And therefore I think it would be nice to have it documented somewhere.
Create your package somewhere (inside or outside the project). Then add this to your contao
composer.json
with a path pointing to your new package (absolute or relative to the project root).What this does is to create a symlink to your local development folder instead of downloading it into the vendor folder. Of course also add your bundle as a requirement. It's important to use
dev-master
if the package is not under version control or has no version set in thecomposer.json
as this is the default if no version can be deduced (and therefore it would not meet the default minimum stability).After a
composer update
your bundle will get linked and listed in theinstall.json
and contao will find it. Bonus: You can use this to develop a bundle for multiple projects at the same time without having to runcomposer update
on every change.More about the
path
directive: https://getcomposer.org/doc/05-repositories.md#pathAnd of course: If there is a better way to do it, please share it with me :-)