Extension-Entwicklung für Contao 4

[thorff]

Dass Contao 4 aktuell für den produktiven Einsatz noch eher ungeeignet ist und es sich eher an Entwickler richtet, die jetzt schon mal ihre Contao-3-Extensions für Contao 4 anpassen können, wurde im Thread zur Installation von Contao 4 ja schon deutlich.

Ich bin Extension-Entwickler und möchte nun meine Extensions für Contao 4 anpassen, aber dafür fehlen mir meines Erachtens auch noch wichtige Informationen. Es muss doch eine Stelle geben, an der alles steht, was man wissen muss. Aber wo?

Was ich bisher gefunden habe, ist das hier: https://docs.contao.org/books/contao4-migration/. Wenn das Dokument fertig wäre, wäre es genau das, was ich (wie wohl auch jeder andere Extension-Entwickler) brauche. Es ist aber völlig unvollständig und im aktuellen Zustand damit nutzlos. Weiß jemand, bis wann die Fertigstellung dieses Dokuments geplant ist und wie ich mir bis dahin die nötigen Infos beschaffen kann?

Für alle Tipps und Hinweise bin ich extrem dankbar!

[webstar]

Auf der Contao Konferenz gab es einen Workshop von Leo Feyer darüber. Die Folien können weiterhelfen, vor allem ab Folie 35.

https://leofeyer.com/files/slides/2015/workshop/

[thorff]

Auf der Contao Konferenz gab es einen Workshop von Leo Feyer darüber. Die Folien können weiterhelfen, vor allem ab Folie 35.

https://leofeyer.com/files/slides/2015/workshop/

Danke für den Tipp. So besonders weit bringen die Folien einen aber irgendwie auch nicht. :-(

[BugBuster]

Es hilft schon mal die jetzigen Erweiterungen kompatibel zu machen.
Echte Symfony-Contao-Bundles, hat ja Contao 4 noch nicht mal selber :-)

[thorff]

Es hilft schon mal die jetzigen Erweiterungen kompatibel zu machen.

Gibt es dafür eine gute Quelle mit hilfreichen und möglichst vollständigen Informationen? Ich habe mit wirklich großen und komplexen Extensions zu tun und möchte mir sicher sein, dass ich die nicht nur mit Glück kompatibel bekomme, sondern dass ich es wirklich richtig und möglichst zukunftssicher mache.

Mal ein Beispiel für die Probleme, an denen ich zu knabbern habe: Wie sieht das in Contao 4 mit dem Autoloading aus? Ich hätte angenommen, dass das zwangsläufig ein Symfony/Composer-Thema ist. Nicht zuletzt weil ich im Contao-4-Backend keinen Menüpunkt "Autoload Creator" mehr finde. Die in der Contao-Standard-Edition mitgelieferten Contao-Komponenten (z. B. Newsletter) haben noch die autoload.php, was dafür spricht, dass sie noch benötigt wird. Hier fände ich es wichtig, Fakten zu kennen und nicht abschauen, raten und probieren zu müssen.

Echte Symfony-Contao-Bundles, hat ja Contao 4 noch nicht mal selber

Ich hatte angenommen, dass z. B. das in der Contao-Standard-Edition enthaltene newsletter-bundle (und auch faq-bundle, news-bundle etc.) Symfony-Bundles wären. Ist das nicht richtig?

Was mache ich, wenn ich jetzt eine ganz neue Extension entwickeln möchte: Eine Erweiterung im Contao-3-Stil, auch wenn das nicht zukunftsweisend ist, oder ein Symfony-Contao-Bundle? Letzteres ist ja das, was man gerne machen möchte, aber ist dafür die Zeit (und Contao 4) noch nicht reif?

[do_while]

Ich denke mal in docs.contao.org findest Du genau die Antworten dazu:
https://docs.contao.org/books/contao4-migration/

viel mehr gibt es wohl noch nicht

[BugBuster]

Also für Contao 4 schon was entwickeln, dafür ist die Zeit zu früh. Es sei denn du kennst dich mit Symfony aus. In den Folien sind ja links und Seiten vom Framework gezeigt worden, da gibt es ja Best Pratice Anleitungen.

Die Module FAQ, NEWS usw. sind lediglich kompatibel gemacht, das sind keine Symfony Bundles. Soweit ist C4 selber noch nicht.

Autoloader: Das geht alles über composer bzw. composer.json. Solange das aber im Backend noch nicht implementiert ist, warte ich ab und staune später wie das laufen soll.
Auch was die eigenen Entry Points betrifft die in C3 ja möglich waren, in C4 noch etwas unklar, laut Ticket soll das in C4.0 wohl doch irgendwie gehen. (aber deprecated)

[c.romeni]

Verstehe ich das richtig, das in Contao 4, kein einziges Contao 3.x Modul mehr funktionieren wird, und alle kompatibel gemacht werden müssen?
Das wäre echt unerfreulich........

[webstar]

Verstehe ich das richtig, das in Contao 4, kein einziges Contao 3.x Modul mehr funktionieren wird, und alle kompatibel gemacht werden müssen?
Das wäre echt unerfreulich........

Meines Wissens nicht, es gibt dafür ein Wrapper. Hab ich allerdings noch nicht getestet.

https://github.com/contao/core-bundl...duleBundle.php

[BugBuster]

Dazu mus man noch abwarten ob und wie die alten Erweiterungen unterstützt werden, wenn es den Installer bzw. das Paketmanagement gibt.
Ansonsten ist die Anpassung bei kleineren Erweiterungen recht schnell erledigt.

Ich gehe davon aus, das ich jede Erweiterung anpassen muss, meist dann nur was die Pfade betrifft oder der Name der Public Ordner die dann automatisch nach /web/ verlinkt werden.
Auch habe ich einige Erweiterungen die eigene Einstiegspunkte haben (außer index.php und main.php), dass soll in C4 noch gehen, in C5 dann nicht mehr. Hier wäre es sicherlich besser es gleich richtig zu machen.
Aber da mache ich mir kein Stress, dieses Jahr sehe ich da noch nichts auf mich zu kommen, wenn dann eher das machbare austesten.

[BugBuster]

Meines Wissens nicht, es gibt dafür ein Wrapper. Hab ich allerdings noch nicht getestet.

https://github.com/contao/core-bundl...duleBundle.php

Aber auch dafür muss man, Stand heute, eine neue Datei anlegen in der Erweiterung, wenn ich das auf der Konferenz richtig verstanden habe.
In dem Vortrag wurde ja in den Folien angedeutet, was da zu tun sei.

[c.romeni]

Gibt es hierzu eigentlich was neues?
Oder funktionierende Beispiele?

[marcos]

Ich denke mal in docs.contao.org findest Du genau die Antworten dazu:
https://docs.contao.org/books/contao4-migration/

viel mehr gibt es wohl noch nicht

Der Post ist zwar schon ein Jahr alt aber es scheint so, als ob das immer noch so gemacht wird. Also ein Symfony-Bundle mit einem Contao-Ordner unter Resources und in diesem Contao-Ordner die normale, bekannte DCA Struktur. Ist das korrket?

Danke und Gruss
Marco

[BugBuster]

Das wäre der erste Schritt, ja. Resources/contao und Resources/public. Die Bundle Klasse Datei noch anlegen und eintragen in app/AppKernel.php.
Einige Pfade und Namen müssen eventuell noch angepasst werden, wegen der Public Dateien, die werden ja alle "gesymlinkt" ins web/ Verzeichnis und mit dem Bundlenamen (der aus dem Namespace gebildet wird) als Verzeichnis versehen.

Und dann nach und nach alles durch Symfony Dinge ersetzen.

Siehe hier Folie 34 - 37
https://leofeyer.de/files/slides/2015/workshop/#34

Weitere Infos auch hier:
https://slides.ck2016.1up.io/contao-...le-development

In den Contao 4.2 Core Modulen (Newsletter,comments) kann man sich das noch abschauen. Die liegen noch in der ersten Resources Variante vor.
Bei News,Calendar und FAQ, wurde schon etwas symfonysiert. (Dependency Container und Event Listener)

[marcos]

Hi BugBuster

Vielen Dank für Dein Feedback. Die Contao-Bundles habe ich mir angeschaut. Wollte dennoch sichergehen, ob man wirklich immer noch den Contao-Ordner bzw. DCA verwenden muss oder ob das in der Zwischenzeit auch schon symfonysiert wurde

David sagt auf Slide 55 auch, dass das noch nicht vollständig refaktorisiert werden kann. Demnach warten wir weiter ab

[mxbm]

Hallo Contao-Profis,

wenn ich mich mal hier dranhängen darf: Ich bin relativ neu in der Extension/Bundle Entwicklung und habe dazu im Bezug auf Contao 4 einige Fragen.
Zunächst aber erst mal: Macht es zum jetzigen Standpunkt Sinn, eine "richtige" Contao 4 / Bundle / Composer / Symfony (wie man es auch nennen mag) Extension zu entwicklen oder sollte ich den "Kompatibilitätsweg" zunächst gehen, also Contao 3 Extension unter system/modules?

Vielen Dank schon mal im Voraus

[Toflar]

Ich denke ich möchte hier was Wichtiges anfügen. Nur weil es die Core-Bundles nicht machen, heisst es nicht, dass es nicht bereits einen neuen, richtigen Weg gibt!

Wir müssen eine Menge Kompromisse eingehen, um garantieren zu können, dass 99% aller Extensions auch in Contao 4 funktionieren können. Contao 4 wird also eine Ansammlung von Code, der den Weg der 3.5 noch unterstützt, aber bereits die Möglichkeiten einbaut, wie es dann in Contao 5 ausschliesslich möglich sein wird. Vielleicht lässt sich das an einem Beispiel besser erklären:

Irgendwann in der 4er Serie wollen wir eine Möglichkeit bieten, wie Frontend-Module und Inhaltselemente als reguläre Symfony Controller benutzt werden können. D.h. sie geben dann neu nicht mehr einen HTML-String sondern eine Response zurück. Dies wird dann der richtige Weg, Module für Contao 4+ zu programmieren. Alle Module wie Newsliste oder Kalender-Leser etc. werden wir deshalb trotzdem nicht umbauen können, weil es hunderte an Extensions gibt welche diese Module erweitern. D.h. wenn der Core sie einfach auf den neuen Weg umbauen würde, wären alle diese Extensions kaputt.

Deswegen nochmal: Nur weil es das Core Bundle oder die offiziellen Bundles News, Calendar etc. nicht tun, heisst es nicht, dass es nicht bereits einen besseren Weg gibt um zukunftssicher zu programmieren! Für Contao 5 werden alle Bundles dann auf die entsprechend neuen Möglichkeiten umgebaut, so dass eine Kompatibilität mit Contao 3 nicht mehr möglich sein wird.

Der Source Code ist voll von entsprechenden Kommentaren und deprecated Warnings, um euch beim Wechsel zu unterstützen. Schön wäre es auch, wenn sich ein Team für die Doku (https://github.com/contao/docs) finden lassen würde.

[FloB]

Irgendwann in der 4er Serie wollen wir eine Möglichkeit bieten, wie Frontend-Module und Inhaltselemente als reguläre Symfony Controller benutzt werden können. D.h. sie geben dann neu nicht mehr einen HTML-String sondern eine Response zurück. Dies wird dann der richtige Weg, Module für Contao 4+ zu programmieren. Alle Module wie Newsliste oder Kalender-Leser etc. werden wir deshalb trotzdem nicht umbauen können, weil es hunderte an Extensions gibt welche diese Module erweitern. D.h. wenn der Core sie einfach auf den neuen Weg umbauen würde, wären alle diese Extensions kaputt.

Es wäre äußerst hilfreich, wenn die Core-Module schon zum entsprechenden Zeitpunkt in der 4er-Serie im neuen Format vorliegen würden – nicht unbedingt per default, sondern als (äquivalent einsetzbare) Vorschau-Versionen* bzw. extra Pakete (contao/calendar-next-bundle), also die "new style"-Varianten als (so gut es geht) Drop-In-Replacement. Dann können andere Entwickler davon kopi…lernen und von diesen Bundles abhängige Erweiterungen bereits portiert werden. Das wird den Übergang von Contao v4 zu v5 erheblich erleichtern.

* Wäre es nicht möglich beide Varianten in einem Code zu liefern? Stelle mir das so vor, dass es neue Methoden gibt ($mod->getResponse() o.ä.), die von C5 (ggf. C4.x) anstelle der bestehenden generate/compile/whatever-Methoden aufgerufen werden. Entweder "wrappen" diese neuen Methoden die String-Ergebnisse der alten Methoden in einem Response oder (besser) die legacy-Methoden extrahieren den String aus der Repsonse. Dann wären von den Bundles abhängende Erweiterungen nicht sofort tot und der Übergang zu v5 würde nicht zwingend eine komplette Nacht-und-Nebel-Aktion bzw. parallele Pflege von zwei Entwicklungssträngen erfordern.

[Toflar]

Das wäre ein immenser Mehraufwand. Das macht keiner freiwillig.

[FloB]

Also technisch machbar wäre es? Wie viel Mehraufwand wäre es denn? Müsste der Aufwand eh nicht in der einen oder anderen Form getrieben werden, nämlich zur Umstellung auf Contao 5? Es geht ja dann "nur" um den Wrapper von der neuen zur alten Schnittstelle (wie du sagtest wird C4 die neue Schnittstelle auch irgendwann beherrschen).

Wäre es eine gute Idee, das zumindest für eines der Bundles (entweder news oder event) zu machen, sodass man sich darauf einstellen kann? Dann könnten Community-Mitglieder vielleicht auch andere Core-Bundles entsprechend umbauen. Ganz ohne "Führung" in der Hinsicht ist es leider schwer vorherzusehen, wie die Core-Entwicklungsgruppe das konkret umsetzen möchte. Es fehlt ja wie gesagt schon an der Doku – wenn es wenigstens einen Referenz-Code gäbe, könnte man sich an diesem entlang hangeln.

[kalterwind]

Der Beitrag ist schon fast ein Jahr alt.
Gibt es mittlerweile eine Anleitung speziell auf Contao bezogen um Erweiterungen für Contao 4 zu entwicklen...?

Würde gerne meine alten Erweiterungen anpassen.
Unter https://docs.contao.org/books/cookbo...ntwickeln.html wird leider nur Allgemein auf das Symfony Handbuch verweisen, was mir nicht sooo weiter hilft. Ein "entlang hangeln" wäre schon gut... .

[BugBuster]

Falls du bereits für Contao 3 Erweiterungen erstellt hast die schon mit Composer installierbar waren, gibt es hier die Folien vom Workshop wie man die zu einem Contao Bundle wandelt und diese Contao Manager kompatibel macht.
https://docs.contao.ninja/de/erweiterung-c3-c4.html

[kalterwind]

Danke, hilft mir leider nicht so ganz, ich habe alle Erweiterungen nur direkt für mich und Kunden erstellt, wurden immer nur manuell installierbar. Denke da wäre eine "richtige" Anleitung sinnvoller um auch eventuelle bisherige "Fehler" zu vermeiden.

[BugBuster]

Solche Grundlagen wie "Composerisierung" einer Erweiterung wirst du in aktuellen Anleitungen kaum finden. Das sind mittlerweile Grundlagen.
Ebenso das Zusammenspiel Erweiterung-Composer-GitHub-Packagist.org. Ein wenig gehe ich dabei auch ein in den Folien.

Dazu sollte man aber hier oder allgemein über Suchmaschinen was finden, auch speziell für Contao.

Oder einfach von kleinen Erweiterungen abschauen wie es geht im Vergleich mit Handbuch (Composer).

[markocupic]

@windblick
Ich habe in einer README.md in einer Erweiterung auf meinem github Repository beschrieben, wie man eine Erweiterung unter contao/managed-edition lokal im ROOT-Verzeichnis unter src/ installiert. Mit "lokal" meine ich ohne ein Repository wie github oder packagist zu nutzen.
Dabei habe ich auch Hilfe im Forum beansprucht.
Github:
https://github.com/markocupic/calend...booking-bundle

Beitrag im Forum:
https://community.contao.org/de/show...haupt-möglich

Ich hoffe, das hilft dir weiter.

Liebe Grüsse

Marko

[webdecker]

Hallo zusammen,

falls hier noch jemand lauscht... Habe es endlich geschafft, eine Managed Edition (4.4.15) zum Laufen zu bekommen...

Nach diversen Quellen soll es möglich sein, (eigene) Contao-3-Extensions manuell per "copy and paste" ins Verzeichnis system/modules zu kopieren, Cache löschen, contao/install, DB aktualisieren, fertig.

Mir ist aber auch nach einiger Googlei und dem PDF von markocupic immer noch nicht klar, welche Voraussetzungen eine 3er-Extension wirklich mitbringen muss, damit das so geht.
Schließlich habe ich in diversen Projekten kundenindividuelle Extensions gebaut, die nicht öffentlich sind und nichts mit Composer / packagist etc. zu tun haben.
Schön wäre, die erstmal überhaupt in einer Contao 4-Installation zum Laufen zu bekommen, Contao-Vierisierung später. Meine Extensions haben kein src-Vereichnis, sondern die klassische Struktur:

extensionname/assets
extensionname/classes
...
extensionname/templates

Konkret: Habe in meiner C4-Installation eine kleine Test-Extension manuell eingetaktet. DB-Erweiterung ist durch, ich kann meine eigenen CEs im Backend anlegen.
Aber im Frontend ist davon nichts zu sehen, sie werden nicht gerendert, unter var/logs/prod...log ist nichts zu finden.
Hat vielleicht jemand Ideen?

Besten Dank im voraus!

[markocupic]

@webdecker
Den autoloader hast du auch neu aufgebaut?
Lg marko

Hallo zusammen,

falls hier noch jemand lauscht... Habe es endlich geschafft, eine Managed Edition (4.4.15) zum Laufen zu bekommen...

Nach diversen Quellen soll es möglich sein, (eigene) Contao-3-Extensions manuell per "copy and paste" ins Verzeichnis system/modules zu kopieren, Cache löschen, contao/install, DB aktualisieren, fertig.

Mir ist aber auch nach einiger Googlei und dem PDF von markocupic immer noch nicht klar, welche Voraussetzungen eine 3er-Extension wirklich mitbringen muss, damit das so geht.
Schließlich habe ich in diversen Projekten kundenindividuelle Extensions gebaut, die nicht öffentlich sind und nichts mit Composer / packagist etc. zu tun haben.
Schön wäre, die erstmal überhaupt in einer Contao 4-Installation zum Laufen zu bekommen, Contao-Vierisierung später. Meine Extensions haben kein src-Vereichnis, sondern die klassische Struktur:

extensionname/assets
extensionname/classes
...
extensionname/templates

Konkret: Habe in meiner C4-Installation eine kleine Test-Extension manuell eingetaktet. DB-Erweiterung ist durch, ich kann meine eigenen CEs im Backend anlegen.
Aber im Frontend ist davon nichts zu sehen, sie werden nicht gerendert, unter var/logs/prod...log ist nichts zu finden.
Hat vielleicht jemand Ideen?

Besten Dank im voraus!

[webdecker]

@markocupic: Nein, habe ich nicht und weiß leider auch gar nicht, was gemeint ist...
Sorry, ich nutze Contao diverse Jahre (ja, ggf. etwas oldschool-like, ohne Composer, war ja nicht zwingend nötig...) - und stehe nun da wie ein Anfänger...

[markocupic]

@webdecker
Im neusten contao manager gibt es, glaube ich, die Funktion.
Mit composer wäre es der
composer dump-autoload
Befehl.

@markocupic: Nein, habe ich nicht und weiß leider auch gar nicht, was gemeint ist...
Sorry, ich nutze Contao diverse Jahre (ja, ggf. etwas oldschool-like, ohne Composer, war ja nicht zwingend nötig...) - und stehe nun da wie ein Anfänger...

[stefan-at-work]

zur Info: auf der Contao Konferenz 2018 wird es zu diesem Thema eine Session von geben

[webdecker]

Habe dump-autoload via Composer und via Manager durchgeführt, Cache geleert, die Dateien unter vendor/composer werden neu erstellt. Aber weiterhin: dca und Co werden für's Backend zum Anlegen gefunden, aber die Klassen nicht.
Habe wie gesagt die Contao-mit-Composer-Entwicklung verschlafen: vermutlich ist meine Test-Extension nicht reif fürs neue Autoloading...
Braucht sie (zwingend) eine composer.json?
Muss in der autoload.ini mehr stehen als requires[] = "core" (requires[] = "*_autoload" ?) und die register_...-Attribute?
Wird die autoload.php eigentlich noch aufgerufen?
Klassen sind ohne Namespace, liegen unter classes, elements, etc. - nicht unter src oder library o.ä. - ist das Voraussetzung?

Für Hinweis wäre ich dankbar. Viel Googelei hat viel halbes und widersprüchliches und für mich wenig eindeutiges und effektives zu Tage gefödert...

[BugBuster]

Die Fehlermeldung wäre mal interessant wenn Contao eine Klasse bei dir nicht findet.

[webdecker]

Es gab ja nirgendwo Fehlermeldungen. Aber jetzt hab ich's endlich, hurra! In die CONTAOROOT/composer.json muss folgender Abschnitt rein:

    "autoload": {
        "classmap": [
            "system/modules/x_test/classes", "system/modules/x_test/elements"
        ]
    }

Bei Contao 4.5.6 ging auch dies (bei Contao 4.4.15 nicht):

    "autoload": {
        "extra": {
            "contao": {
                "sources": {
                    "x_test": "system/modules/x_test"
                }
            }
        }
    }