Contao 4.4.2 Bundle / Tabellen werden von Installertool nicht erkannt

Hallo,
ich versuche aktuell meine eigene Contao Erweiterung zu erstellen, scheitere hier allerdings schon in einem relativ frühen Stadium, da die von mir unter dem Pfad src/ContaoBundle/Resources/contao/dca/tl_cars.php erstellte Tabelle vom Installertool nicht erkannt wird da die Datenbanken laut ihm aktuell sind.
Ich gehe nach folgendem Tutorial vor: https://xuad.net/artikel/contao-4-bu...d-und-frontend
Habe bereits gelesen dass es bei der Version 4.4.1 Probleme mit dem DCA-Picker gab, diese sollten aber doch bei der 4.4.2 gelöst sein?
Hat jemand Tipps, bzw. das gleiche Problem und kann mir weiter helfen?

Benutzt du die Managed Edition oder die Standard Edition? Das von dir verlinkte Tutorial bezieht sich auf die Standard Edition.

Der Berliner Stammtisch hatte gerade vor ein paar Wochen einen Contao Workshop veranstaltet.
Hier die Infos zur Erweiterungen in Contao 4:
https://docs.contao.ninja/de/erweiterung-c3-c4.html

Ich zum Beispiel benutze bei der Bundle-Entwicklung die Standard Edition.
Hast du daran gedacht, das Bundle im app/AppKernel.php zu registrieren, danach den Cache mit

Code:

---

php bin/console cache:clear --env=prod --no-warmup
php bin/console cache:warmup --env=prod

---

zu löschen?

Als Tipp: Ich lösche immer die Cache-Ordner unter var/cache. Dann ist das Backend zwar urmellangsam aber alle Änderungen an den DCAs werden umgehend erkannt.

Bin auf deine Rückmeldung gespannt.

Vielen Dank für eure Kommentare,
mein Cache war geleert, diesen Composer Befehl hatte ich bereits verwendet :)
allerdings hatte ich tatsächlich nicht die Standard Edition (auf die ich jetzt natürlich umgestiegen bin) verwendet, was meine Probleme wahrscheinlich verursacht hat.

Vielen dank für den Workshop, es hakt zwar noch hier und da aber ich glaube ich bin jetzt auf dem richtigen Weg :)

Das heißt, in der Managed-Edition kann ich kein eigenes Modul mehr schreiben? Versuche auch gerade, in der Managed-Edition testweise ein Modul zu erstellen. Gelingt mir nicht. Weder taucht es im BE auf noch werden die Tabellen im Installer erkannt. Kann ich der Managed-Edition irgendwie beibringen, mein Modul (Bundle) zu laden?

Es werden nur die Bundles für Contao erkannt, die auch per composer require installiert wurden, da sie sonst nicht in der Composer installed.json eingetragen sind. Da ich quasi in jedem Projekt ein eigenes Modul packe, kann ich den Manager also vergessen.

Was mache ich dann, wenn ich an einer bestehenden (fremden) 4.4er Managed-Edition mal schnell ein Modul einbauen will? Also eines, dass ich nicht auf Github veröffentlichen will? Die Lösung über die installed.json finde ich echt unglücklich. Oder übersehe ich was? Ja, ich weiß, system/modules wird nach wie vor geladen. Aber das wäre ja wieder ein Rückschritt, oder?

Zitat:

---

Zitat von lomex

Das heißt, in der Managed-Edition kann ich kein eigenes Modul mehr schreiben?

---

Nein, natürlich nicht. Wenn du dir ein Bundle schreibst, dann brauchst du für die Managed Edition ein Contao Manager Plugin. Siehe dazu die Dokumentation: https://docs.contao.org/books/extend...n/plugins.html

Wobei die Dokumentation hier auch noch etwas rudimentär ist. Am besten siehst du dir es von anderen Bundles ab, was man alles machen muss. Siehe zB diesen Pull Request: https://github.com/Craffft/css-style...e/pull/3/files (den conflict mit "contao/core": "*" brauchst du nicht).

Zitat:

---

Zitat von lomex

Da ich quasi in jedem Projekt ein eigenes Modul packe, kann ich den Manager also vergessen.

---

Ich verstehe nicht was du meinst. Warum solltest du den Manager vergessen müssen?

Zitat:

---

Zitat von lomex

Was mache ich dann, wenn ich an einer bestehenden (fremden) 4.4er Managed-Edition mal schnell ein Modul einbauen will? Also eines, dass ich nicht auf Github veröffentlichen will?

---

Ein Bundle kann auf verschiedene Weisen installiert werden, ob das Bundle öffentlich oder nicht ist, ist dabei nicht relevant.

Wenn du ein Bundle nur für eine einzige Installation brauchst, kannst du auch das (in der Managed Edition automatisch geladene) AppBundle verwenden.

Zitat:

---

Zitat von lomex

Die Lösung über die installed.json finde ich echt unglücklich.

---

Was meinst du mit installed.json?

Zitat:

---

Nein, natürlich nicht. Wenn du dir ein Bundle schreibst, dann brauchst du für die Managed Edition ein Contao Manager Plugin. Siehe dazu die Dokumentation: https://docs.contao.org/books/extend...n/plugins.html

---

Ja, habe ich. Reicht aber nicht, weil es nicht erkannt / geladen wird

Zitat:

---

Wobei die Dokumentation hier auch noch etwas rudimentär ist. Am besten siehst du dir es von anderen Bundles ab, was man alles machen muss.

---

Habe ich.

Zitat:

---

Ich verstehe nicht was du meinst. Warum solltest du den Manager vergessen müssen?

---

Weil die Bundles von Contao nicht erkannt werden, die ich per Hand nach vendor packe.

Zitat:

---

Wenn du ein Bundle nur für eine einzige Installation brauchst, kannst du auch das (in der Managed Edition automatisch geladene) AppBundle verwenden.

---

Wie? Das hört sich interessant an. Aber eigentlich will ich ja "nur", dass ein normales Bundle als Contao Modul erkannt wird (unter Angabe von "extra").

Zitat:

---

Was meinst du mit installed.json?

---

Composer legt in vendor/composer eine installed.json an mit allen installierten Composer Paketen. Das Manager-Plugin-Bundle sucht in dieser Datei nach installierten Contao Erweiterungen ("extra" mit ContaoManagerPlugin vorhanden). Also muss ich scheinbar zwingend ein Bundle mit Composer installieren, damit es in der installed.json eingetragen wird. Und das finde ich doof.

Zitat:

---

Zitat von lomex

Weil die Bundles von Contao nicht erkannt werden, die ich per Hand nach vendor packe.

---

In den vendor Ordner gibst du nie etwas selbst, der wird von Composer verwaltet.

Zitat:

---

Zitat von lomex

Wie? Das hört sich interessant an. Aber eigentlich will ich ja "nur", dass ein normales Bundle als Contao Modul erkannt wird (unter Angabe von "extra").

---

Einfach nur im Ordner "src" anlegen, so wie ein normales Symfony bzw. Contao Bundle. So fern du nicht auch zB eigene Routes brauchst (oder andere Interfaces des Contao MAnager Plugins), brauchst du für das AppBundle in der Managed Edition auch kein eigenes Contao Manager Plugin. Falls du doch eigene Routes brauchst, musst du diese mit dem entsprechenden Interface des Contao Manager Plugins laden lassen. Siehe dazu auch die Dokumentation oder auch diese Anleitung: https://community.contao.org/de/show...l=1#post440081

Zitat:

---

Zitat von lomex

Also muss ich scheinbar zwingend ein Bundle mit Composer installieren, damit es in der installed.json eingetragen wird. Und das finde ich doof.

---

Das ist normal. Angenommen du legst dir in app/Resources/contao irgendwo eigene Klassen oder Module ab, dann musst du diese auch über den Autoloader von Composer laden lassen (natürlich kannst du in Contao 4 noch den alten Class Loader von Contao 2 bzw. 3 nehmen, aber der ist deprecated). Benötigst du ein Contao Manager Plugin, musst du auch dieses vom Autoloder laden lassen. Warum du das "doof" findest, weiß ich natürlich nicht ;).

Wir hatten vom Berliner Stammtisch einen Workshop dazu. In der Doku von BugBuster findest Du alles wichtige (auch in Gegenüberstellungen C3 / C4):
https://docs.contao.ninja/de/erweiterung-c3-c4.html

Danke erstmal für die Hinweise.
Das mit dem Autoloader habe ich ja verstanden und will dazu ja auch den Composer Autoloader nutzen.

Habe jetzt in der Standard-Edition ein Modul (unter /src) ans Laufen gebracht. Das gleiche Modul wird in der Managed-Edition jedoch nicht erkannt.
Egal ob mit oder ohne ContaoManagerPlugin. Aber das liegt meines Erachtens daran, dass dieses Plugin nicht in der vendor/composer/installed.json (weil ich ja mein Modul nicht als Composer Paket installiert habe) auftaucht und daher das ContaoManagerPlugin nicht geladen wird. Und das finde ich doof. Das hat nichts mit dem Autoloader zu tun. Aber vielleicht gibt es ja eine Lösung, die ich nicht sehe.

Wie bekomme ich also ein Modul unter /src in der Managed-Edition ans Laufen?

Zitat:

---

Zitat von lomex

Das hat nichts mit dem Autoloader zu tun.

---

Doch (unter Anderem). Das alles hat nichts mit der installed.json zu tun.

Erkläre lieber mal genau, was du in der Managed Edition versucht hast.

In der Managed-Edition im manager-plugin dort im PluginLoader steht:

Zitat:

---

/**
* Finds Contao manager plugins from Composer's installed.json.
*
* @author Andreas Schempp <https://github.com/aschempp>
*/

---

So ganz abwegig scheint mir das nicht zu sein. Mit composer dumpautoload werden die Klassen unter src/ für den Autoloader registriert, tauchen aber nicht in der installed.json auf und werden (meines Erachtens) nicht in der Managed-Edition gefunden.

Was ich versucht habe (in Anlehnung an das von Dir erwähnte Tutorial von Xuad):

/src/Contao4You/TEST/TESTBundle.php
/src/Contao4You/TEST/ContaoManager/Plugin.php
/src/Contao4You/TEST/Resources/contao/dca (etc)

in der /composer.json folgendes angegeben:

Code:

---

"autoload": {
        "psr-4" : { "": "src/" }
    },

---

Danach composer update ausgeführt, das Contao Script hat das Modul (Bundle) nicht erkannt. Der Installer findet die Tabelle nicht.

Wie gesagt, das Modul läuft ja in der Standard-Edition. Hier habe ich nur das ContaoManagerPlugin hinzugefügt.

Das kann jedoch nicht gefunden werden, weil der PluginLoader nach dem "extra" Eintrag in der composer.json sucht, die nur beim Installieren eines Composer Paketes in die installed.json eingetragen wird.

Code:

---

foreach ($json as $package) {
            if (isset($package['extra']['contao-manager-plugin'])) {
                if (!class_exists($package['extra']['contao-manager-plugin'])) {
                    throw new \RuntimeException(
                        sprintf('Contao Manager Plugin "%s" was not found.', $package['extra']['contao-manager-plugin'])
                    );
                }

                $plugins[$package['name']] = new $package['extra']['contao-manager-plugin']();
            }
        }

---

Also nochmal:
Ich habe ein funktionierendes Bundle in der Standard-Edition. Was muss ich tun, damit es auch in der Managed-Edition läuft? Mir reicht ja, wenn jemand sagt, dass das nicht geht. Dann brauche ich es nicht weiter versuchen.

installed.jons? Noch nie was von gehört und noch nie gebraucht.

Vielleicht hilft dir das:
https://docs.contao.ninja/de/vortrag...undle.html#/13
und der composer.json Anteil deiner Erweiterung:
https://docs.contao.ninja/de/vortrag...dle.html#/13/2

Nein. Hilft leider nicht. Weil ich ja das Paket nicht per composer installieren, sondern manuell unter src/ bereitstellen will.

Das Manager Plugin wird aber nur tätig durch den Aufruf composer update/install. Eventuell gibt es noch einen contao-console Aufruf der das auch kann.

Manuell habe ich noch nie was direkt in die Installation gepackt. Ich vermute mal das das nur in der Standard Edition geht.
Ich installiere in so einem Fall eben direkt von Platte statt GitHub/Packagist.

Siehe die Dokumentation: https://docs.contao.org/books/extend...manager-plugin

Für lokale Bundles solltest du es genau so machen, wie es dort steht: eine app/ContaoManagerPlugin.php anlegen und autoloaden lassen. Dein src/Contao4You/TEST/ContaoManager/Plugin.php verschiebst du also nach app/ContaoManagerPlugin.php und schreibst den Inhalt entsprechend um. In diesem Contao Manager Plugin verwaltest du dann das Laden der Bundles in der Managed Edition für all deine lokalen Bundles und sonstigen Symfony (also nicht Contao) Bundles.

composer install ist bei lokalen Bundles nicht notwendig - bzw. nur in sofern notwendig, weil composer install auch ein dump-autoload macht. Es schadet generell aber nicht einfach ein

Code:

---

composer install --optimize-autoloader

---

zu machen, da dadurch auch ein cache:clear und cache:warmup ausgeführt wird, als auch eben ein Autoloader Dump (in diesem Falle für Performance optimiert).

Es wird mir hier gerade zu viel geraten. Mir würde es helfen, wenn jemand es schon so gemacht hätte...

@BugBuster
Das ist richtig, durch composer update wird ein contao script ausgeführt. Hier sieht man dann auch, ob das Modul (Bundle) als Contao Modul erkannt wurde.
Normalerweise würde ja ein composer dumpautoload reichen, nur hier eben nicht.

@Spooky
Der Autoloader lädt Klassen bei Bedarf. Das hat nichts mit der Erkennung des Manager-Plugins zu tun, der nach Contao-Modulen sucht. Wir drehen uns gerade im Kreis. Hast Du schonmal ein eigenes Modul unter src/ in der Managed-Edition installiert?

Zitat:

---

Zitat von lomex

Es wird mir hier gerade zu viel geraten. Mir würde es helfen, wenn jemand es schon so gemacht hätte...

---

Habe ich schon viele male ;).

Zitat:

---

Zitat von lomex

Der Autoloader lädt Klassen bei Bedarf.

---

composer dump-autoload erzeugt den Inhalt von vendor/composer/autoload_….php (und vendor/autoload.php). Dort werden die einzelnen PHP Dateien, die in der composer.json (deiner Installation und aller Pakete) im "autoload" Bereich angegeben wurden, im Autoloader registriert. Der Autoloader lädt dann diese Klassen nach Bedarf. Der Autoloader kann keine Klassen laden, die er nicht kennt.

Zitat:

---

Zitat von lomex

Das hat nichts mit der Erkennung des Manager-Plugins zu tun

---

In so fern schon, denn wenn das ContaoManagerPlugin nicht im Autoloader registriert ist, kann es Contao auch nicht finden.

Zitat:

---

Zitat von lomex

Wir drehen uns gerade im Kreis. Hast Du schonmal ein eigenes Modul unter src/ in der Managed-Edition installiert?

---

Ja, so wie beschrieben schon viele male. Siehe auch das Beispiel, dass ich schon mal verlinkt habe. Darüberhinaus habe ich dir ja schon hier gesagt, was du an deinem aktuellen Setup ändern musst.

Ich danke Dir für deine Geduld. Aber egal, was ich versuche, es passiert nichts.

Habe jetzt testweise mal /app das ContaoManagerPlugin.php gepackt. Jedoch wird das nie geladen laut xdebug.
Kann also reinschreiben was ich will... Selbst wenn meine Autoloader Konfiguration falsch wäre, müsste ja dann zumindest eine Exception kommen, dass die Klasse nicht gefunden würde.

PHP-Code:

---

<?php

namespace Contao4You\TEST;

use Contao\CoreBundle\ContaoCoreBundle;
use Contao\ManagerPlugin\Bundle\BundlePluginInterface;
use Contao\ManagerPlugin\Bundle\Parser\ParserInterface;
use Contao\ManagerPlugin\Bundle\Config\BundleConfig;

class Plugin implements BundlePluginInterface
{
    /**
     * {@inheritdoc}
     */
    public function getBundles(ParserInterface $parser)
    {
        return [
            BundleConfig::create(TESTBundle::class)
                ->setLoadAfter([ContaoCoreBundle::class])
                ->setReplace(['TEST']),
        ];
    }
}

---

Wenn ich alles in /src/AppBundle packe wird das Bundle auch nicht von Contao erkannt. Composer update bzw. dumpautoload natürlich erneut ausgeführt. Composer.json habe ich ebenfalls angepasst mit Classloader app/ContaoManagerPlugin (etc).
Nebenbei gefällt mir das mit AppBundle auch nicht. Würde lieber meinen eigenen Namen, also /src/Contao4You/TEST/TESTBundle.php nutzen. Aber ich bekomme es ja schon mit AppBundle nicht hin.

Das Contao Manager Plugin unter app/ContaoManagerPlugin.php muss bei dir folgendermaßen aussehen:

PHP-Code:

---

<?php

use Contao4You\TEST\TESTBundle;
use Contao\CoreBundle\ContaoCoreBundle;
use Contao\ManagerPlugin\Bundle\BundlePluginInterface;
use Contao\ManagerPlugin\Bundle\Parser\ParserInterface;
use Contao\ManagerPlugin\Bundle\Config\BundleConfig; 

class ContaoManagerPlugin implements BundlePluginInterface
{
    /**
     * {@inheritdoc}
     */
    public function getBundles(ParserInterface $parser)
    {
        return [
            BundleConfig::create(TESTBundle::class)
                ->setLoadAfter([ContaoCoreBundle::class])
        ];
    }
}

---

Deine Bundle Ordner Struktur entspricht außerdem nicht ganz der Konvention von Symfony. Statt

src/Contao4You/TEST/TESTBundle.php

solltest du vielleicht eher

src/Contao4You/TestBundle/Contao4YouTestBundle.php

verwenden, spielt aber grundsätzlich eine untergeordnete Rolle.

Habe jetzt einen Teilerfolg:

Habe den ContaoManagerPlugin unter src/Contao4You/TEST/ContaoManagerPlugin.php gespeichert sowie in der Composer.json die Classmap entsprechend angepasst.

1. durch die Classmap findet der PluginLoader die globale ContaoManagerPlugin Klasse
2. WICHTIG: (mein Fehler): kein Namespace für das Plugin. Und die Klasse muss auch genauso heißen (hieß bei mir noch Plugin, was in der Std.-Edition auch geht)
3. Vermutlich ist es besser, das Plugin tatsächlich unter /app zu packen, dann können dort weitere Bundles registriert werden. Wollte nur sehen, ob es so auch klappt.

In dieser Klasse registrieren wir jetzt unser Bundle. Läuft. Wird jetzt mit composer update und im BE auch angezeigt.
Nur das Install-Tool will die Tabellen noch nicht aktualisieren.

Zitat:

---

Zitat von lomex

Selbst wenn meine Autoloader Konfiguration falsch wäre, müsste ja dann zumindest eine Exception kommen, dass die Klasse nicht gefunden würde.

---

Nein, siehe https://github.com/contao/manager-pl....php#L160-L164

PHP-Code:

---

// Instantiate a global plugin to load AppBundle or other customizations
$appPlugin = '\ContaoManagerPlugin';
if (class_exists($appPlugin)) {
    $this->plugins['app'] = new $appPlugin();
} 


---

Das Contao Manager Plugin (für lokale Bundles) wird nur benutzt, wenn es tatsächlich existiert.

Das habe ich auch gerade gesehen und meine Konfiguration entsprechend angepasst.
Jetzt weiß ich auch, wofür die Classmap gut ist...

Das Problem mit dem Datenbank Update ist auch gelöst. Hatte beim Suchen/Ersetzen einen Tippfehler. Statt tl_test stand da t_test.

Moin,

ich muss mich jetzt hier mal einklinken, da mein Problem eigentlich genau dasselbe ist! Ich programmiere schon viele Jahre mit Contao und auch seit 2 Jahren mit Symfony. Trotzdem bekomme ich es nicht gebacken eine lokale Extension in der Managed Edition anzumelden. Ich habe versucht es anhand dieses Threads und unzähliger Tutorials nachzubauen, aber es läuft einfach nicht.

Meine Ordner-Struktur sieht so aus (ohne den Standard-Kram):

Code:

---

- app
-- ContaoManagerPlugin.php
- src
-- vendorName
--- TestBundle
---- vendorNameTestBundle.php
---- Resources
----- config
------ config.php
----- dca
------ tl_irgendwas.php
----- ...

---

Die /composer.json habe ich wie in der Anleitung um folgendes ergänzt:

Code:

---

"autoload": {
        "classmap": [
            "app/ContaoManagerPlugin.php"
        ],
        "psr-4": {
            "vendorName\\TestBundle\\": "src/vendorName/TestBundle/"
        }
    },

---

In der app/ContaoManagerPlugin.php steht Folgendes:

PHP-Code:

---

use vendorName\TestBundle\vendorNameTestBundle;
use Contao\CoreBundle\ContaoCoreBundle;
use Contao\ManagerPlugin\Bundle\BundlePluginInterface;
use Contao\ManagerPlugin\Bundle\Parser\ParserInterface;
use Contao\ManagerPlugin\Bundle\Config\BundleConfig;

class ContaoManagerPlugin implements BundlePluginInterface
{
    /**
     * {@inheritdoc}
     */
    public function getBundles(ParserInterface $parser)
    {
        return [
            BundleConfig::create(vendorNameTestBundle::class)
                ->setLoadAfter([ContaoCoreBundle::class])
        ];
    }
} 


---

Das wird aber alles nicht erkannt und wenn ich im Manager "Pakete aktualisieren" nutze, zerschießt es mir das ganze System.
Leider steht mir kein SSH zur Verfügung. :(

Nun meine Frage: Wie muss die Ordner- bzw. Dateistruktur grundlegend aussehen?
@lomex: Wenn ich es richtig sehe, hast du es inzwischen zum Laufen gebracht?! Wie sehen deine Dateien bzw. Dateistruktur aus?


Vielen Dank für eure Hilfe und einen schönen Sonntag!

Zitat:

---

Zitat von raveolution

Meine Ordner-Struktur sieht so aus (ohne den Standard-Kram):

Code:

---

- app
-- ContaoManagerPlugin.php
- src
-- vendorName
--- TestBundle
---- vendorNameTestBundle.php
---- Resources
----- config
------ config.php
----- dca
------ tl_irgendwas.php
----- ...

---

---

Du musst die Contao Konfiguration in den Unterorder contao im Ordner Resources geben. Also …/TestBundle/Resources/contao/….

Außerdem sollte dein Vendor Name mit einem Großbuchstaben beginnen ;). Sonst scheint alles zu stimmen.

Zitat:

---

Zitat von raveolution

Das wird aber alles nicht erkannt und wenn ich im Manager "Pakete aktualisieren" nutze, zerschießt es mir das ganze System.

---

Was genau passiert? Welchen PHP Pfad hast du im Contao Manager eingetragen? Welcher Hoster?

Zitat:

---

Zitat von Spooky

Du musst die Contao Konfiguration in den Unterorder contao im Ordner Resources geben. Also …/TestBundle/Resources/contao/….

Außerdem sollte dein Vendor Name mit einem Großbuchstaben beginnen ;). Sonst scheint alles zu stimmen.

---

Wow, vielen Dank für die schnelle Antwort!
Tatsächlich hatte ich sogar den Unterordner "contao". Ich hatte ihn nur in meiner Auflistung hier übersehen. Und mein Vendor beginnt im System auch mit einem Großbuchstaben. ;)

Ich habe jetzt noch einmal eine komplett neue Installation mit Contao 4 Managed Edition aufgesetzt und habe genau die o.g. Struktur beibehalten. Und siehe da: nun geht es!

Ich glaube auch zu wissen, wo mein Fehler vorher war: Ich hatte ursprünglich unter src/VendorName/TestBundle/ noch einen Ordner "ContaoManager" mit der Datei "Plugin.php", sowie den Eintrag "contao-manager-plugin: ..." in der composer.json aus einem anderen Tutorial. Diese habe ich jetzt nicht mehr drin.

Vielleicht sollte man dieses Vorgehen für lokale Bundles mit der Managed Edition noch einmal explizit irgendwo dokumentieren! Für die Standard-Edition und für eigene öffentliche Bundles (in Standard und Managed) ist das ja schon gut dokumentiert. Aber ohne diesen Thread hätte selbst ich - als erfahrener Entwickler - das niemals hinbekommen.


Also, wirklich ein großes Danke für eure schnelle Hilfe und einen schönen Rest-Sonntag.

Ja, meine Erkenntnisse habe ich auch hauptsächlich aus dem Studium des Codes, nicht von der Dokumentation selbst.

Nachdem ich erfolgreich in der Standard-Edition ein Modul geschrieben habe, habe ich mich Heute an der Managed-Edition versucht, da es die Standard-Edition ja wohl bald nicht mehr geben wird.
Mein erstes Problem war, das Bundle in Contao überhaupt bekannt zu machen.

Alle Beispiele beziehen sich immer auf Github/Packagist etc. Ich will aber ein lokales Modul entwickeln.
Daher bin ich über folgende Stolperfallen gestoßen:

In den ganzen Beispielen zum ContaoManagerPlugin befindet sich diese Klasse immer in einem Namespace. Das ist im Falle einer Installation über composer install auch nicht dramatisch. Hier wird der Pfad zum ContaoManagerPlugin auch über die composer.json und der "extra":"contao-manager-plugin" Option mitgegeben. Bei einem lokalen Modul funktioniert das aber nicht. Hier muss die Klasse zwingend ContaoManagerPlugin heißen und nicht z.B. Plugin im Ordner ContaoManager. Dann wird durch ein composer install auch das Bundle gefunden und eingebunden.

Hintergrund ist, dass das manager-plugin nur nach einer globalen ContaoManagerPlugin Klasse sucht. Diese muss in der globalen composer.json per Classmap bekannt gemacht werden.

Code:

---

"autoload": {
        "classmap": [
            "src/Acme/Foo/ContaoManagerPlugin.php"
        ],

---

Aber wie gehe ich denn vor, wenn ich eine Erweiterung schreiben möchte, die ich auch auf Packagist veröffentlichen möchte? Wo läuft die denn während der Entwicklung? In src? In vendor werden ja nur Pakete per composer installiert, oder?

Unabhängig von der vorherigen Frage:
Spätestens wenn ich zwei eigene, von einander unabhängige Module in jeweils eigene Bundles packen möchte, komme ich mit einer globalen ContaoManagerPlugin Klasse nicht aus, oder? Oder anders gefragt, wie kann ich sagen wir mal zwei alte Module für Contao 4 Managed Edition anpassen und in zwei Bundlen veröffentlichen ohne composer install?

Sieh's dir einfach in anderen Bundles an. zB:

• https://github.com/Craffft/css-style...poser.json#L37
• https://github.com/Craffft/css-style...in.php#L28-L35

Was genau soll ich da sehen? Wie ich ein Bundle über Composer installiere und das ich dann das Plugin über extra definieren muss, weiß ich und hatte ich ja auch geschrieben.

Hm, dann habe ich deine Frage nicht genau verstanden.

Genau genommen hatte ich zwei Fragen :-) Aber es geht mir erstmal um diese hier:

Ich habe einige eigene Erweiterungen. Sie liegen alle nicht bei Github / Packagist. Zwei davon möchte ich nun unter /src ans Laufen bringen. Aber jede Erweiterung in einem eigenen Bundle. Wie? Da es ja nur eine globale ContaoManagerPlugin Klasse gibt, weiß ich nicht, wie ich das bewerkstelligen soll.

Daher kam mir die Idee, dies über ein lokales Repository zu lösen und beide Erweiterungen über Composer zu installieren. Aber das erscheint mir doch ein zu großer Aufwand.

Zitat:

---

Zitat von lomex

Da es ja nur eine globale ContaoManagerPlugin Klasse gibt, weiß ich nicht, wie ich das bewerkstelligen soll.

---

Im Contao Manager Plugin kannst du ja beliebig viele Bundles laden. zB:

PHP-Code:

---

class ContaoManagerPlugin implements BundlePluginInterface
{
    /**
     * {@inheritdoc}
     */
    public function getBundles(ParserInterface $parser)
    {
        return [
            BundleConfig::create(Bundle1::class)->setLoadAfter([ContaoCoreBundle::class]),
            BundleConfig::create(Bundle2::class)->setLoadAfter([ContaoCoreBundle::class]),
            BundleConfig::create(Bundle2::class)->setLoadAfter([ContaoCoreBundle::class]),
        ];
    }
} 


---

*Kopfschüttel*
Danke. Das wars. Sehr gut!

Jetzt verrate mir doch mal bitte Deinen Workflow, wenn Du ein Plugin für Composer programmierst.
Habe gelesen, dass es teilweise so gemacht wird:
1. leeres Projekt auf Packagist anlegen
2. per composer install installieren
3. Ordner unter /vendor löschen und
4. per Symlink mit seinem lokalen Sources verlinken
5. Am Ende Ordner unter /vendor wieder löschen und per
6. composer update wieder installieren

Gibt es noch andere Workflows?

Was genau meinst du mit "Composer Plugin"? Ein tatsächliches Composer Plugin?

Was ist ein tatsächliches Composer Plugin?

Ich meine eine typische Anwendung, die man sich per composer install installiert.
Also ein Symfony Bundle, eine Bibliothek, eine Funktion etc.

Zitat:

---

Zitat von lomex

Was ist ein tatsächliches Composer Plugin?

---

Siehe mein Link ;)

Zitat:

---

Zitat von lomex

Ich meine eine typische Anwendung, die man sich per composer install installiert.
Also ein Symfony Bundle, eine Bibliothek, eine Funktion etc.

---

Also kein Composer Plugin, sondern einfach (irgend)ein Package.

Sobald du eine composer.json angelegt hast, könntest du das Paket als lokales Repository in deine Installation einbinden, wie zB hier beschrieben: https://community.contao.org/de/show...l=1#post422990 ("For vendor bundles"). Dieser Weg funktioniert allerdings nicht uneingeschränkt, siehe https://github.com/contao/core-bundle/issues/1114 (im Issue Titel steht zwar Windows, vermutlich ist das aber ein generelles Problem).

Eine andere Möglichkeit wäre, dass du dein Repository zuerst mit einer composer.json initialisiert (inkl. allen Requirements die du brauchst), in ein Repository gibst, und dann dieses Repository in deiner Contao Installation mit

Code:

---

composer require your/package --prefer-source

---

requirest und dann direkt im vendor/your/package Ordner programmierst. Durch --prefer-source macht composer ein git clone und du kannst dann von dort direkt deine Änderungen in dein Repository zurück comitten.

Vielen Dank. Werde mir beide Varianten mal anschauen. Das ist genau das, was ich gesucht habe

guten Morgen!

sorry, dass ich dieses Thema nochmal aufwärme, aber ich stehe momentan leider auf dem Schlauch was die Managed Edition betrifft.
Ich habe prinzipiell das gleiche Problem wie lomex, möchte also ein "lokales" Bundle in der Managed Edition entwickeln. Ich hab mich am Projekt bugbuster/contao-xing-bundle orientiert.

Ich hab es schon geschafft, dass mein Bundle in vendor/myname/bundlename erscheint nach composer require myname/bundlename --prefer-source (hab mir sogar einen lokalen git Server installiert). Leider schaffe ich es nicht, dass meine Klassen in die vendor/composer/autoload_... Dateien aufgenommen werden nach composer dump-autoload. Lediglich in der installed.json bin ich vertreten. Witzigerweise habe ich versehentlich ein composer dumpautoload ausgeführt, als ich in vendor/myname/bundlename stand, dort waren dann die autoload_...php's mit meinen Klassen gefüllt.

Ich vermute, dass das etwas mit dem Manager-Plugin zu tun hat. Vielleicht kann mir den nochmal einer erklären. Die Vorgehensweise wie von Spooky in Beitrag #43 vorgeschlagen hört sich vielversprechend an. Welche Schritte sind da notwendig, nachdem ich etwas an der Programmierung geändert haben (composer dump-autoload, Cache löschen, etc.)

Danke schon mal für die Hilfe

Die Frage ist: was genau möchtest du machen? Setzt du das Bundle in mehreren Installationen ein?

Wenn nicht: dann das Bundle einfach im src/ Ordner der Contao Installation programmieren. Wenn ja stellt sich weiter die Frage, wie du das Bundle dann in mehrere Installationen bringst. packagist.org? packagist.com? Direkt via VCS?

Hallo Spooky,

mehrere Installationen! Wie gesagt ich hab einen eigenen git! und das Bundle ist ja da schon im vendor.

Mein primäres Problem ist denke ich nicht git oder packagist, sondern die Erkennung des Bundles in Contao!

Ist das Paket öffentlich? Ohne Code kann ich dir nicht helfen.

nein, kein öffentliches Paket!

gibt's logdateien was beim dumpautoload passiert/fehlschlägt?

Deine Klassen stehen in den autoload_ Dateien nicht unbedingt drin - außer du verwendest die Option --optimize-autoloader.

Ohne deinen Code zu sehen kann ich dir aber nicht sagen, was dein eigentliches Problem ist.

Damit der autoload alles kennt rufe ich immer wieder php7 composer.phar update --optimize-autoloader auf.
Sogar dann wenn nur ein neues Feld in der DCA erstellt wird. Sogar das wird leider nicht automatisch 'geladen'.

Tipp: https://gist.github.com/joergmoldenh...dbc2d039095142
Mein DANK an den Ersteller dieses gist!

Evtl. wird auch classmap in der Bundle composer.json benötigt?
https://community.contao.org/de/show...-nicht-geladen

HTML-Code:

---

"autoload": {
        "psr-4": {
            "namespace\\Bundle\\": "src/"
        },
        "classmap": [
                "src/Resources/contao"
        ],
        "exclude-from-classmap": [
                "src/Resources/contao/config",
                "src/Resources/contao/dca",
                "src/Resources/contao/languages"
        ]
    },

---

Was Du machst, führt zum Erfolg, weil nach dem composer update auch noch der Cache gelöscht wird. Das Löschen des Cache alleine sollte für Deinen Fall der DCA-Änderungen aber genügen!