neuinstallation scheitert mal wieder wegen dem composer

[css-umsetzung]

Also irgendwie werde ich echt langsam zu einem composer hater, liegt es an mir? Wäre ich jetzt einer der verschiedene systeme testet, wäre ich jetzt bei WP.
Das kann doch echt nicht sein, auch wenn ich mich wiederhole, nichts ist wichtiger als eine saubere erstinstallation, wenn die schon fehlschlägt, verliert doch jeder unbedarfte zukünftige webmaster die Lust.

Fatal error: Uncaught exception Composer\Json\JsonValidationException with message "./composer.json" does not match the expected JSON schema thrown in phar://composer/composer.phar/src/Composer/Json/JsonFile.php on line 183
#0 phar://composer/composer.phar/src/Composer/Factory.php(287): Composer\Json\JsonFile->validateSchema(1)
#1 [internal function]: Composer\Factory->createComposer(Object(Composer\IO\BufferIO))
#2 phar://composer/composer.phar/src/Composer/Util/Silencer.php(67): call_user_func_array(Array, Array)
#3 system/modules/!composer/src/Runtime.php(585): Composer\Util\Silencer::call(Array, Object(Composer\IO\BufferIO))
#4 system/modules/!composer/src/ClientBackend.php(300): ContaoCommunityAlliance\Contao\Composer\Runtime::createComposer(Object(Composer\IO\BufferIO))
#5 system/modules/!composer/src/ClientBackend.php(125): ContaoCommunityAlliance\Contao\Composer\ClientBackend->loadComposer()
#6 system/modules/core/classes/Backend.php(423): ContaoCommunityAlliance\Contao\Composer\ClientBackend->generate()
#7 system/modules/core/controllers/BackendMain.php(131): Contao\Backend->getBackendModule('composer')
#8 contao/main.php(20): Contao\BackendMain->run()
#9 {main} 

[mlweb]

Ja ist ein blöder Fehler. Lösung findest Du unter


https://community.contao.org/de/show...-expected-JSON

https://github.com/contao-community-...ent/issues/300

[css-umsetzung]

Hallo Mlweb,

ja vielen Dank für den Link vom Thread, dass in github hatte ich gefunden, das hier im Forum leider nicht, ich hatte die überschrift nicht auf meinen Fall bezogen.

Da kommen wir wieder zum Punkt, heute ist der 12.01. für das Problem wurde am 2.1. eine Lösung gefunden oder?
Das ist 10 Tage her, ich finde das das zu lang ist, um ein Fragezeichen zu löschen.

Ja das ist eine kostenlose Software, ich weiß das aber diese lebt davon, dass sie von möglichst vielen eingesetzt wird, was aber "komischerweise " immer wenn ich eine Version "neu" installiere, irgendein Problem mit dem composer hat, was eine installation verhindert.

[mlweb]

Ich bin kein Entwickler, aber ich glaube, das dass was Dir und mir in der Lösung recht einfach erscheint - wir Löschen einfach das Fragezeichen - in der Kette der mehr oder minder programmiertechnisch/automatisch erzeugten composer.json nicht ganz so einfach zu handhaben ist.
In den allermeisten Fällen ist bei Änderungen in Software ja doch auf Wechselwirkungen aller Art zu achten. Häufig genug kommt es vor, dass ich vorn mal ganz schnell einen Bug fixe und mir sprichwörtlich mit dem A... das halbe "Haus" einreiße.
In sofern sollten wir den Entwicklern schon die notwendige Zeit geben. Ist ja schließlich auf github schon als kritisch gekennzeichnet und wird damit sicher bald der Vergangenheit angehören.

[Andreas]

Tja, das kann passieren, wenn man an einem Beta-Test teilnimmt.

Install-Tool 3.5.21:

Wir testen momentan eine neue Version der Erweiterungsverwaltung, die Composer für das Paketmanagement verwendet. Bitte installieren Sie den Composer-Client, um am Beta-Test teilzunehmen.

Blöd nur, dass man fast dazu gezwungen wird, weil viele Erweiterungen nur noch für den Composer vorhanden sind. Ja, ich kann mir auch vorstellen, dass diese vielen Probleme mit dem Composer viele Neuankömmlinge abschreckt bzw. vertreibt.

[tab]

Ich baue mir im Moment gerade eine lokale Entwicklungsumgebung für Composer-Installationen auf, so dass ich das composer.lock lokal erzeugen lassen kann, was die ganzen Memory- und Laufzeitprobleme auf den lokalen Rechner verlagert. Der hat damit kein Problem. Eine andere Chance sehe ich im Moment für mich nicht, mit Composer sinnvoll zu arbeiten.

[css-umsetzung]

Das war absichtlich, ein wenig überzogen, klar muss eine Änderung getestet werden, aber alles ist besser als der 10Tage andauernde ist-zustand.

In einer neuen offiziellen contao Installation war doch jetzt kein Beta composer oder?
Das wäre ja noch schlimmer, das glaube ich nicht, kann es aber jetzt nicht beschwören.

[Spooky]

Hallo Mlweb,

ja vielen Dank für den Link vom Thread, dass in github hatte ich gefunden, das hier im Forum leider nicht, ich hatte die überschrift nicht auf meinen Fall bezogen.

Da kommen wir wieder zum Punkt, heute ist der 12.01. für das Problem wurde am 2.1. eine Lösung gefunden oder?
Das ist 10 Tage her, ich finde das das zu lang ist, um ein Fragezeichen zu löschen.

Ja das ist eine kostenlose Software, ich weiß das aber diese lebt davon, dass sie von möglichst vielen eingesetzt wird, was aber "komischerweise " immer wenn ich eine Version "neu" installiere, irgendein Problem mit dem composer hat, was eine installation verhindert.

Du kannst ja gern einen Pull Request machen, wo du eine runonce.php umsetzt, die die composer.json entsprechend ändert, wenn auf eine neue Version des composer-clients aktualisiert wird.

[mlweb]

In einer neuen offiziellen contao Installation war doch jetzt kein Beta composer oder?

Soweit ich das im Kopf habe steht bei jeder Installation 3.5.x genau der von @Andreas zitierte Text drin.

Nachtrag: Ja gerade noch einmal kontrolliert. Ist so.

[tab]

Naja, das steht da halt drin seit der Composer-Client in die Installation integriert ist. Seitdem hat sich ja schon einiges getan. Als Beta würde ich den mittlerweile nicht mehr sehen.

[mlweb]

Aber als Warnung an all diejenigen die sich mit den Problemen nicht befassen mögen schon.

[css-umsetzung]

Wie tab schon sagte, man wird geradezu genötigt den zu nehmen, da es sonst kaum aktuelle Erweiterungen gibt.
Das mit dem Beta hab ich dann in meiner Betriebsblindheit nicht wahr genommen.

Aber man kann sich nicht jahrelang hinter einer Beta verstecken. Wir müssen das auch nicht ausweiten, bald kommt wieder einer der composer Programmierer und schreibt das er das alles kostenlos macht und wir damit leben müssen das er nicht 24h am Tag daran arbeitet.

Ich meine aber, wenn ich an dem Herzen eines Produktes arbeite, dann muss ich dafür sorgen, dass es schlägt.

[mlweb]

da es sonst kaum aktuelle Erweiterungen gibt.

Einige pflegen Ihre Erweiterungen aber schon noch vorbildlich im ER.
Ich habe auch einige Kunden wo ich bisher wegen der schwachen Pakete nicht auf Composer gesetzt habe und da habe ich bisher noch keine Probleme gehabt. Klar hängt eben immer von der konkreten Erweiterung ab.

Ich teile Deine Einstellung, dass so etwas enorm ärgerlich und unbefriedigend für die Gewinnung "neuer Nutzer" ist. Für alle die länger dabei sind sollte das aber kein Problem darstellen. Die Community ist enorm flink und hilfsbereit.

[Spooky]

einer der composer Programmierer und schreibt das er das alles kostenlos macht und wir damit leben müssen das er nicht 24h am Tag daran arbeitet.

Und daran hat sich ja nichts geändert.

[css-umsetzung]

siehe ->

Ich meine aber, wenn ich an dem Herzen eines Produktes arbeite, dann muss ich dafür sorgen, dass es schlägt.

[Andreas]

In einer neuen offiziellen contao Installation war doch jetzt kein Beta composer oder?

Falls du Contao 4 damit meinst, das würde mich auch interessieren, habe momentan keine Contao 4 am Start.

[Andreas]

Wie tab schon sagte, man wird geradezu genötigt den zu nehmen, da es sonst kaum aktuelle Erweiterungen gibt.

Das kam von mir (außer dem "kaum"), nicht von @tab.

Für den nicht studierten Administrator und Nichteingeweihten war das ER2 wirklich richtig klasse und benutzerfreundlich und hat so gut wie keine Fehler gegeben. Die technischen Besonderheiten des Composers müssen schon enorm sein und die Erweiterungsverwaltung in andere Sphären katapultieren, wenn man in Kauf nimmt, dass es damit so viele Fehler gibt. Bin mal gespannt, wie sich das weitereintwickelt. Spätestens mit Contao 4 muss ich den ja wohl auch nehmen und jetzt habe ich bereits den Nachteil, das einige Erweiterungen nur manuell geupdatet werden können.

[tl_richard_user]

Wir müssen das auch nicht ausweiten, bald kommt wieder einer der composer Programmierer und schreibt das er das alles kostenlos macht und wir damit leben müssen das er nicht 24h am Tag daran arbeitet.

Ich meine aber, wenn ich an dem Herzen eines Produktes arbeite, dann muss ich dafür sorgen, dass es schlägt.

Ich bin kein "composer Programmierer" und dennoch geht mir deine Aussage gewaltig auf den Senkel. Unfassbar ignorante Aussage!
"Immer sind die anderen schuld"

[css-umsetzung]

Na aber hallo,
Ich spreche aus, was hier im Grunde alle denken.

Das heißt also, das ich schuld bin, weil ich mich dumm anstelle, das der Composer, wegen einem auf github bestätigtem Fehler, eine weitere Konfiguration verhindert.

Dann lass dich nicht davon abhalten, mir zu erklären, wie ich dieses Problem umgehe.
Es geht hier nicht um mich, ich weiß wo ich mich informiere, sondern um die, die nach ihrem erstkontakt mit contao, dieses direkt wieder löschen und zu einem problemlos installierbarem cms wechseln. Genau diese Leute sind es dann auch die anderen von contao abraten und überall verbreiten, das contao nicht richtig geht.

Wärst du also so helle gewesen, dich mal im Forum zu belesen, was den composer angeht, würdest du vermutlich nicht, dir fremde Personen angreifen.

[Samson1964]

Also irgendwie werde ich echt langsam zu einem composer hater, liegt es an mir? Wäre ich jetzt einer der verschiedene systeme testet, wäre ich jetzt bei WP.
Das kann doch echt nicht sein, auch wenn ich mich wiederhole, nichts ist wichtiger als eine saubere erstinstallation, wenn die schon fehlschlägt, verliert doch jeder unbedarfte zukünftige webmaster die Lust.

Ich stimme Dir zu. Wobei ich es dann eher erstmal wieder mit Drupal versuchen würde, was ich ein halbes Jahr lang 2012 intensiv getestet hatte.
Eine 3.5er Installation mit dem (Beta-)Composer als ER schlug wegen des Fehlers, den Du genannt hast fehl. Und ein 4.3er Contao produktiv zu nennen, wenn sowas wie ein ER fehlt ist schon reichlich ambitioniert. Ich dachte ja wenigstens ich hätte in 4.3 diesen (Beta-)Composer als ER. Aber Fehlanzeige.

[Spooky]

Wobei ich es dann eher erstmal wieder mit Drupal versuchen würde, was ich ein halbes Jahr lang 2012 intensiv getestet hatte.

Drupal 8 basiert ebenso wie Contao 4 auf Symfony und auch in Drupal 8 können Extensions (oder generell alle Abhängigkeiten) über Composer installiert werden. Laut Dokumentation kann auch eine Extension, die über Composer bzw. Packagist bereit gestellt wird, nicht auf drupal.org veröffentlicht werden.

Es gibt für Drupal 8 außerdem das drupal-composer/drupal-project Composer Template. Damit kannst du automatisch eine neue Extension erzeugen lassen (die du dann später bspw. in ein Git Repository laden kannst). Auch diese Extension und deren Abhängigkeiten wird dann über Composer gemanaged.

[Samson1964]

Okay, kommt Drupal ab Version 8 auch nicht mehr in Frage...
Aber da ich sehr treu bin - bei phpCMS noch viele Jahre nach der Projekteinstellung - werde ich Contao auch noch ziemlich lange treu sein.

[Spooky]

Okay, kommt Drupal ab Version 8 auch nicht mehr in Frage...

Damit du dir zusätzliche Recherche sparst: weitere Systeme die du dann vielleicht nicht benutzen wollen wirst sind

• Magento 2.x+
• TYPO3 7.x+
• TYPO3 Neos
• Joomla 3.x+

[css-umsetzung]

ich werde ja auch weiterhin auf contao setzen, aber das Problem ist eben wirklich, bei jeder Version die ich jetzt in der letzten Zeit von contao "neu installiert habe", gab es Fehler sobald der composer aktiviert wurde, es sind immer wieder andere Fehler.

Ich habe einen eigenen Server, daher bin ich etwas flexibler als ein "durchschnittlicher webseitenbetreiber", habe mir ein Rocksolid Theme gekauft, dieses sowie die erfoderlichen Rocksolid module über den composer installiert, ich glaube es waren 4 die ich brauchte. Dann habe ich das notification center installieren wollen, und der Composer versagte, weil ihm "1G RAM" nicht reichte öhm.....was soll ich sagen nutzt ja nichts, wir wissen ja das der composer gerne RAM frisst.
Ich finde das übel und nicht realisierbar für einen "durchschnittlichen Webseitenbetreiber" aber was heul ich hier rum, das ist ja alles bekannt und es wird bereits versucht, das mit unterschiedlichen Varianten zu umgehen, bis es aber dann soweit ist, ist contao ganz weit abgeschlagen, hinter den ganzen CMS die es so gibt und die einfacher sind.

Es wird für einen Entwickler immer schwieriger seinem Kunden, contao mit einem guten Gewissen zu verkaufen.

[lucina]

... nicht zu vergessen: Joomla, Wordpress, SilverStripe und noch etliche andere. Ich glaube nicht, dass es hilft, sich dem verweigern zu wollen.

[tab]

Jedes Ding hat (mindestens) zwei Seiten. Und ob PHP wirklich noch eine Zukunft hat im Web wird die Zeit zeigen. Wenn selbst 1GB RAM nicht mehr reicht, dann ist das gegenüber den entsprechenden Kunden nicht mehr zu rechtfertigen. Jedenfalls schaue ich mich momentan auch nach Alternativen um, da ich eben viele solche Kunden habe. Klar, ich kann einen Workflow für Updates für mich etablieren, mit dem ich zurecht komme. Aber der Kunde ist dadurch mehr oder weniger an mich gebunden. Schön für mich, von manchen kleinen Kunden aber nicht unbedingt gewollt. Die wollen - oder müssen aus finanziellen Gründen - vieles selbst machen können.

Für mich ist jedenfalls wahrscheinlich, dass ich Websites, die keine größeren Interaktionen mit Besuchern brauchen, in nicht mehr allzu ferner Zukunft nicht mehr mit Contao oder einem anderen PHP-basierten CMS realisieren werde. Ich schreibe "wahrscheinlich" und nicht "sicher", weil Wunder immer mal wieder passieren. Sei es, dass Composer seinen RAM-Hunger deutlich reduziert, sei es, dass die in Entwicklung befindliche Variante, die Abhängigkeiten auf einem zentralen Server mit jede Menge RAM aufzulösen, bis dahin reibungslos und anwenderfreundlich funktionieren wird. Das geht jetzt nicht gegen die Entwickler, die das versuchen zu realisieren. Sie tun sicher ihr Möglichstes, manche wahrscheinlich sogar mehr. Aber Contao hat eben einfach nicht so viele davon wie beispielsweise Wordpress. Mit der relativ begrenzten Manpower ist das alles momentan wohl ein ziemlicher Kraftakt. Contao weiterentwickeln, Contao Manager, gleichzeitig eine Lösung für die Composer-Probleme realisieren - und "nebenher" noch der eigentliche Job, der den Kühlschrank füllt. Und sich dann noch das "Gemecker" anhören müssen.

[lucina]

ich werde ja auch weiterhin auf contao setzen, aber das Problem ist eben wirklich, bei jeder Version die ich jetzt in der letzten Zeit von contao "neu installiert habe", gab es bei Fehler sobald der composer aktiviert wurde, es sind immer wieder andere Fehler.

Ich habe einen eigenen Server, daher bin ich etwas flexibler als ein "durchschnittlicher webseitenbetreiber", habe mir ein Rocksolid Theme gekauft, dieses sowie die erfoderlichen Rocksolid module über den composer installiert, ich glaube es waren 4 die ich brauchte. Dann habe ich das notification center installieren wollen, und der Composer versagte, weil ihm "1G RAM" nicht reichte öhm.....was soll ich sagen nutzt ja nichts, wir wissen ja das der composer gerne RAM frisst.
Ich finde das übel und nicht realisierbar für einen "durchschnittlichen Webseitenbetreiber" aber was heul ich hier rum, das ist ja alles bekannt und es wird bereits versucht, das mit unterschiedlichen Varianten zu umgehen, bis es aber dann soweit ist, ist contao ganz weit abgeschlagen, hinter den ganzen CMS die es so gibt und die einfacher sind.

Es wird für einen Entwickler immer schwieriger seinem Kunden, contao mit einem guten Gewissen zu verkaufen.

Ein durchschittlicher Webseitenbetreiber oder gar Endkunde dürfte allerdings diesen Speicherbedarf nicht haben, denn ein durchschnittlicher Webseitenbetreiber braucht keine Pakete mit dem Status 'Dev'. Und somit braucht er auch nur eine überschaubare Menge an RAM.

Ein durchschnittlicher Anbieter von Webseitenentwicklung für Endkunden sollte allerdings auch soweit wissen was er da tut als dass er sich der Dinge bewusst ist, die da ablaufen wenn er (oder sie) entwickelt. Sprich: das Konzept Paketmanagement sollte verstanden worden sein, genauso wie einige andere Konzepte auch. Sorry, mein Mitleid ist da etwas begrenzt.

Ich kann schon zugestehen dass sich die Anforderungen nach oben verschoben haben. Ich sehe allerdings auch, dass sich Menschen absolut keine Gedanken über die Entwicklungen in den letzten 10 Jahren gemacht haben, in denen PHP zu einer halbwegs ernst zu nehmenden Scriptsprache geworden ist, mit der Dinge möglich sind, von der wir alle 2006 nur geträumt haben. Ich sehe, dass wir inzwischen Applikationen bauen, die hochfunktionell und ebenso -komplex sind, und all das wäre nicht möglich, wenn wir weiter auf dem Stand des 200xer-Spaghetticodes geblieben wären.

Aus meiner Sicht ist es essentiell, sich dabei mit den veränderten Konzepten genauso zu beschäftigen wie mit einem grösseren Ressourcenhunger. Niemand hat ein Problem damit, die alte AMD-Athlon-Kiste von 2002 rauszuwerfen - aber das Web soll genau so anspruchsvoll sein wie damals? Ich bitte Dich - niemand kann mir erzählen dass er oder sie umfangreiche Webprojekte mit Funktionen für tausendundein Ausgabegerät, tonnenweise möglichen Benutzerinteraktionen, Datenbindungen an was-weiss-ich-nicht-alles realisiert wie weiland mit Homesite, NetObjects Fusion oder Adobe Contribute. Wir möchten alle diese Komplexität, die eine ganz neue Art der Nutzung ermöglicht, und dann regen wir uns darüber auf, dass es mehr Speicher verbraucht? Das möchtest Du mir jetzt nicht ernsthaft erzählen, oder?

Du bist an einem Fehler hängengeblieben der für Dich und alle anderen ärgerlich war. Der Fehler war simpel. Mit einem ungefähren Verständnis dafür, wie Composer seine Konfiguration aus einer JSON-Datei zieht und was da drinsteht wäre das eigentlich schnell lösbar gewesen.

Man kann sicherlich hingehen und sagen: Das alles interessiert mich vom Background her nicht. Ich will dass es funktioniert, und zum Ausgleich kann ich mit den Basismöglichkeiten gut leben. Dann ist alles gut, und das bleibt es auch - weil man dann im Wesentlichen beim Core bleibt, sowas wie den Paketmanager nicht nutzt und die erweiterten Möglichkeiten, die moderne Software einem schenken könnte aussen vor lässt.

Man kann auch hingehen und sagen, dass man komplexe Dinge herstellen möchte. Das von Dir gewünschte Notification-Center ist so ein komplexes Ding, das zig Funktionen integriert, für deren Entwicklung man im Jahr 2000 ein ganzes Team brauchte (was auch damals gewisse Ressourcen benötigte). Gut, das ist heute nicht anders - aber das Team wird dann halt durch externe Komponenten abgebildet, die gemanaged werden müssen. Composer ermöglicht genau das - und irgendwer wird den Preis dafür zahlen - sei es durch Serverressourcen, Weiterbildung, Sponsoring externer Komponenten, was auch immer. Das ist dann eben so.

Ich finde Globalsätze wie 'Es wird schwieriger, Contao zu verkaufen' in dem Zusammenhang nicht nur problematisch, sondern auch falsch. Kein Endkunde sollte sich mit Komponenten für Entwickler auseinandersetzen müssen. Es ist Sache das 'Entwicklers', dafür zu sorgen, dass ein System individuell entwickelt werden kann und anschliessend reibungslos läuft. Contao ist ein stabiles CMS, dass bereits in seinen Grundfunktionen sehr viele Dinge ermöglicht. Gut konfiguriert reicht das ja für simplen Produktivbetrieb vollkommen aus.

[Samson1964]

Ich finde Globalsätze wie 'Es wird schwieriger, Contao zu verkaufen' in dem Zusammenhang nicht nur problematisch, sondern auch falsch. Kein Endkunde sollte sich mit Komponenten für Entwickler auseinandersetzen müssen. Es ist Sache das 'Entwicklers', dafür zu sorgen, dass ein System individuell entwickelt werden kann und anschliessend reibungslos läuft. Contao ist ein stabiles CMS, dass bereits in seinen Grundfunktionen sehr viele Dinge ermöglicht. Gut konfiguriert reicht das ja für simplen Produktivbetrieb vollkommen aus.

Da liegt der Hase im Pfeffer! Contao braucht in der Zukunft einen technisch versierten Entwickler/Installationsmeister mit hochgerüsteter Hardware, der das System mainstream-fähig macht. Damit bleibt Ottonormalkunde außen vor, der sich technisch nicht so gut auskennt, keine großartige Serverhardware hat und sich keine externen Dienstleister für die Einrichtung eines CMS leisten kann.
Ich bin 2013 auch bei Contao geblieben, weil es sich kinderleicht installieren ließ und nicht wie andere Systeme, den Anwender mit unnützen Fragen ("Wie ist Ihr Documentroot?", "Wie ist der Domainname?") traktiert, die die Installationsroutine leicht mit PHP herausbekommen hätte.

Würde man die Uhr 20-25 Jahre zurückdrehen und man hätte damals einen Composer gebraucht, dann hätte es mit Sicherheit auch findige Köpfe gegeben, die die ganzen Aufgaben in Assembler programmiert auch in 1 MB statt 1 GB Arbeitsspeicher untergebracht hätten. Mal ganz abgesehen von der Prozessorgeschwindigkeit und den Festplatten damals.
Heutzutage wird nur noch geschludert mit den Ressourcen.

[lucina]

https://youtu.be/H8MetzhG9zE

[Samson1964]

https://youtu.be/H8MetzhG9zE

Schaue ich mir immer wieder gern an

[css-umsetzung]

Ein durchschittlicher Webseitenbetreiber oder gar Endkunde dürfte allerdings diesen Speicherbedarf nicht haben, denn ein durchschnittlicher Webseitenbetreiber braucht keine Pakete mit dem Status 'Dev'. Und somit braucht er auch nur eine überschaubare Menge an RAM.

Ein durchschnittlicher Anbieter von Webseitenentwicklung für Endkunden sollte allerdings auch soweit wissen was er da tut als dass er sich der Dinge bewusst ist, die da ablaufen wenn er (oder sie) entwickelt. Sprich: das Konzept Paketmanagement sollte verstanden worden sein, genauso wie einige andere Konzepte auch. Sorry, mein Mitleid ist da etwas begrenzt.

Und jetzt kommts:
ich bin so vorgegangen, wie ein "durchschnittlicher Webseitenbetreiber (nennen wir ihn mal Benutzer)" vorgeht, ich habe die defaulteinstellung belassen, woher soll der "Benutzer" wissen, das der composer verschiedene Modis hat, bzw. die wahl der Pakete entscheidend ist. Programme sollten immer so ausgerichtet sein, dass der DAU mit der normal konfig damit klar kommt.

Ich kann schon zugestehen dass sich die Anforderungen nach oben verschoben haben. Ich sehe allerdings auch, dass sich Menschen absolut keine Gedanken über die Entwicklungen in den letzten 10 Jahren gemacht haben, in denen PHP zu einer halbwegs ernst zu nehmenden Scriptsprache geworden ist, mit der Dinge möglich sind, von der wir alle 2006 nur geträumt haben. Ich sehe, dass wir inzwischen Applikationen bauen, die hochfunktionell und ebenso -komplex sind, und all das wäre nicht möglich, wenn wir weiter auf dem Stand des 200xer-Spaghetticodes geblieben wären.

Aus meiner Sicht ist es essentiell, sich dabei mit den veränderten Konzepten genauso zu beschäftigen wie mit einem grösseren Ressourcenhunger. Niemand hat ein Problem damit, die alte AMD-Athlon-Kiste von 2002 rauszuwerfen - aber das Web soll genau so anspruchsvoll sein wie damals? Ich bitte Dich - niemand kann mir erzählen dass er oder sie umfangreiche Webprojekte mit Funktionen für tausendundein Ausgabegerät, tonnenweise möglichen Benutzerinteraktionen, Datenbindungen an was-weiss-ich-nicht-alles realisiert wie weiland mit Homesite, NetObjects Fusion oder Adobe Contribute. Wir möchten alle diese Komplexität, die eine ganz neue Art der Nutzung ermöglicht, und dann regen wir uns darüber auf, dass es mehr Speicher verbraucht? Das möchtest Du mir jetzt nicht ernsthaft erzählen, oder?

Du machst dir das Leben hier ein wenig zu einfach, der "Benutzer" ist abhängig von den Ihm angebotenen Leistungen der Hoster, er kann es nicht beeinflussen und weiß es ja auch nicht wenn er seine erste Domain online stellt.

Du bist an einem Fehler hängengeblieben der für Dich und alle anderen ärgerlich war. Der Fehler war simpel. Mit einem ungefähren Verständnis dafür, wie Composer seine Konfiguration aus einer JSON-Datei zieht und was da drinsteht wäre das eigentlich schnell lösbar gewesen.

Dir ist klar, das ein Großteil der Programmierer nicht mal weiß was JSON ist, woher soll das der "Benutzer" wissen oder das verstehen.

Ich finde Globalsätze wie 'Es wird schwieriger, Contao zu verkaufen' in dem Zusammenhang nicht nur problematisch, sondern auch falsch. Kein Endkunde sollte sich mit Komponenten für Entwickler auseinandersetzen müssen. Es ist Sache das 'Entwicklers', dafür zu sorgen, dass ein System individuell entwickelt werden kann und anschliessend reibungslos läuft. Contao ist ein stabiles CMS, dass bereits in seinen Grundfunktionen sehr viele Dinge ermöglicht. Gut konfiguriert reicht das ja für simplen Produktivbetrieb vollkommen aus.

Und genau das scheint ja seit einer Weile nicht zu funktionieren Contao ist das stabile System, das aber durch componenten wie dem Composer geschwächt wird.

Ich kämpfe hier gegen Windmühlen aber das ist mir egal, es muss angesprochen werden. Du bist eine Überzeugte, weil du vermutlich den Kundenbereich abdeckst der das Geld bezahlt, um sich nicht selbst kümmern zu müssen und du alles in einem Entwicklungs und Deployprozess verwaltest.
Ich hingegegen übergebe Systeme gerne so, dass der Kunde nach der Fertigstellung auch ohne mich damit klar kommt und jederzeit selbst einen slider oder was auch immer nachinstallieren kann, denn dazu waren damals ja auch keine besonderen Fähigkeiten erforderlich.

Ich bin con contao selbst überzeugt, was man auch daran sehen kann, das ich eine nicht unerhebliche Menge an contao Webseiten online gebracht habe, aber Probleme unter den Teppich zu kehren oder schön zu reden ist nicht OK.

[xtra]

Und jetzt kommts:
ich bin so vorgegangen, wie ein "durchschnittlicher Webseitenbetreiber (nennen wir ihn mal Benutzer)" vorgeht, ich habe die defaulteinstellung belassen, woher soll der "Benutzer" wissen, das der composer verschiedene Modis hat, bzw. die wahl der Pakete entscheidend ist. Programme sollten immer so ausgerichtet sein, dass der DAU mit der normal konfig damit klar kommt.

Deshalb ist die default Einstellung des Modus auch der, der zu 99% funktionieren sollte (abgesehen von minimum-stability: dev, welcher im naechsten minor release auf stable gedropped wird). Der detached funktioniert nicht yberall und kann auch nicht trivial erkannt werden (siehe hierzu auch unsere verschiedenen tickets bei Tenside).

Du machst dir das Leben hier ein wenig zu einfach, der "Benutzer" ist abhängig von den Ihm angebotenen Leistungen der Hoster, er kann es nicht beeinflussen und weiß es ja auch nicht wenn er seine erste Domain online stellt.

Du kaufst auch einfach mal eben so ein Auto und meckerst hinterher dass es keinen Tempomat hat?

Dir ist klar, das ein Großteil der Programmierer nicht mal weiß was JSON ist, woher soll das der "Benutzer" wissen oder das verstehen.

Solche Menschen kann man heutzutage nicht guten Gewissens Programmierer nennen, schon gar nicht im Web Bereich, sorry.

Und genau das scheint ja seit einer Weile nicht zu funktionieren Contao ist das stabile System, das aber durch componenten wie dem Composer geschwächt wird.

Ach so? Deshalb freuen sich meine Kunden dass updates nun in Minuten erledigt sind anstatt Stunden. Dass Die einzelnen Komponenten dank Tests besser zusammenspielen uvm. Weil das System geschwaecht wurde... das ist aber eine seltsame Logik, dass etwas besseres schwaecher ist.

Ich kämpfe hier gegen Windmühlen aber das ist mir egal, es muss angesprochen werden. Du bist eine Überzeugte, weil du vermutlich den Kundenbereich abdeckst der das Geld bezahlt, um sich nicht selbst kümmern zu müssen und du alles in einem Entwicklungs und Deployprozess verwaltest.
Ich hingegegen übergebe Systeme gerne so, dass der Kunde nach der Fertigstellung auch ohne mich damit klar kommt und jederzeit selbst einen slider oder was auch immer nachinstallieren kann, denn dazu waren damals ja auch keine besonderen Fähigkeiten erforderlich.

Ja, ich verwende zeitgemaesse Entwicklungs und Deployprozesse wo moeglich und versuche diese soweit es geht zu etablieren. Meine Kunden verstehen die Rechnung der Arbeitszeit gegen mehr Ressourcen.
Um ehrlich zu sein, ich bin (im Zeitaufwand) um ein vielfaches teurer als die paar Euro monatlich fyr ein aktuelles Hostingpaket, meine Kunden koennen rechnen und entscheiden sich entsprechend.
Systeme zu ybergeben dass der Kunde selbst klar kommt, wenn er einen slider nachinstallieren muss, dann muss er auch CSS erzeugen, denselbigen einbinden etc. Dies ist von meinen Kunden (Redakteure!) nicht zu erwarten, weshalb hierbei wieder ich oder der Webentwickler ihrer Wahl zum Zuge kommt.
Sidenote: wenn ein slider nachinstalliert werden muss, dann wurde der im initialen Design entweder schlicht nicht benoetigt oder vergessen. Letzteres waere dann dein Fehler als Projektkoordinator.

Dass hierzu keine besonderen Faehigkeiten erforderlich waren stimmt neben o.g. CSS und Einbindung schon nicht, weiterhin muss man noch wissen welcher slider vertraegt sich mit der Installation denn manche bringen ganze JS frameworks huckepack mit welche sich potentiell mit Contao schon beissen, spaetestens jedoch mit irgendwas aus deinem Theme knallen koennte (Kennt dein Kunde die Zusammenhaenge deiner Javascripts?).

Ich bin con contao selbst überzeugt, was man auch daran sehen kann, das ich eine nicht unerhebliche Menge an contao Webseiten online gebracht habe, aber Probleme unter den Teppich zu kehren oder schön zu reden ist nicht OK.

Wieviel deines Umsatzes den du mit deinen Webseiten gemacht hast kam hierbei dem Projekt und den von dir eingesetzten Extensions zu Gute?
Bist du Mitglied in der Association und sorgst damit dafyr dass das Werkzeug mit dem du deine Broetchen verdienst auch entsprechend weiter entwickelt werden KANN oder jammerst du hier aus dem off?

Mal meine 0.02€

[Alphawolf]

Du kaufst auch einfach mal eben so ein Auto und meckerst hinterher dass es keinen Tempomat hat?

Der Vergleich "Gekauftes Auto bleibt nach den ersten Metern aufgrund werkseitig miskonfigurierter Voreinstellungen stehen, die ein Besuch in der Werkstatt und einen Fachmann erfordern" trifft es wohl eher, und ist in der Tat Gift für einen ersten Eindruck im Umgang mit egal was.

Als Entwickler "in der Bubble" mit entsprechendem Know-How ist es sicherlich einfach und zuweilen auch Beruf, Probleme anzugehen und abzuschätzen. Für den Benutzer ist und sollte dies nicht die Ausgangssituation sein.

[css-umsetzung]

Wieviel deines Umsatzes den du mit deinen Webseiten gemacht hast kam hierbei dem Projekt und den von dir eingesetzten Extensions zu Gute?
Bist du Mitglied in der Association und sorgst damit dafyr dass das Werkzeug mit dem du deine Broetchen verdienst auch entsprechend weiter entwickelt werden KANN oder jammerst du hier aus dem off?

Du möchtest nicht wissen, was ich dazu zu sagen hätte, sonst artet das hier doch noch aus.

[Schneetiger]

Hallo Leute,

danke für Eure Beiträge; habe den Eindruck gewonnen, dass der Composer inzwischen nahezu State-Of-The-Art bei vielen CMS ist. OK, dann kann Contao sich hier nicht verweigern.

Ich habe allerdings bei meiner Entwicklungsinstallation V 3.5.15 auch so meine Probleme damit. Ich kann keine Updates fahren; es werden immer wieder Fehlermeldungen ausgegeben (siehe ganz oben im Threat). Ich kann zwar produktiv arbeiten, aber wie gesagt, nicht updaten:-(. Im error_log ist nichts verzeichnet.
Ich werde mir jedenfalls mal die obe erwähnten Links zu Gemüte führen.

Schönen Abend noch.

Schneetiger

[xtra]

Du möchtest nicht wissen, was ich dazu zu sagen hätte, sonst artet das hier doch noch aus.

Ich bin gerne auch zu einem persoenlichen, konstruktiven, Gespraech bereit, die Telefonnummer findest du auf meiner Webseite.
Ich erlaube mir jedoch unkonstruktive rants abzurechnen.

Es ist jedoch fraglich wieso du deine Meinung nicht oeffentlich aeussern magst und in welcher Hinsicht diese, sofern konstruktiv, ausarten koennte.

[mlweb]

ich bin so vorgegangen, wie ein "durchschnittlicher Webseitenbetreiber (nennen wir ihn mal Benutzer)" vorgeht, ich habe die defaulteinstellung belassen

In der "Defaulteinstellung" wird der Composer aber gar nicht erst verwendet, sondern deutlich als "Beta-Test" bezeichnet.

Du machst dir das Leben hier ein wenig zu einfach, der "Benutzer" ist abhängig von den Ihm angebotenen Leistungen der Hoster, er kann es nicht beeinflussen

Stimmt nicht ganz. Der Benutzer kann bei fast allen Hostern die Leistung auch upgraden oder ggf. den Hoster wechseln. Reicht zwar bei Composer nicht in jedem Fall, aber bei den kleineren Erweiterungen hat es bei mir bisher immer geklappt auch mit vergleichsweise günstigen Paketen.
Ist der Kunde aus welchen Gründen auch immer nicht bereit zu wechseln, dann kann ich immer noch den ER benutzen. Das hat zugegebener Maßen seine Grenzen bei mächtigen Erweiterungen mit vielen Abhängigkeiten.

und weiß es ja auch nicht wenn er seine erste Domain online stellt.

Wen jemand selbst seine Domain online stellen möchte, der sollte sich schon auch etwas über das Hosting informieren bzw. ggf. auch beraten lassen.

Du bist eine Überzeugte, weil du vermutlich den Kundenbereich abdeckst der das Geld bezahlt, um sich nicht selbst kümmern zu müssen und du alles in einem Entwicklungs und Deployprozess verwaltest.
Ich hingegegen übergebe Systeme gerne so, dass der Kunde nach der Fertigstellung auch ohne mich damit klar kommt und jederzeit selbst einen slider oder was auch immer nachinstallieren kann.

Genau das kann ich gar nicht nachvollziehen. Meine Kunden sind alles kleine örtliche Unternehmen. Das Budget ist eher sehr knapp. Einige dieser Kunden haben anfänglich die Idee ihre Seite inhaltlich selbst zu pflegen. Im Ergebnis machen es dann viele Kunden aber nicht. Sie merken nämlich, dass das alles Zeit kostet.

• meist deutlich mehr Zeit als die, die sie bezahlen müssen, wenn ich diese Aufgabe für sie erledige
• Zeit die sie deutlich effektiver in ihre eigentliche Arbeit stecken können

Der Vergleich "Gekauftes Auto bleibt nach den ersten Metern aufgrund werkseitig miskonfigurierter Voreinstellungen stehen, die ein Besuch in der Werkstatt und einen Fachmann erfordern" trifft es wohl eher

Dieser Vergleich hinkt aber erst recht. Wenn sich der Benutzer ein Hostingpaket aussucht welches keine Datenbank beeinhaltet, würde hier jeder sagen: "Ja klar das kann nicht gehen." Wenn aber andere Voraussetzungen fehlen, werden hier einige enorm nachsichtig mit dem armen "Benutzer".

[Shania]

Ich teile Deine Einstellung, dass so etwas enorm ärgerlich und unbefriedigend für die Gewinnung "neuer Nutzer" ist. Für alle die länger dabei sind sollte das aber kein Problem darstellen. Die Community ist enorm flink und hilfsbereit.

Nö, auch diejenigen die länger dabei und keine Technikfreaks sind, werden damit extrem genervt - zu denen zähle ich mich . Das war ja immer eins der wirklich tollen Sachen an Contao, das alles super klappte. Ich hab nun keine Wahl, meine Seite ist zu groß, um damit was neues auszuprobieren und muss da durch, scheinbar auch mit Composer, weil es sonst mit MM nichts wird. Und ich hab gleich die erste Fehlermeldung, aber da das übers Installtool lief, habe ich dieses Forum erst später entdeckt, sorry.

[Schnubi]

Wenn alle anderen auch Composer verwenden dann haben die das halt einfach besser umgesetzt!

Ich hab bis auf eine Website jetzt mittlerweie alle umgestellt auf Wordpress und ich bereue die Zeit die ich mit unnötigen Fehlersuchen im Contao/Composer vergeudet habe !
Ich hatte bei WP bisher noch nicht ein einziges mal ein Problem nach installieren eines Plugins oder durchfüren eines Updates, bei Contao jedes mal.

Eine Seite läuft wie gesagt derzeit noch mit Contao da ich dort Metamodels eingesetzt habe, viele Funktionen habe ich bereits mit Pods nachgebaut, leider fehlt mir im Moment die Zeit das fertig zu machen, daher wollte ich mal schnell ein Update machen und siehe da wiedermal is alles im Ar***, zu den Fehlern kommen jetzt ja noch die Speichererrors dazu, das macht es alles noch schwieriger aber das wird alles schön geredet.

Komisch das ich das bis jetzt bei keinem anderen CMS gesehen habe?

Das sind meine 2ct!

[lucina]

Wenn alle anderen auch Composer verwenden dann haben die das halt einfach besser umgesetzt!

Ich hab bis auf eine Website jetzt mittlerweie alle umgestellt auf Wordpress und ich bereue die Zeit die ich mit unnötigen Fehlersuchen im Contao/Composer vergeudet habe !
Ich hatte bei WP bisher noch nicht ein einziges mal ein Problem nach installieren eines Plugins oder durchfüren eines Updates, bei Contao jedes mal.

Eine Seite läuft wie gesagt derzeit noch mit Contao da ich dort Metamodels eingesetzt habe, viele Funktionen habe ich bereits mit Pods nachgebaut, leider fehlt mir im Moment die Zeit das fertig zu machen, daher wollte ich mal schnell ein Update machen und siehe da wiedermal is alles im Ar***, zu den Fehlern kommen jetzt ja noch die Speichererrors dazu, das macht es alles noch schwieriger aber das wird alles schön geredet.

Komisch das ich das bis jetzt bei keinem anderen CMS gesehen habe?

Das sind meine 2ct!

Ich glaube, das möchte ich als eine, die auch mal gerne über den Tellerrand schaut, nicht so stehen lassen. Du bist frustriert, okay, aber Du schreibst nicht konkret weshalb, und das finde ich nicht nur schade sondern auch nicht zielführend.

Auch ich setze für bestimmte Projekte Wordpress ein. Meine Erfahrung ist, dass es (meistens) genau dann alles gut funktioniert solange man das System auf den Kern beschränkt und nicht versucht, Funktionalitäten nachzurüsten, die WP von Haus aus nicht hat. Das beginnt bei der spartanischen (und aus meiner Sicht unbrauchbaren) Benutzerverwaltung, zieht sich über die wuchernde Menge kaputter Plugins (hey, die am meisten benutzten Plugins für anständige Formulare und Galerien machen Löcher im System über die man nur staunen kann ...) bis zum so gepriesenen Auto-Update-Feature, dass in einem Drittel der Fälle nicht funktioniert weil es zum einen nicht prüft, wieviel Zeit es zur Verfügung hat und zum anderen nicht richtig schaut, ob Kompatibilitätsprobleme vorliegen.

Das von Dir gepriesene 'Pods' hat zur Zeit 307 offene und bestätigte Bugs, 21 Issues bzgl. Kompatibilitätsproblemen sowie 32 offene Tickets zur Rückwärtskompatibilität. Das sind die getaggten Tickets, bei denen zumindest schon mal jemand drübergeschaut hat um sie einzuordnen. Ich finde das nicht wenig, und meine Erfahrungen dabei sind, dass man so ein System dann auch nur genau dann updatet wenn man sehr genau weiss, was man getan hat.

Du schreibst hier ganz global, dass Du "unnötige Fehlersuchen im Contao/Composer" hattest. Okay, niemand zwingt Dich, Composer einzusetzen. Du möchtest anscheinend etwas mehr als Contao von Haus aus kann - aber dann erwarte ich persönlich auch, dass Du einen Workflow hast, der die Voraussetzungen schafft.

Wir alle wissen, dass Updates, Upgrades, Erweiterungsaktualisierungen auf Livesystemen eine schlechte Idee sind. Ich finde das auch unprofessionell. Wenn man die Freuden einer Paketverwaltung geniessen möchte, dann sollte man sicherstellen, dass das System das auch verarbeiten kann. Ein professioneller Entwicklerworkflow (Du installierst doch Dinge, die in Entwicklung sind? Ach, MM sind nicht Stable ...???) sähe aus meiner Sicht so aus, dass man von einem lokalen System mit genügend Ressourcen auf einen Liveserver deployed. Ich persönlich habe mir dabei noch nie ein System abgeschossen, und ich arbeite seit Ende 2006 mit Contao (damals noch Typolight 2.2 irgendwas ...) und seit zwei Jahren ausnahmslos mit der composerbasierten Paketverwaltung.

Ich hatte auch schon deftige Probleme. Zum einen nach dem Release von Symfony 3, weil damit nämlich der Speicherverbrauch für die Auflösung der Abhängigkeiten massiv angestiegen ist. Das macht im Regelfall dann etwas aus, wenn ich Abhängigkeiten mit dem Status DEV in einer Installation habe und ich dann die Mindeststabilität so niedrig lassen muss dass ein paar hunderttausend Pakete durchgerechnet werden müssen. Wenn ich auf Stable bleibe, dann habe ich diese Probleme nicht, und Contao mit der Composer-Paketverwaltung läuft prima auf einem Feld-Wald-Wiesen-Hosting von einem anständigen Hoster wie beispielsweise df.eu. Ich weiss nicht, ob es bei den bekannten Firmen aus der Fernsehwerbung läuft, und ich will das auch gar nicht wissen, weil ich deren Kundenverarsche keinen Vorschub leisten möchte. Fazit: Zuwenig RAM ist IMHO kein Composer-Problem, sondern dass eines unzureichenden Webservers oder einer unzureichenden Entwicklungsumgebung.

Mein zweites Problem war wiederum keins, das mit Contao oder Composer zu tun gehabt hätte - das war die Migration von MetaModels 1.x auf MetaModels 2.x. - und selbst da muss ich für mich sagen, dass ich selbst da vor zwei Jahren nicht sauber gearbeitet habe und mir das dann halt auf die Füsse gefallen ist. Fazit: hausgemachtes Problem. Von mir selbst. Man soll nicht Composer etwas in die Schuhe schieben das man selbst herbeigeführt hat.

Schliesslich hatte ich ein Problem, als eine neue Version von Composer herauskam die das URL-Schema mit http?:// nicht mehr unterstützte. Das war ärgerlich, ja. Aber die Lösung war recht schnell bekannt, und man konnte, wenn man sich mal fix quer durch die Tickets gelesen hatte, doch recht schnell das '?' aus der composer.json entfernen. Das ist allerdings tatsächlich das einzige Problem, dass Composer in Kombination mit dem Client gemacht hat. EINS.

Und weiter: Du schreibst, dass Du Software einsetzt, die zur Zeit aktiv entwickelt wird. Gut. Du schreibst, dass Du 'mal schnell ein Update' dabei machen wolltest und 'alles im *rsch' sein. Nicht schön. Aber vielleicht klären wir mal, was da passiert ist? Erst einmal geht es anscheinend um MM, nicht um Contao, und nicht um den Composer. Du setzt etwas ein, was Dir ggf. viele Wünsche erfüllt, aber halt nicht den Status einer stabilen Software hat. Kann man machen, mache ich auch. Was Du ganz sicher nicht gemacht hast ist, das zu berücksichtigen. Das nenne ich mal ein 'hausgemachtes Problem'. Statt Dich nun aber aktiv einzubringen und mal zu erzählen, was dann 'alles im *rsch' bedeutet, damit wir dem abhelfen können stellst Du hier relativ länglich in den Raum, dass alles kaputt ist, die Kombination aus Contao & Composer Schuld ist und überhaupt 'Speichererrors' auftreten würden. Die Frage des RAM haben wir ja schon weiter oben beleuchtet - weder ist das ein Problem des Einen noch des Anderen, sondern allein Deines. Du entwickelst, schaffst dir aber nicht die Voraussetzungen dafür. Wo liegt also das Problem?

Niemand ausser Dir redet da etwas schön. Wir alle haben das Ziel einer stabilen und zukunftsfähigen Software. Eine funktionierende Paketverwaltung gehört IMHO zwingend dazu. Zu erwarten, dass so etwas mit einem so viel mehr an Möglichkeiten dann auf Umgebungen läuft, die Ressourcen wie weiland 2006 haben finde ich komplett vermessen. Trotzdem ist Contao auch im Jahr 2017 ein stabiles, benutzerfreundliches System. Du verlässt dich darauf, dass du gesteigerte Fähigkeiten einfach mal zu den alten Bedingungen unterbringen kannst, und das geht - was vollkommen erwartbar ist - fehl. Ob WP da nun mittelfristig eine Ausnahme sein wird wage ich - gelinde gesagt - zu bezweifeln. Ich schaue ja gerne auch mal andere Systeme an - WP mit Pods ist eines davon. Meine persönliche Einschätzung ist, dass Pods interessante Ansätze hat. Unter anderem die Komponenten SEO und API-Zugang erscheinen mir ambitioniert und sinnvoll, wobei insbesondere der API-Zugriff ja zur Zeit kaputt ist, weil WP selbst die API vollkommen kaputt released hat. Und so ein System, dass bereits von Haus aus Probleme hat, stellst Du uns hier als eierlegende-rocksolid-Wollmilchsau-Alternative in den Raum? Sorry, ich verstehe das nicht.