Die niedrige TTL sollte ja nicht zu diesem Problem führen. Du solltest dem Problem selbst auf den Grund gehen - bzw. von Hetzner auf den Grund gehen lassen.
Druckbare Version
Das vermutlich kannst du getrost weglassen. Ansonsten würde ich mich nicht mit meinem Webspace verbinden können. Ist in der Tat wohl ein ds-Lite, was halt manche Dinge etwas komplizierter bzw unmöglich macht. Im Zusammenhang mit Contao ist mir da aber bisher nichts dergleichen aufgefallen, das betrifft andere Anwendungen. Es funktioniert aber auch z.B. mit uberspace, wo "mein" Server sowohl per IPv4 als auch IPv6 erreichbar ist. Hier läuft meine Verbindung zum Server komplett über IPv6. Allerdings ist das ja nicht das eigentliche Problem hier im Thread. Aber auch der Composer hat ja bei uberspace kein IPv6-Problem. Liegt also wohl schon an der Netzwerkkonfiguration des Servers.
Jetzt war ich doch schon fast glücklich... und will mal eine Extension über den Manager installieren. Und da war die ganze Begeisterung dahin. Composer (im Manager) stürzt beim Updaten der Dependencies wegen Speichermangel ab:
Wohl gemerkt: "Nur" Symfony, Contao und eine Erweiterung... aber das kommt davon, wenn man so wenig Speicher hat. 1G als max mem für PHP - wie soll das auch reichen??? Ein bischen Googeln zeigt das Problem: Composer braucht so viel. Is halt so. Punkt.PHP-Code:
Updating dependencies
Error: "Out of memory (allocated 1073731976) (tried to allocate 4096 bytes)" in phar:///var/www/html/web/contao-manager.phar.php/vendor/composer/composer/src/Composer/DependencyResolver/RuleWatchGraph.php on 52
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
Process terminated with exit code 255
Reason: Unknown error
Was machen eigentlich alle die, die hier angeblich mit jedem billigen Hosting zu recht kommen??? Strato und Konsorten haben meines Wissens üblicherweise 256 MB??? Den Composer einfach nie starten? Ohne Erweiterungen arbeiten?
Und dann lese ich, man soll die Installationen doch bitte auf einem lokalen Server durchführen (Website und DB mal kurz "lokal holen") und dann wieder auf den Prod.-Server zurück kopieren... Im Ernst?
Ich wäre sehr glücklich, wenn jetzt einer der hier aktiven Profis sagen würden, dass ich nur was falsch verstanden oder konfiguriert habe und der Composer doch eigentlich nur 200MB braucht. Dann bin ich auch gerne bereit, mich weiterhin für 4.4 zu begeistern... naja.... zu erwärmen. Aber SO ist das Ganze doch einfach nicht zu gebrauchen...
Ja!
Ich mache Updates grundsätzlich NIE auf einem Produktiv-System - schiefgehen kann immer was, auch ohne Composer ;)
Ich mache das folgender maßen:
- DB sichern (mit DB-Backup)
- mit tar das Verzeichnis auf der Konsole packen und anschließend auf meinen lokalen Rechner laden
- entpacken, DB-einspielen, localconfig.php anpassen
- Lokal die Updates ausführen (composer update)
- testen ob alles ok ist
- lokale DB sichern
- lokales Verzeichnis mit tar packen und hochladen
- auf Server entpacken, DB-einspielen, localconfig.php anpassen
Hmm, also ich habe mit 1GB durchaus mehrere Erweiterungen installiert. Welche hattest du denn versucht zu installieren, ich hab ja sowieso noch die Testinstallation von gestern übrig. :D
Tatsächlich! 2GB reichen! Aber jedesmal die Installation hin- und her kopieren? Ein Paketmanager muss auch mal (oder grade) dazu benutzt werden, zwischendurch die Dependencies zu prüfen um auf dem neuesten Stand zu bleiben. Das ist doch grade einer der wesentlichen Vorteile! Man stelle sich nur mal vor, dass man eine komplette Linuxinstallation erstmal durch die Gegend kopiert jedesmal wenn man mit apt-get nur mal kurz ein Paket aktualisiert... Mal abgesehen davon, dass einige meiner Kundeninstallationen gar nicht mal so einfach hin- und her zu kopieren sind.
Ach ja... nach der Installation der ersten Extension (und dem Update der Dependencies...) kam das hier:
Der Composer kann also eine Datei, die er selber angelegt hat, nicht mehr löschen. Aber ich soll den Composer ja sowieso nicht auf dem Server ausführen... bin ich wohl selber schuld.PHP-Code:
Using version ^2.2 for madeyourday/contao-rocksolid-custom-elements
/var/www/html/composer.json has been updated
Loading composer repositories with package information
Updating dependencies
Package operations: 1 install, 0 updates, 0 removals
- Installing madeyourday/contao-rocksolid-custom-elements (v2.2.3): Downloading (100%)
Writing lock file
Generating optimized autoload files
ocramius/package-versions: Generating version class...
ocramius/package-versions: ...done generating version class
> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication
Script Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication handling the post-update-cmd event terminated with an exception
--------------------------------------------------------
Exception occured: Could not delete /var/www/html/var/cache/prod/ContainerWndbyxk/getConsole_Command_AssetsInstallService.php:
Nach acht glücklichen Jahren mit Contao war es das dann wohl für mich. Schade. Aber ich bin für Contao 4 offensichtlich keine ausreichende Ressource.
@Stefko
Das bezieht sich aber auf Contao 3.5 oder nicht? In CTO 4 (wovon doch hier die Rede ist) sind die DB Einstellungen doch in app/config/parameters.yml oder hab ich da jetzt wieder etwas falsch verstanden?:cool:Zitat:
entpacken, DB-einspielen, localconfig.php anpassen
Also ich habe mit 1GB folgende Erweiterungen installiert:
bugbuster/contao-visitors-bundle
do-while/contao-backupdb-bundle
hofff/contao-opengraph
madeyourday/contao-rocksolid-columns
madeyourday/contao-rocksolid-custom-elements
madeyourday/contao-rocksolid-frontend-helper
madeyourday/contao-rocksolid-icon-picker
madeyourday/contao-rocksolid-slider
So viele Erweiterungen habe ich noch nie gleichzeitig benutzt. Normalerweise mache ich Dinge, die ohne Erweiterungen machbar sind, auch wirklich ohne eine Erweiterung. Gut, BackupDB habe ich überall drin, ist einfach bequemer ohne extra phpMyAdmin bemühen zu müssen und die passende DB auszuwählen. Ich hätte ja Metamodels probiert, aber extra deswegen jetzt ins early-adopter Programm einzusteigen ...
Edit: Gibt es eigentlich eine Möglichkeit rauszubekommen, wieviel RAM und Skriptlaufzeit tatsächlich gebraucht wurde?
Es reicht, wenn du lokal (oder auf einem anderen Server) das update machst und dann die composer.json und composer.lock hoch lädst und dann auf dem Zielsystem nur noch ein composer install machst. Dann hast du dort nicht mehr die Speicherhungrigen Abhängigkeitsprüfungen. Bei dem ganzen muss nur auf die passende PHP Version geachtet werden.
Das alles und noch viel mehr wirst du auch hier im Forum finden, da es schon öfter erklärt wurde.
Ich verstehe diesen Thread inzwischen eigentlich nur noch als Sammelsurium, damit du nicht selber suchen musst. Zu jedem deiner Probleme gibt es durchaus schon hilfreiche Threads (solange die mit Contao und Composer zu tun haben.. die anderen Dinge kannst du besser wo anders klären).
So langsam wäre ich fast dafür, dass dieser Thread geschlossen wird, da es hier ja eh nicht wirklich um die Grundsatzfrage 'Contao oder was anderes' geht, sondern um viele kleine Probleme, die auch seit Jahren schon längt hätten gelöst sein können, wenn man mal im Forum sucht (oder wahlweise auch wo anders).
Viele Grüße
Lernbereitschaft gehört dazu und macht es auch gerade spannend. Man "rostet" nicht. Der Punkt "Weiterbildung" ist allerdings vor allem für soloselbstständige Designer eine ziemlich große Hürde, was Zeitaufwand und damit Kosten betrifft - und gefühlt geht die Weiterentwicklung auf allen genannten Gebieten von Jahr zu Jahr schneller voran. Das ist manchmal kaum zu stemmen.
*Lach*, dazu muss man erst mal wissen, was eine Konsole ist bzw. von welcher Konsole die Rede ist. Es soll Leute geben, die bisher mit FTP gut klar kamen. Und da kommen dann auf einmal Begriffe wie SSH/Tunnel, Konsole/Terminal/Kommandozeile (es gibt ja dann auch noch gleich diverse Begriffe für ein- und dasselbe), Git, Pakete, Composer, Symfony, Symlinks usw. auf einen zugeschwirrt, von denen man bisher dachte, das geht nur Programmierer etwas an. Aber nein, dieses Riesengebirge muss man selbst auch besteigen, findet aber manchmal kaum geduldige Bergführer. Die sind schon oben und rufen nur "ist doch alles ein Kinderspiel!".
Klar, was man kann, ist immer leicht. Und ebenfalls klar, man muss es eben auch angehen. Dafür braucht man wiederum Zeit - und ist dankbar für jede geduldige Hilfe, die ich hier in den letzten Tagen gefunden habe :D
Kann ich (Frontendler) genauso gut nachvollziehen wie die Tatsache, dass die "die schon oben sind" manchmal gar nicht bemerken (können), dass ein anderer noch ein bisschen detailierte Nachhilfe benötigt.
Ich glaube aber, dass sich hier im Forum viele dafür einsetzen alle Interessierten mitzunehmen. Schwierig wird es bei unsachlicher Meckerei und Abwehrhaltung.
Eine sehr brauchbare Ressource für vieles im Umfeld SSH ist das Uberspace Wiki/FAQ. Da wird unter anderem detailliert beschrieben, wie man unter Windows PUTTY installiert und konfiguriert für den Zugriff auf einen Webserver über SSH. Aber auch sonstige Vorgehensweisen für bestimmte Aufgaben kann man sich da abschauen. Das funktioniert zumeist auch bei anderen Hostern genauso.
Ergänzend zu Marens Beitrag: Geholfen wird hier glaube ich sehr ordentlich und ausführlich. Schwierig wird es auch dort, wo jemand sich ein neues Auto mit zukunftsfähigen Features anschafft (Contao 4), eine zu kleine Garage hat (Billighoster) und Contao die Schuld gibt, das die Garage zu klein ist.
Das ist wohl wahr und verständlich. Aber genau aus diesem Grund habe ich mir auch viel Zeit gelassen, bis ich mich an die Installation von C4 rangewagt habe, weil ich innerlich total frustriert und auf Abwehr war. (Inzwischen - und auch nach dem Umsehen nach alternativen CMSsen habe ich aber auch einsehen müssen, dass nicht nur Contao auf Symfony aufsetzt.)
Ich bin ja schon seit ersten Typolight-Versionen dabei, und jahrelang hatte ich das beruhigende Gefühl, dass Contao einerseits immer sehr fortschrittlich weiterentwickelt wird, andererseits aber auch von "Privatleuten" installiert und gewartet werden kann und dass man als "Profi" mit ganz rudimentären PHP-Kenntnissen noch das eine oder andere selbst anpassen kann.
Dieses Gefühl hatte sich mit der Ankündigung von C4/Symfonie/Konsole... geändert und ich hatte eher die Befürchtung, dass Entwickler und Agenturen uns komplett abhängen. Das ist zwar legitim, aber nicht mehr ganz deckungsgleich mit der einstigen Philosophie. Früher gab es immer mal Diskussionen mit dem "Fußvolk", wo man denn eigentlich hin will und für welche Klientel Contao da sein soll.
Ich bin genau wie Du Alleinunterhalter, vielleicht mit etwas anderem Background - Quereinsteiger nahezu ohne IT-Vorkenntnisse aber aus der Technik kommend.
Die Angst/das Gefühl "abgehängt" zu werden hatte ich bisher nie.
Hier wird so geduldig alles auch zum x-ten Mal erklärt. Für meinen Geschmack auch nie mit Hochnässigkeit. Allenfalls mal unter Verwendung von reichlich Fachjargon, was man in Zeiten von Google aber durch ein bisschen Recherche ganz gut kompensieren kann. Schlimmstenfalls muss man dann halt noch einmal gezielt nachfragen.
Und selbst als "Frontendler" kommt man ja heute nicht mehr ohne Console (node.js, node-script Tasks, Grunt, Gulp etc. ) zwecks less, sass, image Optimierung, svg/Icon sprite Automatismen usw. aus.
Auch ich als "Alleinunterhalter" muß mich halt mit diesen Dingen auseinandersetzen und immer Neues lernen ...
Ich bin froh in diesem Forum so zahlreiche Hilfestellungen finden zu können ...
Genauso ist es.
Mann kanns aber auch so sehen:
Contao hat über Jahre hinweg wunderbare Mittelklassewagen produziert.
Die haben in 99% der Garagen Platz gefunden.
Nun wirft Contao einen Full-Size-SUV auf den Markt.
... manche werden wohl die Automarke wechseln, und nicht die Garage :)
Hallo,
evtl. sollten man da doch ein wenig weiter abstrahieren.
Tatsache ist das ich für meine eigenen Belange (nach dem Release der 4.x) den Hoster gewechselt habe (von 1und1 - die hatten zu diesem Zeitpunkt noch keine php7 cli im Angebot - nach hostingwerk). Preislich fiel mir dies nicht schwer und alles außer webhosting/Datenbank u. E-Mail habe ich eh nie benötigt. Dies - zugegebenermaßen - im Hinblick auf eine bekanntermaßen funktionierende Umgebung um während der Lernphase für die LTS bzw. 4.5 Fallstricke seitens des hostings ausschließen zu können. Mittlerweile habe ich auf meiner NAS und unter Windows/xampp weitere "lokale" Umgebungen hinsichtlich der 4er Versionen zurück gewinnen können - nicht zuletzt aufgrund dieses Forums mit seinen unermüdlichen Moderatoren und all den anderen Mitgliedern ...
Grundsätzlich kann ich mich erinnern das - zumindest meine eigene Lernkurve - Release/Switches von Typolight, Contao2 u. Contao3 schon immer mit neuen Wissen u. hiesigen Nachfragen verbunden waren ...
Die "pure" Installation der LTS/4.5 via .zip o. composer o. CM ist weiterhin bei fast allen shared hostern o. Windows/xampp (entsprechend den Systemvoraussetzungen) gegeben. Problematisch wird es es erst hinsichtlich der Abhängigkeits Auflösung von Erweiterungen/Pakten über den Composer - bzw. via CM als quasi composer GUI. Auch hierzu werden hier im Forum zahlreiche Lösungswege aufgezeigt und es wird sich sicher weiter und stetig verbessert ...
Und wenn ich mich anderswo umsehe ist die composer Thematik - sagen wir mal - zumindest ähnlich umfangreich/ausbaufähig:
https://www.google.de/search?q=typo3+php+composer
https://www.google.de/search?q=joomla+php+compose
https://www.google.de/search?q=drupal+php+composer
https://www.google.de/search?q=magento+php+compose
Ich bin dabei zahlreiche 3.5 Installationen bei unterschiedlichen Hostern auf die LTS umzustellen - Hierbei ist von Vorteil, das ich fast immer auf Erweiterungen verzichtet hatte - sofern irgendwie möglich - sondern die 90%tigen Anforderungen (Slider/Gallerie/Mobil-Navigation etc.) über die Core Mittel/Template realisieren konnte. Alle anderen werde ich in Bezug auf die Erweiterungen und das Hosting nach und nach prüfen ...
Insofern - Chancen sehen und nutzen
Wird schon ...
Lieben Gruß
Franko
Ich habe mehrere einfache Websites mit Contao 3.5, für die abgesehen von der Aktualisierung von Daten auch in ferner Zukunft Zeit kein Handlungsbedarf absehbar ist. Leider sind auch einige Erweiterungen von 3.5 im Einsatz. In ca. 1 1/2 Jahren ist Contao 3.5 end of life und bis dann besteht Handlungsbedarf.
Was ich zur Sprache bringen möchte: Es wäre mir, und vielleicht auch noch einigen anderen sehr, sehr geholfen, wenn die Sequrity für Contao 3.5 noch möglichst lange gewährleistet werden könnte. Dann könnte ich zu gegebener Zeit, wenn es dann soweit ist und auch mit Mehrwert begründet werden kann, einen Relaunch mit der dann aktuellen Contao-Version planen.
Gruss, Golem
Siehe https://contao.org/en/release-plan.html
Bis Mai 2019 bekommt Contao 3.5 noch Security Fixes.
Beim Nordtag wurde erwähnt, dass ein anderes bekanntes CMS die Updates nach EOL gegen eine Gebühr pro Domain/Installation anbietet.
Vielleicht ist das ja auch eine faire Lösung, die sich für Contao 3.5 etablieren könnte.
Das steht und fällt natürlich mit der Bereitschaft der Kunden ein paar mehr Euro in die Hand zu nehmen und das ganze zu finanzieren.
Genau das ist m.E. ein Knackpunkt. Je älter das System wird desto aufwendiger wird es das System noch mit Sicherheitsupdates zu versorgen und desto weniger Kunden werden es sein, die das noch finanzieren wollen.
Contao "lebt" ja auch in der 3er Version nicht im luftleeren Raum. Da gibt es Coreabhängigkeiten von Fremderweiterungen. Auch die werden weiterentwickelt oder bekommen Sicherheitspatches. Damit sind sie dann vielleicht nicht mehr kompatibel mit Contao 3 und es sind größere Anpassungen in Contao 3 erforderlich um das zu händeln.
Erweiterungen werden zunehmend nicht mehr im ER gepflegt. Wer aus verschiedensten Gründen nicht auf Contao 4 umsteigen möchte, hat nach meiner Erfahrung überdimensional häufig den ER im Einsatz. Da wird dann der Aufwand für das aktuell halten der Erweiterungen zunehmend größer, ganz davon abgesehen, dass auch dort alle Sicherheitslücken in beiden Versionen (Contao 3 und 4) geschlossen werden müssten ohne dass es zu Inkompatibilitäten kommt.
So ein Modell gibt es ja z.B. auch bei Webhostern mit der PHP-Version (zum Beispiel 1&1). Wer eine veraltete PHP-Version weiter nutzen will, muss dafür extra bezahlen. Der Wunsch besteht ja oft wegen irgendwelchen Skripten, die irgendwann mal irgendjemand :D geschrieben hat und die jetzt keiner (beim Kunden) mehr versteht. Anstatt einmal herzugehen und das Skript auf eine aktuelle Version zu heben (oder heben zu lassen), zahlt man lieber für die alte PHP-Version. Ist ja letztlich exakt das gleiche Problem wie hier im Thread. Hier ist die veraltete Version dann eben Contao. Hier erhebt sich dann allerdings zusätzlich die Frage, bis zu welcher PHP-Version Contao 3.5 eigentlich laufen wird, so dass man irgendwann sowohl für die veraltete Contao-Version UND die veraltete PHP-Version wird zahlen müssen. Oder man muss noch mehr für die Pflege von Contao 3.5 bezahlen, damit auch die Kompatibilität zu neuen PHP-Versionen nachgeführt wird nach EOL. Spätestens da wird man dann aber Probleme mit den alten Erweiterungen bekommen und halt doch irgendwann ein Contao-Update fahren müssen. Ob das durch den dann größeren Versionssprung einfacher und günstiger wird, wage ich zu bezweifeln.
@Golem: Der Mehrwert ist doch beim Update auf die neue LTS-Version allein schon die Aktualität und Sicherheit der Installation für mehrere weitere Jahre. Ein Update für eine "einfache Website" ist ja in der Regel auch kein Drama. Viele 3.5 Erweiterungen laufen schon mit 4.4. Bei anderen relativ häufig genutzten Erweiterungen sollte man halt mal den Entwickler darauf ansprechen und eventuell lieber hier dann das Geld investieren als in die Pflege eines veralteten Systems. Die Lebensdauer der LTS-Versionen ist ja eh schon deutlich verlängert worden. Systemwartung gehört eben auch zu den Kosten eines CMS.
Irgendwie störe ich mich in dem Zusammenhang immer an Begriffen wie
- Admin-Profis
- Konsolen-Profis
- Hardcore-Entwickler
- Nerd
- ...
Ich gebe allen Recht, die sagen für den Privatanwender der mal eben seine private Hompage bauen will ist Contao 4 nicht ganz das optimale Werkzeug.
Ich bin mir aber auch nicht sicher ob das Contao 3 war. In dem Bereich sind Baukastensysteme durchaus eine sehr gute Alternative.
Wenn eine professionelle Website erstellt werden soll ist m.E. nicht allein Contao 4 ein Problem. Da gibt es weit aus mehr zu beachten als das, was das jeweils verwendete CMS an Anforderungen mit sich bringt.
Wie häufig darf ich mir anhören "eine Website bringt mir ja eh nichts". Meist hat das auch einen Grund.
Für professionelle Webworker (auch wenn man es nur nebenberuflich macht) sollten die Anforderungen die Contao 4 stellt, keine unüberwindbare Hürde darstellen. Keiner muss Konsolen-Profi sein. Ein paar wenige Befehle reichen für den Alltag. Wenn es ins Eingemachte geht, dann gibt es Hilfe im Forum oder man lässt sich direkt unterstützen bei den Bereichen die man gar nicht machen möchte.
Muss man ja auch nicht. Wie sinnvoll bestimmte Dinge sind ist sicher auch eine Frage des eigenen Workflows. Manches kann auch viel Erleichterung mit sich bringen, wenn man sich einmal durchgebissen hat. Anderes passt überhaupt nicht zur eigenen Arbeitsweise. Wenn man bestimmte Dinge aber nicht wenigstens mal sehr genau in Augenschein nimmt, wird man das auch nie merken.
Ich kann es bei mir z.B. bei sass,scss, less, compass, bourbon und gulp relativ genau beschreiben.
Less habe ich getestet, die Idee fand ich gut aber bei einigen Dingen fehlte mir für die "optimale" Erleichterung einiges, was ich bei scss gefunden habe. Sass habe ich von vornherein abgelehnt, weil ich mich durchaus kenne und weiss, dass mir das Suchen nach Einrückungsfehlern ein Graus wäre.
Mit Compass bin ich nie ganz warm geworden, weil ich viele Dinge die Compass mitgeliefert hat nicht genutzt habe. Dafür hat mir dann bourbon mehr zugesagt. Auch die Integration in meine Entwicklungsumgebung ging mir leichter von der Hand.
Vor gulp habe ich mich lange gedrückt, weil ich anfänglich Probleme hatte node.js in meiner Windows-Entwicklungsebene korrekt zum Laufen zu bringen. Jetzt möchte ich nicht mehr drauf verzichten.
Das ausprobieren kostet Zeit, die einem unter Umständen woanders fehlt - ja. Manchmal lohnt es sich aber und man kann aus voller Überzeugung sagen, warum man das ein oder andere nicht nutzt. Das gibt mir ein besseres Gefühl, als wenn ich bestimmte Dinge gar nicht versuchen würde.
Hallo,
vermutlich stört es Dich deshalb, weil Du zur Seite der "Wissenden" gehörst und Dir gar nicht vorstellen kannst vor wie viel Böhmischen Dörfern man stehen kann, wenn man einige Beiträge hier im Forum durchstöbert oder kryptische Fehlermeldungen ließt.
Es gibt dann auch noch die Fraktion der "nicht ganz Wissenden" und trotzdem "nicht ganz Dummen". Jene, die beispielsweise seit Jahren im Feierabend oder am Wochenende Webseiten für (beispielsweise) Sportvereine basteln ... einem Klientel, bei dem grundsätzlich kein Geld fließen kann ... weil keines da ist. Professionelle Unterstützung ist da schlicht keine Option.
Contao 3 war (und ist) ein hervorragendes Werkzeug für eben jene "nicht ganz Dummen" User, für die ein Homepage-Baukasten (wie sie abends in Fernsehspots beworben werden) nicht die Methode der Wahl ist. Contao 4 ist das nicht mehr. Contao 4 hat ein Maß an Komplexität (und Fragilität) überschritten, die nicht mehr sinnvoll nutzbar ist, wenn man sich nicht wirklich intensiv mit der Materie auseinandersetzen will oder kann. Werkzeug, im Sinne von: Nutzt mehr als es schadet. Mithin wird es zunehmend zu einem Tool, dass die Normalo-User immer mehr abhängt und die Kluft zwischen den "Wissenden" und "Unwissenden" verbreitert. Da kann man nun anderer Wahrnehmung sein (insbesondere als "Wissender" wäre es seltsam, wenn das nicht so ist) ... meine Wahrnehmung ist nun mal so wie oben beschrieben.
Ein Blick über den Zaun zu beispielsweise Wordpress oder Joomla! lässt erahnen, dass da zwar viele Probleme aus Contao 4 nicht vorhanden sind, dafür aber viele andere, die man sich auch nicht unbedingt ans Bein binden möchte.
PT
Finde Dich einfach damit ab, dass Contao 3 im nächsten Jahr tot ist. Der Einsatz von Tools ist - genau wie der Bedarf an Weiterbildung - nicht abhängig vom Budget eines Sportvereins, das in den meisten Fällen übrigens grösser ist als man denkt. Oder denkst Du, Sporthallen, Plätze und Vereinsheime wachsen auf Bäumen? Sorry, das ist weltfremd.
Contao 4 ist ein genauso stabiles Werkzeug wie es Contao 3 war. In vielen Bereichen empfinde ich es sogar als zugänglicher und flexibler. An der Stabilität habe ich bisher nichts auszusetzen - ganz im Gegensatz zu den ersten 3er-Versionen mit einem komplett vergurkten Konzept des datenbankgestützten Dateisystems. Das war dann auch erst mit der ersten LTS 3.2 einsetzbar.
Ich verstehe nicht, warum Du Contao 3 glorifizierst anstatt Dich mit Contao 4 zu beschäftigen. Du stellst hier Behauptungen in den Raum, die schlicht nicht richtig sind. Wo bitte ist Contao 4 'fragil'? Was ist von der Funktion für 'normale User' (was soll das sein?) anders, vom aufgeräumten Backend mal abgesehen? Bekommst Du einen Herzkasper wie bei Office, wenn die GUI jetzt solid statt mit Verläufen ist?
Ich kann deine Einschätzung verstehen. Contao hat halt unterschiedliche Nutzergruppen - die Normalo-User, die bisher mit Contao und 2-3 Erweiterungen alles abgedeckt bekommen. Es gibt aber auch die Nutzergruppe von Agenturen, die Contao für komplexe Webanwendungen einsetzen, für die Contao 4 nun eine riesige Arbeitserleichterung darstellt. Die letzere Gruppe ist erfahrungsgemäß die, die sich kaum hier im Forum tümmelt und damit weniger repäsentiert wird in dem Forum. Als Entwickler habe ich in einigen Contao-Projekten mitwirken können, wo das Contao-System stark an die Grenze des Möglichen getrieben wurde. Ohne die Weiterentwicklung in Contao 4 hätte sich meinerseits die Frage gestellt, ob es Zeit für etwas neues wäre.Zitat:
Contao 3 war (und ist) ein hervorragendes Werkzeug für eben jene "nicht ganz Dummen" User, für die ein Homepage-Baukasten (wie sie abends in Fernsehspots beworben werden) nicht die Methode der Wahl ist. Contao 4 ist das nicht mehr. Contao 4 hat ein Maß an Komplexität (und Fragilität) überschritten, die nicht mehr sinnvoll nutzbar ist, wenn man sich nicht wirklich intensiv mit der Materie auseinandersetzen will oder kann. Werkzeug, im Sinne von: Nutzt mehr als es schadet. Mithin wird es zunehmend zu einem Tool, dass die Normalo-User immer mehr abhängt und die Kluft zwischen den "Wissenden" und "Unwissenden" verbreitert. Da kann man nun anderer Wahrnehmung sein (insbesondere als "Wissender" wäre es seltsam, wenn das nicht so ist) ... meine Wahrnehmung ist nun mal so wie oben beschrieben.
Wie ich schon mehrfach betont habe, zeigt ja die Investition in den Contao Manager, dass die Nutzergruppe der "Normalos" nicht vergessen werden soll. Klar, hakt es hier und dort noch, aber es wird dran gearbeitet - und vor allem durch Leute, die den Contao Manager nicht wirklich benötigen.
Doch genau das kann ich mir vorstellen. Ich bin als Quereinsteiger 2011 nicht mit dem Wissen von heute ins Forum gekommen. Ich habe hier gerade anfänglich viel mitgelesen, auch über Probleme die ich selbst noch nicht gehabt habe. Ich habe dabei eine ganze Menge gelernt. In einigen Bereichen stehe auch ich häufiger vor "Böhmischen Dörfern" und merke mal wieder was ich alles nicht weiss. Das muss ja aber nicht so bleiben.
Ich bin z.B. heute dem Contao Manager sehr dankbar, dass er unter Windows noch nicht funktioniert. Ohne diesen Umstand hätte wahrscheinlich mein innerer Schweinehund gewonnen und ich hätte nur im äußersten Notfall zur Konsole gegriffen. Heute bevorzuge ich immer mehr die Konsole und habe die Standardbefehle inzwischen auch halbwegs im Kopf.
Ich nutze Contao auch nur in meiner Freizeit und habe inzwischen ein paar Webseiten mit der 4.4 aufgesetzt (immer mit dem Contao-Manager). Trotz günstigem Hosting (uberspace, allInkl, webgo) gab es keine Probleme - es ist nur manches anders als früher. Nachdem ich mal verstanden hatte, dass man einen Unterordner /web braucht und darauf die Domain richten muss, fand ich die Installation mit dem CM sogar smarter als früher. Und das Anlegen einer Kopie einer Webseite geht mit den neuen Möglichkeiten sogar einfacher und schneller als früher. Und dabei habe ich noch nie den Composer aus einer Konsole aufgerufen und nutze meinen SSH Zugang nur, weil es von einer Linuxumgebung so viel bequemer ist als mit irgendwelchen FTP-Programmen :-) (das hat natürlich nichts mit Contao 4 zu tun)
Viele der hier im Forum beschriebenen Schwierigkeiten passierten am Anfang der Version 4 oder bei der Migration von einer 3er Version. Und selbstverständlich muss man VOR der Verwendung einer Software prüfen, ob die Rahmenbedingungen stimmen (z.B. PHP-Version). Verlorenes Vertrauen - aus welchen Gründen auch immer - ist bekanntlich schwer wieder zu gewinnen...
Ich kann aus meiner Erfahrung allerdings nur sagen: wer heute auf Contao 4 LTS umsteigt braucht kein kostspieliges Hosting und keine 'Profi'-Kenntnisse um damit eine ansprechende und technisch ausgereifte Webseite zu bauen, ggf. mit fertigen Themes (z.B. Open Sauce).
Wer's individueller und/oder komplexer will musste auch früher Templates anpassen oder eigene Extensions programmieren. Hier hat sich einiges geändert und man muss sicher einiges lernen - aber Neues ist erstmal nur 'anders' und nicht 'schwieriger'. Ich bin überzeugt, dass Dank der neuen Techniken viele Dinge nun sogar einfacher werden als früher.
Hi Leute,
ich habe in den letzten Wochen 6 Installationen von einfachen Kundenwebseiten mit jeweils 3-4 Erweiterungen von 3.5.x auf 4.5.x upgedatet und zwei neue INstallationen direkt und 4.5.x erstellt. Dabei habe ich mit große Hilfe des Forums alle Klippen umschifft, und habe nun meinen Weg zum Updaten weitere Seiten gefunden.
Dafür ein großes DANKE an die Community!
Zum Thema möchte ich eine Frage stellen, ganz ohne Ironie: Welche konkreten Vorteile habe ich denn, wenn meine Seite statt auf contao 3.5.x auf 4.5.x basiert? Gemeint sind die Dinge die der Betrachter oder der Kunde hat, nicht ein schöneres Backend, oder sowas. Der schnellere Seitenaufbau wegen php7.x war ja schon bei 3.5.x ein Thema, oder?
Grüße
JK
Ich kann den Kunden den Updatservice oder Einzelupdates günstiger anbieten weil bei Contao 4 ein Update für mich wesentlich schneller von statten geht. Ganz besonders weil es sich bei den noch auf Contao 3.5 stehenden Installationen bei mir immer um Installationen handelt bei den auf Grund des Hostingpaketes der alte ER im Einsatz ist.
Betrifft bei meinen Kunden derzeit allerdings Contao 4.4 weil ich wenn es nicht zwingend erforderlich ist für Kundeninstallationen normalerweise LTS-Versionen nutze.
An alle, die überhaupt keine Probleme mit Contao 4 haben: Es geht nicht um Euch und es geht nicht darum, dass Ihr Lösungen kennt (und auch weitergebt - keine Frage). Es geht um die, die Probleme haben. Und das sind eben (zu) viele und die werden nach einer Alternative suchen. Und damit wird der Markt für Extension- und Template-Entwickler kleiner und kleiner. Das heißt, dass grade die Profis (im wörtlichen Sinne) weniger oder zu wenig verdienen.
Es gibt technische Probleme, die bei aller Begeisterung für Contao nicht weg zu diskutieren sind:
- Contao 4 lässt sich nur schwer bzw. gar nicht unter Windows installieren (Richtig übel für Intra- und Extranet-Anwendungen, die sehr häufig auf Win laufen)
- Contao 4 braucht min. PHP 7.1 (bei 4.4 als require eingetragen) was noch lange nicht alle Hoster können (z.B.: allInkl: PHP 5.6 lt. techn. Info, Hetzner PHP 7.02 im Repository)
- Der CM als "GUI für den Composer" braucht bei Updates (spätestens nach Erstinstallation) 1GB Speicher. Meines Wissens gibt es keinen(!) Hoster der 1GB PHP-Runtime-Speicher zur Verfügung stellt
- Contao 4 braucht PDO, was nicht zwingend bei jedem Hoster verfügbar ist
Das alles sind im Kern natürlich bekannte Composer- oder Symfony-Probleme und wahrscheinlich kann man sie alle irgendwie umgehen (anderen Hoster nehmen, anderes Betriebssystem nehmen, Composer-cycles auf einem Entwicklerserver laufen lassen und dann das Ergebnis als Ganzes auf den Liveserver kopieren, auf Composer / CM ganz verzichten, eigenen Server betreiben usw.) aber genau so ein Gewurschtel war bei 3.5 nie nötig. Jeder Hoster, jedes Betriebssysstem - Contao 3.5 läuft einfach. Und genau das hat Contao groß gemacht. Ich will keine Lösungen zu Problemen - ich will keine Probleme!
Und weil die Probleme eigentlich keine Contao-Probleme sind sondern in Composer und Symfony vergraben sind, werden sie auch nicht mit neuen Contao-Versionen verschwinden. Oder ggfls sogar schlimmer werden... so haben die Composer-Entwickler die interne Speicheranforderung auf 1.5GB erhöht.
Contao 4.4 braucht mindestens PHP 5.6, nicht PHP 7.1. Das steht bei dir drin, weil du eben mit PHP 7.1 die Installation durchgeführt hast. Contao 4.4 lässt sich nicht ganz so unproblematisch iunter Windows installieren wie 3.5, das ist richtig. Aber es lässt sich sehr wohl installieren. Viele hier haben es meines Wissens unter Windows installiert. Mein Allerweltspaket stellt mir jedenfalls die 1GB RAM für den Manager zur Verfügung, falls er denn wirklich soviel braucht. Mein Webhoster ist nicht der Einzige, der das tut, vielleicht kennst du einfach nur die Falschen. PDO könnte stimmen, aber jedenfalls schon mal mindestens 75% "fake news". PDO ist jetzt auch nicht unbedingt eine exotische Anforderung, da muss man jedenfalls nicht lange danach suchen.
Und da PHP 5.6 nur noch bis Ende des Jahres mit Sicherheitsupdates versorgt wird und PHP 7.0 sogar nur bis Anfang Dezember 2018 sollte Hetzner aber langsam die Beine in die Hand nehmen ;-)
Zip laden, /install aufrufen ...
Contao 4.5 benötigt PHP ab 7.1. PHP 7.0 hat End of Life im Dezember 2018. Die LTS 4.4 wird weit länger supportet. AllInkl bietet PHP 7.2. Hetzner kenne ich nicht. Mag sein. Hosteurope schläft, ja. Ansonsten mit PHP > 7.0: Cyon, Uberspace, Hostpoint, Metanet, Webgo, Netcup, 1und1 ... das sind so die, die ich gesehen habe.
Siehe obige Liste. 1und1 beschubst seine Kunden seit 20 Jahren. Ist so. Wird ihnen auf die Füsse fallen.
Nein? Ich zitiere mal:
Mir fällt aus dem Stand kein Hosting ein, das PDO nicht unterstützen würde. Darüber habe ich allerdings auch seit mindestens acht Jahren nicht mehr nachgedacht.Zitat:
PHP Data Objects sind seit PHP 5.1 ein fester Bestandteil der Sprache. Da PDO auf den neuen, stärker objektorientierten Ansätzen von PHP 5 aufbaut, ist die Nutzung erst seit dieser Version möglich. Vorher konnte die Software als PECL-Modul implementiert werden.
Mit Composer hat einzig zu tun, dass er recht gnadenlos offen legt, welcher Provider Dich bei PHP auf der Kommandozeile behumst. Kein Entwickler hat den Speicherbedarf erhöht. Wer wenige Abhängigkeiten hat, der kommt mit wenig Speicher hin. Wer viele hat, der braucht mehr. Das war schon immer so. Ich kenne auch die Fälle, in denen TYPOlight mit 28 MB wundervoll bis zu dem Zeitpunkt gelaufen ist, an dem ein User eine Menge an grösseren Bildern hochgeladen hat. Das hat fein geknallt. Und heute knallt es auch, wenn Du von Deinem Hosting zu viel willst.
Ich entwickle lokal ausschließlich unter Windows. Welche Probleme hast du?
Nein, Contao 4.4 benötigt mindestens PHP 5.6. Ab Contao 4.5 benötigt man PHP 7.1. All-Inkl und Hetzner haben beide PHP 7.1 zur Auswahl. PHP 5.6 wird wie schon erwähnt nicht mehr lange unterstützt.
Es gibt mehrere Hoster mit Shared Hosting Paketen wo du auch direkt am Server Paketupdates problemlos laufen lassen kannst. Nähere Infos dazu werden hier gesammelt: https://github.com/contao/contao-manager/wiki
Den Datenbank Treiber kannst du auch unter Contao 4 selbst wählen.
Siehe z.B.
https://community.contao.org/de/show...-4-0-auf-XAMPP
https://community.contao.org/de/show...-u-Xampp-7-2-1
Haben mir unter Windows geholfen - laufen ...
Ja, und hier antworten einige, die selbst mit Schwierigkeiten bekämpft hatten und die gemeistert haben - die zeigen, wenn man sich mit der Materie beschäftigt gibt es für vieles Lösungen. Das heißt nicht, dass bestehenden Probleme weggeleugnet werden, sondern dass man auch die Lernkurve meistern kann.
Dass die Theme-Entwickler evtl. einen kleineren Markt haben, mag sein, kann ich aber nicht beurteilen. Als Extension-Entwickler kann ich dir aber versichern, dass sich der Markt (für mich) nicht geändert hat. Nach meiner Erfahrung sind es auch die, die sich Contao 4 angeeignet haben, von einzelkämpfenden Frontendlern bis hin zu Powerusern und Agenturen, die die Entwicklung von Extensions finanzieren und damit ermöglichen. Die Breite Masse, die davon profitieren kann, ist meist nicht bereit sich an der Entwicklung zu beteiligen. Aber ich habe den Eindruck, dass sie hier am lautesten schreit.
Zum Thema Fake-News: Mem-Limits der Hoster, die mir auf die schnelle eingefallen sind (jeweils größtes Paket):
- Strato: 256 MB
- 1&1: 512 MB
- AllInkl: 256 MB
- HostEurope: 128 MB
- AlfaHosting: 156 MB
- Manitu: 128 MB
Welches "Allerweltspaket" stellt denn 1GB zur Verfügung?
Contao 4.4 braucht in der Tat nur PHP ^5.6
"... für den Manager zur Verfügung, falls er denn wirklich soviel braucht..." - braucht er. Aus der Doku der Composer-Entwickler: "Composer internally increases the memory_limit to 1.5G" (Quelle: https://getcomposer.org/doc/articles...y-limit-errors)
"Viele hier haben es meines Wissens unter Windows installiert." Symfony setzt zum Einblenden der Assets-Ordner in den Webordner symbolische Links mit relativen Pfaden und "Symlinks on windows are created by Symlink() which accept only absolute paths but not relative paths .relative paths on windows are not supported for symlinks" (Quelle: php.net) (Ob das unter dem aktuellen Win-Server noch gilt, weiß ich nicht - unter Server 2008 und 2012 scheitert die Installation)
"PDO ist nicht exotisch" - habe ich auch nicht gesagt. Aber auch nicht selbstverständlich. So muss man es z.B. bei LAMP-Servern bei Hetzner nachinstallieren.
Insofern 25% Fake-News...
Abgesehen davon: Vielen Dank für die lückenlose Bestätigung meiner Aussagen.
Das sind die PHP memory_limit Einstellungen für den PHP Prozess des Web Servers. Das hat nichts mit dem Speicherlimit zu tun, dass während eines Paketupdate Prozesses zur Verfügung steht.
Die Aussage, dass Windows keine relativen Symlinks unterstützt ist grundsätzlich falsch. Lediglich mit PHP können unter Windows keine relativen Symlinks angelegt werden - aufgrund eines Bugs in PHP, der zwar schon lange bekannt, aber mangels Interesse nie behoben worden ist. Symfony (und Contao) haben daher einen Fallback auf absolute Symlinks unter Windows. Und das funktioniert einwandfrei.
Deine Probleme unter den Windows Servern haben vermutlich eher mit der Berechtigung Symlinks anlegen zu können zu tun.
Wie schon erwähnt musst du nicht unbedingt PDO verwenden.
In diesem Kontext ist das leider schon wieder Kokolores, sorry. Der Kontext wäre: Wenn Composer aufgerufen wird, dann versucht er, die Variable für das Memory-Limit anzuheben. Auf 1.5G, damit er es warm und trocken hat. Wenn das möglich ist, dann nimmt er trotzdem nur den Speicher, den er benötigt. Das sind in den allermeisten Fällen keine 1.5G.
Im Übrigen ist das dann die Conveniance-Funktion, wenn Du Installationsabhängigkeiten auf dem Server auflösen möchtest. Wenn Du das nicht möchtest, dann machst Du das halt lokal, kopierst zwei Dateien auf den Server und lässt ihn dann dort seine Installationsarbeit verrichten. Das kostet in den allermeisten Fällen so gut wie gar nix™.
Z.B. Webgo CMS Power, uberspace und uberspace 7, Netcup - keine Ahnung welche der Webhosting 1000-8000 - jedenfalls läuft der CM da. Deine Werte gelten nicht alle, manche möglicherweise schon, unbedingt für die Konsole.
Nur weil das memory_limit, mehr oder minder eine freiwillige Selbstbeschränkung von PHP, auf 1,5GB gesetzt wird, heißt nicht, dass dies auch gebraucht wird. Ich glaube der Contao Manager macht das auch so, eventuell sogar auf 2GB. Ich kann mich aber auch täuschen. Das heißt jedoch nur, dass bei soviel allokiertem RAM PHP mit Fehlermeldung abbricht. Mehr RAM wird also nicht gezogen. Es heißt nicht, dass der entsprechende Prozess nicht schon bei 32MB vom Prozessmanager abgeschossen werden könnte.
Nur weil die Symlinks unter Windows anders, als absolute Symlinks erzeugt werden, heißt nicht, dass das unter Windows dann nicht funktioniert. Es macht nur (auf recht einfache Weise lösbare) Problemchen, wenn man die Installation auf einen Linux-Server überträgt.
Bei PDO war ich mir nicht sicher, aber laut Spooky wird das nicht einmal unbedingt benötigt. Und hier ist mit Sicherheit der LAMP-Server bei Hetzner der Exot und nicht der Regelfall. Welche MySQL-Version läuft da überhaupt?
Ich muss mich korrigieren, 100% Fake-News.:D Lückenlose Bestätigung? Offenbar lebst du in einer alternativen Realität mit alternativen Fakten. Du heißt nicht zufällig Donald mit Vornamen?:rolleyes:
Nicht? Composer ist ein PHP-Skript und als solches kann er nur soviel Speicher anfordern wie die memory_limit Einstellung zulässt. Alles andere würde mich wundern...Zitat:
Das sind die PHP memory_limit Einstellungen. Das hat nichts mit dem Speicherlimit zu tun, dass während eines Paketupdate Prozesses zur Verfügung steht.
Mag sein... ich kann nur sagen, dass die Installation scheiterte weil die Symlinks nicht angelegt waren.Zitat:
Deine Probleme unter den Windows Servern haben vermutlich eher mit der Berechtigung Symlinks anlegen zu können zu tun.
@lucina:Stimmt eingeschränkt - die Erhöhung findet ja nur statt, weil die Entwickler schon wissen, dass der Speicherhunger entsprechend ist. In vielen Fällen sind es dann wohl nur 1GB - 1.2GB. Leider immer noch sehr viel mehr als die Hoster zulassen.Zitat:
In diesem Kontext ist das leider schon wieder Kokolores, sorry. Der Kontext wäre: Wenn Composer aufgerufen wird, dann versucht er, die Variable für das Memory-Limit anzuheben. Auf 1.5G, damit er es warm und trocken hat. Wenn das möglich ist, dann nimmt er trotzdem nur den Speicher, den er benötigt. Das sind in den allermeisten Fällen keine 1.5G.
Aber letztlich sind alle Antwort-Posts nur Bestätigungen für mich. Nochmal in aller Deutlichkeit: Für eine breite Akzeptanz reicht es nicht, dass Contao nur bei bestimmten Hostern läuft oder nur nach dem Studieren des Forums und langem Gegoogle und dem trickreichen Beseitigen von Problemen. Contao muss auf jeder Plattform (und sei es noch so ein kümmerlicher Hoster) sofort und ohne Einschränkungen laufen. Bei 3.5 ging das (und einige meiner Kundenhoster waren wirklich das Hinterletzte)!
Ich weiß, dass dieser Traum ausgeträumt ist, denn Symfony und Composer werden wohl nicht mehr verschwinden. Und alle anderen Systeme, die Composer nutzen, haben die gleichen Probleme - zumindest wenn sie derart viele Vendor-Extensions nachladen (in Contao knapp 100(?))
Aber trotzdem ärgert es mich maßlos, dass ausgerechnet Contao, das bis dahin mit schlanken, pfiffigen Lösungen und einem eigenen, ebenfalls schlanken Framework daher kam und so alles richtig machte, sich jetzt diese Klötze Composer und Symfony ans Bein bindet - und dann gleich so maßlos Module nachlädt und so den Composer zum Speichermonster macht. Sorry - das waren für mich die falschen Entscheidungen. Etwas mehr Mut zur eigenen Leistung und etwas weniger "Wenn alle das machen, dann wir auch" hätte Contao seine Sonderstellung behalten lassen.
Über die Konsole ist das memory_limit by default 0 oder es wird ansonsten von composer selbst auf 1.5 GiB erhöht. Unabhängig davon sind die Zahlen die du genannt hast wie schon erwähnt die memory_limit Einstellung des PHP Prozesses für den Web Server. Direkt auf der Konsole bzw. für die geforkten Prozesse die der Contao Manager macht gelten andere Umgebungsbedingungen.
Diese Diskussion hat sich totgelaufen und kommt 5 Jahre zu spät.
Stimmt - es gelten andere Limits - in Linux gesprochen /etc/php/apache2 vs. /etc/php/cli. Ich kann mir nur nicht vorstellen, dass die Hoster in der cli-Datei signifkant höhere Werte einstellen. Mein erster Kontakt hiermit war übrigens ein 1&1-Hosting (512MB), das mit der bekannten Speicherfehlermeldung (z.B. hier erwähnt: https://community.contao.org/de/show...-aktualisieren) den MC bzw. den Composer "abschoss". Das Speicherlimit wird auch nicht erhöht -das kann der Prozess gar nicht über das PHP-Limit hinaus- , der Composer versucht es nur.
Solange Contao (oder streng genommen Symfony 3) so "fett" sind (oder es einen "schlaueren" Composer gibt) wird das Speicherproblem m.E. nicht verschwinden.
Auch wenn du es dir nicht vorstellen kannst ist das in den meisten Fällen so.
In restriktiv eingestellten Shared Hosting Umgebungen reicht der zur Verfügung gestellte Speicher oft nicht.
Doch, das geht. Es gibt aber viele beeinflussende Faktoren, nicht nur die schlichte memory_limit Einstellung.
Warum braucht der Composer so viel Speicher?
Das kann man am Besten den Composer mal selbst fragen.
Ich habe hier eine Installation ohne viele Erweiterungen (fast nur die eigenen), das sind schon 122 installierte Pakete!
Nun muss man sehen, dass es von jedem Paket verschiedene Versionen und Stände gibt, die jeweils eigene Anforderungen und Abhängigkeiten haben können.Code:F:\MAMP\htdocs\contao44lts>composer -v update --dry-run
Loading composer repositories with package information
Updating dependencies (including require-dev)
Dependency resolution completed in 2.041 seconds
Analyzed 15210 packages to resolve dependencies
Analyzed 1189901 rules to resolve dependencies
Package operations: 0 installs, 1 update, 0 removals
Updates: do-while/contao-pdfforms-bundle:1.0.2
- Updating do-while/contao-pdfforms-bundle (1.0.0) to do-while/contao-pdfforms-bundle (1.0.2)
Der Composer muss das alles berücksichtigen, so kommt er schon auf 15210 Pakete, aus denen er die beste und aktuellste Kombination finden soll, die möglich ist.
Dazu muss er in meinem Fall 1189901 Regeln prüfen um diese Kombination zu finden oder um eine Fehlermeldung auszugeben, dass es keine lauffähige Kombination gibt.
Ich denke bei der Prüfung sind dann die composer.json-Dateien aller 15210 Pakete in einer Entscheidungsmatrix im Speicher notwendig.
Bei diesen Größenordnungen, die übrigens deutlich von den verwendeten Erweiterungen und Modulen abhängen, kann man sich leicht die lange Laufzeit und den Speicherbedarf erklären.
Das hat aber alles nicht mit Contao zu tun, nur in sofern, dass man sich vor einigen Jahren für diesen zukunftsträchtigen Weg für Installation und Updates entschieden hat.
Mich persönlich ärgert viel mehr das die gleiche Diskussion hier zum xten mal geführt wird. Die Zeit die wir alle damit verschwenden könnten wir auch nutzten Doku zu schreiben etc. da hätten alle viel mehr von.
Contao hat eben diesen Weg als erstes CMS beschritten ich garantiere dir aber das die anderen nachziehen werden. Weil es einfach die logisch beste Entscheidung ist. Contao 4.4 ist die beste LTS die es von Contao jemals gegeben hat. Das entwicklen ist im Vergleich zur 3.5 er um Welten besser.
Das Contao jetzt nicht mehr überall läuft ist schade aber lässt sich nicht vermeiden, wenn die Hoster zeitgemäße Pakete bereitstellen funktioniert es auch. Das tun viele eben noch nicht, das wird aber kommen. Da drüber hinaus wird es auf absehbare Zeit sicherlich auch eine Lösung geben um die Abhängigkeiten extern aufzulösen und damit ist das Problem dann sowieso erledigt.
Der Contao Manager zeigt doch das genau die Zielgruppe die Contao mit GUI nutzen will nicht egal ist. Für die prof. Anwender würde die Kommandozeile vollkommen ausreichen. Der Manager ist zurzeit eben auch noch Beta, ihr müsst halt auch bedenken das Contao Open Source ist und alle freiwillig daran arbeiten da finde ich es etwas unangemessen mit sowas wie „mehr Mut in die eigene Leistung“ zu kommen.
Warum sollen sich die ehrenamtlichen um Probleme kümmern die schon gelöst sind? So kann doch viel effizienter gearbeitet und fokussierter entwickelt werden und das kommt am Ende Contao und allen Nutzern zu Gute.
Dito - Meine Sorge wäre vielmehr das derartige threads hier o. auf GitHub dazu führen das sich womöglich all die Core-Entwickler, Erweiterungs-Entwickler oder hiesige Forums-Moderatoren zukünftig nicht mehr so enthusiastisch ins Zeug legen und Ihre Zeit für dieses Projekt daher einschränken werden ...
Nicht falsch verstehen: Kritik (wie von DampfHans u.a. hier formuliert) muß auch erlaubt sein und kann weiterhelfen ...
Ich glaube die meisten Vorteile liegen eher auf Entwicklerseite. Wobei ich mich damit noch gar nicht beschäftigt habe, weil ich nur für Contao 3 Erweiterungen programmiert habe. Ich sehe also noch nichts von den Vorteilen, weil ich jetzt erstmal viel Neues als Entwickler dazulernen muß.
Nein nicht wirklich. Du hattest explizit gefragt welche konkreten Vorteile der Betrachter oder Kunden hat.
Dem Betrachter einer Website ist es m.E. vollkommen egal welche Technik hinter eine Website steht. Er möchte das finden was er gerade sucht (Übersichtlichkeit, logischer Aufbau etc.), erwartet das die Website fehlerfrei funktioniert und freut sich wenn sie auch noch hübsch anzuschauen ist. Je nach Mentalität bekommen einzelne Punkte unterschiedliche Gewichtung.
Bei den Kunden hast Du das Backend in Deiner Frage schon fast ausgeschlossen. Damit fällt der Vorteil der Verbesserungen im Backend schon weg. Außerdem ist es bei meinen kleinen Kunden häufig so, dass sie zwar viel Wert auf die Möglichkeit legen, Inhalte einpflegen zu können, in der Praxis aber doch häufig darauf verzichten. Bei Kunden die Inhalte einpflegen, das sind bei mir z.B. Print- bzw. Werbeagenturen, die gern Ihren Kunden auch eine Website anbieten möchten, aber die Einrichtung des CMS und die Umsetzung des Layouts nicht selbst übernehmen wollen sieht das etwas anders aus. Die schauen schon auch aufs Backend.
Was als System dahinter liegt ist auch denen weitestgehend egal. Wichtig ist nur, dass ich die Funktionalitäten umsetzen kann, die gewünscht sind und das Sie möglichst komfortabel und flexibel die Inhalte eingeben können, die sie brauchen.
Was man bei der ganzen Diskussion einfach auch berücksichtigen muss ist, dass sich auch Erweiterungen weiter entwickeln (auch in der Funktionalität), die wie z.B. bei [calender_extended] nur noch im contao 4 bundle weitergepflegt werden, wenn ich es richtig gelesen habe. Wenn ich die Funktionalität nicht benötige und der Sicherheitsaspekt noch gewährleistet ist, wäre es kein konkreter Vorteil für den Kunden, wenn ich aber irgenwann in einigen Jahren doch updaten müßte und der Sprung dann über mehrere Versionen geht, könnte das ein Nachteil für den Kunden sein.
Wenn man ganz provokant ist, darf man auch die Frage stellen welchen konkreten Vorteil bringt das CMS dem Betrachter einer Website bzw. welchen Vorteil bringt es dem Kunden, wenn der Kunde eine statische Präsenz wünscht, ohne Kontaktformular oder sonst irgendwelche Funktionalität.
Das ist zum Beispiel auch ein Grund warum Kunden bei mir eine Webvistenkarte durchaus auch als reine HTML-Seite bekommen können.
Siehe auch: https://contao.org/de/news/contao_4-4-0.html
... und noch 22 Gründe für Contao 4.4 von Leo.
Naja ich meinte eher wegen der Auflistung der Vorteile und den Folien der Keynote ;). Mittlerweile sind für Contao 4.5 ja noch weitere Vorteile hinzugekommen. Siehe dazu auch:
https://contao.org/de/news/contao_4-5-0-beta1.html
https://contao.org/de/news/contao_4-5-0-beta2.html
https://contao.org/de/news/contao_4-5-0-beta3.html
Vielleicht habe ich die Frage ja auch falsch verstanden. Für mich hatte @kubjo die Verbesserungen im Backend eigentlich ausgeschlossen. Die sind dem Betrachter der Website ja auch völlig egal und in meinem Fall auch vielen Kunden. Mir allerdings nicht, aber das war ja nicht die Frage.
Naja, ob eine Website Typo3, Drupal, WordPress, Contao, Joomla, pure Symfony, etc. benutzt ist dem Besucher sowieso egal. Indirekt ergeben sich aus den Möglichkeiten im Backend und in der Programmierung dann Vorteile für den Benutzer im Frontend.
Ja genau.
Ich habe eben Updates zweier Testinstallationen auf Contao 4.4.14 und Contao 4.5.4 via CM durchgeführt (jeweils mit einer Erweiterung).
Habe noch nicht einmal die Tasse Kaffee geschafft so schnell war das durch.
Das zum Thema "Benutzerfreundlichkeit: One Klick Button "Pakete aktualisieren" - man sieht also wohin die Reise geht ...
Ist auch eine Tatsache ( Ok - unter idealen Bedingungen hoster: hostingwerk ).
Lieben Gruß
Franko
Wo/wie kann man am besten (an einer zentralen Stelle?) feststellen, welche der Erweiterungen, die man bislang unter C3.5 nutzt, schon für C4.4 zur Verfügung stellen? Oder muss man da mit jedem Entwickler von 3.5-Erweiterungen Kontakt aufnehmen?
Über die Suche von https://packagist.org/ geht es wohl am besten. Man kann hier explizit nach Contao-Bundles (Für Contao 4 entwickelt) und Contao-Modulen (Meistens für Contao 3 entwickelt, ggf. Contao 4 fähig) suchen:
https://packagist.org/?q=&p=0&hFR%5B...=contao-bundle
https://packagist.org/?q=&p=0&hFR%5B...=contao-module
Bin auch seit längerem auf der Suche nach einem Ersatz, möchte mir jedoch nicht Typo3 oder WP antun.
Eventuell könnten dich folgende CMSe interessieren:
Sulu CMS: https://sulu.io/de
Ähnliches Content-Management Konzept, wie Contao, finde ich.
Ebenfalls deutsche Entwickler, falls das für dich wichtig ist.
Grav CMS https://getgrav.org/
Sehr modernes, flat-file CMS. Content wird hauptsächlich über Markdown gepflegt, es gibt aber auch einen WYSIWYG Editor für End-Kunden.
Leider ist die ganze Modularität, wie bei der Contao Content Pflege nicht geben. Mann muss seine individuellen Content Elemente selber mit Hilfe von Twig zusammenstellen.
Das optionale Backend ist extrem feature-reich und die Community ist relativ groß.
concrete5 https://www.concrete5.org/
Sehr einsteigerfreundlich, riesen Community, viele Themes + Plugins.
Das Ökosystem erinnert mich ein bisschen an WP, ist aber von Haus aus ein viel überzeugenderes CMS.
Ich persönlich bin immer noch auf der Suche, nach einem idealen Ersatz.
Vielleicht wirds am Ende gar kein PHP basiertes CMS sein, die letzten 3-4 Jahre haben einen Großen Umschwung in der Welt der Webentwicklung ergeben, und es lohnt sich den letzten Trends und Neuerungen zumindest ein wenig Aufmerksamkeit zu schenken.