Backup einer 4.4 - so oder wie?

[tab]

Ich finde schon, dass eine Website-Agentur oder ein Freelancer, der sich auf die Fahne schreibt Websites erstellen zu wollen mit diesen unanständigen Wörtern was anfangen können sollte. Contao ist doch kein Baukasten-System .

Sehe ich natürlich genauso. So ein um eine Umzugs-/Backupfunktion erweiterter Contao-Manager ist schön, ersetzt aber die Konsole nicht vollständig. Besonders wenn eben mal was nicht so funktioniert wie erwartet, oder wenn der Contao-Manager auf dem Garnichtsobillig-Webspace des Kunden bei einem der "Marktführer" nicht funktioniert. Das könnte sich eine Agentur vielleicht bestenfalls erlauben, wenn sie dem Kunden zwingend eins von mehreren bekannt funktionierenden Hostings zur Bedingung macht.

Dringend gesucht : CMS mit den Features von morgen, lauffähig auf allen Hostings - auch mit der Technik von vorgestern.

[Y-Nell]

Ich vermute eher das die Agenturen mit < C4 bisher ein gutes und in der Handhabung einfaches CMS hatten. In Bezug auf das Hosting im Prinzip einfaches Copy & Paste.

Auch wird nicht jeder täglich mit der Console arbeiten müssen, sodass man in dem Zusammenhang C4 schon als aufwändiger betrachten muss.

C4 ist für die Zukunft gerüstet, keine Frage aber auf Kosten der Systemanforderungen und entsprechendes Wissen. Daher kann auch ich nachvollziehen, dass C4 gerade für kleine Projekte vielleicht doch zu anspruchsvoll geworden ist.

[folkfreund]

Ich finde schon, dass eine Website-Agentur oder ein Freelancer, der sich auf die Fahne schreibt Websites erstellen zu wollen mit diesen unanständigen Wörtern was anfangen können sollte. Contao ist doch kein Baukasten-System .

Stimmt. Aber ich finde, Contao sollte trotzdem auch für Nicht-Profis attraktiv sein/bleiben (ich gehöre auch dazu).
Und falls es möglich ist, eine gute Unterstützung durch Tools zu schaffen, dann bin ich auf jeden Fall dafür! Das Bessere ist der Feind des Guten... Abgesehen davon werden gute Tool Zeit einsparen - und gerade für die Profis ist Zeit = Geld .

Mir ist auch bewusst, dass es aktuell oft an den Gegebenheiten des Hostings hängt. Aber vor 10 Jahren gab es nicht mal überall PHP, heute gehören SSL Zertifikate und oft ein SSH-Zugang zur Grundausstattung. Das wird sich alles in naher Zukunft relativieren, davon bin ich überzeugt.

[zonky]

gebe Y-Nell und folkfreund recht... meine ersten E-Mails habe ich auch auf Konsole abgesetzt und Bilder wurde per uuencode/uudecode umgewandelt als ASCII-Block... will heute sicher keiner mehr

[tab]

Naja, das hat jetzt hiermit aber auch sowas von gar nichts zu tun. Und selbst damals gab es für so etwas schon Programme. Ein Zugriff auf den Webserver ist halt entweder indirekt über den Apache oder direkt per Konsole möglich. Und wenn du beim Umweg über den Apache nicht genug Ressourcen bekommst, dann nimmst du halt was übrig bleibt. Zumal der direkte Weg nicht grundsätzlich der schlechtere oder langsamere ist. Das mit den Ressourcen wird sich irgendwann ändern, da bin ich auch überzeugt. Aber im Moment ist es eben häufig noch nicht so. Und beim Eintippen von Befehlen oder Kopieren per Copy&Paste ist auch noch niemand ein Finger abgebrochen. Selbst Scotty konnte noch die Formel für transparentes Aluminium in Sekundenschnelle per Tastatur eingeben, als der Computer auf seine Sprachbefehle partout nicht reagieren wollte . Hier wird ja teilweise so getan, als ob man für die Eingabe einfacher und nachlesbarer Befehle ein versierter Linux-Admin sein müsste. Hoffentlich kommt nicht noch einer auf die Idee, das man das alles über Siri durchführen können muss anstatt über veraltete Interfaces wie Tastatur und Maus.

[mvo]

Wenn ihr aufhören würdet immer die ganze Installation zu sichern, hättet ihr auch keine Probleme mit Symlinks. :-) Das Problem ist wirklich nicht das System, sondern vermutlich der Versuch irgendein altes gelerntes Muster darauf anzuwenden.

Wie schon unzählige Male erwähnt reicht es neben dem DBDump in der Regel Files, Templates, composer.json/lock + ggf. angepasste Config-Files zu sichern und gut ist. Und wer sich gegen Repositories und Deployment verwehrt, macht das halt per FTP.

[ok99]

Moin in die Runde!

Ich möchte auch noch mal meinen "Senf" zu diesem Thema dazugeben, die ich aktuell vor genau dem Problem stehe, Contao4 auf einen anderen Server zu "kopieren".

Vieles, was hier gesagt wird, von beiden Seiten, hat durchaus seine Berechtigung, aber man muss es einfach differenzieren.

Contao 4 läuft auf einigen Servern wirklich richtig gut und gerade der Manager ist schon eine große Hilfe, gerade beim Updaten.
ABER, wenn ein Kunde schon einen Server hat (bspw. bei 1und1, was aufgrund der Populaität nicht unwahrscheinlich ist!) und auch nicht wechseln möchte oder aufgrund der Kosten oder Vertragslaufzeiten nicht kann/will, dann ist man mit Contao 4 schon aufgeschmissen. Contao 4 ist so anspruchsvoll geworden, dass viele Server damit nicht klar kommen. Und das nervt wirklich total! Da helfen auch die Sprüche "1und1 taugt doch eh nichts" oder "muss man sich halt einen richtigen Server holen" so überhaupt nicht weiter! Da wurde aus meiner Sicht etwas an der Realität vorbei entwickelt....

Ich bin seit Jahren totaler Contao Fan! Ich liebe dieses System! Aber mit Contao 4 haben die Entwickler uns "Normalos" wirklich keinen Gefallen getan!
Natürlich muss man bei einem neuen System umdenken, sich neu einarbeiten und lernen, aber die Lernkurve scheint mir hier doch sehr hoch!

Das ich jetzt noch nicht einmal, ein einfaches Backup, bzw. einen einfachen Umzug auf einen anderen Server realisieren kann, das stimmt micht echt traurig.
Natürlich gibt es diverse Lösungen und Ansätze hier, aber das funktioniert ja in der Realität auf sehr vielen Server so überhaupt nicht!
Ich habe viele der hier genannten Ansätze ausprobiert, habe mich echt reingekniet und viele Tage damit verbracht, aber glücklich bin ich dabei nicht geworden!
Ich kann nicht überall per Konsole arbeiten, auch der Contao Manager funktioniert auf so vielen Servern nicht (bspw. 1und1) oder Erweiterungen können hier nicht installiert werden, die Symlink-Problematik nervt zusätzlich und und und .....

Eine einfache Komplett-Sicherung, so wie es bei den meisten anderen CMSen möglich ist, also Ordner (zippen und) sichern, Datenbank-Dump anlegen, das ganz dann auf einen anderen Server schupsen, Datenbank einspielen und alles ist gut, gibt es mit Contao 4 nun nicht mehr.
Contao hat mit der 4 Version wirklich viel verloren, was Contao ausgezeichnet hat! Leider! Die Zeilgruppe dafür ist leider eine andere geworden und Contao wird dadurch sehr an Popularität verlieren und den Anschluss an andere CMSe verlieren ....
Ich stehe nun vor dem Problem, wenn ein Kundenserver nicht für Contao geeignet ist (einige Kunden haben nunmal ihre Provider und wollen nicht wechseln!), was ich tun soll? Contao 3.5 ist spitze, aber wird nicht mehr so lange supportet, Wordpress finde ich absolut schei**.....

Dies ist natürlich nur meine Meinung, andere sehen das ganz anders und viele fühlen sich dadurch vielleicht auf den Schlipps getreten, aber so ganz sollten die Entwickler, die ja wirklich grandiose Arbeit leisten und ihre Freizeit opfern, die Stimmung, die gerade herrscht nicht einfach ignorieren ...

[Stefko]

Moin,

also ich sehe nur einen einzigen Show-Stopper, der gegen den Einsatz von Contao4 spricht und das ist ein nicht vorhandener SSH-Zugang. Ist dieser nicht vorhanden hat man uU wirklich die Pappnase auf und steht wie gerade mit dem Symfony-Problem blöde da (zwar lässt sich dieses wohl auch ohne SSH lösen, aber wesentlich aufwändiger).
Aber um SSH zu haben braucht man nicht gleich einen V-Server oder den Hoster zu wechseln. Im besten Fall genügt ein Anruf, meist ein einfacher Wechsel in ein etwas größeres Paket (hatte ich bei einigen Kunden und die hatten zT so alte Verträge, dass der neue auch nicht teurer war (1&1)).

ABER, wenn ein Kunde schon einen Server hat (bspw. bei 1und1, was aufgrund der Populaität nicht unwahrscheinlich ist!) und auch nicht wechseln möchte oder aufgrund der Kosten oder Vertragslaufzeiten nicht kann/will, dann ist man mit Contao 4 schon aufgeschmissen.

Contao4 läuft bei 1&1, wie hier im Forum schon zigfach erklärt wurde ist lediglich die Abhängigkeitsauflösung durch den Composer die Hürde.
Das habe ich selbst bei mehreren Installationen. Einfachste Lösung: Eine lokale Installation auf welcher die Auflösung durchgeführt wird und anschließend composer.json und composer.lock auf den Produktiv-Server spielen und anschließend auf der Konsole ein composer install ausführen. Das geht mittlerweile auch mit dem Manager (habe ich selbst aber noch nicht getestet, da überall SSH vorhanden.
Ein Weg zu dem ich auch raten würde, selbst wenn der Server ausreichend RAM hätte, denn es vermindert die Downtime der Seite auf ein Minimum und man kann zuvor alles in einer Testumgebung testen. Teufel, Eichhörnchen und so weiter ... Ich bin einfach kein Freund von Operationen am "offenen Herzen"

Eine einfache Komplett-Sicherung, so wie es bei den meisten anderen CMSen möglich ist, also Ordner (zippen und) sichern, Datenbank-Dump anlegen, das ganz dann auf einen anderen Server schupsen, Datenbank einspielen und alles ist gut, gibt es mit Contao 4 nun nicht mehr.

Doch das geht, habe ich anfangs selbst so gemacht. Komplette Contao-Installation auf der Konsole .tar.gz packen auf dem Testserver wieder auspacken, DB-Verbindung anpassen und fertig. Die Sym-Links stellen wohl vor allem unter Windows ein Problem da, wenn man sie einfach per FTP runterlädt.
Aber wie hier auch schon erklärt wurde, ist das eigentlich gar nicht nötig -> "files/, templates/, composer.json/lock + ggf. angepasste Config-Files zu sichern und gut ist"

Contao hat mit der 4 Version wirklich viel verloren, was Contao ausgezeichnet hat! Leider! Die Zeilgruppe dafür ist leider eine andere geworden und Contao wird dadurch sehr an Popularität verlieren und den Anschluss an andere CMSe verlieren ....

Ich vermute eher, dass andere CMSe über lang oder kurz den gleichen Weg gehen werden/müssen

[zonky]

Moin in die Runde!

Ich möchte auch noch mal meinen "Senf" zu diesem Thema dazugeben, die ich aktuell vor genau dem Problem stehe, Contao4 auf einen anderen Server zu "kopieren". ...

vielleicht wäre ein CONTAOlight für Dich das Richtige ;-)

[dackelchen]

Hi ok99,

was Du schreibst ist richtig. Auch ich finde es echt schade, dass Contao ein Stück Einfachheit verloren hat. Die Lernkurve ist schon ordentlich nach oben gegangen, was den Installations- und Updatebereich angeht.

Ich sehe Contao im Gegensatz zur Version 3.5 – wie Du – zur Zeit auch nicht als geeignetes CMS, um damit mal eben eine kleine Kundenseite zu machen, mit der man anschließend nie wieder etwas zu tun hat. Das Know-how in dem Bereich ist beim Kunden einfach nicht da. Deshalb mache ich die ganz kleinen Aufträge im Moment mit WordPress, macht keinen Spaß, geht aber gerade nicht anders.

Ich habe aber auch festgestellt, dass das eigentliche Problem nicht die Kunden sind, sondern ich anfangs keinen überragenden Job gemacht habe. Ich habe meinen Kunden einfach nicht gut genug erklärt, wie genau sie die Updates machen und wo sie klicken müssen. Je länger ich aber mit der C4 unterwegs bin, desto besser kenne ich mich aus und desto besser kann ich meine Kunden schulen.

Was ich dagegen bei der C$ schmerzlich vermisse ist eine Auflistung der installierten Bundles und den Hinweis auf neue Contaoversionen. Ich denke nämlich, dass das Fehlen eines Hinweise Contao auf Dauer unsicherer macht, weil Sicherheitsupdates schlichtweg vergessen werden, weil der entsprechende Hinweis fehlt.

Providerwechsel. Das ist ja nun wirklich kein Hexenwerk, wenn die Servervoraussetzungen stimmen. Mach doch einfach mal einen Thread auf, dann wird Dir hier mit Sicherheit geholfen.

Gegenüber dem Kunden ist das dann wiederum eine Frage der Argumentation, auf die Du Dich vorbereiten kannst. Die Änderungen sind ja schlie0lich nicht deswegen da, um uns zu ärgern, sondern damit Contao für die Zukunft gut aufgestellt ist.

Im Augenblick nervt es zwar, dass Contao nicht überall reibungslos oder zum, Teil gar nicht läuft, aber hey, das gibt sich. Auch die anderen CMS Systeme werden bald vor dem Problem stehen, dass deren Systeme in der jetzigen Form ausgereist sind und sie nachlegen müssen. Überlege mal, wie umständlich es bis vor kurzem noch war, ein HTTPS- Zertifikat zu installieren.

[ok99]

Vorab vielen Dank für deine Informationen!

Ich durchblicke das aber irgendwie nicht .....

Contao4 läuft bei 1&1, wie hier im Forum schon zigfach erklärt wurde ist lediglich die Abhängigkeitsauflösung durch den Composer die Hürde.
Das habe ich selbst bei mehreren Installationen. Einfachste Lösung: Eine lokale Installation auf welcher die Auflösung durchgeführt wird und anschließend composer.json und composer.lock auf den Produktiv-Server spielen und anschließend auf der Konsole ein composer install ausführen. Das geht mittlerweile auch mit dem Manager (habe ich selbst aber noch nicht getestet, da überall SSH vorhanden.
Ein Weg zu dem ich auch raten würde, selbst wenn der Server ausreichend RAM hätte, denn es vermindert die Downtime der Seite auf ein Minimum und man kann zuvor alles in einer Testumgebung testen. Teufel, Eichhörnchen und so weiter ... Ich bin einfach kein Freund von Operationen am "offenen Herzen"

Dass das bei 1und1 laufen soll, habe ich bisher noch nicht entdecken können. Und zum laufen gebracht habe ich es bei 1und1 auch noch nicht fehlerfrei. AUch mit deiner "Anleitung" kann ich erstmal so nichts anfangen.... Wie soll ich eine bestehende Installation, die nicht lokal liegt, sondern auf einem anderen Entwicklungsserver, sauber zu 1und1 transferieren???
Mein Ansatz war bisher, Contao per Manager auf 1und1 Server zu installieren (mit PHP 7 hat das auch geklappt), nur dann konnte ich die benötigten Erweiterungen nicht installieren und damit ist dann Theme importieren und Db einspielen hinfällig.

Doch das geht, habe ich anfangs selbst so gemacht. Komplette Contao-Installation auf der Konsole .tar.gz packen auf dem Testserver wieder auspacken, DB-Verbindung anpassen und fertig. Die Sym-Links stellen wohl vor allem unter Windows ein Problem da, wenn man sie einfach per FTP runterlädt.
Aber wie hier auch schon erklärt wurde, ist das eigentlich gar nicht nötig -> "files/, templates/, composer.json/lock + ggf. angepasste Config-Files zu sichern und gut ist"

Ich habe leider absolut keine Möglichkeit per Konsole zu arbeiten, kann also die Installation nicht .tar.gz packen! Ich habe bisher auch noch kein PHP Script gefunden, was mir dies erledigt. Als .zip packen habe ich diverse Scripte gefunden, aber die helfen mir ja nicht weiter.

Ich stehe einfach auf dem Schlauch, vielleicht blockiere ich innerlich auch, weil mich das echt ärgert .....

[ok99]

vielleicht wäre ein CONTAOlight für Dich das Richtige ;-)

Vielen Dank für die äußerst konstruktive Antwort!
All meine Probleme und Sorgen haben sich damit quasi in Luft aufgelöst! Contao 4 ist einfach nur super! Alles läuft!

[tab]

Dass das bei 1und1 laufen soll, habe ich bisher noch nicht entdecken können. Und zum laufen gebracht habe ich es bei 1und1 auch noch nicht fehlerfrei. AUch mit deiner "Anleitung" kann ich erstmal so nichts anfangen.... Wie soll ich eine bestehende Installation, die nicht lokal liegt, sondern auf einem anderen Entwicklungsserver, sauber zu 1und1 transferieren???
Mein Ansatz war bisher, Contao per Manager auf 1und1 Server zu installieren (mit PHP 7 hat das auch geklappt), nur dann konnte ich die benötigten Erweiterungen nicht installieren und damit ist dann Theme importieren und Db einspielen hinfällig.

Um die benötigten Erweierungen zu installieren, musst du lediglich die composer.json und composer.lock vom Entwicklungsserver auf den 1&1 Server transferieren. Danach kannst du sie entweder in der Konsole mit "composer install" oder im Manager (Systemwartung->Installer ausführen) installieren lassen. Da hier nur die Erweiterungen installiert werden müssen und die Abhängigkeiten nicht neu aufgelöst werden, reicht das RAM auch bei 1&1 normalerweise dicke.

Ich habe leider absolut keine Möglichkeit per Konsole zu arbeiten, kann also die Installation nicht .tar.gz packen! Ich habe bisher auch noch kein PHP Script gefunden, was mir dies erledigt. Als .zip packen habe ich diverse Scripte gefunden, aber die helfen mir ja nicht weiter.

Kein Konsolenzugang bei 1&1? Dann ist das aber entweder ein uraltes Paket oder ein "Starter" Paket ("Für überwiegend statische HTML-Seiten"). Oder geht es dabei gar nicht um 1&1?

[Spooky]

Starter Paket hat auch SSH Zugang.

[ihkwdiopk]

Ich kann mich da nur anschliessen, früher war alles so einfach - ein Klick und zack war die Webseite fertig. Ich konnte damit ohne Probleme leicht meinen Lebensunterhalt als Quereinsteiger bestreiten. Doch mit Contao 4 hat sich alles geändert. Seit dem kann ich nicht ...mimimi... und was mich total aufregt ist ...mimimi... Es ist nicht zu fassen, dass die Entwickler ...mimimi... und der Knopf für die fertige Webseite ist auch verschwunden.

Ich habe mich dann dazu entschlossen eine Ausbildung zum Informatiker zu absolvieren; habe mehrere Bücher gelesen und viel selber ausprobiert. Nun ja - ich muss sagen, es hat sich viel geändert. Ich verstehe jetzt das Konzept hinter Contao4 und finde die eingebrachten Ideen super und zukunftsorientiert. Nach dem ganzen Lernen fühle ich mich nun auch bei all meinen Projekten viel besser, da ich für meine Kompetenz diesmal tatsächlich bezahlt werde. Es reichte einfach für mich nicht mehr aus, zu wissen, dass "www.domain.tdl" eine Subdomain ist.

[ok99]

Um die benötigten Erweierungen zu installieren, musst du lediglich die composer.json und composer.lock vom Entwicklungsserver auf den 1&1 Server transferieren. Danach kannst du sie entweder in der Konsole mit "composer install" oder im Manager (Systemwartung->Installer ausführen) installieren lassen. Da hier nur die Erweiterungen installiert werden müssen und die Abhängigkeiten nicht neu aufgelöst werden, reicht das RAM auch bei 1&1 normalerweise dicke.

Du meinst also, ich kann Contao 4 auf dem 1und1 Server über den Contao Manager installieren (geht meines Wissens aber nur mit PHP 7, aber nicht mit PHP7.1..) , dann die beiden composer-Dateien per FTP überspielen und dann im Manager über die Systemwartung den Installer "Composer Abhängigkeiten" ausführen? Damit werden dann die Erweiterungen nachinstalliert ohne das es zum Fehler/Abbruch kommt?
Verstehe ich das richtig? Das wäre ja ein Träumchen .....

Kein Konsolenzugang bei 1&1? Dann ist das aber entweder ein uraltes Paket oder ein "Starter" Paket ("Für überwiegend statische HTML-Seiten"). Oder geht es dabei gar nicht um 1&1?

Ich habe keine Konsole, auf dem Server, wo ich mein Contao-Projekt entwickelt habe. Deshalb kann ich das hier nicht .tar.gz'tten und auf 1und1 transferieren.

[Spooky]

Du meinst also, ich kann Contao 4 auf dem 1und1 Server über den Contao Manager installieren (geht meines Wissens aber nur mit PHP 7, aber nicht mit PHP7.1..) , dann die beiden composer-Dateien per FTP überspielen und dann im Manager über die Systemwartung den Installer "Composer Abhängigkeiten" ausführen? Damit werden dann die Erweiterungen nachinstalliert ohne das es zum Fehler/Abbruch kommt?
Verstehe ich das richtig? Das wäre ja ein Träumchen .....

Du kannst auch folgendes machen:

• composer.json & composer.lock auf den Server kopieren.
• Per SSH verbinden.
• wget https://getcomposer.org/download/1.6.4/composer.phar
• /usr/bin/php7.1-cli composer.phar install -o
• Templates, Dateien & sonstige selbst erzeugte Dateien auf den Server kopieren.
• DocumentRoot setzen.
• Contao Install Tool aufrufen.

[tab]

Du meinst also, ich kann Contao 4 auf dem 1und1 Server über den Contao Manager installieren (geht meines Wissens aber nur mit PHP 7, aber nicht mit PHP7.1..) , dann die beiden composer-Dateien per FTP überspielen und dann im Manager über die Systemwartung den Installer "Composer Abhängigkeiten" ausführen? Damit werden dann die Erweiterungen nachinstalliert ohne das es zum Fehler/Abbruch kommt?
Verstehe ich das richtig? Das wäre ja ein Träumchen .....

Im Prinzip ja. Wie die Situation dazu gerade bei 1&1 ist, weiss ich nicht. Ich habe da keinen Webspace mehr. Und die PHP-Versionen müssen übereinstimmen, sonst müssen noch Einträge in der composer.json gemacht werden. Ist aber alles irgendwo hier im Forum beschrieben. Z.B. hier

Ich habe keine Konsole, auf dem Server, wo ich mein Contao-Projekt entwickelt habe. Deshalb kann ich das hier nicht .tar.gz'tten und auf 1und1 transferieren.

Das ist natürlich ganz schlecht. Aber nicht hoffnungslos. Schau dir mal die Erweiterung BackupDB an. Die liefert auf Wunsch ein Skript mit, mit dem beim Dateitransfer zerstörte SymLinks automatisch wieder hergestellt werden können. Allerdings würde ich den Server dann auch nicht unbedingt als Entwicklungsserver hernehmen und eher lokal entwickeln (z.B. XAMPP). Da hast du dann zwar unter Windows auch keinen funktionierenden Manager, aber einen prima funktionierenden composer in der Konsole.

[Samson1964]

Um die benötigten Erweiterungen zu installieren, musst du lediglich die composer.json und composer.lock vom Entwicklungsserver auf den 1&1 Server transferieren.

Da dieser Vorschlag immer wieder gemacht wird, würde mich mal interessieren wie das überhaupt funktioniert?! Ohne Vorwissen würde ich jetzt versuchen (unter Windows) möglichst genau mit XAMPP die Konfiguration inkl. aller Dateien und der Datenbank vom Server lokal nachzubauen - und dann die Erweiterungen lokal installieren und die beiden Dateien hochladen. Doch wie ist es bei mehreren Webseiten mit unterschiedlichen PHP-Versionen? Wie kriege ich denn das gewuppt? Kann man denn XAMPP mit unterschiedlichen PHP-Versionen betreiben?

[Spooky]

Die PHP Version kannst du in der "platform" Definition unter "config" in der composer.json festlegen.

[tab]

Kann man im Prinzip. Muss man aber nicht. Man muss nur in der composer.json die auf dem Server verwendete PHP-Version eintragen wie im Link beschrieben. Dazu sollte die PHP-Version nicht älter sein als die auf dem Server. Ob das Problem bei 1&1 mit neueren PHP-Versionen als 7.0 mittlerweile überhaupt noch besteht, wäre natürlich auch erst nochmals zu überprüfen. Ist ja doch schon einige Monate alt der Thread. Die neuesten PHP-Versionen bei 1&1 funktionieren meistens noch nicht einwandfrei, zumindest wenn sie noch als "experimentell" oder ähnliches gelistet sind bei der PHP-Versionsauswahl. Das dürfte ja aber mittlerweile für PHP 7.1 nicht mehr gelten. Ich kann es leider (oder zum Glück) nicht mehr nachprüfen.

[Spooky]

Auch wenn die PHP Version, die du lokal verwendest, neuer ist als die auf dem Server, kann es zu Problemen komen. Angenonmmen du verwendest auf dem Server nur PHP 7.0, lokal aber PHP 7.2. Dann würdest du lokal alle Abhängigkeiten für PHP 7.2 installieren, was aber im Falle von doctrine bspw. dann zu einem Fehler auf dem Server führen wird.

[tab]

Ich meine natürlich mit in de rcomposer.json eingetragener "Plattform". Die ersten beiden Sätze bezogen sich auf XAMPP mit mehreren PHP-Versionen. Das geht, aber es wird eben nicht benötigt, weil man ja den "platform" Eintrag jeweils passend für die einzelnen Installationen machen kann in der composer.json.

[fiedsch]

Ohne Vorwissen würde ich jetzt versuchen (unter Windows) möglichst genau mit XAMPP die Konfiguration inkl. aller Dateien und der Datenbank vom Server lokal nachzubauen - und dann die Erweiterungen lokal installieren und die beiden Dateien hochladen.

Das Thema mit den untersschiedlichen PHP-Versionen wurde ja bereits diskutiert.

Darüber hinaus müsstest Du lokal keinen Webserver und keien Datenbank betreiben -- also keine vollständige/lauffähige Contao-Installation. Du brauchst eigentlich nur die composer.json und PHP um eine aktualisierte composer.lock zu erzeugen.

Die composer.json und die composer.lock gehen dann auf den Server und dort führst Du ein composer install aus.

Die lokal heruntergeladenen Dateien im vendor Ordner könntest Du theroretisch wieder löschen. Sie sparen aber wahrscheinlich Traffic bei nicht aktualisierten Paketen, wenn Du das das nächste Mal wiederholst.

[planepix]

Sollte noch jemand am Mac lokal deployen und einen Tipp / Link haben, wie ich mehrere PHP-Version lokal verwalten kann: Her damit . Danke.

[fiedsch]

Sollte noch jemand am Mac lokal deployen und einen Tipp / Link haben, wie ich mehrere PHP-Version lokal verwalten kann: Her damit . Danke.

Hallo Thomas,

meinst Du lokal verschiedene PHP-Versionen betreiben oder von lokal deployen für verschiedene PHP-Versionen auf verschiedenen Servern?

[planepix]

Hallo Andreas,

lokal würde ich gerne die ~relevanten PHP-Versionen verwenden können ohne MAMP, Docker etc.. Ggf. macht das dann dennoch Sinn - ich würde mir eben einfach für das Update der composer.json und composer.lock - wie in eurem Blogpost vom Stammtisch beschrieben - je Projekt einen lokalen Ordner anlegen, dann via Konsole die PHP-Version passend zur Version, die online verwendet wird, aufrufen wollen und das Update ausführen.

In einem Test habe ich lokal hier die 7.1.2, auf dem Server die 7.0.25. Damit habe ich einmal ein Update ausgeführt und hatte - wenn wunderts - alle Verzeichnisse einer Contao-Installation lokal in dem Ordner; nicht nur den beschriebenen Vendor-Ordner.

[fiedsch]

Wenn ich es richtig verstanden habe, musst Du für das Auflösen für (z.B.) PHP 7.2 Anfordeungen (Server) lokal nicht PHP 7.2 haben sondern nur die "platform" im Abschnitt "config" passend -- also "7.2" -- eintragen (siehe #180).

Wenn ich es nicht richtig verstanden habe, wird mir sicher bald jemand widersprechen ;-)

In einem Test habe ich lokal hier die 7.1.2, auf dem Server die 7.0.25. Damit habe ich einmal ein Update ausgeführt und hatte - wenn wunderts - alle Verzeichnisse einer Contao-Installation lokal in dem Ordner; nicht nur den beschriebenen Vendor-Ordner.

Das macht ja aber nichts, die Ordner könntest Du ignorieren oder wieder löschen. Wichtig ist die so erzeugte composer.lock

[planepix]

Danke dir Andreas. Dann teste ich das so einmal. Und wir schauen wer ergänzt oder widerspricht

[planepix]

So Testlauf beendet.

Spannend:
Rufe ich online „php -v” auf, wird mit PHP 7.0.25 (cli) angezeigt.
Hoster ist allinkl.

IM KAS ist PHP 7.2.1 eingestellt; das ist ja „nur” die PHP-Version für Webanwendungen und ist nicht zwingend die gleiche Version wir die für den Aufruf via Konsole.

Habe nun in der composer.json ergänzt:

"config": {
        "component-dir": "assets",
        "platform": {"php": "7.0.25"}

Und erhalte dann beim Testlauf mit „composer update --dry-run” folgende Ausgabe:

Your requirements could not be resolved to an installable set of packages.


  Problem 1
    - ausi/contao-slug-backport v1.0.2 requires ausi/slug-generator ^1.0.1 -> satisfiable by ausi/slug-generator[v1.0.1].
    - ausi/contao-slug-backport v1.0.3 requires ausi/slug-generator ^1.0.1 -> satisfiable by ausi/slug-generator[v1.0.1].
    - ausi/contao-slug-backport v1.0.0 requires ausi/slug-generator ^1.0 -> satisfiable by ausi/slug-generator[v1.0.0, v1.0.1].
    - ausi/contao-slug-backport v1.0.1 requires ausi/slug-generator ^1.0 -> satisfiable by ausi/slug-generator[v1.0.0, v1.0.1].
    - ausi/slug-generator v1.0.1 requires php ^7.1 -> your PHP version (7.1.12) overridden by "config.platform.php" version (7.0.25) does not satisfy that requirement.
    - ausi/slug-generator v1.0.0 requires php ^7.1 -> your PHP version (7.1.12) overridden by "config.platform.php" version (7.0.25) does not satisfy that requirement.
    - Installation request for ausi/contao-slug-backport ^1.0 -> satisfiable by ausi/contao-slug-backport[v1.0.0, v1.0.1, v1.0.2, v1.0.3].

Bedeutet?
Entweder ist die PHP-Version online nicht richtig oder nur die Erweiterungen klappt online auch unter 7.0.25?

Bekommen wir auch noch raus .

[Spooky]

Siehe https://github.com/contao/contao-manager/wiki/All-Inkl

Wenn du PHP 7.2.1 eingestellt hast, musst du

/usr/bin/php72

verwenden. Nicht einfach nur

php

[planepix]

Danke Spooky.

Ok. ich frage mich woher ich diese Zeilen haben…

php72 composer.phar update

Ich habe eben in der lokalen composer.json die PHP-Version 7.1.0 eingestellt und erhalte in der Konsole dann:

Package operations: 145 installs, 0 updates, 0 removals

.
Keine extra Ordner - es wird

[tab]

Es ist eigentlich schade, dass man nicht nur die neue composer.lock erzeugen kann, ohne irgendwelche Pakete herunterzuladen. Das wäre jetzt für Contao 4 eine ziemlich praktische Funktion. Habe aber leider nichts dergleichen gefunden. --dry-run ändert ja wohl gar nichts, also auch nicht die composer.lock .

[mvo]

Es ist eigentlich schade, dass man nicht nur die neue composer.lock erzeugen kann, ohne irgendwelche Pakete herunterzuladen. Das wäre jetzt für Contao 4 eine ziemlich praktische Funktion. Habe aber leider nichts dergleichen gefunden. --dry-run ändert ja wohl gar nichts, also auch nicht die composer.lock .

Die Idee dahinter ist, das du im Testsystem, in dem du das composer update ausführst, sowieso erst einmal testest. Und dazu benötigst du den Vendor Ordner.

(Der Usecase wie für Yannicks Cloud Resolver ist nur bei programmatischer Interaktion mit Composer möglich.)

[xchs]

@toflar hatte das mal vorgeschlagen, wurde aber abgelehnt bzw. nicht für sinnvoll erachtet: https://github.com/composer/composer/pull/4946

[tab]

Tja, ich will ja unter anderem die Downloads auf mein lokales System minimieren. Testen werde ich dort mit Sicherheit nicht in jedem Fall, sondern meistens in einer extra für diesen Zweck angelegten Kopie auf dem selben Server wie das Live-System. Ich sehe keinen großen Sinn darin, das lokal auf einem Windows-Rechner zu machen, der von der Konfiguration her vom Zielserver eine ganze Ecke entfernt ist. Das würde nur Sinn machen, wenn ich etwas entwickeln würde und es debuggen müsste. Aber selbst dann würde ich wohl den finalen Test auf dem Zielserver machen. Aber gut, abgelehnt ist abgelehnt. Dann bleibt es halt beim Update auf meinem eigenen Webspace, werde dann halt eventuell bei mehreren Hostern jeweils ein geeignetes Paket brauchen, um möglichst nah am Zielsystem zu sein .

[mvo]

Tja, ich will ja unter anderem die Downloads auf mein lokales System minimieren. Testen werde ich dort mit Sicherheit nicht in jedem Fall, sondern meistens in einer extra für diesen Zweck angelegten Kopie auf dem selben Server wie das Live-System. Ich sehe keinen großen Sinn darin, das lokal auf einem Windows-Rechner zu machen, der von der Konfiguration her vom Zielserver eine ganze Ecke entfernt ist. Das würde nur Sinn machen, wenn ich etwas entwickeln würde und es debuggen müsste. Aber selbst dann würde ich wohl den finalen Test auf dem Zielserver machen. Aber gut, abgelehnt ist abgelehnt. Dann bleibt es halt beim Update auf meinem eigenen Webspace, werde dann halt eventuell bei mehreren Hostern jeweils ein geeignetes Paket brauchen, um möglichst nah am Zielsystem zu sein .

Und die Begründung ist ja auch durchaus nachzuvollziehen. Die Frage ist wie esoterisch der Usecase ist. :-)

Der Download auf deinen 'Resolving'-Rechner wird aber vermutlich auch nicht der Bottleneck sein.

[tab]

Naja, esoterisch,..., ich mag jetzt nicht Wikipedia dazu zitieren. Ich habe jetzt leider bei Unitymedia zwar schnelles Internet, aber nur wenn es gerade funktioniert. Und wie es der Zufall so will, gerade wenn man es dringend braucht, ist es weg. So geschehen bereits mehrfach wieder heute Morgen. Habe zwar in weiser Voraussicht immer einen Surfstick als Reserve, aber natürlich da kein unbegrenztes Datenvolumen. Sofern Unitymedia - wie im Moment - funktioniert, trage ich aber gern meinen Teil zur Überlastung des Internets bei, indem ich pro Kundeninstallation bei einem notwendigen Update (wie z.B. heute) jeweils mehrere hundert Pakete runterlade, die ich hinterher zu mindestens 99,9% unbenutzt wieder lösche. Zum Glück sind die meisten Installationen noch Contao 3, da kann ich mir den lokalen Zwischenschritt sowieso sparen.

Den abschliessenden Funktionstest irgendeiner Software NICHT auf dem Zielsystem (oder zumindest einem 100 %-igen Klon des Zielsystems) durchzuführen, halte ich zwar meinerseits nicht für esoterisch, aber für, sagen wir mal einfach blauäugig. Bei der Art von Software, die ich früher entwickelt habe, hätte ich eher das Wort "unverantwortlich" benutzt. Bei einer Website belasse ich es bei "blauäugig", da geht es ja schlimmstenfalls um materielle Werte. Soviel zum Thema Esoterik allgemein und zum Thema esoterischer Usecase im Besonderen.

[fiedsch]

indem ich pro Kundeninstallation bei einem notwendigen Update (wie z.B. heute) jeweils mehrere hundert Pakete runterlade

Ich denke, Du lädst es nur einmal runter, beim zweiten Kunden sollte es aus dem Cache kommen. Das macht es zumindest etwas besser.

Den abschliessenden Funktionstest irgendeiner Software NICHT auf dem Zielsystem (oder zumindest einem 100 %-igen Klon des Zielsystems) durchzuführen, halte ich zwar meinerseits nicht für esoterisch, aber für, sagen wir mal einfach blauäugig.

M.E. geht es auch nicht darum mit einem lokalen Test zu "beweisen", daß es auch auf dem Server laufen wird. Das muss ich auf jeden Fall verifizieren. Aber wenn es lokal schon kracht, kann ich erst mal den Grund suchen und brauche auf dem Serber erst gar nicht mehr weiter zu machen.

[tab]

Ist schon richtig, das Ganze ist jetzt auch nicht der Untergang der Welt. Natürlich kann ich damit leben, was bleibt mir auch anderes übrig, auch wenn mir die andere Lösung lieber gewesen wäre. An den Cache hatte ich noch gar nicht gedacht, das macht es in der Tat um einiges besser. Zur Not klone ich das Composer-Projekt, baue den Pull-Request von @Toflar ein und stelle es unter dem Namen esotericComposer zur Verfügung .