neuinstallation scheitert mal wieder wegen dem composer

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.

PHP-Code:

---

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} 


---

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

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.

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.

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

Zitat:

---

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.

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.

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.

Zitat:

---

Zitat von 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.

---

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.

Zitat:

---

Zitat von css-umsetzung

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.

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.

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

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.

Zitat:

---

Zitat von css-umsetzung

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.

Zitat:

---

Zitat von css-umsetzung

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.

siehe ->

Zitat:

---

Zitat von css-umsetzung

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

---

Zitat:

---

Zitat von css-umsetzung

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.

Zitat:

---

Zitat von css-umsetzung

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.

Zitat:

---

Zitat von css-umsetzung

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"

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.

Zitat:

---

Zitat von 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.

---

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.

Zitat:

---

Zitat von Samson1964

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.

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.

Zitat:

---

Zitat von Samson1964

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+

;)

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.

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

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.

Zitat:

---

Zitat von 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 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.

Zitat:

---

Zitat von lucina

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.

https://youtu.be/H8MetzhG9zE

Zitat:

---

Zitat von lucina

https://youtu.be/H8MetzhG9zE

---

Schaue ich mir immer wieder gern an :)

Zitat:

---

Zitat von lucina

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.

Zitat:

---

Zitat von lucina

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.

Zitat:

---

Zitat von lucina

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.

Zitat:

---

Zitat von lucina

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.

Zitat:

---

Zitat von css-umsetzung

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).

Zitat:

---

Zitat von css-umsetzung

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?

Zitat:

---

Zitat von css-umsetzung

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.

Zitat:

---

Zitat von css-umsetzung

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.

Zitat:

---

Zitat von css-umsetzung

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?).

Zitat:

---

Zitat von css-umsetzung

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€

Zitat:

---

Zitat von xtra

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.

Zitat:

---

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.

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

Zitat:

---

Zitat von css-umsetzung

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.

Zitat:

---

Zitat von css-umsetzung

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.

Zitat:

---

Zitat von css-umsetzung

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.

Zitat:

---

Zitat von css-umsetzung

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.

Zitat:

---

Zitat von css-umsetzung

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

Zitat:

---

Zitat von Alphawolf

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".

Zitat:

---

Zitat von mlweb

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.

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!

Zitat:

---

Zitat von 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!

---

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.

@Lucina Wenn jemand davon überzeugt ist, dass ein anderes System für ihn und seine Kunden besser ist, dann ist das meist nicht zu ändern - insbesondere dann, wenn mit Contao warum auch immer Probleme aufgetreten sind. Einige kommen nach ein paar Ausflügen wieder zu Contao zurück, andere finden ein System was zu ihrem Workflow, ihren Anforderungen besser passt.

@Schnubi Ich persönlich wünsche Dir weiterhin viel Glück mit dem Systemwechsel. Ich würde mich freuen wenn Du trotz Deines Ärgers und Deiner Entscheidung gegen Contao etwas Objektivität walten läßt. Bei keinem mir bekannten CMS ist alles "Friede, Freude, Eierkuchen". Man muss bei einer Entscheidung gegen ein System nicht zwingend alles in Bausch und Bogen verurteilen. Die unterschiedlichen Systeme haben Ihre Vor- und Nachteile und es gilt das für den Einsatzzweck und den eigenen Workflow "beste" System zu finden.

@lucina: Wie immer ganz lustig deine Seitenlangen wiederholungen zu lesen! Nur eins noch, nur weil du etwas ständig wiederholst wird es och lange nicht wahr! :)

Zitat:

---

Zitat von Schnubi

@lucina: Wie immer ganz lustig deine Seitenlangen wiederholungen zu lesen! Nur eins noch, nur weil du etwas ständig wiederholst wird es och lange nicht wahr! :)

---

Nur so aus Neugier: was genau stimmt denn da nicht?

Weiß man ungefähr wie viele Seiten mit 2.x, 3.x und 4.x laufen?
Auch wenn die Vision von Contao ins anspruchsvollere Segment tendiert, dürften doch sehr, sehr viele Seiten von 3.x nicht (so einfach) auf 4.x kommen.
Wenn das der Fall ist, wird es vermutlich ähnlich wie bei Drupal sein, wo es parallel mehrere mehr oder minder aktuelle Versionen gab und keine 5 Plugins mit einer Version funktionierten. Egal welche Version man wählte, entweder schon veraltet oder nicht sauber zu installieren, von Update/ Upgrade will ich gar nicht erst reden. Deswegen bin ich jedenfalls damals auf Contao gewechselt. Ein klasse Entscheidung.
Seitdem haben wir als Agentur viele meist kleinere Seiten umgesetzt - Contao hat uns dabei sehr unterstützt: schneller installiert wie andere, solide im Betrieb, top anpassbar für Endnutzer. Spätestens seit 4.x fühlt sich das jedenfalls im Moment aber nicht mehr so an, v.a. wegen des Composers.
Wie viele Nutzer verwenden denn bei neuen Projekten die 4.x-Version, wie viele greifen noch zur 3.x?

Dabei hängt es wohl viel vom verwendeten Hosting ab.

Wenn Du ein Hosting hast, was mit Contao-Manager, Composer & Co. gut zurecht kommt, dann macht Contao 4.4 richtig Spaß.

Zitat:

---

Zitat von hartlrobert

Auch wenn die Vision von Contao ins anspruchsvollere Segment tendiert, dürften doch sehr, sehr viele Seiten von 3.x nicht (so einfach) auf 4.x kommen.

---

Wie kommst Du darauf? Die Umstellung hat mir bei meinen bisherigen Kunden weitaus weniger Probleme bereitet als erwartet und gefühlt sogar weniger Probleme als beim Umstieg von Contao 2 auf Contao 3. Das kann aber auch daran liegen, dass ich damals noch nicht all zulange mit Contao unterwegs war.

Zitat:

---

Zitat von hartlrobert

Seitdem haben wir als Agentur viele meist kleinere Seiten umgesetzt - Contao hat uns dabei sehr unterstützt: schneller installiert wie andere, solide im Betrieb, top anpassbar für Endnutzer. Spätestens seit 4.x fühlt sich das jedenfalls im Moment aber nicht mehr so an, v.a. wegen des Composers.
Wie viele Nutzer verwenden denn bei neuen Projekten die 4.x-Version, wie viele greifen noch zur 3.x?

---

Ich habe auch fast nur kleine Kunden. Neue Projekte setze ich ausschließlich mit Contao 4 um (seit Contao 4.4) und für mich sind Installation und Update spürbar einfacher und schneller.
Ich bin kein Entwickler. Also Kommando-Zeile mit Composer war für mich als Windows-Nutzer auch eher gewöhnungsbedürftig.
Da ich immer mit einer lokalen Entwicklungsumgebung (Windows mit XAMPP) arbeite, musste ich mich wohl oder übel mit der Konsole anfreunden und bin inzwischen sehr froh darüber, dass ich dadurch meinen inneren Schweinehund überwunden habe.
Live habe ich meist aus Gewohnheit den Contao-Manager parallel installiert.

Erweiterungen, die nicht funktionieren habe ich bei meinen Projekten bisher kaum entdeckt, bin aber auch relativ sparsam beim Einsatz von Erweiterungen.
Ist eine Erweiterung noch nicht für Contao 4 freigegeben, kann man manuell installieren und schauen ob es funktioniert. In meinem Fall hat alles geklappt und ich habe den Entwickler auf Github informiert.
Wenige Stunden später war die Erweiterung auch für Contao 4 freigegeben.

Zitat:

---

Zitat von do_while

Dabei hängt es wohl viel vom verwendeten Hosting ab.

---

Ja genau. Ein geeignetes Hosting ist Voraussetzung und da lasse ich mich auch nicht auf faule Kompromisse ein.
Bisher ist die Strategie aufgegangen.
Bei nicht geeignetem Hosting von Bestands-Seiten bin ich fleißig dabei Überzeugungsarbeit zu leisten. So lange bleiben die Seiten auf dem 3er-Zweig. Ich hoffe bis 2019 ändert sich die Einstellung des Kunden oder das Angebot des jeweiligen Providers verbessert sich.

Zitat:

---

Zitat von hartlrobert

Wie viele Nutzer verwenden denn bei neuen Projekten die 4.x-Version, wie viele greifen noch zur 3.x?

---

Hängt natürlich vom Hosting ab. Wenn es ein für Contao 4 geeignetes Hosting ist, dann nehme ich das. Wenn nicht und der Kunde sich auch nicht zu einem anderen Hosting überzeugen lässt, eben eine 3.x. Ausnahmen bestätigen die Regel ;). Bin gerade dabei, eine Kundenwebsite mit 3.x zu machen, weil die schon vor etwa einem Jahr von mir vorbereitet wurde und erst jetzt aktuell wird. Das Design ist bis auf Updates zur neuesten 3.x eigentlich im Wesentlichen fertig, fehlen noch die Texte und ein paar passende Bilder. Eventuell passe ich die Farben noch etwas an. Aber du bringst mich auf eine Idee, den Spass gönne ich mir jetzt mal. Ich mache ein Update auf 4.x, das Hosting des Kunden gibt das mittlerweile her, weil ich ihn schon vor Monaten in weiser Voraussicht dahin umgezogen habe, wo Contao 4 funktioniert und das Hosting bei wesentlich besseren Leistungen auch nicht teurer ist als das vorhergehende (wohin ich seine Websites 2012 auch schon umgezogen habe zum Relaunch). Eher ist sogar das Gegenteil der Fall.

Bei den Webs mit Server gehe ich auf 4 hoch, bei Hosting-Webs bleibe ich bei 3.5 auf Dauer. Die Voraussetzungen für 4 sind einfach zu hoch. Vielleicht passt das in 10 Jahren auch beim Hosting für die 4. Contao ist seiner Zeit voraus.

Gesendet von meinem L52 mit Tapatalk

War bei mir in allen Installationen bisher total easy. Verwendet man kein angepasstes Navigationstemplate, hat man css-technisch mit dem Wechsel von <strong> zu <span> zu tun. Da ich in diesem Bereich häufig angeasste Templates habe, hatte ich nicht mal das Problem und entscheide je nach Kunde und Budget, ob ich hier auf das semantisch bessere <strong> wechsle. Ansonsten aufgefallen sind mir noch folgende Sachen:

• es gibt kein Template ce_hyperlink_image.html5 mehr sondern es wird durchgängig das Template ce_hyperlink.html5 verwendet
  hat man ce_hyperlink_image.html5 (der Name lies sich auch nicht ändern, war hartcodiert) angepasst wird es nicht mehr gezogen
• für die css-id wird automatisch die ID des Artikels gezogen und nicht mehr der alias
  hat man die id im css oder als Ansprungmarken verwendet, muss man nacharbeiten
• verwendet man eigene Layoutbereiche, dann ist das Handling viel schöner als in Contao 3, aber der erzeugte Code ist anders
  auch dort musste ich im css nacharbeiten

Alle in allem aber nicht wild. Die Problemstellen such man ja auch nur beim ersten Mal, danach kennt man seine "Pappenheimer". ;)

Edit: Typo

Zitat:

---

Zitat von Samson1964

Bei den Webs mit Server gehe ich auf 4 hoch, bei Hosting-Webs bleibe ich bei 3.5 auf Dauer. Die Voraussetzungen für 4 sind einfach zu hoch. Vi

---

Ich habe keine einzige Kundeninstallation mit Server.
Die Hostingpakete die mit dem Contao-Manger funktionieren findet man im Github-Wiki.
Wenn ssh Zugang vorhanden ist, sollte dort überall auch die Installation über Konsole problemlos laufen.

So, Updatemarathon bei allen Kundeninstallationen erfolgreich abgeschlossen. Jetzt habe ich gerade mal versucht, die neue Contao 4.4.7 per Contao-Manager (Beta10, neueste Version) zu installieren auf meinem Webspace bei Webgo, um eine 3.5.31 Installation upzudaten. Leider blieb es zunächst beim Versuch. Dabei war von meinen letzten Versuchen noch PHP 7.0 eingestellt, was damals funktioniert hat. Jetzt nicht mehr.

Zuerst hatte ich mal wieder die allseits beliebte Fehlermeldung, dass eine .htaccess<irgendeinhash> gefunden wurde, die danach natürlich nicht mehr existiert hat. Aus meinen Erfahrungen von den letzten Versuchen bin ich dann hergegangen und habe ein Refresh gemacht, also Seite neu laden. Danach ging es weiter mit einigen Downloads, das Ganze war aber dann sehr schnell beendet mit der Fehlermeldung, dass der Konsolentask unerwartet beendet wurde mit Status 1. Das war auch reproduzierbar, ich habe es mehrfach probiert und zuvor jeweils die Dateien und Verzeichnisse wieder entfernt. Da macht sich schon mal Frust breit. Das hat immerhin bisher sehr zuverlässig funktioniert. Keine Ahnung was da jetzt wieder los ist :rolleyes:. Das irritiert mich jetzt doch ein wenig. Was hat sich da jetzt wieder geändert? Der Contao-Manager oder die Konfiguration bei Webgo?

Also habe ich jetzt umgestellt auf PHP 7.1, was ja leider bei Webgo momentan dann für alle Installationen gilt, womit ich wohl meine alten 4.4.x Testinstallationen erst einmal alle auf 7.1 "umstellen" darf :rolleyes:. Zum Glück sind wenigstens die 3.5 Installationen in der Hinsicht problemlos, sonst würde mich das wieder ein paar Stunden kosten. Dafür lief die Installation von Contao 4.4.7 dann mit PHP 7.1 problemlos durch. Ich werde jetzt also am Morgen mal ein Update von 3.5.31 auf 4.4.7 versuchen. Wenn das bei der Installation nicht funktioniert, dann bei anderen schon gar nicht. Dass EasyUpdate3 notgedrungen fehlen wird in der 4.4.7 dürfte ja kein Hindernis sein und BackupDB installiere ich dann vor dem Aufruf des Installtools noch per Manager.

Du meinst sicher Contao 4.4.8 :)

Ja, das Neueste eben. Muss ich mich nachher erst nochmal kundig machen, welche Dateien ich in die neue Installation übernehmen muss. Ok, unklar ist mir eigentlich nur die localconfig.php. Die müsste eigentlich mit wegen der Systemeinstellungen, oder muss ich die manuell nochmal eingeben? Naja, wird sich finden.

Zur PHP-Version: https://github.com/contao/managed-edition/issues/25

Sollte nun also auch unter 7.0.x wieder funktionieren.

Ah ja, prima, aber ich bleibe jetzt sinnvollerweise gleich bei 7.1. Die C3-Websites die da laufen juckt das nicht und den Rest passe ich halt bei Bedarf an. Das Update muss ich sowieso erst mal auf Eis legen, hatte vergessen, dass da dk_mmenu benutzt wird. Das hat mir der Contao-Manager nicht installiert, muss ich also wohl erst mal ersetzen durch was anderes für Contao 4. Auf längere Sicht wohl eh besser. Das sprengt aber im Moment den Zeitrahmen, zwei Projekte die am besten letzte Woche laufen sollen. Da muss es eben im Moment erst einmal beim praktisch fertigen 3.5.31 bleiben. War ja ursprünglich auch so vorgesehen. Klar, wenn es problemlos gegangen wäre mit maximal ein paar Template-Anpassungen ... Immerhin, Installtool ist durchgelaufen. Was mir danach im BE aufgefallen ist, ich kann mich nicht abmelden (Firefox Quantum 57.0). Beim Anmelden sind die Input-Felder viel zu lang. Mit Chrome alles ok. Wird wohl ein Bug im neuen Firefox sein, da gefällt mir eh so einiges nicht mehr seit diesem Update auf Quantum. Upps, alles zurück, Seite neu laden hat geholfen ;).