Composer-Integration

[andreasisaak]

Kurz zur Erklärung warum man den Composer nicht festpinnen sollte - man verliert jegliche Vorteile der Updates. Den LiveUpdate Service pinnt man ja auch nicht fest und der aktualisiert sich ständig selber. Genauso verhält es sich beim Composer.

Das ist für mich gravierend. Wenn nun jeder die Version festpinnt, dann brauchen wir ja auch nicht mehr weiter entwickeln.

[tab]

Ja, aber reicht es dazu nicht, sich auf stabile Versionen zu beschränken? Als Anwender, der ein produktives System aufbauen muss meine ich. Ein Update auf eine neuere, stabile Version gibt es im Moment gar nicht. Deswegen würde es doch reichen, die Composeraktualisierung erst dann freizugeben, wenn eine solche stabile Version existiert. Meine ist im Moment allerdings "dev-master", was immer das auch ist

[ciaobello]

Und sowas schreibe ich dir lieber hier und nicht im Wiki weil das mehr Leute verwirren würde. Im Wiki entferne ich kurz den Nebensatz mit dem festpinnen und dann ist alles in Ordnung.

Genau so stelle ich mir das vor, dass ohne gross Wind zu machen die Sache angeschaut wird und wenn was falsch ist einfach korrigiert wird. Einen kleinen Hinweis hier im Thema und die Sache kann abgehakt werden. Dann bin ich nämlich auch motiviert da was im Wiki weiter zu machen.

Ich tue das ganze ja nicht aus Langeweile ... vielmehr um meinen Beitrag an der Opensource Community beizusteuern und Euch arbeit bei der Dokumentation abzunehmen. Wer kriegt schon gerne eine Kopfnuss als Belohnung

...damit zeigen das ich ab und zu richtig liege mit meiner Meinung oder meinen Hilfestellungen.

Das ist eine großartige Motivationshilfe und daher will ich alle aufrufen auch in Zukunft sich bei den Leuten zu bedanken wenn sie helfen konnten. Ich finde die Funktion super und bin immer glücklich wenn ich persönlich jemanden helfen konnte.

Mir geht es auch so

[ciaobello]

Also mein Problem mit dem Composer ist wohl größtenteils ein Verständnisproblem. Für mich ist er einfach ein Ersatz für das ER2, mit dem ich Pakete installieren und up to date halten kann. Einen Einfluss darauf, ob das System als Ganzes funktioniert oder nicht, sollte er doch eigentlich nur haben, wenn er verwendet wird - und nicht im "normalen Betrieb".

Ich sehe das ähnlich und lese dass auch aus vielen Beiträgen von Anderen Usern so. Darum auch meine Anfrage auf Unteschiedliche Konfigurationen beim Composer. Es sollte doch machbar sein, dass man bei Den Einstellungen, wie es jetzt beim ER2 gehandhabt wird, einstellen kann ob die Inkompatiblen Erweiterungen angezeigt werden sollen oder nicht

Einen Anwender oder Entwicklermodus wäre vielleicht idealer beim Composer. Eine für den Anwender vorkonfigurierte Einstellung welche keine gorssen Änderungen zulässt ohne diese in den Einstellungen zu aktivieren.

Ja, aber reicht es dazu nicht, sich auf stabile Versionen zu beschränken? Als Anwender, der ein produktives System aufbauen muss meine ich. Ein Update auf eine neuere, stabile Version gibt es im Moment gar nicht. Deswegen würde es doch reichen, die Composeraktualisierung erst dann freizugeben, wenn eine solche stabile Version existiert. Meine ist im Moment allerdings "dev-master", was immer das auch ist

Irgendwie dachte ich dass das Festpinnen so eine Funktion ist welche Versionen auf Stable hält. Wie ich aber heute Belehrt wurde ist dem nicht so.
Als ich meine Composer Testversion heute wieder mal aufgerufen habe kam ja auch die Mitteilung das der Composer älter als 30 Tage ist und aktualisiert werden sollte.

@ciaobello Was fehlt Dir denn noch in deinem Wiki-Beitrag zum Composer? Der sit eigentlich schon recht vollständig.

Unklarheiten richtig zu stellen wäre von Vorteil. Der Composer kommt mir mit zu viel Schalter und Hebel daher. Ich habe Angst vor dem Komposter

Beispiel, eine ältere Person hat auch Kommunikations Bedürfnisse. Sie will auch mit Ihrer jungen und Modernen Familie kommunizieren können. Es ist Ihr aber zu umständlich das hantieren mit einem PC oder mit einem Tablett zu erlernen. Vielmehr will diese Person ein Mobiles Telefon mit Grossen Tasten die eine Hintergrund Beleuchtung haben und vielleicht noch wissen wie man eine Text-Nachricht beantworten kann.

Für Euch Entwickler ist der Composer ein mächtiges Werkzeug. Für einen Durchschnitts User ist der Composer einfach einen besseren Ersatz für das ER2.
Er will Erweiterungen damit suchen & installieren und vielleicht noch die Aktualisierungen damit verwalten können. Mehr nicht.

[Nina]

Mal ein paar grundlegende Fragen zum Composer:

• Läuft er mittlerweile stabil genug, dass man ihn guten Gewissens in ein Live-Projekt (3.2.x+) von Kunden installieren kann?
• Erkennt der Composer aktive Extensions die in der Contao-Installation laufen, aber ursprünglich nicht übers ER installiert wurden? Oder agiert er da wie das ER und ignoriert diese Extensions einfach?
• Könnte man im Notfall sauber auf das ER zurückswitchen, falls es erhebliche Composer-Probleme gibt, oder geht es nach dem Motto "Einmal gehangen, für immer gefangen" ;-)
• Kann der Composer Extensions verwalten, die die Entwickler im ER ablegen, oder findet er nur die Extensions die speziell für den Composer eingestellt wurden?
• Wie ist der aktuelle Stand zur Integration von Composer in den Contao-Core? Kommt da jetzt was mit der 3.3 oder wird das noch länger parallel laufen? Falls letzteres der Fall ist, woran hakt es?

Vielen Dank für eure Antworten

[tab]

Ich sehe das ähnlich und lese dass auch aus vielen Beiträgen von Anderen Usern so. Darum auch meine Anfrage auf Unteschiedliche Konfigurationen beim Composer. Es sollte doch machbar sein, dass man bei Den Einstellungen, wie es jetzt beim ER2 gehandhabt wird, einstellen kann ob die Inkompatiblen Erweiterungen angezeigt werden sollen oder nicht

Sehe ich eigentlich auch so - und wahrscheinlich kann man das schon jetzt leicht erkennen, wenn man denn wüsste, was die einzelnen Informationen bei den verschiedenen Versionen genau bedeuten. Leider bin ich mir ziemlich sicher, das nicht zu wissen.

Ich gebe mal ein Beispiel aus einer meiner Composer/Metamodels/3.2.9 Installationen. Da verwende ich bei den Metamodels den relativ neuen Filter "metamodels/filter_perimetersearch". Bei den installierten Paketen in der Paketverwaltung steht dazu:

Angeforderte Version: dev-contao3 Installierte Version dev-contao3

Jetzt klicke ich vorne auf den Paketnamen und bekomme (vermutlich) alle verfügbaren Versionen des Pakets angezeigt. Geöffnet ist allerdings nicht die Version "dev-contao3", sondern (wieder vermutlich) die neueste stabile Version 1.0. Da das sowieso nicht meine installierte Version ist, klicke ich mal auf die Version "dev-contao3", die leider nicht so schön beruhigend grün hinterlegt ist.
Da lese ich dann unter anderem Informationen zu Abhängigkeiten und Konflikten:

Abhängigkeiten
    php >=5.3
    contao/core >=2.11,<4.0
    contao-community-alliance/composer-installer *
    metamodels/core ~1

Konflikte
    contao/core 3.0.*

Was will mir das jetzt sagen? Zu welcher Contao-Version ist das Paket z.B. kompatibel? 2.11 bis 3.x? Wenn ja, was will mir dann der Eintrag bei Konflikte sagen? Die Core-Version 3.0.x liegt doch in diesem Bereich!?! Was würde das jetzt bedeuten, falls ich Contao 3.0.6 installiert hätte (was ich zum Glück nicht mehr habe). Dass es damit nicht funktioniert?
Die Fragen, die ich mir stelle, zeigen mir, dass ich nicht wirklich verstehe, was die Informationen mir sagen wollen.

Als ich meine Composer Testversion heute wieder mal aufgerufen habe kam ja auch die Mitteilung das der Composer älter als 30 Tage ist und aktualisiert werden sollte.

Auch so eine Sache. Ich habe meinen Composer aufgrund dieser Meldung schon mehrfach aktualisiert, wobei er sich aber augenscheinlich nicht geändert hat. Die Meldung scheint also wirklich rein zeitgesteuert zu kommen.

Unklarheiten richtig zu stellen wäre von Vorteil. Der Composer kommt mir mit zu viel Schalter und Hebel daher. Ich habe Angst vor dem Komposter

Angst wäre jetzt übertrieben, aber im Prinzip bin ich bei dir. Ich fühle mich dabei in etwa so, wie sich der Zauberlehrling wohl gefühlt haben muss, als ihm die Kontrolle über die Dinge entglitten ist. .
Ich denke, im Hinblick auf die Akzeptanz des Composers ist es wichtig, über solche Dinge zu schreiben und sie ein Stück weit auch zu erklären. Die reine Argumentation nach dem Motto "früher oder später müsst ihr sowieso den Composer benutzen" hilft dabei nicht, sondern ist eher kontraproduktiv.

[BugBuster]

Da lese ich dann unter anderem Informationen zu Abhängigkeiten und Konflikten:

Abhängigkeiten
    php >=5.3
    contao/core >=2.11,<4.0
    contao-community-alliance/composer-installer *
    metamodels/core ~1

Konflikte
    contao/core 3.0.*

Was will mir das jetzt sagen? Zu welcher Contao-Version ist das Paket z.B. kompatibel? 2.11 bis 3.x? Wenn ja, was will mir dann der Eintrag bei Konflikte sagen? Die Core-Version 3.0.x liegt doch in diesem Bereich!?!

Das musst du genauer lesen!
Dort steht sinngemäß: Es läuft unter contao/core ab 2.11 und kleiner 4.0, aber nicht mit Contao 3.0.
Das ist eine Art der Definition die ER2 nicht konnte, hier hätte man 2 Versionen anlegen müssen, eine für 2.11 und eine ab 3.1.

Und noch was. Composer schaut beim Installieren immer auf die Erfüllung aller Paketabhängigkeiten. Das merkt man besonders, wenn zwei Erweiterungen ein gemeinsames drittes brauchen, aber mit anderer Versionsnummer. Das ER2 war da knallhart und hat ggf. das neuste drüber gebügelt oder das alte, je nachdem welches der beiden Pakete das letzte war.
Composer prüft hier, ob das überhaupt sein darf und verweigert in dem Fall die Installation bzw. das Update.

Daher sagt man ja auch nicht, mach mal ein Update von der Erweiterung X sondern, Versuche mal alle Pakete zu Aktualisieren (wenn es denn was neues geben sollte) unter Beachtung aller Abhängigkeiten.

Deshalb kann man meines Wissens auch nicht sagen, er soll ein Paket installieren was inkompatibel ist. Aus Composer Sicht wäre dann die gesamte Installation gefärdet.


Das einzige was zu machen kannst ist manuell zu steuern eine nächst höhere Beta zu installieren.
So bin ich gestern von Composer 0.8.13 auf die 0.9 beta3? hochgegangen. Hier wird natürlich auch geprüft ob dann noch alles Abhängikeiten stimmen.

[BugBuster]

Mal rein meine Erfahrung aus "ab und zu mal in der Testumgebung mit arbeiten".

Mal ein paar grundlegende Fragen zum Composer:

• Läuft er mittlerweile stabil genug, dass man ihn guten Gewissens in ein Live-Projekt (3.2.x+) von Kunden installieren kann?

Für micht nicht, zu oft noch Fatal Error, wobei das meistens an der Erweiterung liegt, selten am Composer bzw. seinem Installer.

• Erkennt der Composer aktive Extensions die in der Contao-Installation laufen, aber ursprünglich nicht übers ER installiert wurden? Oder agiert er da wie das ER und ignoriert diese Extensions einfach?

Wüsste nicht wie, das der ja die composer.json benötigt von den Extensions. Hab es aber nicht probiert, nur die Migration der bereits über ER2 installierten.

• Könnte man im Notfall sauber auf das ER zurückswitchen, falls es erhebliche Composer-Probleme gibt, oder geht es nach dem Motto "Einmal gehangen, für immer gefangen" ;-)

Es gibt einen Link, zurück zum alten ER, ob der funktioniert, keine Ahnung.

• Kann der Composer Extensions verwalten, die die Entwickler im ER ablegen, oder findet er nur die Extensions die speziell für den Composer eingestellt wurden?

Erweiterungen aus dem ER2 können ebenfalls installiert werden, dazu hat die c-c-a was gebaut. Diese Erweiterungen tauchen dann als contao-legacy/<name> auf.
Können auch gesucht werden, wobei das bisher immer aus meiner Sicht einer der größten Schwachpunkte war, da dort nicht nach Contao Paketen gefiltert wurden.
Die Verwaltung geht ja über packagist.org und dieser Service verwaltet ja alle Composer Pakete.
Hier soll es auch in Zukunft eine eigene Lösung geben, hörte ich mal.

• Wie ist der aktuelle Stand zur Integration von Composer in den Contao-Core? Kommt da jetzt was mit der 3.3 oder wird das noch länger parallel laufen? Falls letzteres der Fall ist, woran hakt es?

Parallel laufen wird es sowieso, zumal es lange dauern wird bis die Erweiterungen alle auf GitHub liegen, was eine Vorraussetzung ist per Composer/Packagist installiert werden zu können.
Sicherlich wird es irgendwann mal einen Schnitt geben.
Private und kommerzielle Pakete die es im ER2 gibt können darüber nicht installiert werden.

Kurz gesagt, für Kenner die bei Fehlermeldungen wissen was zu tun ist: OK, aber für reine Anwender (Kunden) halte ich persönlich das noch für gefährlich.
Es hat sich aber auch ne Menge getan, vielleicht kenne ich noch nicht alle Verbesserungen.
Müsste mal wieder ein Extrem-Test-Tag einlegen.

[tril]

... Ich habe zwar meinen Composer nicht "festgepinnt", aber ich verstehe nicht wirklch, warum das ein (gravierendes) Problem sein sollte?!? Die stable version war gut genug, um die Erweiterungen zu installieren, ich gehe einfach mal davon aus, sie wird auch gut genug sein, um Erweiterungen upzudaten?! ... Bringt der verbesserte Composer die Erweiterung besser von Version X nach Version Y? ...

Wir arbeiten ständig an der Verbesserung von dem Composer Client. Und ja, das bedeutet auch dass die neueren Versionen einen besseren Installationsprozess haben werden, als ältere. Es steht sogar eine völlige Überarbeitung des Installationsprozesses auf dem Plan, weil wir aktuell auch ein paar edge-cases haben, die mit dem aktuellen System zu Problemen führen.

Insbesondere im Zusammenhang mit den Metamodels ist mir auch noch unklar, ob - und wenn ja wie - ich für jedes einzelne Paket separat festlegen kann, ob ich jetzt nur stabile Versionen haben will oder auch Entwicklerversionen. Was ja bei den Metamodels unter Contao 3.2.x wohl durchaus manchmal notwendig ist, um benötigte Features zu erhalten?!? Gleichzeitig will ich das bei anderen Erweiterungen möglicherweise nicht. Festpinnen ist da auf Dauer auch keine Lösung, sonst bekomme ich ja auch neue, stabile Versionen nicht. Bisher habe ich nur eine - nach meinem Verständnis - globale Einstellmöglichkeit dafür gefunden. Oder muss ich da dann einfach die neuere stabile Version "drüberinstallieren". Also nicht mit aktualisieren arbeiten?

Hier hilft dir die sogenannte Version-Constraint (Bedingung für die zu installierende Version).
Zu dem Thema müsste im Wiki noch was geschrieben werden, weil das ein ganz wichtiges Thema ist.
Im Gegensatz zum alten ER2 Client der "nach gut dünken" Versionen Installiert hat (ja ich weiß dass es dort Einstellungmöglichkeiten gibt, hast du schon gesehen dass diese korrekt berücksichtig werden? Also ich nicht ...), kannst du Composer gezielt sagen welche Version es installieren soll. Dazu zählt auch dass du Composer sagen kannst, es soll nur stabile Versionen von Extension X und eine Entwicklungsversion von Extension Y installieren. Composer ist da sehr strikt, da wir aktuell noch in einer sehr frühen Phase sind, haben wir aber aktuell alle Pakete freigegeben (findet man in den Einstellungen als "Minimale Stabilität"). Stellst du dort auf "Stabiles Release" um, installiert dir Composer ausschließlich stabile Versionen, außer für die, die du explizit als instabil frei gibst.

Das pinnen ist nur eine Convenience Funktion um ein Paket (temporär) auf einer Version zu halten und dies zu einem späteren Zeitpunkt auch wieder Rückgängig zu machen.

Ich sehe das ähnlich und lese dass auch aus vielen Beiträgen von Anderen Usern so. Darum auch meine Anfrage auf Unteschiedliche Konfigurationen beim Composer. Es sollte doch machbar sein, dass man bei Den Einstellungen, wie es jetzt beim ER2 gehandhabt wird, einstellen kann ob die Inkompatiblen Erweiterungen angezeigt werden sollen oder nicht

Leider ist das absolut nicht so einfach. Denn Composer ist da sehr strikt was das angeht. Einfach mal ein inkompatibles Paket installieren ist bei Composer keine einfache Sache.
Was wir allerdings machen könnten wäre Pakete die definitiv mit der Contao Installation inkompatibel sind heraus zu filtern.

Einen Anwender oder Entwicklermodus wäre vielleicht idealer beim Composer. Eine für den Anwender vorkonfigurierte Einstellung welche keine gorssen Änderungen zulässt ohne diese in den Einstellungen zu aktivieren.

Das ist doch jetzt schon der Fall. Bei der Migration kannst du 2 Systemeinstellungen auswählen (für Produktiv-Betrieb und Entwicklungs-Betrieb) und für ganz hard gesottene gibt es den Expertenmodus.

An dieser Stelle sei aber auch gesagt, dass der Client noch grundsätzliche Designänderungen erfahren wird.
2 Entwürfe von mir kann man auf Twitter finden:
https://twitter.com/TristanLins/stat...73089763098625
https://twitter.com/TristanLins/stat...14073246253056

Das Design Team beschäftigt sich aktuell mit diesem Thema und da werden wir in den nächsten Wochen auch einige Neuerungen liefern können. (Aktuell haben wir nur mit Konferenz, Contao 3.3 und Association einfach alle zu viel zu tun).

Irgendwie dachte ich dass das Festpinnen so eine Funktion ist welche Versionen auf Stable hält. Wie ich aber heute Belehrt wurde ist dem nicht so.
Als ich meine Composer Testversion heute wieder mal aufgerufen habe kam ja auch die Mitteilung das der Composer älter als 30 Tage ist und aktualisiert werden sollte.

Auch so eine Sache. Ich habe meinen Composer aufgrund dieser Meldung schon mehrfach aktualisiert, wobei er sich aber augenscheinlich nicht geändert hat. Die Meldung scheint also wirklich rein zeitgesteuert zu kommen.

Man muss zwischen dem Client / Backend-Integration, der Composer Library und dem Composer Plugin unterscheiden.
Viele assoziieren den Begriff Composer mit dem Client, das was in der Meldung genannt wird ist aber die Composer Library (composer.phar) und hat mit dem Client überhaupt nichts zu tun. Was du festpinnen kannst ist der Client, niemals aber die Library.

Läuft er mittlerweile stabil genug, dass man ihn guten Gewissens in ein Live-Projekt (3.2.x+) von Kunden installieren kann?

Es gibt genug die NUR NOCH den Composer Client einsetzen.

Erkennt der Composer aktive Extensions die in der Contao-Installation laufen, aber ursprünglich nicht übers ER installiert wurden? Oder agiert er da wie das ER und ignoriert diese Extensions einfach?

Der verhält sich genau so wie der ER2 Client und ignoriert diese. Wenn du die Installation aber via Composer installierst wird die manuell installierte Erweiterung aktualisiert.

Könnte man im Notfall sauber auf das ER zurückswitchen, falls es erhebliche Composer-Probleme gibt, oder geht es nach dem Motto "Einmal gehangen, für immer gefangen" ;-)

Kurz gesagt: Ja, aber ich habe es seit der Implementierung dieser Funktion vor ca. nem halben Jahr nicht mehr ausprobiert.
Im Zweifel einfach den Composer Client und alle damit installierten Pakete löschen (OHNE DIE DATENBANK-TABELLEN/FELDER ZU LÖSCHEN) und via ER2 Client neu installieren geht immer.

Kann der Composer Extensions verwalten, die die Entwickler im ER ablegen, oder findet er nur die Extensions die speziell für den Composer eingestellt wurden?

Theoretisch ja, das ginge hier aber zu weit das zu erklären wie das geht, dafür muss man schon Entwicklerwissen haben, wie die composer.json zu schreiben ist, dann kann man Composer auch ein nicht-Composer-ready Paket hinzufügen.

Wie ist der aktuelle Stand zur Integration von Composer in den Contao-Core? Kommt da jetzt was mit der 3.3 oder wird das noch länger parallel laufen? Falls letzteres der Fall ist, woran hakt es?

Dazu kann ich am besten auf die News Beiträge verweisen:
https://contao.org/de/news/zwischenm...ository-3.html
https://c-c-a.org/aktuelles/news/det...-composer-team

[tab]

Es steht sogar eine völlige Überarbeitung des Installationsprozesses auf dem Plan, weil wir aktuell auch ein paar edge-cases haben, die mit dem aktuellen System zu Problemen führen.

Ok, wenn das nicht nur ein paar eingesparte Sekunden beim Update bringt, sondern darüber entscheiden kann, ob das Update funktioniert, das ist dann ein echtes Argument.

Hier hilft dir die sogenannte Version-Constraint (Bedingung für die zu installierende Version).
Zu dem Thema müsste im Wiki noch was geschrieben werden, weil das ein ganz wichtiges Thema ist.

Stimmt, mir ist das auch wichtig. Ich will ja nicht alle Erweiterungen auf "minimale Stabilität" einstellen müssen, nur weil ich es für eine so brauche. Werde ich mich also mal nach "Version-Constraint" umschauen müssen. Manchmal hilft ja schon das richtige Stichwort.

Das pinnen ist nur eine Convenience Funktion um ein Paket (temporär) auf einer Version zu halten und dies zu einem späteren Zeitpunkt auch wieder Rückgängig zu machen.

Gut. Hätte ich mit meinen festgepinnten "stabilen" Erweiterungen natürlich auch so gemacht. Freigeben, wenn es wieder eine neue stabile Version gibt und diese dann wieder festpinnen. Sobald es mir gelingt, den Version-Constraint für die ganzen Metamodels-Pakete richtig zu setzen, werde ich dann Composer auf "stabile Versionen" einstellen und kann auf das Festpinnen verzichten.

Bis dahin erst mal vielen Dank für die Antworten, ich denke das wird mir weiterhelfen.

[Nina]

Danke für die Infos. Leider sind sie aber für mich noch nicht klar genug, was daran liegen mag, dass ich die ganze Angelegenheit aus Sicht eines Webdesigners/Admins sehe, nicht aus der Programmiererecke.

Momentan stellt sich die Sache für mich so dar:

Ich trau mich nicht, die Contao-Installationen meiner Kunden auf Composer umzustellen. Die Gründe dafür sind vielseitig:

• Die ganze Geschichte mit Composer ist für einen Nicht-Programmierer wie mich noch zu unklar/verwirrend. Ich sehe, dass ein Haufen der besten Community-Programmierer daran arbeitet und entnehme auch z.B. der verlinkten News von contao.org, dass der Composer die Zukunft werden soll. Allerdings lese ich dort auch heraus, dass der Composer noch keinen Status hat um das ER zu ersetzen (sonst wäre das mit Contao 3.3 passiert). Also bin ich erstmal skeptisch und schrecke davor zurück, das für meine Kunden-Installationen einzusetzen.
• Theoretisch gibt es eine Funktionalität mit der man auf das ER zurückstellen könnte, wenn etwas schief geht. Das ist schon mal besser, als die alte Info, dass das generell nicht geht (wurde mir letztes Jahr? so gesagt). Gleichzeitig erfahre ich aber, dass das wohl noch keiner so richtig getestet hat, also ob das auch wirklich problemlos klappt. Sprich: Ich riskiere, dass ich Kunden-Installationen für einen essentiellen Core-Part auf ein System umstelle, das nicht dem Core entspricht (sonst wäre es schon darin aufgenommen), aber keiner kann mir garantieren, dass ich im Notfall zurückstellen könnte, falls es eben doch noch hakt. Damit riskiere ich also, dass die Kunden-Installation de facto tot sein könnte, wenn irgendwas passiert. Ist jetzt natürlich total auf die Spitze getrieben, aber ich hoffe, ihr versteht, was ich meine.
• Es gibt einige Extensions die nicht für den Composer angepasst sind. Es scheint eine Möglichkeit zu geben, wie man sie dennoch über den Composer installiert und verwaltet, aber wie gerade hier geschrieben wurde, ist das nicht so trivial oder benötigt bestimmtes Wissen, etc. Sprich: Ich riskiere, dass ich die Extensions die nicht im Composer sind, nicht korrekt verwalten kann (installieren, leicht prüfen ob dafür Updates vorhanden sind, aktualisieren, etc.).
• ...etc.

Weil ich mich nicht traue, umzustellen, stehe ich aber wiederum vor anderen Problemen:

• Es gibt bestimmte (relevante) Extensions, die werden nur über den Composer bereitgestellt. Wenn ich den Composer nicht nutze, bin ich gezwungen, mir die Files dieser Installationen via Github händisch zusammen zu suchen. Ich kann sie auch nicht wie gewohnt einfach verwalten, sondern bin gezwungen danach auch händisch immer auf Github nachzusehen, ob es eine Aktualisierung gibt und diese händisch dann durchzuführen. Ich habe dazu schon mehrfach von Composer-Fans die Aussage gehört "Ne, ins ER stell ich mein Extension-Update nicht mehr. Ist zu aufwändig. Ich mach nur noch Composer". Tja, kann ich aus Entwickler-Sicht verstehen. Aus Sicht der durchschnittlichen Contao-Nutzer ist es hingegen super nervig, weil nun a) im ER Extensions stehen, für die es scheinbar keine Updates gibt - dabei sind sie da, nur eben im Composer, was der Nutzer erraten muss. Und wenn er es rausfindet, muss er entweder Composer installieren (auch wenn das noch nicht zum Core gehört), oder den ganzen manuellen Ärger auf sich nehmen ...
• ...etc.

Sprich: Wie ich es auch drehe und wende, in dieser "Übergangszeit" ist es für mich als Contao-Nutzer eine richtig doofe und sehr unbefriedigende Situation, in der ich zwischen den Stühlen stehe.
Auf der einen Seite Contao-Core mit dem ER, der zweifelsohne seine Probleme hat (deswegen wird ja ein Ersatz gesucht). Bisher kam ich als Contao-Nutzer/-Admin damit aber (bis auf die bekannten Probleme) brauchbar zurecht. Nun ist das immer öfter nicht mehr der Fall, weil relevante Extensions nicht mehr dafür gepflegt werden.
Auf der anderen Seite ein interessanter ER-Ersatz in Form des Composers, der äußerst wahrscheinlich die Zukunft für Contao ist und für dessen Entwicklung ich prinzipiell sehr dankbar bin. Allerdings ist die ganze Sache aktuell noch für mich zu unklar/unsicher um Composer einzusetzen. Dadurch entstehen mir die bekannten Probleme mit reinen Composer-Extensions, die ich dadurch nur umständlich und mit deutlichen Mehraufwand nutzen kann.

Man kann übrigens aus den Kommentaren zur Contao-News ganz gut rauslesen, dass ich da offensichtlich nicht alleine so zwischen den Stühlen stehe.

PS: Bitte bekommt das nicht in den falschen Hals! Ich finde eure Arbeit am Composer super und weiß, dass er - hoffentlich in naher Zukunft - für Contao eine prima Sache sein wird, die den alten ER-Zopf mit seinen Problem endlich abschneidet. Ich will euch nur klar machen, in welcher Situation die Leute stehen, die nicht aus Programmierer-Sicht drauf schauen, bzw. die entsprechenden Spezis neben sich haben um sich da tief reinzugraben, sondern sich der Situation im zeitlich beschränkten Rahmen der verfügbaren Agenturzeit zuwenden müssen.

[andreasisaak]

Hallo Nina,

die drei Gründe die du für dich gegen Composer aufführst, lassen sich in 20-25 Minuten entkräften. Du musst dich nur damit beschäftigen und bei Fragen uns direkt ansprechen. Ich sehe da keine technischen Hürden

[Nina]

Wenn die sich so leicht entkräften lassen, weshalb wird das dann nicht auf eine Art und Weise gemacht, dass alle Nutzer etwas davon haben? Ist ja schön, dass ich mich "nur 20-25 Minuten reingraben" muss. Aber wie/wo?

Offensichtlich ist es ja eben doch nicht so easy, wenn man die "Entkräftung" der Problempunkte nicht so gestalten kann, dass sie von sich aus für Otto-Normalnutzer klar sind und man dann doch wieder bei euch nachhaken muss. Lass das mal jeden Contao-Nutzer machen, dann seid ihr nur noch mit Fragen/Antworten beschäftigt

Verstehst du, wie ich das meine? Es geht nicht darum, dass ich etwas auf dem Silbertablett serviert haben will. Ich versuche die ganze Sache so für euch darzustellen, wie sie momentan für einen stinknormalen Contao-Nutzer ist. Da sind Ängste, Sorgen und vermeintliche Risiken da, die von Composer-Seite nicht eindeutig geklärt sind (siehe meine Posts hier, Kommentare der Nutzer zu den Composer-News auf contao.org, etc). Ich kenne mich mit Contao natürlich passabel aus und ja, wenn ich anfange euch in den Ohren zu liegen, werde ich nach und nach die Infos zusammen gestückelt bekommen. Vielleicht sind meine Sorgen danach behoben. Aber was ist mit den tausenden anderen Contao-Core Nutzern da draußen? Die stehen immer noch mit zu wenig klaren, eindeutigen, benutzerfreundlichen Infos für Core-Anwender da und wissen nicht, was nun los ist.

Sprich: Composer ist technisch sicher spitze. Aber in Bezug auf Benutzerfreundlichkeit ist es momentan noch ein totaler Verhau. Und da bezieh ich mich gar nicht auf die Benutzerfreundlichkeit des Interfaces, sondern auf die verfügbaren Infos rundherum, die den Nutzer überhaupt erst dazu bekommen, dass er sich traut den Composer einzusetzen ... sprich: Momentan besteht da ein erhebliches Kommunikationsproblem, das aus meiner Sicht nur von Core AG+Composer-Team in Kombination gelöst werden kann.

PS: Unter anderen Umständen würde ich versuchen mich da reinzugraben und danach versuchen die Kommunikationsprobleme für die Community zu beheben, aber momentan ist mir das aus bekannten Gründen (hochschwanger) nicht möglich. Es geht also nicht darum, dass ich mich hier "verweigere", sondern tatsächlich aus der Sicht eines typischen gestressten Agenturinhabers schreibe, der davon ausgeht, dass ihn der CMS-Anbieter bei einem derart essentiellen Part wie den Extensions mit guter Kommunikation eindeutig informiert

// Nachtrag siehe mein Beitrag vom 09.05.

[andreasisaak]

Wie schon zigfach erklärt: Es fehlt schlichtweg die Zeit. Ich finde es super das sich Leute wie ciaobello nun hinsetzen und das Wiki anfangen mit Composer Dokumentationen zu bestücken. Und wann immer ich persönlich die Zeit finde, werde ich dort auch reinschauen. Und so handhaben es die anderen bestimmt auch.

Aber ich finde deinen Post sehr interessant. Wie war das denn mit Contao 3? Gab es da eine riesen Dokumentation und viel Kommunikation von Seiten des Contao Teams? Oder war es nicht eher so das viele ins kalte Wasser geworfen wurden? Wie oft habe ich dazu im Forum gelesen das der Umstieg auf Contao 3 Ängste bereitet. Ich will damit die Entwicklung von Composer nicht rechtfertigen aber wenn es selbst beim Core zu diesen Problemen kommt - dann ist es einfach verständlich das auch wir im Composer Team diese Probleme haben.

[Nina]

Danke Leo, grundsätzlich gut und laienfreundlich erklärt

Wenn ich dich also richtig verstehe, gibt es keinerlei Risiko, dass ich mir eine Contao-Installation zerschieße, falls ich Composer installiere und es wieder deinstallieren müsste, weil irgendwas hakt. Ich würde die "Extension Composer" deinstallieren und dann ... ja dann wäre das ER wieder sichtbar, auch wenn es dann halt nicht wüsste, welche Extensions installiert sind (weil nicht via ER installiert). Sprich: mir würden die typischen ER-Vorteile fehlen, dass ich leicht sehe, ob es Aktualisierungen gibt und diese mit Knopfdrück aktualisieren kann ... ich müsste also hoffen, dass diese Extensions in der installierten Version (welche war das noch gleich?) auch im ER liegen, damit ich sie drüberbügeln kann und mir das ER wieder den Versionsstand anzeigt sowie mir die Aktualisierungsmöglichkeiten gibt ... vorausgesetzt natürlich, die Extension gibt es überhaupt fürs ER, sonst müsste ich bei der manuellen Geschichte bleiben, wo aus Nutzersicht eben auch keine leicht verfügbare Info zu Versionsstand/Aktualisierung per Knopfdrücken besteht ... aber ja, laut deiner Info wäre zumindest die Core-Installation im Notfall an sich noch intakt, was zumindest einen essentiellen potentiellen Angstpunkt aus meiner obigen Liste entfernt. Korrekt?

Was ist dann noch mit den genannten Problemen, dass eben z.B. wenn ich den Composer installiert habe, ich anscheinend keinen einfach Zugriff auf Extensions habe, die nur im ER liegen? Oder ist das doch alles ganz einfach, auch wenn weiter oben was anderes dazu steht?

PS: Sorry, ich frage absichtlich so "einfach". Versuche nur weiterhin die Denkweise von Nichtprogrammierern abzubilden.

[462]

Wo ich darüber gestolpert war, ist noch, dass das ER dann wieder in den Einstellungen de-inaktiviert werden muss.

[ciaobello]

Wo ich darüber gestolpert war, ist noch, dass das ER dann wieder in den Einstellungen de-inaktiviert werden muss.

Du meinst wohl dass hier:

Einstellungen > Inaktive Erweiterungen:

❏ [repository] Extension Repository

Den Haken entfernen damit Das Repository auch wieder angezeigt wird?!

[ciaobello]

Was wir allerdings machen könnten wäre Pakete die definitiv mit der Contao Installation inkompatibel sind heraus zu filtern.

Wäre sicher Hilfreich. Soll man das auf Github als Change Request anbringen?

Das ist doch jetzt schon der Fall. Bei der Migration kannst du 2 Systemeinstellungen auswählen (für Produktiv-Betrieb und Entwicklungs-Betrieb) und für ganz hard gesottene gibt es den Expertenmodus.

Ich werde das noch einmal testen und gucken ob ich es jetzt beim CH-Provider auch installieren kann. Es ist eine Weile zurück wo ich eine Neuinstallation vorgenommen habe. War das letzte mal als ich bei Inetrobots meine Testinatallation installiert habe. Da ging es ja problemlos.

An dieser Stelle sei aber auch gesagt, dass der Client noch grundsätzliche Designänderungen erfahren wird.
2 Entwürfe von mir kann man auf Twitter finden:
https://twitter.com/TristanLins/stat...73089763098625
https://twitter.com/TristanLins/stat...14073246253056

Wenn es der Übersicht und der Vereinfachung dient ist es ja für alle gut.

Man muss zwischen dem Client / Backend-Integration, der Composer Library und dem Composer Plugin unterscheiden.
Viele assoziieren den Begriff Composer mit dem Client, das was in der Meldung genannt wird ist aber die Composer Library (composer.phar) und hat mit dem Client überhaupt nichts zu tun. Was du festpinnen kannst ist der Client, niemals aber die Library.

OK. Danke dass ist ein Wichtiger Hinweis.
In der Verzeichnis Struktur ist die Library in /composer zu finden und der eigentliche Client bei den Erweiterungen /system/Modules/!composer. Zumindest ist es bei meiner älteren Installation so.

Und das Ausrufezeichen dient dazu das diese Erweiterung an erster Stelle steht und somit als erstes geladen wird, richig?

Im Backend steht contao-community-alliance/composer für den Client & contao-community-alliance/composer-installer für das Plugin/Installer, auch richtig?

Wenn meine Annahmen Stimmen ist mir nun einiges klarer.

Es gibt genug die NUR NOCH den Composer Client einsetzen.

Das wäre dann über den https://github.com/contao/check/arch...er.zip/.tar.gz ?
Ich habe gesehen dass Leo den Memorylimit von 512MB entfernt hat. Dass könnte bei meinem CH-Provider die Ursache gewesen sein für die Fehler. Ich teste es nochmal und melde mich hier bei allfälligen Fragen nochmal dazu.
Da habe ich wohl wieder was falsch verstanden. Mit anderen Worten, es gibt genug Leute die gänzlich auf ER2 verzichten und nur noch mit Composer-Client arbeiten. Sei er mit ER2 installiert oder von Hand.

Danke an alle die sich an der konstruktiven Auseinandersetzung mit Composer beteiligt haben und auf Details ausführlich eingegangen sind. Ich habe auch nicht wirklich Angst von Composer . Habe nur überspitzt dargelegt um auch eher den Anwender zu Vertreten der hier still mitlesen tut und sich nicht traut da was zu sagen.

Ich werde in einem Separaten Wiki die Installation und Deinstallation vom Composer Client erörtern, falls Ihr mir meine Vermutungen bestätigt oder allenfalls korrigiert.

Ich mache das wiki separat und verlinke es, damit wir die Ausführungen zu Composer schlank halten können und weil in naher oder fernen Zukunft der Composer eh mit Contao daher kommt und eine Installation weg fällt.

[Nina]

Ich habe mitbekommen, dass meine Beiträge als schroff wahrgenommen wurden, insbesondere meine Reaktion auf Andreas' nettes Hilfsangebot. Sorry, war nicht meine Absicht und wirklich nicht so gemeint. Ich steh derzeit unter großem persönlichen und beruflichen Stress, da liegt mein Feingespühr für Formulierungen teilweise offensichtlich ganz schön daneben (und meine Nerven liegen deswegen sowieso blank ). SORRY. Ich hab nix böse gemeint und Andreas' Angebot als sehr nett empfunden (wie dann auch das heutige von Nicky). Auch wenn es vielleicht anders rüber gekommen ist: Ich steh dem Composer-Projekt total positiv gegenüber und finde es eine prima Sache, vor allem auch die ganze Mühe und Zeit die so viele Leute darin investieren.

Also bitte meine aktuelle gestresste Art nicht auf euch oder eure Arbeit beziehen. War nicht so gemeint.