Contao 4 - wo ist der Composer

[Honig]

Hi,
wollte nur mal fragen ob ich irgendwas übersehen habe aber wo ist der Composer? Ich habe das Contao installiert und auch eine Anleitung gefunden wie man Module installiert mit Composer aber
das ist jede Menge Shellfummelei.
Ist das jetzt die Defaultvorgehensweise im 4er Contao - ich hoffe mal nicht oder?
Olli

[lucina]

Bis jetzt ist das in der Tat noch 'Shellfummelei' (schönes Wort!). Sorry. Ausblick auf die zukünftige Funktionsweise bietet https://contao.org/de/news/informati...o-manager.html.

[Honig]

Alles klar danke für die Antwort. Damit wäre "Contao 4 ist für den produktiven Einsatz absolut geeignet!" und "Alles was in Contao 3.5 möglich ist, ist mit Contao 4 schon seit längerer Zeit möglich." aus dem Artikel allerdings eine sehr optimistische Ansicht Ich frage mich wer in dem Text als Entwickler und Anwender gesehen wird.
Der Contao Manager klingt aber wie eine sehr coole Sache. Das könnte viel Arbeit abnehmen.

[lucina]

Sehe ich etwas anders. Im Produktiveinsatz hat ein Paketmanager nichts zu suchen. Der gehört auf ein Stagingsystem und in die Hand eines Admins.

Ansonsten: Ja, das wird Freude machen.


Sent from my Nokia 6210 using Tapatalk

[the_scrat]

Im Produktiveinsatz hat ein Paketmanager nichts zu suchen.

Ist das nicht ein bisschen zu sehr Verallgemeinert? Ich sehe den Paketmanager sehr wohl (auch) auf einem Produktivsystem! Es kommt wie üblich auf den Einsatzzweck der Seite an. Nicht jeder Seite muss zwingend ein Staging System besitzen. Solche Vorstellungen sind ungefähr genauso realistisch, als dass jeder Hoster 1GB RAM (oder mehr) zur Verfügung stellt. Denn nicht jeder Seite die mit Contao umgesetzt wird, spielt im Enterprise-Bereich.

[tab]

Naja, eben weil nicht für jede produktive Installation 1 GB RAM zur Verfügung steht, wird man ja gerade bei "kleinen" Installationen so etwas wie ein Staging System. Das muss ja nicht auf dem Webspace liegen, kann ja gerne auch ein lokaler PC sein. Wobei ich über die Situation auch nicht unbedingt glücklich bin. Bisher liegen meine "Staging-Systeme" irgendwo auf einem meiner Webspaces, sei es 1&1, Uberspace oder wo auch immer. Wegen der besseren Internetanbindung. Aber die jetzt mit >1GB RAM aufzurüsten ist momentan nicht realistisch. Wird es also ein zusätzlicher PC werden müssen. Sinnvollerweise dann wohl gleich mit Linux.

[the_scrat]

tab, auch wenn du mit deiner Aussage generell recht hast, war der Vergleich anders gemeint. Ich meinte damit, dass teilweise immer so getan wird, als wäre jede Installation eine Enterprise-Lösung (in der man ein Staging-System braucht). Nicht jedes Kundenprojekt muss hochverfügbar sein. Denn auch die kleine Werkstatt / der Buchladen oder das Restaurant sind die Zielgruppen. Und wenn hier die Seite mal 5 Minuten offline ist, geht die Welt auch nicht unter :-)

Kurzum: Kanonen => Spatzen ;-)

[Honig]

Sehe ich etwas anders. Im Produktiveinsatz hat ein Paketmanager nichts zu suchen. Der gehört auf ein Stagingsystem und in die Hand eines Admins.

Ja aber ein Admin (wobei das in der Regel der Webdesigner ist) will auch nicht lange Fummeln um seinen Kram gemacht zu bekommen. Ich nehme dafür übrigens verschiedene Accounts - unprivilegierter Access für die Redakteure und Admin darf alles. Das ist sehr unkompliziert und fehlerfrei. Aber ich kann mir auch gut vorstellen, dass das bei größeren Setups ein anderes Thema sein muss (irgendwelche Spheren Typo3, Drupal oder komerzielle CMS genutzt werden).
Ich sehe es aber Prinzipiell the_scat in dem Beitrag https://community.contao.org/de/show...l=1#post413856 . Contao wird zwar für neue Zielgruppen interessant und beileibe ein Staging und eine Produktivumgebung sind ne tolle Sache aber oft halt auch einfach oversized. Heißt wohl dann in Zukunft wohlmöglich "Wordpress für kleine Webseiten und für anspruchsvolleres Contao". Ich weiß nicht ob ich das gut finde.
Aber abwarten. Trotzdem nicht vergessen - Admins sind auch bequem und Dateien shell-vim Gefummel will man in der Regel vermeiden wenn man es kann *gg*

[lucina]

Ja aber ein Admin (wobei das in der Regel der Webdesigner ist) will auch nicht lange Fummeln um seinen Kram gemacht zu bekommen. Ich nehme dafür übrigens verschiedene Accounts - unprivilegierter Access für die Redakteure und Admin darf alles. Das ist sehr unkompliziert und fehlerfrei. Aber ich kann mir auch gut vorstellen, dass das bei größeren Setups ein anderes Thema sein muss (irgendwelche Spheren Typo3, Drupal oder komerzielle CMS genutzt werden).
Ich sehe es aber Prinzipiell the_scat in dem Beitrag https://community.contao.org/de/show...l=1#post413856 . Contao wird zwar für neue Zielgruppen interessant und beileibe ein Staging und eine Produktivumgebung sind ne tolle Sache aber oft halt auch einfach oversized. Heißt wohl dann in Zukunft wohlmöglich "Wordpress für kleine Webseiten und für anspruchsvolleres Contao". Ich weiß nicht ob ich das gut finde.
Aber abwarten. Trotzdem nicht vergessen - Admins sind auch bequem und Dateien shell-vim Gefummel will man in der Regel vermeiden wenn man es kann *gg*

Wenn ich lange Klickorgien vermeiden möchte dann nehme ich die Shell. Immer. Ausnahmslos. Viel schneller, viel weniger Gefummel.

Ausserdem: https://leofeyer.de/files/slides/2016/konferenz/#18 (gegenwärtige Nutzerbasis) sowie https://leofeyer.de/files/slides/2016/konferenz/#19 (Zielgruppe).

[Honig]

Wenn ich lange Klickorgien vermeiden möchte dann nehme ich die Shell. Immer. Ausnahmslos. Viel schneller, viel weniger Gefummel.

Mag sein. Es gibt aber 2 Punkte welche ich kritisch finde: 1. manche Hoster bieten keine Shell an 2. gibt es auch User die mit der Unix Shell nichts am Hut haben (ja es gibt sogar welche die nicht mal Englisch sprechen). Diese Userbasis wird vor eine große Herausvorderung gestellt.

Ausserdem: https://leofeyer.de/files/slides/2016/konferenz/#18 (gegenwärtige Nutzerbasis) sowie https://leofeyer.de/files/slides/2016/konferenz/#19 (Zielgruppe).[/QUOTE]

Ist das wo Contao jetzt ist oder wo Contao hin will?

[Honig]

Das nennst du einfach?
https://www.youtube.com/watch?v=YJIN...=youtu.be&t=85
Sorry aber nö. Das nenn ich mal eine gediegene Klickorgie wie du so schön schreibst
Wenn ich vergleiche wie es jetzt mit der Composererweiterung geht - suchen anklicken, noch mal klicken und noch mal klicken - fertig und dann noch fix Cache aufbauen lassen.

[BugBuster]

Das kommt ja auch alles wieder, ist halt nur noch nicht fertig. Siehe die Ankündigung zum Contao-Manager.

Ist das wo Contao jetzt ist oder wo Contao hin will?

Steht doch da, Folie 18 zeigt wie Contao von anderen gesehen wird und eingesetzt wird, Folie 19 wo die Entwickler von Contao das Einsatzgebiet sehen. (und schon immer so gesehen haben)

Das die (Ex-) Homepagebaukasten Nutzer nicht mit einer Kommandozeile klarkommen geschweige denn eine Hoster nutzen wo das überhaupt geht ist die Folge davon.
War bisher ja auch nicht unbedingt nötig (aber auch damals schon von Vorteil wenn man Contao 3.5 + Composer nutzte).
Aber die Zeiten und somit die Anforderungen können sich nun auch mal ändern. Deswegen ist das ja auch keine 3.6 sondern eine 4.x Version.
Wer sich daran nicht anpassen will oder kann (ganz ohne Wertung) der muss sich halt ne Alternative suchen. Ist nun mal so im Leben.

[Honig]

Naja anpassen ist eine können ist eine Sache.
Ich schätze Contao für das unkomplizierte Bedieninterface und das man schnell Zeug zusammen bekommt und doch sehr flexibel ist.
Durch dieses ganze Gewurstel wird es einfach deutlich komplizierter - zumindest gefühlt.
Und bevor das der Contao Manager an den Start geht gehen wieder 2 Jahre ins Land. Wie dem auch sei - mal sehen wie die Landschaft am Ende des 3.5er LTS aus sieht. Vielleicht das alles dann Benutzbar ohne das Browserfenster zu oft verlassen zu müssen

[tschero]

Aber die Zeiten und somit die Anforderungen können sich nun auch mal ändern. Deswegen ist das ja auch keine 3.6 sondern eine 4.x Version.
Wer sich daran nicht anpassen will oder kann (ganz ohne Wertung) der muss sich halt ne Alternative suchen. Ist nun mal so im Leben.

Oha,

das sehe ich aber sehr kritisch.
Ohne jetzt zu viel auf Pro und Kontra eingehen zu wollen; aber wenn ich meinen Nutzerkreis nicht mitnehme wird Contao die bisher hervorragende Akzeptanz, glaube ich, sehr schnell verlieren.

Gerade das Thema mit dem "anpassen können".
Wenn z.B. ein "kleiner Webkrauter" jahrelang sehr gut mit Contao kleine Webauftritte erstellen kann, das möglicherweise ein Hobby ist und man jetzt "halt eben ´ne Alternativesuchen muss", werden das viele nicht so toll finden.
Ich glaube aber auch nicht, dass das Leo´s Plan ist. Ich denke und hoffe dass er die ganze Community mitnehmen will und wird.


Gruß
tschero

[BugBuster]

An den Anforderungen für Composer Applikationen kann auch Leo nichts ändern.
Aber wie gesagt, es wird ja versucht Mittel zu entwickeln es zumindest in der Nutzung zu vereinfachen.

[mlweb]

Obwohl mein Kundenkreis auch eher der kleine Handwerker um die Ecke mit "schwachem" Webhosting ist, sehe ich das im Prinzip genauso wie @BugBuster.

Wenn z.B. ein "kleiner Webkrauter" jahrelang sehr gut mit Contao kleine Webauftritte erstellen kann, das möglicherweise ein Hobby ist und man jetzt "halt eben ´ne Alternativesuchen muss", werden das viele nicht so toll finden.

Wenn man Abstriche auf der anderen Seite macht und die professionellen Webdesigner bzw. die Agenturen sich abwenden, weil andere CMS alle verfügbaren/modernen Möglichkeiten einsetzen, dann ist das noch viel schlimmer. Dann ist Contao in meinen Augen dem Tod geweiht.

[the_scrat]

Wenn sich Agenturen abwenden, ist es sowieso schon zu spät. Ein viel schlimmeres Vorzeichen sehe ich es, wenn sich der versierte Nutzer abwendet, weil ihm die Anforderungen zu hoch werden und die Alternativen am Markt es "genauso" einfach können.
Agenturen bleiben normalerweise bei dem System bei dem es sich am besten auskennt, unabhängig von den Anforderungen. Wenn du deiner Werkstatt um die Ecke jedoch ein Webhosting mit 1GB RAM anbietest und derjenige auch nur ein bisschen Ahnung hat, wird er das dankend ablehnen und sich halt ein Wordpress installieren.

Das Argument Webdesign zählt irgendwie auch nicht wirklich, denn Contao unterstützt den Webdesigner! nicht mehr oder weniger als andere Systeme. Schließlich ist es ein CMS (Content Manamgent System) und kein Design Mananagment System. Mit jedem System kann ich eine bestimmte Lösung erreichen.

Also ich persönlich finde nicht, dass Contao gerade einen massiven "Zulauf" erfährt, sogar ganz im Gegenteil, viele sehen sich andere Lösungen an (weil die Zukunft von Contao doch ein gewisses Risiko birgt).

(Fort)Entwicklung (egal in welcher Hinsicht) ist gut und wichtig, aber nicht um jeden Preis und vorallem muss jeder diesen Preis zahlen können! Und ich persönlich (der auch gerne in der Shell am Server arbeitet) bin z.B. nicht bereit den Preis "Composer-Shell" zu zahlen.

[Honig]

Mich lässt das Thema jetzt gerade nicht so recht in Ruhe.

Steht doch da, Folie 18 zeigt wie Contao von anderen gesehen wird und eingesetzt wird, Folie 19 wo die Entwickler von Contao das Einsatzgebiet sehen. (und schon immer so gesehen haben)

Beim Lesen dieser Zeile bin ich doch etwas überrascht. Wenn die Entwickler das Einsatzgebiet immer schon teilweise im Enterprisebereich gesehen haben, dann kann ich mir nicht so recht erklären warum Contao bis 3.5 zu dem geworden ist was ist geworden ist. Das System ist wirklich nice - man kommt schnell zum Ziel, die Nutzerführung ist eindeutig und klar und man hat unheimlich schnell eine Standard 0815 Webseite zusammen gebastelt wie man sie sonst mit Wordpress erstellen würde. Das passt nicht so ganz dazu, dass die Entwickler immer schon in Richtung Enterprise wollten weil da Features fehlen die schon lange hätten eingebaut werden müssen (z.B. Redaktionsworkflow, Analysefähigkeiten jenseits von Analytics und feinere Rechtesteuerung etc pp).

Das es irgendwo weiter gehen muss mit der Entwicklung ist klar und das als Basis ein Application Framework wie Symphonie genutzt wird ist auch sehr zu begrüßen. Das aber ein integraler Bestandteil von Contao mehr oder weniger geopfert wird, nämlich das einfache Installieren von Erweiterungen ist schon komisch. Zum Composer hin zu wechseln war für viele schon ein großer aber wichtiger Schritt (seien wir ehrlich das ER war schon recht cool und bequem) aber jetzt das alles nur noch von der Console aus zu machen oder später mit dem Contao Manager (der ohnehin erst in 2 Jahren oder später stabil sein wird) ist komisch. Logisch wäre eine richtig feste Integration des Composer gewesen. Die hatte ich eigentlich auch erwartet. Das er nicht kommt oder nur über Umwege kommt ist kein glücklich machender Umstand.
Der nächste Punkt ist übrigens das wenn man Contao 4.2 installiert erst mal keinen Unterschied zu 3.5 merkt außer das es komplizierter geworden ist. Das ist keine Sache die für Freude auf der Userbasis sorgt sondern Akzeptanzprobleme hervor ruft. Es ist sicher immer schwierig neue Features akzeptiert zu bekommen (siehe Composer) aber es mit der 4er und dem was ich jetzt in den Posts dieses Threads entnahm gibt es einen starken Richtungswechsel und wie ich richtig vermute sorgt das nur bei manchen für Jubel.

[mlweb]

Wenn du deiner Werkstatt um die Ecke jedoch ein Webhosting mit 1GB RAM anbietest und derjenige auch nur ein bisschen Ahnung hat, wird er das dankend ablehnen und sich halt ein Wordpress installieren.

Vielleicht bin ich etwas blauäugiger oder aber auch gelassener. Mein kleiner Handwerker um die Ecke ist im Moment mit Contao 3.5 und der Erweiterungsverwaltung gut bedient. Dazu reicht eines kleines Hostingpaket. Der Security-Report geht noch bis Juni 2019. In den drei Jahren wird sich noch sehr viel tun - sowohl bei Contao als auch bei den Webhostern. Außerdem sind die benötigten Erweiterungen bei diesen Kunden auch eher sehr überschaubar und wären m.E. auch ohne weiteres manuell zu installieren, wenn es gar nicht anders gehen würde.

Brauche ich für die Umsetzung eines Projektes beispielsweise so mächtige Erweiterungen wie [metamodels], dann ist mit Sicherheit auch ein ordentliches Webhosting drin.

weil die Zukunft von Contao doch ein gewisses Risiko birgt

Das ist doch bei anderen Systemen nicht anders. Vor nicht allzulanger Zeit haben sich TYPO3 und TYPO3 Neos "getrennt".
Schon etwas länger her (ca. 2-3 Jahre), da haben einige entscheidende Köpfe sich von modx abgewendet und haben processwire für sich entdeckt.

[BugBuster]

Das er nicht kommt oder nur über Umwege kommt ist kein glücklich machender Umstand.

Das macht uns alle nicht glücklich. Aber so ist das nun mal wenn in einem kleinem Open Source Projekt 1-2 Entwickler wegbrechen.
Dann verzögert sich eben einiges. Contao hat die Manpower nicht um sowas aufzufangen. Das war übrigens auch ein Grund, wie hier schon öfters von mir geschrieben, das man sich ein Framework sucht als "Unterbau" (Symfony) wo die Power eben weltweit da ist.
Aber damit das fruchtet muss man eben erst mal alles dahin portieren.

[the_scrat]

Ich glaube das Hauptproblem ist nicht Contao 4, die Vorgehensweise erinnert mich an Microsoft mit Windows 8. Dort wurde auch alles umgebaut/modernisiert (natürlich haben die etwas mehr Menpower, egal).
Allerdings wird suggeriert, dass Contao 4 "einsatzbereit" ist. Seit Monaten wird Contao 4 auf der Webseite angeboten. Personen die sich zum ersten mal mit Contao beschäftigen laden sich natürlich erstmal die Version mit den "neuesten Funktionen" herrunter und scheitern (an diversen Dingen, Installation, Composer, fehlende Erweiterungen (die Webseite sagt ja indirekt aus, es gäbe 1897 Erweiterungen - auf für Contao 4)).

Genau wie MS "Windows 8" halbfertig auf den Markt geworfen hat, wird Contao 4 ("halbfertig" - aus Sicht eines Contao3 Users) angeboten.
Und dass so eine riesen Portierung dauert ist auch verständlich, gerade mit dem Core-Entwicklerteam. Doch warum wird so ein großes Projekt nicht erst der Öffentlichkeit vorgestellt, wenn es auch für die breite Masse nutzbar ist und bis dahin als Entwicklerversion gekennzeichnet? Und die breite Masse sitzt nunmal nicht vor der Shell und installiert sich eine Webseite und Erweiterungen. Die breite Masse weiß was FTP ist und wie man eine Datei editiert! Und auch wenn die Zielgruppe lt. Folie irgendwo im CMS/Enterprise Bereich liegt, heißt das nicht, dass nun jeder, alles mit einer Shell bedienen muss.

[Spooky]

Effektives arbeiten mit Symfony bedeutet nun mal Composer und Shell.

Unabhängig von Contao.

[the_scrat]

Das mag sein, nur ist die 1. Priorität hier nicht Symfony, sondern Contao. Symfony ist aktuell einfach der "fade Beigeschmack" von Contao womit sich alle beschäftigen müssen.

[MacKP]

Ich hab das Gefühl, das ihr hier noch einiges vermischt.
Für Redakteure soll das System immer noch so einfach zu nutzen sein wie bisher.
Für den/die Ersteller(in) soll Contao alles bieten, was ein gutes bis sehr gutes CMS so bieten muss/kann. Das siedelt sich dann auch in Richtung CMS bis Enterprise CMS an. Das ist auch gut so. Klar sind die Anforderungen dabei höher, als bei einem Homepage-Baukasten. Aber mal ernsthaft. Diejenigen, die einen Baukasten brauchen, sollen den auch benutzen. Das ist dann günstig und passt.
Wenn man aber ein vollwertiges CMS braucht, dann ist Contao eine Variante.

Wenn Ihr euch wegen Composer umschauen wollt/müsst, dann habt ihr Glück: Andere setzen genau so auf Composer. Die könnt ihr dann direkt weg lassen und ihr habt nicht mehr so viel Auswahl ;-)

Vergesst bitte nicht, das auch an Lösungen gearbeitet wird, das Composer einfacher zu bedienen ist. Das braucht allerdings eine Weile. Davon ab ist Contao 4 nutzbar. Das hat an sich auch nichts mit der Erweiterungsverwaltung zu tun (das sind eben zwei verschiedene Dinge). Und auch dort kann man (per Konsole relativ easy) schon die ein oder andere Erweiterung installieren, wenn man das braucht. Muss man aber alles nicht, es ist vollkommen in Ordnung, wenn man noch bei Contao 3.5 bleibt. Und auch ohne Composer nutzt.. das geht auch noch... Ich weiß also gar nicht, warum ihr hier teilweise Stresspickel bekommt.

Viele Grüße

[the_scrat]

Naja, das Konzept 'Contao' steht/fällt mit den Erweiterungen. "Contao ist nutzbar". Das mag sein. Ein Windows Phone ist auch "nutzbar" wenn man keine weiteren Ansprüche hat. Nur die Erweiterungen von Contao sind nunmal das Herzstück (so sehe ich es jedenfalls persönlich).
Dass ein reiner Redakteur keinen Unterschied mitbekommt, ist sicherlich klar. Doch in der Praxis ist es nunmal so, dass ein Ein-Mann-Betrieb für 'Alles' zuständig ist und weder Zeit noch Bock hat sich mit Symfony oder Composer zu beschäftigen. Contao ist laut Umfrage (Platz 3: Freiberufler / Platz 4: Agenturen). Aber 'Agentur' bedeutet nicht automatisch, dass es sich dabei um mehrere Personen bzw. im speziellen um Administratoren/Entwickler handeln muss. Schon garnicht, dass dort eine Shell im Einsatz ist. Und wer einmal per ER2 oder auch mit dem Composer-Client (sofern er nicht wg. Speichermangels versagt) eine Erweiterung innerhalb weniger Sekunden installiert hat, wird im Traum nicht daran denken irgendwelchen Zeilen in einer AppKernel einzupflegen.

Darum geht es doch hier im Thread "Conto 4 - wo der der Composer[Client]"?
Das ist ja nicht der erste Thread in dem sich Leute fragen, warum das "aktuelle" System auf der Webseite, also das mit den "Neuesten Funktionen".... sich zwar installieren aber nicht einfach erweitern lässt uvm.

Wäre es nicht sinnvoller Contao4 gezielt in der Symfony-Community vorzustellen um hier ggf. das Coreteam zu vergrößern? Letztendlich wird die Composerlösung eh in der Cloud landen um dort die Abhängigkeiten zu prüfen, denn selbst bei wenigen Erweiterungen sind die Anforderungen bei hohen (Hardware-)Standards kaum zu erfüllen.

[FloB]

Wenn ich lange Klickorgien vermeiden möchte dann nehme ich die Shell. Immer. Ausnahmslos. Viel schneller, viel weniger Gefummel.

Finde die Aussage ehrlich gesagt etwas ignorant. Bin auch Fan der Kommandozeile und administriere meine Root-Server seit Jahren ausschließlich über die Shell mit viel Handarbeit, und das als Nebenjob – weil's mir Spaß macht. Dass bei Contao 4 für's Paket-Management aber auf die Kommandozeile zurückgegriffen werden muss, halte ich mindestens für unglücklich. Eine Contao-Version ohne den Erweiterungs-Manager, der (für mich zumindest) jahrelang zu den wichtigsten und besten Features zählt, als fertig zu bezeichnen, ist meines Erachtens humbug. Trotz seiner Fehler (die für mich nie großartig zum Tragen kamen) war/ist er einfach bequem, und diese Bequemlichkeit (in Kombination mit den Möglichkeiten) ist das, was ein gutes CMS von einem schlechten unterscheidet. Ohne diese Bequemlichkeit kann ich auch gleich zu einem Static Site Generator und bei Bedarf ein paar zusammengewürfelte Scripts umsteigen (gibt's ja inzwischen auch in hoher Qualität wie Sand am Meer).

Ja, der Manager kommt, und das ist auch gut so (für meinen Geschmack viel zu spät, aber was soll's – ist schließlich auch eine schwierige Aufgabe). Der Manager löst aber auch z. B. das Resourcenproblem nicht. Das ist ja das eigentliche Unding. Ich habe (im Gegensatz zu vielen anderen langjährigen Contao-Administratoren) kein Problem alles so zu konfigurieren, dass die Prozesse ausreichend Resourcen haben, aber es handelt sich schließlich immernoch "nur" um ein CMS (Stichwort "Bequemlichkeit") und Paket-Manager. Das haben Andere in unoptimierteren Sprachen als PHP schon viel besser lösen können. Herrgott, meine Orbit-Analysen von Sichtfaktoren in Satellitenkonstellationen brauchen nur ein Bruchteil der Ressourcen trotz integriertem SAT-Solver und Python. Die Composer-Entwickler scheinen sich aber auch lieber ein Beispiel an Kernfusion und Marsmission genommen zu haben und versprechen seit Immer eine "baldige" Lösung, anstatt gescheites Mentoring für willige Entwickler anzubieten … so viel verschenktes Potenzial, grade wenn bei allen Beitiligten die Zeit knapp bemessen ist. Und einige Contao-Entwickler verschieben die Verwantwortung lieber auf die Composer-Entwickler, anstatt Lösungen zu bieten oder zumindest Mal Konzepte zu erarbeiten. Vielleicht habe ich da auch was übersehen, zumindest aber kriege ich nicht mit, dass da mit großem Elan daran gearbeitet wird, das Problem zu lösen – vielleicht mal ein bisschen mehr Pläne in einem Wiki/regelmäßigen Posts/… skizzieren anstatt nur in den Mumble-Calls oder anderen halb-privaten Wegen alles auszutragen, bei denen einfach viele aus Zeitgründen nicht teilnehmen können? Muss ja nix Dolles sein, finde die knappen MM-News jeden Monat zum Beispiel großartig und völlig ausreichend, da kann man am Ball bleiben ohne viel Zeit, die man nicht hat, in Eigenrecherche zu verbrennen.

Ausserdem: https://leofeyer.de/files/slides/2016/konferenz/#18 (gegenwärtige Nutzerbasis) sowie https://leofeyer.de/files/slides/2016/konferenz/#19 (Zielgruppe).

Noch so ein kritischer Punkt. Gewünschte Zielgruppe in allen Ehren, wer aber leichtfertig Potenzial aus der Nutzerbasis verschenkt, schießt sich dabei selber ins Knie. Versteht mich nicht falsch, niemand will ein Homepage-Baukasten-System. Man sollte sich aber auch nicht zu sehr davon abgrenzen, denn dieser Markt wächst und greift den CMS-Markt direkt an. Also warum nicht die "obere" Zielgruppe dieser Systeme gezielt mit einigen Features ansprechen, die Homepage-Baukästen nicht oder nur unter hohem Aufwand/Kosten anbieten?

Im Übrigen finde ich es auch nicht sehr freundlich, gleich alle Composer- bzw. Contao-4-Kritiker (beachte, Kritiker != Gegner, auch wenn das in den aktuellen, selbst-ernannten "bürgerlichen, kritischen" Bewegungen anders gelebt wird) in die Homepage-Baukasten-Ecke oder dergleichen zu stellen. Hier wird die (berechtigte) Bitte um Verständnis seitens der Core-Entwickler z.T. derart überzogen und verzerrt an die Kritiker/Bedenkenträger herangebracht, dass sich damit einige ja regelrecht angegriffen fühlen müssen. Bin etwas überrascht, wie einigermaßen zivil die Diskussion hier zur Zeit abläuft – scheint sich doch was getan zu haben in den letzten Monaten .

Aber 'Agentur' bedeutet nicht automatisch, dass es sich dabei um mehrere Personen bzw. im speziellen um Administratoren/Entwickler handeln muss. Schon garnicht, dass dort eine Shell im Einsatz ist. Und wer einmal per ER2 oder auch mit dem Composer-Client (sofern er nicht wg. Speichermangels versagt) eine Erweiterung innerhalb weniger Sekunden installiert hat, wird im Traum nicht daran denken irgendwelchen Zeilen in einer AppKernel einzupflegen.

Amen.

[BugBuster]

Nur zur Sicherheit erwähnt, es ist die composer.phar die so viel RAM braucht, also kein Tool was von Contao kommt.
Daher kann Contao wenig dran drehen.

...wird im Traum nicht daran denken irgendwelchen Zeilen in einer AppKernel einzupflegen.

Eine Agentur, auch wenn diese nur aus einer Person besteht, die schon einmal ein reines Symfony Projekt hatte, wird genau das schon mal getan haben.
Das ist quasi eine Notwendigkeit in Symfony.

Und mal ne ganz andere Sichtweise: Selbst wenn es den Contao-Manager schon geben würde: Und dann? Es existieren nur ne Handvoll Erweiterungen die für Contao 4 freigegeben sind. Da kommt man selbst dann nicht weit.
Hier sind die Entwickler gefragt, da schließe ich mich ein, ihre Erweiterungen kompatibel zu machen, im besten Fall ist das nur eine Anpassung in der composer.json. (plus einer Anleitung was man händisch in die Appkernel.php eintragen muss, vorerst. Beispiel hier)

Drücken wir die Daumen das alle Beteiligten daran genug Zeit und Lust haben, dass der erste Wurf zum Contao Camp bereit steht.
Denn nur so haben wir Entwickler und die mutigen Tester genug Zeit etwas beizutragen, bis zur Contao 4.4 LTS eine stabile und benutzerfreundliche Version zu erhalten.

[tab]

Ich denke schon, dass auch Contao bzw die Erweiterungsentwickler schon einiges dran drehen können. Composer braucht ja auch (allerdings nicht nur) so viel RAM, weil es soviele Kombinationen von Erweiterungen gibt. Vielleicht kann man ja mit fixen Bundles einiges abfedern. Gerade bei Erweiterungen, die viele Abhängigkeiten haben. Sicher ist das kein Allheilmittel. Aber es könnteeventuell dazu beitragen, in vielen Fällen Ressourcen einzusparen. Wenn es dann durch die Bundles dazu kommt, dass keine Lösung gefunden werden kann (weil nur Bundles als Ganzes betrachtet werden und da eventuell eine Version einer Erweiterung drin ist, die eine andere Erweiterung nicht nutzen kann), obwohl es eigentlich eine gäbe, wenn man alle Erweiterungen einzeln betrachtet. In dem Fall kann man dann immer noch den Umweg über den dicken Staging-Server oder PC gehen. Aber in vielen Fällen könnte man sich das eventuell sparen.

Wenn ich z.B. "nur" Metamodels installieren will, dann ist das mit einem fertigen Bundle doch ein Klacks. Und wenn ich dann einstellen kann, dass ich bei Updates nur neuere Versionen des Bundles suchen will und keine Updates der einzelnen, enthaltenen Erweiterungen, dann hätte Composer wohl nicht viel zu tun. Wenn ich mit der Einstellung dann mal keine Lösung bekomme, dann muss ich sie eben rausnehmen und den Umweg nehmen. Aber erst dann und nicht schon gleich von Anfang an.

[the_scrat]

Eine Agentur, auch wenn diese nur aus einer Person besteht, die schon einmal ein reines Symfony Projekt hatte, wird genau das schon mal getan haben.
Das ist quasi eine Notwendigkeit in Symfony.

Das mag sein, nur sind wir hier weiterhin bei Contao und nicht Symfony. Ich würde sogar mal vermuten, dass ein Großteil der Agenturen/Nutzerbasis von Contao bis auf den Namen Symfony noch nie etwas damit zu tun hatte.
Wenn Contao Symfony als Framework nutzt, alles gut, solange man dies im Hintergrund macht, ohne den Nutzer damit zu belästigen irgendwelche kruden Dinge zu machen.

Shopware ist z.B. ein exzellentes Beispiel, dass es auch anders geht - mit Symfony im Hintergrund. Sauberer Installer, integrierter Plugin(Manager). Nix mit Shell, Composer oder irgendwelchen 1GB Arbeitsspeicher-Problemen. 256MB ist die Anforderung.

Und mal ne ganz andere Sichtweise: Selbst wenn es den Contao-Manager schon geben würde: Und dann? Es existieren nur ne Handvoll Erweiterungen die für Contao 4 freigegeben sind. Da kommt man selbst dann nicht weit.
Hier sind die Entwickler gefragt, da schließe ich mich ein, ihre Erweiterungen kompatibel zu machen, im besten Fall ist das nur eine Anpassung in der composer.json. (plus einer Anleitung was man händisch in die Appkernel.php eintragen muss, vorerst. Beispiel hier)

Der Contao-Manager ist die Grundvoraussetzung, dass die Entwickler ihre Erweiterung aktualisieren. Warum soll ein Entwickler seine Erweiterung für ein System kompatibel machen, welches er selbst nichtmal nutzt? Das gleiche Problem hatte Microsoft doch ebenfalls mit ihrem AppStore (hier stehen sogar zig tausend Entwickler dahinter). Aber niemand hat es interessiert, weil niemand wirkliches Vertrauen ins System hatte = Ein leerer AppStore. Folglich: Erst wenn das System passt, wird es Erweiterungen geben. Das war bei Contao 3 so und wird auch bei Contao 4 so sein.

[lucina]

Das mag sein, nur sind wir hier weiterhin bei Contao und nicht Symfony. Ich würde sogar mal vermuten, dass ein Großteil der Agenturen/Nutzerbasis von Contao bis auf den Namen Symfony noch nie etwas damit zu tun hatte.
Wenn Contao Symfony als Framework nutzt, alles gut, solange man dies im Hintergrund macht, ohne den Nutzer damit zu belästigen irgendwelche kruden Dinge zu machen.

Wenn ein Teil der Agenturen keine Ahnung hat, dann sollen sie es - mit Verlaub - einfach lassen. Ich bin mir aber relativ sicher, dass dem nicht so ist. Frontendentwicklung hat in den letzten Jahren viele technische Fortschritte gesehen. Niemand, der sich nicht weiterbildet und auf dem Stand des PHP-Kurses von 1999 stehen geblieben ist wird dabei noch lange bestehen. Technik entwickelt sich, und darüber sind wir alle sehr froh.

Es ist ja nicht nur das Beispiel des Frameworks und der Paketverwaltung. Willst Du im Jahre 2016 etwa ernsthaft noch CSS für drülfzigtausend Geräte und Screengrössen von Hand schreiben und warten? Möchtest Du im Jahr 2016 so etwas immer noch per Einzelklick in dem obsoleten CSS-Coremodul zusammentackern? Wann möchtest Du fertig werden, und bist Du wirklich scharf auf ein Karpaltunnelsyndrom, das Du Dir bei der Klickerei zuziehst?

Es sind viele Dinge, die sich da weiterentwickeln. Du brauchst auf Sicht solche Dinge wie funktionierendes Paketmanagement, Präprozessoren, lokale Arbeitsumgebungen mit herzzerreissend fetten Ressourcen, automatisiertem Deployment und was nicht noch alles. Es hilft absolut nichts, jetzt zu sagen, dass alles bleibt wie es war. Agenturen vom Typ 'Ludger Winter' muss ich nun wirklich nicht mitnehmen.

Shopware ist z.B. ein exzellentes Beispiel, dass es auch anders geht - mit Symfony im Hintergrund. Sauberer Installer, integrierter Plugin(Manager). Nix mit Shell, Composer oder irgendwelchen 1GB Arbeitsspeicher-Problemen. 256MB ist die Anforderung.

Das ist bei Contao nicht anders. Systeme, auf denen nichts entwickelt wird, keine experimentellen Extensions mit 'DEV'-Status vorhanden sind und einfach nur 'normale' Seiten ausgeliefert werden laufen bei mir in diversen Systemen ab 128 MB RAM. Mit der composerbasierten Erweiterungsverwaltung.

Aber es gibt ja auch Nutzer, die heulen, weil sie bei einem Hoster sind, der ihnen um die 40 MB Arbeitsspeicher zuteilt. Sag mir, wie ich die mitnehmen soll. Ich seh nicht, wie das gehen soll, ohne am Ende komplett von den Entwicklungen abgehängt zu werden.

Der Contao-Manager ist die Grundvoraussetzung, dass die Entwickler ihre Erweiterung aktualisieren. Warum soll ein Entwickler seine Erweiterung für ein System kompatibel machen, welches er selbst nichtmal nutzt? Das gleiche Problem hatte Microsoft doch ebenfalls mit ihrem AppStore (hier stehen sogar zig tausend Entwickler dahinter). Aber niemand hat es interessiert, weil niemand wirkliches Vertrauen ins System hatte = Ein leerer AppStore. Folglich: Erst wenn das System passt, wird es Erweiterungen geben. Das war bei Contao 3 so und wird auch bei Contao 4 so sein.

Den Microsoft-Vergleich hast du ja schon an anderer Stelle gebracht, und er ist hier immer noch falsch. Das meiste, was an Erweiterungen unter Contao 3 läuft, das läuft auch unter Contao 4. Die Anpassungen sind nicht so schrecklich - im optimalen Fall ist das eine Ziffer in der verlangten Versionsnummer.

Im Gegenteil, solche Kommentare wie Deiner machen bei mir (und sicher auch bei anderen) massive Verunsicherungsgefühle. Wenn ich mir aussuche, mit welchem System ich in den nächsten fünf Jahren arbeiten möchte, dann tue ich das gewiss nicht wegen eines gefüllten App-Stores, sondern weil ich sicher sein muss, dass ich auch dann noch zeitgemässe Funktionen bauen kann und nicht auf einem Berg an Technik aus dem letzten Jahrtausend sitze.

Im Gegensatz zu Dir habe ich Vertrauen in Contao, und ich weiss, dass ich mir da mit vielen anderen sehr einig bin. Ich sehe auch, dass wir bis zur Contao 4-LTS noch einen Weg zu gehen haben, und niemand streitet das ab. Der Zeitplan ist allerdings mehr als grosszügig, und Du kannst vermutlich verheerend lange auf Contao 3.5 bleiben. Schaun wir doch mal, wo andere Systeme im Jahr 2018 stehen.

[tschero]

Liebe lucina,

mal in aller kürze, grob zu Deinem Beitrag.

Ich denke es geht insgesamt nicht darum, Contao in der Entwicklung einzuschränken oder darüber zu meckern das Contao noch immer nicht fertig ist mit Problemen rund um Composer usw.

Ich könnte mir vorstellen, dass die "Ein-Mann-Agentur" eine Weiterbildung zu entsprechenden Themen in Betracht zieht, wenn es absehbar ist, dass sich diese Technik nicht noch ständig ändert.
Warum?

Ganz einfach, weil in der Zeit Abends ab 20 Uhr wenn die Kinder im Bett liegen und teilweise am Wochenende die paar kleinen Kundenwünche erledigt werden müssen und die Zeit zur Weiterbildung einfach schlichtweg nicht da ist, selbst wenn 'Ludger Winter' sich weiterbilden möchte.

<Ironie>
OK dann nehme ich diese kleinen Wichte eben nicht mit, gut. Gibt ja große Agenturen die für deutlich mehr Geld den Kunden überregional betreuen.
Der Kunde legt Wert auf regionale Betreuung? Der Webdesigner ist auch mal für ein persönliches Gespräch vor Ort? Alles Quatsch, braucht man nicht.
Natürlich.

'Ludger Winter' kann die Bude zumachen und soll sich gefälligst ein neues Hobby suchen und in den Garten gehen.
Die Community sind sowieso nur die elitären Programmierprofis welche sich nur mit "0" und "1" unterhalten.
</Ironie>

Sorry wenn ich mich hier gerade aufrege und ich möchte niemand zu nahe treten.


Aber das hier liebe lucina:

Wenn ein Teil der Agenturen keine Ahnung hat, dann sollen sie es - mit Verlaub - einfach lassen.

geht überhaupt nicht.
Das ist aus meiner Sicht ein völlig unangebrachtes, überhebliches und Community zerstörendes Verhalten welches ich persönlich absolut nicht teilen möchte.

Man darf nicht stehenbleiben, da bin ich absolut bei Dir und man (ja auch 'Ludger Winter') MUSS sich weiterbilden.

Aber als Community und als Entwickler eines CMS (LEO) lasse ich bewusst, SO WIE DU ES SCHREIBST, keinen auf der Strecke.


Noch mal SORRY für´s Dampfablassen, aber das musste an dieser Stelle sein.



Viele Grüße,

tschero

[BugBuster]

Aber als Community und als Entwickler eines CMS (LEO) lasse ich bewusst, SO WIE DU ES SCHREIBST, keinen auf der Strecke.

Nicht gewollt, aber bewusst schon. Durch die erhöhten Anforderungen, die nicht nur von Contao kommen, fallen halt einige raus, wenn diese keine Chance haben sich ebenfalls zu verbessern.
Das ist nun mal so im Leben.

Der Contao-Manager ist die Grundvoraussetzung, dass die Entwickler ihre Erweiterung aktualisieren. Warum soll ein Entwickler seine Erweiterung für ein System kompatibel machen, welches er selbst nichtmal nutzt?

Naja, nicht unbedingt. Wenn ich Erweiterungen entwickle, dann auf meinem lokalem System, daher kann ich durch aus auch mal ne Contao 4.2 installieren.
Gerade wer jetzt eine neue für Contao 3.5 anfangen würde, kann schon einiges tun um es für Contao 4.2 leichter zu haben.
Wie Lucina schon schrieb, wer es sich einfach machen will und alles einfach in system/modules/ belässt, hat nicht viel zu tun.
Ich jedoch fange an die Erweiterungen bereits nach dem Resources/contao/.. Prinzip anzulegen für Contao 4. Dann habe ich es später leichter irgendwann man ein echtes Contao-Bundle draus zu machen.
Aber das braucht Zeit. Zwei Erweiterungen habe ich, bleiben noch geschätze 20

Die einzige Sache wo ich sehe, dass einige Entwickler jetzt ins straucheln kommen ist GitHub/Bitucket/... -> Packagist.org. Denn das nutzen noch nicht alle, was aber derzeit nötig ist für eine Installation über Composer. (ja, es geht auch über eigene Git Server, aber dazu braucht man wieder die gute alte Konsole)
Denen kann aber geholfen werden. Der Berlin Contao Stammtisch zum Beispiel macht demnächst ein Git/GitHub Workshop. Mal sehen ob dann einige umschwenken.

Ich kann nur allen Entwicklern empfehlen, nutzt die Zeit und beschäftigt Euch mit der neuen Materie. Wenn dann der Contao Manager da ist, sollten im besten Fall die Erweiterungen auch so weit sein.
Das wär doch mal was.

[tschero]

Nicht gewollt, aber bewusst schon. Durch die erhöhten Anforderungen, die nicht nur von Contao kommen, fallen halt einige raus, wenn diese keine Chance haben sich ebenfalls zu verbessern.
Das ist nun mal so im Leben.

Ja das kennt man ja leider auch aus anderen Bereichen, da geb ich Dir Recht.

Wenn aber andere Systeme die weitläufig schon besprochenen Problem auch irgendwie lösen können, sollte dann nicht auch Contao mit dem neuen Framework und Composer so Benutzerfreundlich gestaltet werden ,dass auch der einfache kleine Webdesigner weitermachen kann?

Es gibt mit Sicherheit Lösungen, man arbeitet ja auch schon dran und wenn´s länger dauert istdas nicht schlimm. Sollen sich die Entwickler gerne so viel Zeit nehmen wie sie brauchen, gerade weil diese auch sehr oft in der Freizeit die Entwicklung vorantreiben.

Letztlich sind es auch die "Kleinen" welche mithelfen Fragen zu klären, oder solche Fragen stellen die auch anderen helfen.
Das Forum hier ist ja voll davon und das ist auch gut so.

Ich sehe es halt nicht unbedingt so "Streng" - friss oder stirb -


Gruß
tschero

[lucina]

Wenn aber andere Systeme die weitläufig schon besprochenen Problem auch irgendwie lösen können, sollte dann nicht auch Contao mit dem neuen Framework und Composer so Benutzerfreundlich gestaltet werden ,dass auch der einfache kleine Webdesigner weitermachen kann?

Was meinst Du denn woran gearbeitet wird? Der Manager wird das alles abbilden. Er wird nicht davon entbinden, sich mit technischen Details auseinanderzusetzen.

Es gibt mit Sicherheit Lösungen, man arbeitet ja auch schon dran und wenn´s länger dauert istdas nicht schlimm. Sollen sich die Entwickler gerne so viel Zeit nehmen wie sie brauchen, gerade weil diese auch sehr oft in der Freizeit die Entwicklung vorantreiben.

Letztlich sind es auch die "Kleinen" welche mithelfen Fragen zu klären, oder solche Fragen stellen die auch anderen helfen.
Das Forum hier ist ja voll davon und das ist auch gut so.

Was hier teilweise im Forum an Ansprüchen gestellt wird zielt allerdings nicht auf das Thema 'Klein' ab. Sorry, aber wenn mir jemand schreibt, dass er den Full Monty einsetzen möchte, aber gleichzeitig jammert, dass sein Shared Hosting in die Knie geht, dann habe ich dafür einfach mal null Verständnis.

Wie bereits ausgeführt funktioniert das alles bereits jetzt mit C3 für kleine Webprojekte, anständiges Hosting (das ohne die Fernsehwerbung ...) mal vorausgesetzt. Das alles wird aber unreflektiert vermischt - so lese ich beispielsweise Bezüge auf 'Composer' in Kombination mit Fehlermeldungen, die damit absolut nichts zu tun haben, angereichert um Sätze wie 'Das nervt', 'Das ist Kacke' oder 'Alles Scheisse'. Was kann ein Paketmanager dafür, wenn das, was er installiert, technische Grütze ist? Was kann ein Paketmanager dafür, dass ein Webhosting für die Installation von MetaModels und Isotope zu klein ist? Früher mit den Databecker-Editoren ging das doch auch!!! EINS!!! ELF!!!!!!

Ich kapiere es nicht. Und leider trifft das zur Zeit auf relativ viele Themen hier zu.

Contao hatte auch bisher Fähigkeiten bis in den Enterprise-Bereich. Davon haben hier alle profitiert, auch die, die sich jetzt darüber beschweren.

Was erwartet Ihr eigentlich? Hier sind Menschen, die Contao technisch nach vorne bringen - nicht nur weil sie davon leben, sondern auch, weil sie Open Source für etwas sinnvolles halten. Es sind nicht ausschliesslich die 'Kleinen', die Contao am Leben halten, sondern diejenigen, die mit Contao Erträge erwirtschaften, die sie der Community zurückgeben. Durch den Core, Extension-Code, Tutorials, Wikiartikel, Moderation, Videokurse, Bücher und viel mehr.

Wenn man jetzt sagt 'Ist doch alles prima so wie es ist', dann sägt man sich den Ast ab, auf dem man sitzt.

Ich sehe es halt nicht unbedingt so "Streng" - friss oder stirb -


Gruß
tschero

Es wird - ob man es nun bedauert oder nicht - anspruchsvoller. Ist eben so.

[the_scrat]

Die einzige Sache wo ich sehe, dass einige Entwickler jetzt ins straucheln kommen ist GitHub/Bitucket/... -> Packagist.org. Denn das nutzen noch nicht alle, was aber derzeit nötig ist für eine Installation über Composer. (ja, es geht auch über eigene Git Server, aber dazu braucht man wieder die gute alte Konsole)
Denen kann aber geholfen werden. Der Berlin Contao Stammtisch zum Beispiel macht demnächst ein Git/GitHub Workshop. Mal sehen ob dann einige umschwenken.

Diese Aussage zeigt doch deutlich wo die "Praxis" ist. Die Praxis weiß noch nichtmal wie Git/Github funktioniert, soll sich aber mit Symfony beschäftigen!

Ich kann nur allen Entwicklern empfehlen, nutzt die Zeit und beschäftigt Euch mit der neuen Materie. Wenn dann der Contao Manager da ist, sollten im besten Fall die Erweiterungen auch so weit sein.

Das ist leichter gesagt als getan. Nicht jeder Entwickler hat eben die Muse blind jeder Neuerung hinterherzulaufen.

Ich persönlich finde das Verhalten einiger hier als blinden Enthusiasmus, ohne kritisch zu hinterfragen. Contao 4 "kann" das neue "iPhone" werden, kann aber auch das neue "Betamax" sein. Entscheiden wird es sicherlich nicht die Technik, sondern die Zielgruppe, Nutzerbasis UND die vorallem die Erweiterungs(entwickler). Auch wenn hier 100x gesagt wird, Contao 4 ist nutzbar, so mag das technisch stimmen, aber praktisch nicht. Der BER ist in der Theorie auch nutzbar, in der Praxis nicht.
Und auch der Hinweis, dass man doch "nur" XY machen muss (Shell, Composer, AppKernel...) ist ungefähr so als würde man 2016 verlangen sein Auto mit einer Kurbel zu starten (ist ja nur eine Kurbel).

@lucina
Nicht, dass du mich falsch verstehst. Ich finde Contao super und opfere gerne meine Zeit auch hier im Forum. Doch sehe ich es in letzter Zeit sehr kritisch, dass die Community von Contao doch nur aus einem relativ kleinen Kreis besteht (und auch nicht übermäßig wächst). Sieht man sich andere Systeme an steht hier eine wesentlich breitere Community und Entwicklergemeinschaft dahinter. Die Frage ist warum? Liegt es vielleicht daran, dass andere Systeme ihre CMS nicht an die Spitze des Technischen treiben? Mehr Wert auf eine Usability legen oder vielleicht einfach nicht irgendwelchen halbfertigen Tools in die Community werfen (Composerclient). Ich persönlich finde Composerclient eine sehr gute Sache im Vergleich zum lächerlichen ER2 (aus Entwicklersicht). Aus Usersicht ist der Composerclient eine (teilweise) Katastrophe (selbst die erfahrenste Agentur muss wissen wie die Pakete heißen).

[BugBuster]

Diese Aussage zeigt doch deutlich wo die "Praxis" ist. Die Praxis weiß noch nichtmal wie Git/Github funktioniert, soll sich aber mit Symfony beschäftigen!

Ja, aber eins nach dem anderem. Manche tun so, als wenn es Composer erst seit Contao 4.0 gäbe. Dem ist nunmal nicht so.
Seit Jahren macht Leo & Co. auf den Konferenzen Werbung für Composer. Auch Entwickler Vorträge gab es. Es wäre also genug Zeit gewesen sich damit zu beschäftigen. Dann hätte man jetzt "nur" noch sich mit Symfony zu beschäftigen. Ich habe auch bestimmt ein Jahr gebraucht um von ER2 und ohne lokale Versionsverwaltung auf Git und Github umzusteigen. Mach das ja auch nur als Hobby.

Aufschieberitis ist das Problem. "Läuft doch, wozu anpassen"

Aber ehrlich, ich muss über Symfony nicht viel wissen, um meine Erweiterung für Contao 4 kompatibel zu machen, eigendlich gar nichts. Ich mache das was in den Folien der Konferenzen bzw, in den Contao News mal beschrieben wurde und das wars auch schon. Wie gesagt, oft reichen 2 Zeilen Anpassung in der composer.json meiner Erweiterung.
Wer tiefer gehen will, echte Bundles erstellen will, der muss dann eben sich damit doch beschäftigen.

Daher sehe ich eben nicht das Hauptproblem für fehlende Erweiterungen bei Symfony Kenntnissen sondern bei composer/github Kenntnissen.


Und das nicht jemand sagt es wusste niemand und in einigen Jahren wieder erschreckt, Contao 5 wird noch härter was die Kompatibilität betrifft, da funktioniert dann system/modules meines Wissens nicht mehr. Aber da haben wir ja noch sooo viel Zeit. Oder doch nicht?

[tschero]

@lucina
Nicht, dass du mich falsch verstehst. Ich finde Contao super und opfere gerne meine Zeit auch hier im Forum. Doch sehe ich es in letzter Zeit sehr kritisch, dass die Community von Contao doch nur aus einem relativ kleinen Kreis besteht (und auch nicht übermäßig wächst). Sieht man sich andere Systeme an steht hier eine wesentlich breitere Community und Entwicklergemeinschaft dahinter.

Genau dem schließe ich mich an.

Es geht mir hier nicht darum über Contao oder die Entwicklung zu meckern.
Im Gegenteil, persönlich bin ich sehr zufrieden mit der Entwicklung, ich bleibe als einfacher Webdesigner erst mal bei Contao 3.5 und ER2 und vor allem danke ich allen Entwicklern für die tolle Arbeit.

Ich habe Dich @lucina in meinem Post von oben nur so DIREKT angeschossen, weil ich nicht möchte, dass sich die Community verkleinert oder es zu einer "zwei-Klassen-Gesellschaft" wird, was für Contao auch für die Entwicklung langfristige, negative Folgen haben würde/könnte.

Gruß
tschero

[Spooky]

@the_scrat: die 256MiB Anforderung bei Shopware gilt für den Betrieb, nicht für etwaige composer Operationen. Und bei shopware wurde quasi die selbe Diskussion, die hier jetzt stattfindet, vor zwei Jahren auch schon ausgetragen.

Und bei Magento 2.0 sieht es nicht anders aus.

[lucina]

Mehr Wert auf eine Usability legen oder vielleicht einfach nicht irgendwelchen halbfertigen Tools in die Community werfen (Composerclient).

Niemand wirft halbfertige Tools in die Community. Das Contao-Installtool fragt Dich, ob Du die experimentelle Erweiterungsverwaltung benutzen möchtest.

Aus Usersicht ist der Composerclient eine (teilweise) Katastrophe (selbst die erfahrenste Agentur muss wissen wie die Pakete heißen).

Weil es wieder etliche Leute nicht schaffen, ihre Extensions mit korrekten Suchbegriffen auszuzeichnen. Was hat Composer damit zu tun? Wir hatten das auch mal ±8 Jahren, als wir den Wildwuchs der Schlagwörter im ER2 einzudämmen versuchten. Hat auch nichts gebracht, war aber auch nicht die Schuld des ER2.

[Spooky]

@lucina die Suche von Packagist selbst ist eher dürftig, egal wie passend die Keywords in der composer.json sind und die Implementation im Composer client ist unvollständig: https://github.com/contao-community-...ent/issues/244

Darüberhinaus hat man keine Möglichkeit zB optional nur nach contao Paketen suchen zu lassen. Die Suche ist daher eher unbenutzbar.

In Sachen Usability gibt es beim composer-client auf jeden Fall noch einiges, was man verbessern kann. Es fehlt halt die Zeit bzw. das Geld dafür. Wenn ich da mehr hätte, könnte ich sicher ein oder zwei PRs machen