contao-community-alliance/composer-plugin

[Franko]

Hallo,
ich habe eine Verständnisfrage hinsichtlich der Typen "contao-module" bzw. "contao-bundle". Je mehr ich lese desto verwirrter werde ich (als Nicht Entwickler).
Daher: Hintergrund ist die Installation eines Frontend Theme Package (als library) - nur Contao 4.x.

Ich teste momentan über ein lokales Repository und setze hier als Typ "contao-module" und require das "contao-community-alliance/composer-plugin" in der Version ">=3".
Das plugin kümmert sich um das autoloading und über Einträge ala

"extra": {
        "contao": {
            "sources": {

werden dann meine Dateien entsprechend z.B in den "template" Ordner oder z.B. nach "files/themes/demo-theme" kopiert. Also analog zur https://github.com/contao/official-demo - Soweit schön.

Jetzt verstehe ich es so, das das Contao composer-plugin (ist ja selbst ein Composer Custom Installer vom Typ "composer-plugin") so ne Art Zwischenlösung darstellt. Wenn man nur Contao 4er berücksichtigen will sollte man langfristig dann "echte" Bundles vom Typ "contao-bundle" bereiststellen:

Versions older than 2.4 will not support contao/core-bundle, so make sure to set a correct dependency. If you only support Contao 4, the required version would simply be 3.*. However, you should probably create a Symfony bundle and not require the Contao Composer Plugin at all…

Und da stehe ich dann. Die Angaben zum Autoloading beim Typ "contoa-bundle" krieg ich evtl noch hin. Aber wie bekomme ich meine reinen Frontend-Daten kopiert? Die Direktive extra/contao/sources greift ja dann nicht mehr. In diesem Zusammenhang wohl auch für meine Umsetzung irrelevant sowas wie https://github.com/composer/installers / https://github.com/oomphinc/composer...llers-extender oder https://github.com/contao-components/installer.

Wie kann ich Frontend Daten/assets eines bundles in die Ordner template und files kopieren lassen?

Dies wäre der erste Schritt. Damit die Daten aber nicht überschrieben werden nachdem z.B .scss Daten lokal geändert wurden müßte man die default Theme Namen nach Installation umbenennen können. So wie für das https://github.com/ErdmannFreunde/euf_nutshell_kit. Allerdings wird dies als Projekt (inkl. custom installer https://github.com/ErdmannFreunde/eu...hell_installer) bereitgestellt und nicht als library.

Es geht mir nicht um die spätere Nutzung via node/npm/gulp etc. sondern halt erstmal um die eigentliche Installation eines reinen Theme Bundles.
Danke

[Spooky]

Ich denke das composer-plugin wirst du weiterhin für solche Zwecke brauchen. Eine andere (für den User konfigurationsfreie) Lösung kenn ich da derzeit auch nicht.

[Franko]

Ich denke das composer-plugin wirst du weiterhin für solche Zwecke brauchen. Eine andere (für den User konfigurationsfreie) Lösung kenn ich da derzeit auch nicht.

Schnell wie immer - Danke.
Warum beinhaltet das https://github.com/contao/manager-plugin aber nicht die gleiche Funktionalität wie das Contao composer-plugin hinsichtlich des Umgangs mit extra/contao/source Einträgen?

[Spooky]

Naja, das manager-plugin hat damit ja nichts zu tun. So würde ich zumindest argumentieren

[Toflar]

Weil es die nicht braucht Du kannst weiterhin Assets zur Verfügung stellen, wie in jedem Symfony Bundle:

Einfach in deinem Bundle im Verzeichnis "Resources/public" ablegen und dann wird es automatisch nach "web/bundles/<bundlename>" kopiert bzw. gesymlinked (je nach dem was dein Server kann).
Mehr dazu: https://symfony.com/doc/current/bund...tory-structure

[Spooky]

Ihm geht es aber um ein Theme, dass bspw. auch Dateien in files/ benötigt. So wie es eben die Contao Official Demo macht.

[Franko]

Als Unbedarfter - Please be patienced with me.
Was nutzt mir aber die Verlinkung über web/bundles in Zusammenhang mit einem Frontend Theme?

[Franko]

Ich werde mal den Umgang mit https://github.com/oomphinc/composer...llers-extender lokal testen.

Wäre es hierzu evtl. hilfreich wenn für Contao in https://github.com/composer/installers ein entsprechendes Contao Package Type bereitgestellt werden könnte (s. https://github.com/composer/installe...ser/Installers) ...?

[Franko]

Wäre es hierzu evtl. hilfreich wenn für Contao in https://github.com/composer/installers ein entsprechendes Contao Package Type bereitgestellt werden könnte (s. https://github.com/composer/installe...ser/Installers) ...?

Hm, bringt ja eigentlich auch nicht viel ...
Contao stellt doch bereits einen eigenen composer custom installer. Es wäre praktisch wenn Contao zusätzlich einen Typ ala "contao-theme" bieten würde, wobei dabei dann entsprechende Einträge unter extra/contao berücksichtigt würden ...

[andreas.schempp]

Der Type "contao-bundle" und "contao-module" inklusive composer-plugin richtet sich an Erweiterungen, nicht an Themes. Für Themes gibt es keine generelle Lösung, und ich wüsste auch nicht wie die aussehen sollen. Wie du selber sagst ist es nicht generell sinnvoll Daten nach /files zu kopieren weil sie der Benutzer da ja ändern kann.

Aus meiner Sicht ist das vorgehen mit dem Custom Installer nicht falsch, zumindest nicht bis sich ein Standard etabliert hat. Das composer-plugin hat damit aber sicherlich nichts zu tun und ist nur eine Krücke aus alten Zeiten. Es kann zwar Dateien kopieren, aber es ist trotzdem nicht die richtige Lösung.

Generell glaube ich auch nicht dass die Installation eines Themes per Composer wirklich sinnvoll ist. Dafür gibt es doch die Theme-Option im Backend?
Ein Update eines Themes kann über Composer doch nie kommen, sonst würde Änderungen des Benutzers immer überschrieben?

[Franko]

Naja, im weitesten Sinne geht es ja um ein asset management - und wenn ich sowas lese wie
https://github.com/fxpio/foxy
https://asset-packagist.org/
https://github.com/kriswallsmith/assetic
https://symfony.com/blog/introducing...set-management

komme ich zu meiner ersten Aussage:

Je mehr ich lese desto verwirrter werde ich (als Nicht Entwickler).

Hierbei wird immer darauf hingewiesen, das es selbstverständlich keine generelle Vorgehensweise geben kann. Unterschiedliche Application/Frameworks erwarten halt unterschiedliche Strukturen. Daher sollte in speziellen Fällen ein Installer bereitgestellt werden. Also:

Der Quasi Standard für ein Contao Theme ist doch eben:
- Eine Verzeichnis mit möglichen custom templates im Contao Verzeichnis templates
- Ein Theme Verzeichnis im Contao files Verzeichnis mit css/scss/fonts/icon etc. o. zusätzlichen deployment features package.json, gulp.js etc.

Aus meiner Sicht ist das vorgehen mit dem Custom Installer nicht falsch, zumindest nicht bis sich ein Standard etabliert hat.

Du meinst jetzt einen eigenen Custom Installer sowie etwa https://github.com/ErdmannFreunde/eu...ell_installer? Aber der greift ja nur bei der Installation eines composer Projektes und nicht bei einer composer library? Wenn ich ein Contao Theme Package als library bereitstelle und dieses required einen custom installer wird dessen Ausführung doch bei der installation meines package ignoriert - Oder nicht????

Ein Update eines Themes kann über Composer doch nie kommen, sonst würde Änderungen des Benutzers immer überschrieben?

Ja, ein Problem - aber die erstmalige Bereitstellung/kopieren der Daten wäre ja schon hilfreich ...

Generell glaube ich auch nicht dass die Installation eines Themes per Composer wirklich sinnvoll ist. Dafür gibt es doch die Theme-Option im Backend?

Naja, dann hätte man sich bei der Contao Demo ja auch mit der Bereitstellung einer .cto Datei begnügen können ...

[Spooky]

Du meinst jetzt einen eigenen Custom Installer sowie etwa https://github.com/ErdmannFreunde/eu...ell_installer? Aber der greift ja nur bei der Installation eines composer Projektes und nicht bei einer composer library? Wenn ich ein Contao Theme Package als library bereitstelle und dieses required einen custom installer wird dessen Ausführung doch bei der installation meines package ignoriert - Oder nicht????

Nein, composer plugins werden vorher geladen.

[Franko]

Nein, composer plugins werden vorher geladen.

Habe jetzt versucht über ein lokales repository mein library package zu requiren, wobei in dieser composer.json dann zum Test der https://github.com/ErdmannFreunde/eu...hell_installer angegeben ist.
Der Installer scheint aufgerufen zu werden - bekomme zwar

[ErrorException]
copy(package.json.dist): failed to open stream: No such file or directory

aber das liegt wohl an fehlenden Dateien meines lokalen packages die dieser installer voraussetzt.

Also ja - es ist so wie Du gesagt hast.
Muß mich also dann näher mit der composer-plugin Umsetzung beschäftigen.

Ansonsten bleibt die Frage mit der Umbenennung. Der euf_nutshell_installer fragt z.B. auf der Konsole u.a nach eigenen Verzeichnisnamen und benennt diese entsprechend um. Derartiges wäre über die Konsole des CM eh nicht möglich - oder kann mann da Eingaben tätigen? Ich denke daher ist das https://github.com/ErdmannFreunde/euf_nutshell_kit auch von vorn herein als composer project ausgelegt.

Oder ich nutze weiterhin das Contao composer.plugin zum kopieren und lagere die Umbennung über node/npm Scripts aus. Letzteres verlangt dann aber eine manuelle User Aktion und müßte deutlich dokumentiert werden ...

[andreas.schempp]

Warum verwendest du nicht einfach die Theme-Dateien welche im Contao Backend importiert werden können?

[Franko]

Warum verwendest du nicht einfach die Theme-Dateien welche im Contao Backend importiert werden können?

Könnte man. Aber einfacher ist es dies auch via composer bereitstellen zu können. Dabei kann man dann auch gleich Pakete angeben die das Theme entweder direkt benötigt oder für die das Theme Layout Unterstützung bereitstellt oder halt einfach die Arbeit erleichtern:

madeyourday/contao-rocksolid-custom-elements
erdmannfreunde/euf_grid
terminal42/notification_center
terminal42/contao-changelanguage
etc.

Ansonsten muß man alles erklären: Installieren Sie zunächst dieses Paket, dann dies etc. Selbst wenn man diese Pakete als metapackage bereitstellt erfordert es entsprechende Hinweise.
Weiterhin ist es für den User bequem nach Contao Themes an prominenter Stelle - über den CM - suchen/finden/installieren zu können ...

Außerdem werden in dieser Form ja bereits zahlreiche Themes (Backend/Frontend) auf packagist.org aufgeführt - Allerdings alle mit unterschiedlichen Ansätzen. Insofern war Deine Aussage richtig:

Aus meiner Sicht ist das vorgehen mit dem Custom Installer nicht falsch, zumindest nicht bis sich ein Standard etabliert hat.