Was kann Contao 4.x was Contao 3.5 nicht kann

[marq]

Hallo,

auf die Gefahr hin das es ein ähnlichen Thread schon gibt, möchte ich hier mal meine kurze Erfahrungen mit Contao 4.5, bzw. den Vergleich zu Contao 3.5 nieder schreiben und bitte darum es vielleicht kurz und knapp zu ergänzen.

Achtung: Der Security-Support von Contao 3.5 endet im Mai 2019

Änderung in Contao 4.X

1. Backend
- Neuer Style (nicht mehr so Altbacken)
- Element-Schnellauswahl
- Benutzergruppe: Es können jetzt erlaubte Bildformate für eine Gruppe oder Benutzer festelegt werden.
- TinyMCE wird jetzt in einem extra Template eingebunden, so das es update-sicherer ist.
- Im BE lassen sich in Popups Dateien leichter auswählen und bearbeiten.
- Nicht nur Dateien und Seiten lassen sich jetzt über das Popup verlinken, sondern auch News, Artikel, Events und FAQ.
- HTTP/2 Unterstützung

2. Frontend
- Keine XHTML-Unterstützung mehr.
- Einige Änderungen am HTML-Markup.
- Verbessung der HTML5-Semantik (events,news)
- Honeypot-Spamschutz


3. Webserver
- .htaccess-Bindung entfällt, da nun web/ als Document-Root verwendet wird.

Habe ich jetzt bis auf den Symfony-Budle-Part etwas übersehen?

[Spooky]

https://leofeyer.github.io/konferenz-2017/

Es gibt außerdem da und dort weitere Kleinigkeiten. Wie zB die Möglichkeit News Beiträge in Newslisten anders sortieren zu lassen.

• https://github.com/contao/core-bundl...estone%3A4.5.0
• https://github.com/contao/news-bundl....0+is%3Aclosed
• https://github.com/contao/calendar-b....0+is%3Aclosed
• …

[Physiklehrer]

...oder auf Deutsch:
https://contao.org/de/news/contao_4-1-beta1.html
https://contao.org/de/news/contao_4-1-RC1.html
https://contao.org/de/news/contao_4-2-0.html
https://contao.org/de/news/contao_4-3-0.html
https://contao.org/de/news/contao_4-4-0.html

Den 3. Punkt finde ich übrigens sehr missverständlich in den Ankündungen formuliert, denn auf Apache-Webservern ist die Verarbeitung der mitgelieferten .htaccess, die bei Contao 3.5 optional war, jetzt Pflicht, damit die Anfragen auf die app.php geroutet werden...

[Spooky]

Den 3. Punkt finde ich übrigens sehr missverständlich in den Ankündungen formuliert, denn auf Apache-Webservern ist die Verarbeitung der mitgelieferten .htaccess, die bei Contao 3.5 optional war, jetzt Pflicht, damit die Anfragen auf die app.php geroutet werden...

Pflicht ist das nicht. Welchen Webserver du einsetzt und wie du den konfigurierst bleibt dir überlassen.

[dtptiger]

Für mich ist C4 wegen der der Weiterentwicklung von Extensions von Wichtigkeit. Und wird daher bei den Webseiten für die ich mich verantwortlich zeige, bei Bedarf upgedated. Manchmal mühsam
Und wird deswegen bei neuen Sites definitiv (möglichst) verwendet.
Wobei ich aus Prinzip update was easy geht oder bezahlt wird. Doch nicht primär wegen Sicherheitsbedenken, mag man mich jetzt auch steinigen
Habe bei Kunden (dernix.zahlt.de ;-) noch eine Site auf 2.9.5, einige andere auf 2.11. Warte seit Jahren auf die Apokalypse
Vielleicht ist von Interesse, dass ein befreundeter Programmierer (weitgehends Assembler und C) bemerkte, das er sich mit C4.5 befassen würde (falls er mal ein Website machen würde) da C4.5 Sicherheitsfeatures von Symphony verwendet.

Gruß dtptiger

[mvo]

Die DX! :-)

Symfony + Composer als Paketverwaltung machen es überhaupt erst möglich von anderen Entwicklungen und Technologien zu profitieren.

Ich freue mich außerdem drauf, wenn der LTS Zeitraum der 3.5 abgelaufen ist und Erweiterungen nur noch Contao 4 unterstützen müssen. Das wird einen Push an Qualität und Optionen geben.

[marq]

Eigentlich ging es mir nicht darum was sich unter der Haube ändert, sondern eher darum was für den "normal" Standard-Benutzer über beibt.

Symfony + Composer als Paketverwaltung machen es überhaupt erst möglich von anderen Entwicklungen und Technologien zu profitieren.

Magst du viellecht ein kurzes Beispiel geben, was mit Symfony und Composer nun genau möglich ist?

[mlweb]

Eigentlich ging es mir nicht darum was sich unter der Haube ändert, sondern eher darum was für den "normal" Standard-Benutzer über beibt.

Definiere mal was Du als "normalen" Standard-Benutzer siehst.

Mal so als Beispiel:
Dem reinen Redakteur der keine Themeanpassungen durchführt wird es erst einmal völlig Schnuppe sein, dass es jetzt viel einfacher ist eigene Layoutbereiche flexibel zu setzen. Dagegen sind die Änderungen bei den Metadaten für Bilder sicher schon interessant und erleichtern die Arbeit.
Wenn aber er bzw. der Kunde eine Veränderung der Website haben möchte, die sich mit eigenen Layoutbereichen am besten umsetzen lässt, profitiert er davon vielleicht ohne es tatsächlich zu bemerken.

Für den Kunden könnte durchaus die HTTP/2 Unterstützung und Honeypot-Spamschutz wichtig sein.

Für mich als Webdesigner ist das einfache Updaten und installieren von Erweiterungen ausgesprochen interessant und das ist dann wiederum auch für den Kunden von Vorteil.

Alle diese Veränderungen haben ihren Ursprung zum großen Teil in Veränderungen unter der Haube.

Wie stark Veränderungen unter der Haube sich auch direkt auf die unterschiedlichen Benutzer auswirken, hängt wohl auch vom eigenen Kenntnisstand, vom eigenen Workflow und von der Tatsache ab, ob man sich mit den Neuerungen "anfreundet" bzw. ob man genau dieses Feature jemals vermisst hat oder überhaupt nutzt.

[Samson1964]

Hier mal meine Antworten was Contao 4.x kann, was Contao 3.5 nicht kann:

• Im BE lassen sich in Popups Dateien leichter auswählen und bearbeiten. Man spart dadurch einige Klicks.
• Nicht nur Dateien und Seiten lassen sich jetzt über das Popup verlinken, sondern auch Nachrichten, Artikel, Events und FAQ.
• Die Auswahldialoge vergessen jetzt die ausgewählten Dateien, wenn man sich in einem anderen Zweig befindet und dann trotzdem auf "Anwenden" klickt.
• Erweiterungsverwaltung und -katalog gehören nicht mehr zur Grundausstattung. Das ist positiv weil man nicht mehr davon genervt wird, das es neue Versionen einer Erweiterung oder des Cores gibt.
• Das Cacheverhalten scheint anders zu sein. Insbesondere CSS-Dateien entwickeln in C4 ein Eigenleben. Man muß per SSH/FTP immer /var/cache und /assets/css löschen.

[marq]

Definiere mal was Du als "normalen" Standard-Benutzer siehst.

Ich glaube, auch wenn ich mir das Forum immer wieder anschaue, dass der größte Teil der "normalen Standard-Benutzer" eher wenige technisch versiert ist, sprich der holt sich bei irgendein Hoster ein Webspace für 5 Euro im Monat und will sich die Internetseite schnell aufbauen. Per FTP Daten hochladen ist gerade noch drin. Dann möchte wohl der "normale Standard-Benutzer", dann ggf. einfach und bequem Erweiterungen selber installieren. Das diese Seiten halt meistens auch optisch kein Highlight sind ist klar, weil es im Vergleich zu z.B. Wordpress eigentlich kaum Themes für Contao gibt. Das ist aber egal.

Mal so als Beispiel:
Dem reinen Redakteur der keine Themeanpassungen durchführt wird es erst einmal völlig Schnuppe sein, dass es jetzt viel einfacher ist eigene Layoutbereiche flexibel zu setzen. Dagegen sind die Änderungen bei den Metadaten für Bilder sicher schon interessant und erleichtern die Arbeit.
Wenn aber er bzw. der Kunde eine Veränderung der Website haben möchte, die sich mit eigenen Layoutbereichen am besten umsetzen lässt, profitiert er davon vielleicht ohne es tatsächlich zu bemerken.

Ein reiner Redakteur bekommt eh niemals Zugriffe auf Themes oder ähnliches.

Für den Kunden könnte durchaus die HTTP/2 Unterstützung und Honeypot-Spamschutz wichtig sein.

Es gibt für beides zwar eine Erweiterungen, aber da es jetzt zum Core gehöre, habe ich es mal hinzugefügt.

Für mich als Webdesigner ist das einfache Updaten und installieren von Erweiterungen ausgesprochen interessant und das ist dann wiederum auch für den Kunden von Vorteil.

Da ich halt leider kaum bis keine externen Projekte erstelle und nur eine große Multi-Domain-Installation habe, kann ich das leider nicht beurteilen. Allerdings nutze ich für interne Projekte eh zu 95% nur Erweiterungen die ich selber geschrieben habe oder aber der Meinung bin das es wirklich nötig ist.

Mir geht es in diesem Thread nicht darum, ob Contao 4.x oder oder 3.5x besser oder schlechter ist. Sondern einfach nur um eine einfache Darstellung. Für mich persönlich habe ich nachdem ich mir die "paar Vorteile" angeschaut habe, festgelegt, dass ich die LTS 3.5x solange betreibe bis Contao 5 einsatzfähig ist. Das heißt für mich, das ich erstmalig in meinen 20 Jahren Berufsleben eine Major Version skippe - dass muss aber jeder für sich selber entscheiden.

[Spooky]

dass ich die LTS 3.5x solange betreibe bis Contao 5 einsatzfähig ist

Der Security Support von Contao 3.5 endet in einem Jahr, der LTS Zeitraum ist bereits vorbei. Für Contao 5 gibt es noch keinerlei Pläne. Contao 4 wird zumindest bis Februar 2021 aktiv entwickelt, laut aktuellem Release Plan. Der LTS Zeitraum von Contao 4.9 würde im Februar 2023 enden.

[marq]

Der Security Support von Contao 3.5 endet in einem Jahr, der LTS Zeitraum ist bereits vorbei. Für Contao 5 gibt es noch keinerlei Pläne. Contao 4 wird zumindest bis Februar 2021 aktiv entwickelt, laut aktuellem Release Plan. Der LTS Zeitraum von Contao 4.9 würde im Februar 2023 enden.

Du hast natürlich recht, ich habe mich selber etwas verhaspelt Da ich erst vorhin halt ein Kommentar im Code gelesen habe. //deprecated removed in contao 5. Ich hoffe einfach darauf, das wenn der LTS von Contao 3.5 endet - die Arbeit an Contao 5 anfängt.

[Spooky]

Ich hoffe einfach darauf, das wenn der LTS von Contao 3.5 endet - die Arbeit an Contao 5 anfängt.

Das passiert definitiv nicht . Denn der LTS Zeitraum von Contao 3.5 ist schon zu Ende und es gibt für Contao 5 keine Pläne. Für Contao 4 gibt es Pläne für die nächsten 5 Jahre. Siehe https://contao.org/en/release-plan.html

[mlweb]

Für mich persönlich habe ich nachdem ich mir die "paar Vorteile" angeschaut habe, festgelegt, dass ich die LTS 3.5x solange betreibe bis Contao 5 einsatzfähig ist. Das heißt für mich, das ich erstmalig in meinen 20 Jahren Berufsleben eine Major Version skippe - dass muss aber jeder für sich selber entscheiden.

Für mich ist es so, dass ich schon jetzt ungern mit Contao 3 - Installationen arbeite. Die paar die ich noch habe, versuche ich auf Contao 4 zu bringen.
Es gibt für mich überhaupt keinen Grund die Version Contao 4 nicht zu nutzen. Selbst auf Strato und 1&1 ist die Installation inzwischen problemlos möglich, wenn die Abhängigkeiten woanders (z.B. lokal) aufgelöst werden. An einer diesbezüglichen Lösung für den contao Manager wird auch weiter gearbeitet.

Auch bei einem Contao 5 oder 6 ... wird es in den ersten Versionen wieder Anlaufschwierigkeiten geben.
Außerdem sagt mir meine Erfahrung, das regelmäßige Updates für meine Kunden ein Garant dafür sind, dass es nicht irgendwann plötzlich mal teuer wird. Ein Update über mehrere Versionen hinweg ist nach meiner Erfahrung immer etwas aufwendiger als regelmäßige Updates innerhalb einer LTS-Version und der jeweilige Wechsel von einer LTS-Version zur nächsten.

[marq]

Sorry das ich da jetzt mal auszüge raus nehme, aber mich interessiert das Thema aus einer anderen Sichtweise schon:

Für mich ist es so, dass ich schon jetzt ungern mit Contao 3 - Installationen arbeite.

Es gibt für mich überhaupt keinen Grund die Version Contao 4 nicht zu nutzen.

Würdest du so lieb sein und verraten was für dich an Contao 4 besser als an 3 ist?

Die paar die ich noch habe, versuche ich auf Contao 4 zu bringen.

Bitte nicht böse verstehen, aber ich habe mir gerade deine Referenzen angeschaut und dort laufen selbst noch die hälfte auf Contao 3. Gerade die älteren Installationen.


Generel ist es glaub ich schon ein Unterschied ob man eine Website betreibt wo sich hin und wieder mal ein paar Leute hin verirren oder eine die sagen wir mal 1 mio PIs hat.

[mvo]

Gegenfrage: nenn mir einen Grund bei der 3.5 zu bleiben.

[mlweb]

Würdest du so lieb sein und verraten was für dich an Contao 4 besser als an 3 ist?

Habe ich ja eigentlich schon geschrieben.

• Behandlung der Metadaten
• Honeypod Spamschutz
• eigene Layoutbereiche
• HTTP/2
• schnelleres Updaten
• schnellere Installation von Erweiterungen
• keine Gedanken verschwenden auf Inkompatibilitäten bzw. notwendige Abhängigkeiten überhaupt (habe ich natürlich bei Verwendung von Composer unter Contao 3 auch, aber das macht für mich erst recht keinen Sinn)
• ist die aktuelle LTS
• ich vermeide Versionsprünge wegen nicht durchgeführter Updates gern

Bitte nicht böse verstehen, aber ich habe mir gerade deine Referenzen angeschaut und dort laufen selbst noch die hälfte auf Contao 3. Gerade die älteren Installationen.

Außer den Seiten in meinen Referenzen betreue ich auch Seiten, die aus den verschiedensten Gründen nicht in den Referenzen auftauchen.
Nicht alle Kunden deren Websites ich mal erstellt habe, lassen die Seiten durch mich dauerhaft betreuen.
Außerdem habe ich geschrieben, dass ich versuche die Installationen auf Contao 4 zu bringen. Es gibt immer Kunden die aus den verschiedensten Gründen nicht mitziehen.
Das ändert aber nichts an meiner Einstellung zu Contao 4.

Generel ist es glaub ich schon ein Unterschied ob man eine Website betreibt wo sich hin und wieder mal ein paar Leute hin verirren oder eine die sagen wir mal 1 mio PIs hat.

Ja ist es, ist aber für mich überhaupt kein Grund nicht Contao 4 einzusetzen oder ein Update auf Contao 4 zu empfehlen.

[Samson1964]

Gegenfrage: nenn mir einen Grund bei der 3.5 zu bleiben.

Ich bin nicht der, der gefragt hatte, aber ich antworte mal trotzdem.

• Großer Arbeitsspeicherbedarf von C4/Composer/Symfony.
• Hosting/ManagedServer ist nicht ohne größere Anpassungen kompatibel mit C4/Composer/Symfony.
• Kein Überblick darüber, ob für die C4-Installation Updates vorliegen. Man muß erst ein externes Programm (CM) starten.
• Erweiterungs-/Bundle-Updates mit CM wegen zu hoher Arbeitsspeicherauslastung oft nicht möglich, deshalb SSH-Account Pflicht.
• Schlechtes Caching in C4, insbesondere beim assets-Ordner (s.o.).
• Die Fehler-Logs lesen sich in C4 wie wissenschaftliche Abhandlungen, auch der Dev-Modus ist nicht sehr hilfreich für Nicht-Hardcore-Entwickler in C4.
• Unübersichtliche Dateistruktur durch Symfony-Vorgaben, tief verschachtelte Verzeichnisse. Symlinks.
• Installation von C4 um einiges aufwendiger als bei C3.
• Aufforderung der C4-Anhänger die Installation lokal zu updaten und eine composer.json auf den Server zu kopieren, mit Composer ein Update zu machen - und zu schauen ob es auf dem Server auch paßt.

Insgesamt um vieles komplizierter als mit C3, was bei einigen Leuten Ängste aufbaut. Zu Recht.

Ich betreibe mit einem großen Projekt eine C4.4-Installation und will mit einem weiteren großen Projekt in den nächsten Monaten von 3.5 auf 4 nachziehen. Außerdem will ich irgendwann in die C4-Bundle-Programmierung einsteigen, wobei mir Symfony per se erstmal schnuppe ist. Bisher entwickle ich nur für C3.
Andere Projekte, die nur auf Hostingtarifen laufen, werde ich weiter mit 3.5 betreiben oder neu damit aufsetzen, wenn C4 dort nicht läuft.

[mvo]

Ich bin nicht der, der gefragt hatte, aber ich antworte mal trotzdem.

• Großer Arbeitsspeicherbedarf von C4/Composer/Symfony.
• Hosting/ManagedServer ist nicht ohne größere Anpassungen kompatibel mit C4/Composer/Symfony.
• Kein Überblick darüber, ob für die C4-Installation Updates vorliegen. Man muß erst ein externes Programm (CM) starten.
• Erweiterungs-/Bundle-Updates mit CM wegen zu hoher Arbeitsspeicherauslastung oft nicht möglich, deshalb SSH-Account Pflicht.
• Schlechtes Caching in C4, insbesondere beim assets-Ordner (s.o.).
• Die Fehler-Logs lesen sich in C4 wie wissenschaftliche Abhandlungen, auch der Dev-Modus ist nicht sehr hilfreich für Nicht-Hardcore-Entwickler in C4.
• Unübersichtliche Dateistruktur durch Symfony-Vorgaben, tief verschachtelte Verzeichnisse. Symlinks.
• Installation von C4 um einiges aufwendiger als bei C3.
• Aufforderung der C4-Anhänger die Installation lokal zu updaten und eine composer.json auf den Server zu kopieren, mit Composer ein Update zu machen - und zu schauen ob es auf dem Server auch paßt.

Insgesamt um vieles komplizierter als mit C3, was bei einigen Leuten Ängste aufbaut. Zu Recht.

Ich betreibe mit einem großen Projekt eine C4.4-Installation und will mit einem weiteren großen Projekt in den nächsten Monaten von 3.5 auf 4 nachziehen. Außerdem will ich irgendwann in die C4-Bundle-Programmierung einsteigen, wobei mir Symfony per se erstmal schnuppe ist. Bisher entwickle ich nur für C3.
Andere Projekte, die nur auf Hostingtarifen laufen, werde ich weiter mit 3.5 betreiben oder neu damit aufsetzen, wenn C4 dort nicht läuft.

Das ist eine sehr subjektive Einschätzung, die an vielen Stellen einfach nicht wahr ist. Installation und erst Recht Updates sind mit Contao 4 deutlich schneller zu machen, gerade wegen des Package Managements. Die Dateistruktur ist nicht unübersichtlich, sondern ist analog zu den Namespaces und folgt PSR Naming. System Tasks haben nichts im Backend verloren und deshalb ist es insbesondere auch richtig dort keine Erweiterungsverwaltung zu haben. Symlinks sind kein Nachteil (wtf?), sondern normaler und essentieller Bestandteil vieler Anwendung. Contao/Symfony hat keinen großen Arbeitsspeicherbedarf. Changes erst auf den Testsystem testen und dann auf dem Live-System hast du hoffentlich auch unter C3 gemacht..

[marq]

Das ist eine sehr subjektive Einschätzung, die an vielen Stellen einfach nicht wahr ist. Installation und erst Recht Updates sind mit Contao 4 deutlich schneller zu machen, gerade wegen des Package Managements. Die Dateistruktur ist nicht unübersichtlich, sondern ist analog zu den Namespaces und folgt PSR Naming. System Tasks haben nichts im Backend verloren und deshalb ist es insbesondere auch richtig dort keine Erweiterungsverwaltung zu haben. Symlinks sind kein Nachteil (wtf?), sondern normaler und essentieller Bestandteil vieler Anwendung. Contao/Symfony hat keinen großen Arbeitsspeicherbedarf. Changes erst auf den Testsystem testen und dann auf dem Live-System hast du hoffentlich auch unter C3 gemacht..

Nun ich möchte an dieser Stelle noch einmal darauf hinweisen, die Vorteile von Contao 4.x aufzuzeigen, gerade um "Wechselmuffeln" (wie ich einer bin) eine Entscheidung finden zu lassen. Daher auch der Thread-Titel "Was kann Contao 4. was Contao 3.5" nicht kann und nicht "Wieso soll ich bei Contao 3.5 bleiben". Im übrigen würde ich mich freuen (wie oben bereits erwähnt, worauf du mit einer Gegenfrage geantwortet hast), wenn du in ein ganz kurzen Satz oder von mir aus auch zwei Sätzen erklärst, wieso Composer/Symfony ein Vorteil sind.

[Samson1964]

Das ist eine sehr subjektive Einschätzung, die an vielen Stellen einfach nicht wahr ist.

Generell sind alle Einschätzungen hier subjektiv. Sowohl meine als auch Deine. Was aus meiner subjektiven Sicht wahr ist, ist aus Deiner subjektiven Sicht unwahr - und umgekehrt.

Installation und erst Recht Updates sind mit Contao 4 deutlich schneller zu machen, gerade wegen des Package Managements.

Auch eine subjektive Wahrnehmung. Wenn ich das Entpacken und anschließende Hochladen per FTP unter C3 mit hinzuzähle, muß ich Dir Recht geben. Das geht jetzt deutlich schneller, weil alles gleich auf dem Zielserver passiert. Vergleiche ich die beiden Installationsroutinen C4/CM gegen C3 und ignoriere die Vorarbeiten, ist beides wohl etwa gleich schnell. Nach- oder Vorteil bei C4/CM ist das zusätzliche Skript (CM) das ich aufrufen muß. Zudem fliegt man schon nach kurzer Zeit beim CM aus der Sitzung - für den einen Nachteil, für die anderen ein Vorteil. Aber das schnelle Sitzungsende soll ja gefixt werden.

Bei Updates bin ich mit C3 deutlich schneller. Häkchen bei den Erweiterungen rein und los gehts. Bei C4 ist der CM wegen zu hoher Arbeitsspeicheranforderungen bei Updates nicht mehr benutzbar. Man muß auf die Shell gehen und die Befehle für jede Erweiterung manuell eingeben. Die Befehle sollte man sich zuvor in einer Textdatei gespeichert haben. Hier brauche ich bei C4 also deutlich länger.

Die Dateistruktur ist nicht unübersichtlich, sondern ist analog zu den Namespaces und folgt PSR Naming.

Das Hauptverzeichnis mit app, assets, contao-manager, files, system, templates, var, vendor, web kommt in C4 ja noch friedlich daher. Doch schaut man in vendor rein, sträuben sich einem die Haare. Den Core findet man jetzt z.B. nicht unter system/modules/core, sondern gut versteckt unter vendor/contao/core-bundle/src/resources/contao.
Namespaces sind okay, gab es ja auch schon in C3. Man muß halt damit klar kommen, das die keine Verzeichnisstruktur abbilden, sondern reine Phantasienamen sind.

System Tasks haben nichts im Backend verloren und deshalb ist es insbesondere auch richtig dort keine Erweiterungsverwaltung zu haben.

Als Admin stimme ich Dir weitgehend zu. Mir fehlt aber die Info im BE ob Updates für die Erweiterungen/Bundles und für den Core vorliegen.

Symlinks sind kein Nachteil (wtf?), sondern normaler und essentieller Bestandteil vieler Anwendung.

Ich vermeide Symlinks soweit es geht. Mich stören die auch unter Windows. In der Contao-Verzeichnisstruktur ist es so: Man sieht einen Symlink und muß dann erstmal schauen, wo die Dateien dafür eigentlich wirklich liegen.

Contao/Symfony hat keinen großen Arbeitsspeicherbedarf.

Nein natürlich nicht! Ich sehe C4 aber als Ganzes und untrennbaren Bestandteil im Paket Contao/Symfony/Composer. Würde Composer nicht mehr zu C4 gehören, wäre C4 dann noch lauffähig - also könnte man dann z.B. Updates von Erweiterungen oder des Cores machen?

Changes erst auf den Testsystem testen und dann auf dem Live-System hast du hoffentlich auch unter C3 gemacht..

Nein. Versionssprünge von 3.5.2 auf 3.5.5 oder so, habe ich ohne Backups gemacht. Vor einem Update von z.B. 3.0 auf 3.5 mache ich ein DB-Backup und ein Datei-Backup. Wobei ich hier das Update an einer 1:1-Kopie vornehme. Läuft die Kopie schalte ich die Domain auf das Verzeichnis mit der Kopie und fertig. Läuft bei einem Update etwas schief und ich habe keine Backups vom Dateisystem (DB-Backup habe ich automatisch immer, einmal täglich), dann tausche ich einfach die Dateien aus oder lege in den Erweiterungsordner eine .skip-Datei. Die schlimmsten Szenarien hatte ich unter C3 bisher bei der Deinstallation von MetaModels und der Composer-Paketverwaltung. Das ist aber eine Kleinigkeit, wenn ich sehe was mich bei C4 erwartet. Einfach die Erweiterung auf dem Server löschen oder .skip-Datei geht ja nicht mehr. Trotz Leeren diverser Caches scheint C4 immer noch nach im Dateisystem gelöschten Verzeichnissen und Dateien zu suchen. Ich lege dann z.B. einfach Dummy-Verzeichnisse an.

Versionssprünge des Cores von z.B. 4.4.1 auf 4.4.3 (und auch Updates von Erweiterungen) mache ich ohne "Fangnetz". Wartungsmodus an, Shell aufrufen (CM geht ja nicht bei Updates), Kommandos eintippen und abschicken und hoffen das keine Fehlermeldungen kommen, Install-Skript aufrufen (okay kein eindeutiges PHP-Skript mehr, sondern ein Routing, wo man nicht weiß was eigentlich aufgerufen wird), schauen ob FE/BE läuft, Wartungsmodus beenden. Und an diversen Stellen dazwischen immer mal wieder var/cache und assets/css mit dem MC oder per FTP löschen.
Den Sprung von 4.4 auf 4.5/4.6 würde ich nicht ohne Fangnetze machen. Hier würde ich die Installation auf dem Server duplizieren und dabei die Hoffnung hegen, das das wirklich so problemlos wie unter C3 geht (wegen der Symlinks). Und dann würde ich das Update auf 4.5/4.6 an meinem Duplikat vornehmen. Läuft alles, wiederhole ich die Prozedur an einem neuen Duplikat der Website, wobei ich vorher in den Wartungsmodus gehe.

Lokal mache ich keine Updates. Selbst wenn ich eine 1:1-Kopie der Website in htdocs von XAMPP hätte: Es ist einfach nicht möglich, weil sich ja allein die Betriebssysteme unterscheiden, von den vielen PHP-Einstellungen ganz abgesehen.

[derRenner]

Hallo,

rein objektiv gesehen bietet cto4 vieles an Vorteilen - hier noch zu hinterfragen, was denn nun besser oder nein richtig geschrieben: was es denn nun mehr kann, sehe ich als "Zeitverschwendung". Ich denke, dass der Weg in Richtung cto4 eingeschlagen ist und dieser in diese Richtung weitergehen wird/muss. Jetzt an dieser Stelle zu hinterfragen, was cto4 denn mehr kann sehe ich als Widersinn in sich » würde es nicht mehr können, dann würde es es nicht geben

Klar doch, für viele Anwender und Nicht-Entwickler ändert sich vieles UND: in mittlerweile anderer Form als bisher ...
Wer meine threads dahingehend kennt, weiss, dass ich auch nicht unbedingt der grosse Entwickler bin und ich mich mit dem Schritt zu cto4 als Anwender ziemlich schwer getan habe und mich noch immer tue - zu erkennen, dass cto4 immer mehr an Anforderungen und Wisssen braucht, ist nicht einfach aber die Entscheidung ist doch gefallen. Du kannst nun "mitgehen" oder du kannst "stehen bleiben". Mit Zwang versuchen, herauszufinden, warum man nicht auf cto4 wechseln sollte, ist der falsche Weg

Und hier zu erwarten, dass du Aufzählungen bekommst, was denn cto4 mehr kann als cto3 ... mmmh - nun ja, ich seh's als Zeitverschwendung.

Vielleicht tust du dir mit dieser Vorgehensweise etwas leichter: geh davon aus, dass cto4 in diese Richtung geht bzw. jenen Weg eingeschlagen hat, dass nun sehr vieles, ja wirklich sehr vieles, mit angeboten bekommst, was du in cto3.5 vermisst hast
Seien es features, technische Anpassungen oder usability.

[Samson1964]

Was kann Contao 4.x was Contao 3.5 nicht kann?

Zusammenfassend:

• Contao 4 hat neue Funktionen - für mich am besten: Auswahl-Popup läßt Dateibearbeitung/-auswahl gleichzeitig zu, einfache Verlinkung von Nachrichten, Events usw.
• Contao 4 kann viel schwieriger als Contao 3 - bei Updates
• Contao 4 kann mehr Arbeitsspeicher verbraten (z.B. beim Erstellen der XML-Sitemap)
• Contao 4 kann freundlicher für Hardcore-Entwickler und Symfony-Gurus

[tab]

Mir geht es in diesem Thread nicht darum, ob Contao 4.x oder oder 3.5x besser oder schlechter ist. Sondern einfach nur um eine einfache Darstellung. Für mich persönlich habe ich nachdem ich mir die "paar Vorteile" angeschaut habe, festgelegt, dass ich die LTS 3.5x solange betreibe bis Contao 5 einsatzfähig ist. Das heißt für mich, das ich erstmalig in meinen 20 Jahren Berufsleben eine Major Version skippe - dass muss aber jeder für sich selber entscheiden.

Dass das so nicht klappen wird, darauf hat @Spooky ja schon hingewiesen.
Zusätzlich möchte ich darauf hinweisen, dass zumindest wir Normalsterblichen (hoffentlich auch die Core-Entwickler) noch gar nicht wissen, welche Features bis zur letzten Contao 4.x Version hinzugefügt werden. Die Hoffnung, dass das auch die Core-Entwickler noch nicht wissen, kommt daher, dass ich ein ungutes Gefühl dabei hätte, wenn die Features für die nächsten 5 oder mehr Jahre bereits jetzt festlägen. In 5 Jahren tut sich in Sachen Webdesign doch meist einiges. Darauf nicht mehr reagieren zu können wäre aus meiner Sicht fatal. Der Release-Plan - ein reiner Zeitplan - geht bis Contao 4.10. Da dies keine LTS-Version sein wird, gehe ich davon aus, dass noch weitere 4.x Versionen folgen werden. Bisher war die letzte Minor-Version immer eine LTS-Version. Alles andere wäre aus meiner Sicht auch sinnlos.

Jetzt also Contao 3.5 in Sachen Features mit Contao 4.4 zu vergleichen um daraus abzuleiten, dass man 4.x komplett auslässt, wäre also nicht nur vom reinen Zeitplan her eine Milchmädchenrechnung. Man kann höchstens sagen: "Ich lasse 4.4 aus und steige erst frühestens bei 4.7 um (wegen fehlender Sicherheitsupdates für 3.5) oder wenn möglich erst bei 4.9 LTS, falls bis dahin keine ungefixten Sicherheitsprobleme mit 3.5 auftauchen." Außerdem kann es ja sein, dass erst mit Contao 4.5, 4.6, 4.7, 4.8 irgendwelche Killer-Features eingeführt werden, die man dringend braucht oder für die man zumindest freiwillig früher auf 4.x umsteigt. Wenn es also darum ginge, die Major Version komplett zu überspringen, müsste man fairerweise 3.5 mit 4.14 (angenommene letzte 4.x LTS-Version) vergleichen. Was natürlich noch gar niemand kann. Es kann also sinnvollerweise nur um die Entscheidung gehen zwischen 3.5 und 4.4. Das sind beides LTS-Versionen und die Features sind bekannt.

Ich kann mir ehrlich gesagt auch nur schwer vorstellen, dass es 2020 noch Hoster geben wird, die immer noch nicht Contao 4.x tauglich sind und trotzdem noch im Geschäft. Damit meine ich, dass sie einen tauglichen Tarif haben werden, der vom Preis her den heutigen 6 Euro/Monat Paketen entspricht. Dass es für 1 Euro/Monat vermutlich nicht gehen wird ist relativ klar, aber eher unwichtig. Dafür bekommt man heute auch nichts, mit dem man eine mittelmäßig frequentierte, CMS basierte Website mit vielen Bildern ernsthaft würde betreiben wollen. Sicher wird es diese Tarife nicht wegen Contao geben, aber bis dahin wird es von den Anforderungen her bei Wordpress, Joomla und Konsorten auch nicht anders aussehen als bei Contao.

[Spooky]

• Das Cacheverhalten scheint anders zu sein. Insbesondere CSS-Dateien entwickeln in C4 ein Eigenleben. Man muß per SSH/FTP immer /var/cache und /assets/css löschen.

Du musst nichts dergleichen machen. Beschreibe dein Problem genauer.

• Schlechtes Caching in C4, insbesondere beim assets-Ordner (s.o.).

Was genau meinst du damit?

[mvo]

@Samson1964 Du verwendest glaube ich Strategien mit Contao 4, die unter Contao 3 ggf. noch sinnig waren, aber hier nicht dienlich sind. Und ich bin mir sicher, dass du damit nicht allein bist. :-) Damit der Thread zumindest ein bisschen Gehalt bekommt, hier ein bisschen Background:

Jede halbwegs komplexe Software verwendet Librarys - also abstrakt nutzbare Drittprodukte. Von Bildbearbeitung bis Datenaustausch mit Servern. Wenn jetzt jede Komponente der Software - und sobald Erweiterungen genutzt werden können, können das viele sein - die benötigten Resourcen selbst mitliefern muss, gibt es einen Riesenchaos. Zumal jede Komponente auch dafür sorgen muss, dass die Drittprodukte aktuell bleiben etc. und die Drittprodukte ggf. selbst wieder Resourcen einbinden. Das Ergebnis ist entweder eine Sammlung an veralteter (vlt. unsicherer?) Software und/oder eine massive Beschränkung der Möglichkeiten. Die Lösung dafür heißt Package Management und delegiert die Aufgabe an eine zentrale Stelle ab: die Applikation sagt welche Komponenten sie braucht, jede Komponente und Subkomponente sagt ihrerseits, was sie braucht (das alles steht in der jeweiligen composer.json), der Package Manager löst diese Anfragen auf und installiert die entsprechenden Versionen. Und der populärste und beste Package Manager, den wir derzeit haben ist Composer. Damit wir uns nicht falsch verstehen, das ist ein Standard - ein größeres Projekt ohne Package Manager zu entwickeln ist aus heutiger Sicht absurd.

Der Vendor-Ordner ist nicht Teil dessen was bei einer Applikation distribuiert wird. Im Vendor Ordner liegen alle von Composer geladenen Pakete samt einer Möglichkeit für die Applikation sie gemeinsam einzubinden (autoload.php). Man kann ihn jederzeit löschen und mit einem composer install oder composer update neu erstellen. Aus diesem Grund macht es auch überhaupt keinen Sinn ihn zu sichern. Wer in den Ordner schaut sieht alle installierten Pakete - sortiert nach 'Hersteller' (vendor) und Paketname und darin die jeweilige Struktur des Pakets. Das ist deutlich übersichtlicher als Librarys in Unterordnern von Modulen zu suchen. Als Administrator hast du in letztgenanntem Fall keine keine Übersicht (und keine Chance sie zu bekommen), was in welcher Version installiert ist. Wenn du diese Herangehensweise akzeptierst, kannst du als Entwickler davon profitieren: Du benötigst eine Library? Nur ein Requirement hinzufügen, direkt nutzen und ohne Aufwand aktuell halten. Du benötigst eine komplexere Funktion? Dank der großen Symfony-Entwicklergemeinde, gibt es diese wohlmöglich schon und du kannst sie ebenfalls mit einem Requirement + ggf. ein paar Zeilen Konfiguration für dich nutzbar machen.

Genau das gleiche macht der Contao Core und nur so kann er überhaupt zukunftsfähig bleiben und mit den aktuellen Technologien mithalten. Ein Framework + Package Manager zu verwenden sind schon alleine aus Gründen der Manpower essentiell.

Wobei wir hier wären:

[..]wenn du in ein ganz kurzen Satz oder von mir aus auch zwei Sätzen erklärst, wieso Composer/Symfony ein Vorteil sind.

Satz 1: Du erhälst überhaupt erst die Möglichkeit zur zukunftssicheren, strukturierten Pflege deiner Codebase. Satz 2: Wir profitieren von der guten Arbeit von tausenden Entwicklern.

Und wie ich ganz oben im Thread geschrieben habe: Die DX - die developer experience - ist dermaßen viel besser. Ich schreibe heute in einem Bruchteil der Zeit Erweiterungen, die um vielfaches mehr können als zuvor. Ein CMS ist kein fertiges Produkt, sondern eine Basis für komplexe Lösungen. Wer das nicht braucht, ok - aber dann bitte nicht drüber beschweren. :-)

[operatorone]

Hier mal meine Antworten was Contao 4.x kann, was Contao 3.5 nicht kann:

• Im BE lassen sich in Popups Dateien leichter auswählen und bearbeiten. Man spart dadurch einige Klicks.
• Nicht nur Dateien und Seiten lassen sich jetzt über das Popup verlinken, sondern auch Nachrichten, Artikel, Events und FAQ.
• Die Auswahldialoge vergessen jetzt die ausgewählten Dateien, wenn man sich in einem anderen Zweig befindet und dann trotzdem auf "Anwenden" klickt.
• Erweiterungsverwaltung und -katalog gehören nicht mehr zur Grundausstattung. Das ist positiv weil man nicht mehr davon genervt wird, das es neue Versionen einer Erweiterung oder des Cores gibt.
• Das Cacheverhalten scheint anders zu sein. Insbesondere CSS-Dateien entwickeln in C4 ein Eigenleben. Man muß per SSH/FTP immer /var/cache und /assets/css löschen.

Ne muss man nicht. Einfach „Skripte komprimieren“ im Layout aktivieren, dann geht das auch so, außer man macht änderunen in DCA Dateien. Dann muss mannden Cache leeren, was aber mit nem Einzeiler in der Console sehr einfach ist.


Gesendet von iPhone mit Tapatalk Pro

[tab]

Wo wir gerade beim Cache sind. Gerade habe ich festgestellt, dass Contao 4.4 etwas kann, was Contao 3.5 nicht kann, was ich mir aber schon einige Male gewünscht hätte: Separate Cachezeiten für Server- und Browser-Cache! In vielen Kundenwebsites gibt es Seiten, die selten geändert werden, also vielleicht nur einmal im Jahr oder noch seltener. WENN diese Seiten aber geändert werden, dann soll das dem Besucher nicht erst nach Monaten angezeigt werden. Deshalb musste ich bei 3.5 entweder auf das Browser-Caching komplett verzichten oder die Cache-Zeit relativ kurz halten. Das galt dann natürlich auch für den Server-Cache, was völlig unnötig war, weil ich diesen Cache unter Kontrolle habe und - im Gegensatz zum Browser-Cache der Besucher - nötigenfalls einfach löschen kann. Jetzt kann ich eine lange Cachezeit für den Server-Cache einstellen und eine kürzere für den Browser-Cache.

[iuna123]

Ich bin nicht der, der gefragt hatte, aber ich antworte mal trotzdem.

• Großer Arbeitsspeicherbedarf von C4/Composer/Symfony.
• Hosting/ManagedServer ist nicht ohne größere Anpassungen kompatibel mit C4/Composer/Symfony.
• Kein Überblick darüber, ob für die C4-Installation Updates vorliegen. Man muß erst ein externes Programm (CM) starten.
• Erweiterungs-/Bundle-Updates mit CM wegen zu hoher Arbeitsspeicherauslastung oft nicht möglich, deshalb SSH-Account Pflicht.
• Schlechtes Caching in C4, insbesondere beim assets-Ordner (s.o.).
• Die Fehler-Logs lesen sich in C4 wie wissenschaftliche Abhandlungen, auch der Dev-Modus ist nicht sehr hilfreich für Nicht-Hardcore-Entwickler in C4.
• Unübersichtliche Dateistruktur durch Symfony-Vorgaben, tief verschachtelte Verzeichnisse. Symlinks.
• Installation von C4 um einiges aufwendiger als bei C3.
• Aufforderung der C4-Anhänger die Installation lokal zu updaten und eine composer.json auf den Server zu kopieren, mit Composer ein Update zu machen - und zu schauen ob es auf dem Server auch paßt.

Insgesamt um vieles komplizierter als mit C3, was bei einigen Leuten Ängste aufbaut. Zu Recht.

Du sprichst mir aus der Seele!
Danke!
Jetzt wo ich beginne mich mit Contao 4 auseinander zu setzen, habe ich plötzlich das Gefühl, das mein Wissen nicht mehr ausreicht um damit arbeiten zu können.
Wie als ob ich ein neues CMS starte - na ja nicht ganz, aber fast.

Ich liebe Contao und arbeite seit Jahren damit (gestartet mit Typo Light)
Aber für mich bedeutet ein CMS eine einfache Handhabung - keine Konsole und Kurzbefehle. Ich bin keine Entwicklerin sondern Designerin.
Auch wenn ich bereit bin mich hier einzuarbeiten - meine erste Euphorie und mein Elan mich Contao 4 zu widmen ist ziemlich gebremst, weil ich nicht einfach starten kann.

Das beginnt alleine schon damit, dass der Provider wo ich gerne bin, das nicht so anbieten kann, dass es für mich einfach nur ein Update ist.
Ich muss also entweder plötzlich in die Tiefen der SSH/Konsolen/wasweissichwas-Welt tauchen oder einen Provider finden, der das so anbietet, dass es kein Problem ist. Preissteigerung von 300% muss ich bei meinen Kunden erst mal erklären.

Daher werde ich das momentan anstehende Projekt dann vielleicht doch mit Contao 3 machen und hoffen, dass die Provider im nächsten Jahr noch nachziehen.

[tab]

Wenn der Hoster auf die zukünftigen Anforderungen schlepend reagiert, dann ist das natürlich bedauerlich. Das ist sicher momentan noch eines der größten Probleme von Contao 4, dass es im Vergleich zur Konkurrenz den Vorreiter spielt. Die anderen werden sicher bald nachziehen, aber bis dahin sind die Hoster eben noch nicht gezwungen zu reagieren. Dazu ist der Marktanteil von Contao einfach zu klein. Hätte Wordpress etwas Vergleichbares gemacht, dann sähe das mit Sicherheit ganz anders aus. Das würde ruckzuck überall bei allen Hostern laufen, denn ansonsten würden die Kunden laufen - zur Konkurrenz. Wenn du einen österreichischen Hoster suchst, der da anders funktioniert und nicht auf Wordpress wartet, wird sich sicher einer finden. Vielleicht kann ja Spooky oder ein anderes österreichisches Forenmitglied da ein paar nennen. Kann man aber sicher auch im Forum den einen oder anderen finden. In Deutschland ist es jedenfalls kein Problem.

Einigen der Aussagen von Samson1964 zu den Nachteilen von Contao 4 konnte ich damals, vor einem halben Jahr, sicher noch zustimmen. Heute ist manches davon bereits gegenstandslos geworden, weil diese Probleme mittlerweile weitgehend gelöst sind. Der Contao-Manager wurde kontinuierlich verbessert und es steht mittlerweile ein Cloud-Resolver zur Verfügung, was die großen RAM-Probleme wegnimmt. Die Vorteile sind dagegen geblieben. Sicher muss man sich etwas umgewöhnen, was Installation und Update von Contao und Erweiterungen betrifft. Aber letztlich ist es auch nicht schwieriger, nur anders. SSH-Zugang hilft bei manchen Problemen (abgesehen davon, dass viele Dinge damit eben wesentlich schneller gehen als per FTP oder gar Web-Interface), aber vieles geht mittlerweile auch ohne SSH - mit dem Contao-Manager.

[Samson1964]

Einigen der Aussagen von Samson1964 zu den Nachteilen von Contao 4 konnte ich damals, vor einem halben Jahr, sicher noch zustimmen. Heute ist manches davon bereits gegenstandslos geworden, weil diese Probleme mittlerweile weitgehend gelöst sind. Der Contao-Manager wurde kontinuierlich verbessert und es steht mittlerweile ein Cloud-Resolver zur Verfügung, was die großen RAM-Probleme wegnimmt. Die Vorteile sind dagegen geblieben.

Da stimme ich tab zu. Durch den externen Dienst, der die Abhängigkeitsauflösungen übernimmt, sind die meisten RAM-Probleme beseitigt. Ich war sehr erfreut über diesen Cloud-Resolver wodurch Installationen jetzt auch da möglich wurden, wo es sonst nie was draus geworden wäre. Meine restlichen Aussagen bleiben so bestehen. Da bin ich ein halbes Jahr später auch noch nicht viel weiter gekommen. Erweiterungen für C4 code ich immer noch im C3-Stil, weil die Hürden die sich da auftürmen noch zu groß sind. Wenn sich jemand wie früher Tristan Lins findet, der Videotutorials für Entwickler macht, wäre mir schon sehr geholfen.

[claudiacarolina]

Ich bin auch eine von denen, die Berührungsängste vor Contao 4 hat...

Ich habe einfach (noch) nicht den Durchblick wie das genau ist mit Composer (und hier habe ich noch was von Symphony gelesen) etc. Wird der Composer mit der Installation gleich mitgeliefert? Oder muss man sich extra darum kümmern? So wie ich es verstanden habe, braucht man für Contao 4 zwingend den Composer.


War vorhin auf dieser Seite hier:

http://https://docs.contao.org/books...tallieren.html

Da gibt es zwei Absätze:

- Contao installieren
- Installation mit Composer


Verstehe ich das richtig:
Wenn ich mich an den ersten Absatz halte, dann kann ich Contao wie früher installieren (runterladen, entpacken, verschieben)? Und dann, was ist dann mit dem Composer? Den muss ich dann noch als Erweiterung installieren?

Ich denke mal, das sind "Kindergartenfragen", die ich da stelle... Ich sehe einfach noch nicht so durch, wie das alles zusammenhängt... Contao/Composer/Synphony …


Vielleicht könnt Ihr mich einfach an die richtige Stelle verweisen, wo ich eine einfache Zusammenfassung lesen kann?


Danke sehr!
Claudia

[iuna123]

Ich bin auch eine von denen, die Berührungsängste vor Contao 4 hat...

Ich habe einfach (noch) nicht den Durchblick wie das genau ist mit Composer (und hier habe ich noch was von Symphony gelesen) etc. Wird der Composer mit der Installation gleich mitgeliefert? Oder muss man sich extra darum kümmern? So wie ich es verstanden habe, braucht man für Contao 4 zwingend den Composer.


War vorhin auf dieser Seite hier:

http://https://docs.contao.org/books...tallieren.html

Da gibt es zwei Absätze:

- Contao installieren
- Installation mit Composer


Verstehe ich das richtig:
Wenn ich mich an den ersten Absatz halte, dann kann ich Contao wie früher installieren (runterladen, entpacken, verschieben)? Und dann, was ist dann mit dem Composer? Den muss ich dann noch als Erweiterung installieren?

Ich denke mal, das sind "Kindergartenfragen", die ich da stelle... Ich sehe einfach noch nicht so durch, wie das alles zusammenhängt... Contao/Composer/Synphony …


Vielleicht könnt Ihr mich einfach an die richtige Stelle verweisen, wo ich eine einfache Zusammenfassung lesen kann?


Danke sehr!
Claudia

Mir ging es genauso - Die Dokumentaion ist momentan auch nicht aktuell.
Daher habe ich mir das jetzt über die Contao Academy angesehen.
https://contao-academy.de/umstieg-auf-contao-4

oder hier auch ein Link nur zur Installation: https://www.youtube.com/watch?v=GIgmdc1QJVA

[iuna123]

Wenn der Hoster auf die zukünftigen Anforderungen schlepend reagiert, dann ist das natürlich bedauerlich. Das ist sicher momentan noch eines der größten Probleme von Contao 4, dass es im Vergleich zur Konkurrenz den Vorreiter spielt. Die anderen werden sicher bald nachziehen, aber bis dahin sind die Hoster eben noch nicht gezwungen zu reagieren. Dazu ist der Marktanteil von Contao einfach zu klein. Hätte Wordpress etwas Vergleichbares gemacht, dann sähe das mit Sicherheit ganz anders aus. Das würde ruckzuck überall bei allen Hostern laufen, denn ansonsten würden die Kunden laufen - zur Konkurrenz. Wenn du einen österreichischen Hoster suchst, der da anders funktioniert und nicht auf Wordpress wartet, wird sich sicher einer finden. Vielleicht kann ja Spooky oder ein anderes österreichisches Forenmitglied da ein paar nennen. Kann man aber sicher auch im Forum den einen oder anderen finden. In Deutschland ist es jedenfalls kein Problem.

Ein Provider, bei dem ich sehr lange war und zu dem ich ein freundschaftliches Verhältnis habe, meinte:
Mit der hohen Speicheranforderung ist man dann halt auch gleich mal bei der Leistung von Servern.
Er wird sich jetzt bemühen, hier was anzubieten.

Mein erster Frust ist mal besänftigt
Hoffe, dass mich Contao 4 - wenn ich damit arbeite - dann meinen Frust vergessen lässt

[folkfreund]

Verstehe ich das richtig:
Wenn ich mich an den ersten Absatz halte, dann kann ich Contao wie früher installieren (runterladen, entpacken, verschieben)? Und dann, was ist dann mit dem Composer? Den muss ich dann noch als Erweiterung installieren?

Nein, Contao 4 kann man nicht mehr als ZIP runterladen und installieren.

Für mich ist immer noch der einfachste Weg:

• Zielordner auf dem Webspace anlegen (leer!)
• darin einen Ordner /web
• in /web die Datei contao-manager.phar von https://contao.org/de/download.html ablegen und umbenennen in contao-manager.phar.php
• documentroot auf den /web-Ordner richten
• Im Browser <meineDomain>/contao-manager.phar.php aufrufen

Wie bei C3 brauchst du natürlich vorher eine Datenbank. Außerdem kann es sinnvoll sein, schon direkt ein SSL-Zertifikat für die Domain einzurichten.

Gruß, folkfreund

[claudiacarolina]

Nein, Contao 4 kann man nicht mehr als ZIP runterladen und installieren.

Für mich ist immer noch der einfachste Weg:

• Zielordner auf dem Webspace anlegen (leer!)
• darin einen Ordner /web
• in /web die Datei contao-manager.phar von https://contao.org/de/download.html ablegen und umbenennen in contao-manager.phar.php
• documentroot auf den /web-Ordner richten
• Im Browser <meineDomain>/contao-manager.phar.php aufrufen

Wie bei C3 brauchst du natürlich vorher eine Datenbank. Außerdem kann es sinnvoll sein, schon direkt ein SSL-Zertifikat für die Domain einzurichten.

Gruß, folkfreund

Das wollte ich nun gerade machen, danke sehr folkfreund - den Contao-Manager installieren.

Wenn ich nun aber diese Fehlermeldung bekomme (siehe unten), dann geht das wohl auf meinem Server nicht!? Ich habe meinen Hostinganbieter (http://www.cyon.ch) deswegen kontaktiert. Mal schauen, wie die Antwort sein wird.

The PHP function "proc_open" and/or "proc_close" is not available on the server.
The "proc_open" and "proc_close" functions are necessary to run command line tasks in the background. Check with your hosting provider why this method is not available; neither the Contao Manager nor Contao 4 will run correctly without it.

[mlweb]

Schau mal hier https://github.com/contao/contao-manager/wiki/cyon
Da ist für Deinen Hoster erklärt, wie Du das selbst einstellen kannst.

[claudiacarolina]

Nein, Contao 4 kann man nicht mehr als ZIP runterladen und installieren.

Für mich ist immer noch der einfachste Weg:

• Zielordner auf dem Webspace anlegen (leer!)
• darin einen Ordner /web
• in /web die Datei contao-manager.phar von https://contao.org/de/download.html ablegen und umbenennen in contao-manager.phar.php
• documentroot auf den /web-Ordner richten
• Im Browser <meineDomain>/contao-manager.phar.php aufrufen

Wie bei C3 brauchst du natürlich vorher eine Datenbank. Außerdem kann es sinnvoll sein, schon direkt ein SSL-Zertifikat für die Domain einzurichten.

Gruß, folkfreund

Was mir noch nicht ganz so klar ist (habe mir auch noch ein Video angeguckt) ist das mit dem Anlegen der Ordnerstruktur. Heisst es am Schluss :

- public_html/cms/web/contao-manager.phar.php

oder

- public_html/web/contao-manager.phar.php

Zuerst verstand ich es so, dass ich meinte die zweite Variante.

Dann aber verstand ich es so, dass ich die erste Variante (public_html/cms/web/contao-manager.phar.php) machte. Doch sicher bin ich mir nicht. Könnt Ihr mir das kurz sagen, gerne? Wäre super.

(die PHP-Einstellungen auf dem Server habe ich schon mal gemacht - danke!)

Herzlichen Dank und beste Grüsse
Claudia

[tab]

Ich würde immer die Variante in einem Unterordner deines Webspace-Root (ich gehe mal davon aus das ist public_html) bevorzugen. Also deine erste Variante mit dem cms Unterordner. Möglich sind aber beide Varianten, man muss halt die Domain in jedem Fall dann auf den entsprechenden web-Ordner leiten. Der Unterschied zu Contao 3 ist eigentlich nur, dass die Domain in den Unterordner web geleitet werden muss und nicht in den (bei Contao4 darüberliegenden) Installationsordner. Hättest du also Contao 3 in public_html/cms installiert, dann nimm auch jetzt die Variante 1. Hättest du es idirekt in public_html installiert dann eben die Variante 2. Mit Variante 2 hast du halt keine (gute) Möglichkeit mehr, noch eine andere Seite in deinem Webspace zu installieren, weil deine gazen Contao-Dateien direkt auf der obersten Ebene zu liegen kommen. Und das funktioniert mit dem Manager auch sowieso nur, wenn dieser Ordner leer ist (abgesehen vom Unterordner web natürlich). Also z.B. weitere Installationen für Updates, Weiterentwicklung der Seite usw. sind mit Variante 2 eher schwierig. Das gilt für Contao 3 ebenso wie für Contao 4.

[folkfreund]

Wichtig bei der Installation ist, dass der Ordner oberhalb von /web vor dem Aufruf der contao-manager.phar.php leer ist! Sonst bekommst du Fehlermeldungen.

Darum ist ein zusätzlicher Unterordner die einfachere Lösung, v.a. wenn du später noch eine weitere Installation in eine Subdomain (für Weiterentwicklung, Relaunch etc.) einrichten willst.