Backup einer 4.4 - so oder wie?

[Webstylerin]

Es war eine typische Fehlermeldung, die beim Ausführen eines PHP-Script meistens kommt.
Ich glaube Fehler in Zeile 100.

Hm, danke dir. Dann war das nicht mein Problem. Mich hat der Contao Manager immer nur angemeckert, er könne die Contao-Installation irgendwie nicht zuordnen und ich soll doch alles löschen. Den genauen Wortlaut hab ich verdrängt.

Es wird sicher die Gelegenheit für mich kommen, bei der ich den FTP-Transfer noch mal testen muss.

[gregor]

Da hatte ich anfänglich auch paar Probleme mit dem Manager und mit restoreSymlinks.php auch.
Erst nachdem ich nicht selektiv sondern einfach die komplette Installation transferiert habe, waren die Probleme weg.
Sicherlich wird es nur eine Datei sein, die in dieser Auflistung evtl. fehlt und somit nicht mitkopiert wurde.

[gregor]

Ein Transfer nach All-Inkl hat leider nicht funktioniert, es gibt Probleme mit den Symlinks

Bei AI kann ich mich nur per FTP einloggen, bei df per SFTP.
Bei AI werden mir die per restoreSymlinks.php erstellten Symlinks als graue Datei-Icons in WinSCP angezeigt, bei df werden mir die Symlinks als Verknüpfung angezeigt.

Ob es an den Rechten liegt kann ich nicht sagen, eigentlich habe ich gem. KAS bei AI volle Dateirechte.
Ich vermute mal, dass es was mit SFTP zu tun hat.

[tab]

Hast du einen SSH-Zugang? Falls ja, benutze rsync. Oder hast du sonst noch eine Möglichkeit mit tar ein Archiv zu erstellen? Falls ja, dann erstelle das Archiv, übertrage es per FTP (oder wie auch immer) und packe es auf dem Zielsystem wieder aus.
Edit: FTP oder SFTP haben leider keinen Plan, was ein SymLink ist , da wird die verlinkte Datei übertragen.

[gregor]

Naja, irgendwie funktioniert es ja bei mir mit WinSCP/SFTP bei df.
WinSCP überträgt bei mir keine Symlinks.

Die Symlinks werden ja bei mir von restoreSymlinks.php nach dem Transfer der "richtigen" Dateien erzeugt.
Die Frage wäre eigentlich, warum restoreSymlinks.php bei df korrekt funktioniert und bei AI nicht.
Sie werden ja bei mir in WinSCP unterschiedlich dargestellt.

Es geht mir wirklich nur darum zu testen eine Installation ohne SSH zu transferieren.

[do_while]

Das verstehe ich erstmal auch nicht. Bei mir hat das mit All-Inkl. bisher funktioniert.

Das Script macht folgendes:
Es hat alle Symlinks der gespeicherten Installation in einem Array.
Bei der Ausführung wird jeder Symlink kontrolliert, wenn er bereits vorhanden ist, bleibt alles unangetastet.
Wenn es sich nicht um einen Symlink, sondern um eine Datei oder ein Verzeichnis handelt, wird es umbenannt und unter dem Namen der korrekte Symlink angelegt.

@Gregor:
Interessant wäre jetzt: wie sieht es vor dem Scriptstart in WinSCP aus?
und wie sieht es auf der Kommandozeile aus (ls -l), vor und nach dem Scriptlauf?

[gregor]

Vor dem Scriptstart sind in WinSCP keine Symlinks, oder Dateileichen davon vorhanden, bzw. zu sehen.
Die werden von WinSCP bei mir ja nicht mitkopiert.
Kommandozeile ist in diesem Tarif nicht zugänglich.

Ich denke nicht das es ein Problem vom Script ist.
Das Script meldete nach Aufruf 0 Fehler und 19 erstellte Symlinks.
Leider kann ich jetzt auch keine weiteren Tests mehr auf dem Account durchführen.

Am nächsten Donnerstag haben wir Stammtisch in Frankfurt und vielleicht bekomme ich da einen Bossel-Account bei einem anderen Hoster.
Benötige ja nur eine temporäre Subdomain.

[Y-Nell]

Hallo Zusammen,

Ich scheitere gerade bei Punkt 11. Nach dem Login im CM kommt die Fehlermeldung "ERROR 500 An empty string is not a valid JSON value". Hosting ist Managed Professional, ebenfalls bei df.

Hat jemand eine Idee was nicht stimmen könnte?

Gruß

Thomas

PS: Gregor, dir nochmals vielen Dank für die Anleitung.

[gregor]

Wie ja die Fehlermeldung schon mitteilt, es gibt irgendwo einen leeren String.
Ich weiß jetzt auch nicht, was und wo der CM für Dateien da benötigt.
Vielleicht liegt das Problem in der composer.json oder composer.lock?

[Y-Nell]

Die Dateien hatte ich auch in Verdacht, jedoch waren beide aus dem eigentlichen Backup nicht leer. Dann habe ich sie mit denen aus dem Datenbankbackup von BackupDB ersetzt, hat aber auch nichts gebracht. Die composer.lock ist auch zu komplex, wenn man nicht weiss woran man darin suchen muss.

Ich werde erst einmal alles löschen und versuchen eine Blanko-Installation mit dem CM vorzunehmen. Sollte es dabei schon Probleme geben, liegt die Ursache vermutlich eher bei der Hosting-Konfiguration bzw. beim Composer-Install.

[gregor]

Vielleicht hilft es bei der alten Installation unter Systemeinstellung die Symlinks neu generieren zu lassen und im CM Cache leeren und die Pakete aktualisieren. Dann nochmal BackupDB ausführen und alles neu kopieren.

[Y-Nell]

Bis auf den CM-Cache hatte ich schon alles bereinigt.

[Y-Nell]

So Blanko-Installation verlief erfolgreich.

Dann habe ich deinen Vorschlag mit den Updates und Cache leeren im CM durchgeführt das Ergebnis:

"ERROR 500 Unknown installation status
Some files were found on your server but no known Contao version could be detected.
You must either manually repair your application or remove the following files and folders to install Contao:

- .gitignore
- README.md
- app
- assets
- composer.json
- composer.lock
- files
- system
- templates
- var
- vendor"

Meine Vermutung zu Anfang von Contao 4 bestätigt sich mal wieder. Updates werden mit Composer sehr vereinfacht, dafür steigt der Aufwand an anderer Stelle.

Update:

Im Log steht folgendes:

[2017-09-23 15:20:00] app.CRITICAL: An exception occurred. {"exception":"[object] (Doctrine\\DBAL\\Exception\\ConnectionException(co de: 0): An exception occured in driver: SQLSTATE[HY000] [2002] No such file or directory at /kunden/…/webseiten/contao/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:103, Doctrine\\DBAL\\Driver\\PDOException(code: 2002): SQLSTATE[HY000] [2002] No such file or directory at /kunden/…/webseiten/contao/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:47, PDOException(code: 2002): SQLSTATE[HY000] [2002] No such file or directory at /kunden/…/webseiten/contao/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:43)"} []

Update 2:

Composer Update über die Konsole bringt leider auch nichts.

[Y-Nell]

Problem umschifft dank BugBuster aus einem anderen Thread:

…
Da reicht es im Prinzip die composer.lock zu kopieren und am Ziel "composer install" aufzurufen, schon hast du eine identische Kopie der über composer installierten Pakete (Symfony + Contao + Erweiterungen inkl. der jeweiligen Abhängigkeiten) auf dem Server drauf. Dann die DB kopieren, die files/ und templates/ Dinge, dann erst contao/install aufrufen und es sollte das gewesen sein. (eventuell noch nachträglich manuelle Anpassungen an der parameters.yml übernehmen) …

Meine Vorgehensweise war jetzt insgesamt folgende:

1. Ich habe wie von Gregor vorgeschlagen im CM des zu sichernden Installation ein Update der Pakete und das löschen des Cache durchgeführt. Dann in der Installation unter den Systemeinstellungen alles gelöscht und die Symlinks neu aufgebaut.

2. Backup der DB mit BackDB im Backend vorgenommen.

3. Auf dem Entwicklungsserver ein komplettes Backup per Konsole erstellt:

tar cfvz contao-backup.tar.gz contao-kunde-xy

4. Webverzeichnis auf dem Hosting vorbereiten und Composer herunterladen:

wget https://getcomposer.org/download/1.4.2/composer.phar

5. contao-manager.phar hochladen, umbenennen in contao-manager.phar.php und ein Clean-Install von Contao durchführen. Alternativ per Konsole

/usr/local/bin/php7.0.13-cli composer.phar create-project contao/managed-edition <ziel> 4.4.*

6. Anpassung der parameters.yml in app/config.

7. Kopien von files, templates, composer.json und composer.lock aus dem Backup in die neue Installation. Hier kann man natürlich auch die contao-backup.tar.gz hochladen und per Konsole entpacken:

tar -xvzf contao-backup.tar.gz

und die Verzeichnisse und composer.lock entsprechend verschieben.

8. Datenbank vom Clean-Install mit der aus BackupDB ersetzen.

9. restoreSymlinks.php aus BackupDB in /web kopieren und ausführen.

10. Composer updaten:

/usr/local/bin/php7.0.13-cli composer.phar update

11. Contao-Install aufrufen: sub.domain.de/contao/install

12. Fertig!

Nachtrag:

Ich hab jetzt doch ein Problem mit dem dma_simple_grid festgestellt. Im BE sind die Inhaltselemente sichtbar und können bearbeitet werden aber es fehlen die Felder zum einstellen des Grids. Scheinbar ist also nicht alles vollständig installiert. Reparieren über den CM geht wegen Memory-Limit Fehler nicht.

Per Konsole Update bzw. Simple Grid entfernen und neu installieren hat auch nichts gebracht.

[pcartist]

Hm, danke dir. Dann war das nicht mein Problem. Mich hat der Contao Manager immer nur angemeckert, er könne die Contao-Installation irgendwie nicht zuordnen und ich soll doch alles löschen. Den genauen Wortlaut hab ich verdrängt.

Ich hatte auf zwei Maschinen nach einem "simulierten" Umzug ebenfalls Probleme mit dem Manager. Contao selbst lief im FE und BE ohne Probleme. Letztendlich war in der contao-manager/manager.json nur der Pfad zur php-cli falsch gesetzt.

 "php_cli": "\/Applications\/MAMP\/bin\/php\/php7.1.8\/bin\/php",

Angepasst und lief.

[pcartist]

Für die Managed-Edition gehe ich bei einem Umzug aktuell wie folgt vor:

1. Sicherung der Ausgangsdatenbank
2. Archiv mit Bewegungsdaten ( files / templates / usw ) anlegen
3. composer.lock und composer.json auf das Zielsystem kopieren
4. in der Shell auf dem Zielsystem composer install --no-dev --optimize-autoloader ausführen
5. Datenbankdump im Zielsystem importieren
6. Bewegungsdaten per FTP auf den Zielserver kopieren und entpacken (man kann das auch mit einem Git-Repo und automatischem Deployment machen => PLESK ist mein Freund)
7. /app/config/parameters.yml anlegen (entweder per Hand oder Upload und anpassen
8. contao/install ausführen

Optional:

Contao Manager herunterladen, in den Document Root kopieren, umbenennen und ausführen -> läuft.

Backups sind also vom Inhalt her also ebenfalls recht klar wie in Beitrag 1 von BugBuster Punkt 2

An sich benötige ich die Backups eigentlich nur bei der Übergabe eines Projekts an den Kunden bzw. zum ausrollen einer Seite nach Fertigstellung. Solange ein Projekt bei mit in Betreuung ist, werden serverseitige Backups des vollständigen Webs angelegt.

[zonky]

... es ist schade, dass nicht rechtzeitig an eine Backup/Roll-out-Strategie für C4 gearbeitet bzw. das Vorgehen offenherziger propagiert wurde...

selbst "größere" Agenturen (für die ich ab und an mal was mache) sind in die Falle getappt und haben wie zu C3-Zeiten "einige Stunden vor Deadline" den Roll-out per FTP gemacht... so wie immer halt...

Die Flucherei, was für ein besch*** System C4 geworden ist, müsste ich an Zeit bei der nächsten Rechnung eigentlich mit eintakten ;-)

Die Argumente von "man muss nur ein, zwei Befehle auf der Konsole..." greifen hier m.E. zu kurz - die Agenturen hatten mit Contao (1/2/3) ein robustes und einfach zu handhabendes System. Da sich nun C4 anschickt, etwas nach den "Enterprise-Kirschen zu hangeln", verschreckt das eine ganze Reihe von "alten Contao-Kunden" - aber gut, auf Typo3 schwören ja auch viele...

Sofern sich jemand anschickt, so was zu programmieren, könnte ich gern beim "Geldsammeln" helfen - bei MetaModels 2.1 gelingt mit das ja auch ganz gut ;-)
... und auch selbst was spenden

zonky

[folkfreund]

Hallo Zonky,

anfangs hab ich das auch gedacht - dann bin ich hierauf gestoßen: https://erdmann-freunde.de/logbuch/contao-4-4-umziehen/

Nachdem ich es mal ausprobiert hatte war klar - es ist eigentlich jetzt viel einfacher und schneller als früher
(Ich mach das nicht beruflich und dem entsprechend selten - aber dennoch)

Was könnte man daran durch ein zu erstellendes Programm noch vereinfachen?

• Zusammenstellen von lokal angepassten Dateien (Templates, private Erweiterungen)
• Erstellen des DB Backups
• und dann?

Aber wenn du noch Sponsoren auftreiben kannst, dann gibt es ja vielleicht im Bereich Contao-Manager Verwendung dafür...

Gruß, folkfreund

[zonky]

... den Beitrag kenne ich und verlinke den auch meistens in meiner "Warum-habt-ihr-nicht-vorher-gefragt!-E-Mail"...

aber das sind wir auch an dem Punkt "man muss nur auf der Konsole..."

Die Erweiterung BackupDB von do_while ist ja nicht deshalb so beliebt, weil man seinen DB-Dump auf der Konsole macht.

Hier ist wohl eher ein "pack-mich-ein"- und ein "pack-mich-aus"-Button gewünscht/erforderlich.

Aber wenn du noch Sponsoren auftreiben kannst, dann gibt es ja vielleicht im Bereich Contao-Manager Verwendung dafür...

Meine Erfahrung bei MetaModels: es ist einfacher so ein Feature "zu verkaufen", wenn es schon vorhanden ist (geschützt) und wer es als "early-adopter" einsetzen möchte, eine Spende von mind. x€ leistet - wenn Spendenziel erreicht, gibt es eine Freigabe...

[mlweb]

Wenn es das Hosting zulässt geht das ja auch alles mit dem Manager.
Nach meine Erfahrung steht dem vor allem ein "Das haben wir schon immer so gemacht engegen".

[zonky]

Wenn es das Hosting zulässt geht das ja auch alles mit dem Manager.

Was bedeutet den das "geht das ja auch alles" - den Button "mache Snapshot" habe ich noch nicht entdeckt...?!?

[Stefko]

Ahoi,

ich habe mir mal vor einiger Zeit ein PHP-Script zusammen gedengelt, welches ein mysqldump anstuppst und die kompletten Daten per tar.gz sichert.
Beides wird in einem definierten Ordner gespeichert und dort für eine einstellbare Zeit vorgehalten (hier 14 Tage), bevor sie wieder gelöscht werden.
Den ganzen Vorgang kann man per Cronjob oder auch per Hand/Link (zB aus dem Backend heraus) anstoßen.
Das müsste doch theoretisch das sein, was Du möchtest, oder?

<?php
// Variablen für das Backup

$dbHost = "localhost";                    // Datenbank Host
$dbDatabase = "database";                // Name der Datenbank
$dbUser = "user";                        // Datenbank User
$dbPass = "password";                    // Datenbank Passwort
$project = "Projektname";                // Projektname
$root = "https://domain.tld/";            // Http-Pfad der Installation mit / am Ende
$path = "Backup-Folder";                 // Ordner für Sicherung (Ordner muss existieren)
$prefix = "backup";                        // Backup Name (Daten)
$date = date("Y-m-d_H-i-s");            // Datumsformat (für Filename)
$tage = 14;                                // Angabe in Tagen nach denen Sicherungen gelöscht werden sollen
$fileType = 'gz';                        // Dateiendung welche gelöscht werden soll


// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Ab hier keine Änderungen mehr nötig
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

// Datenbank sichern und als gz-Archiv ablegen
shell_exec('mysqldump -h '.$dbHost.' -u '.$dbUser.' -p'.$dbPass.' '.$dbDatabase.'  | gzip > '.$path.'/'.$date.'_'.$dbDatabase.'.sql.gz');

// Daten sichern und als gz-Archiv ablegen
shell_exec('tar --exclude=\''.$path.'\'* -cvpzf '.$path.'/'.$date.'_'.$prefix.'.tar.gz ./* .??*');

// Textausgabe
echo '<p>Die <strong>'.$project.'</strong> Sicherung wurde am '.$date.' erstellt</p>';

// Ältere Sicherungen löschen
foreach (array_slice(scanDir($path), 2) as $datei) {
 $dateityp = pathinfo($datei);
 if (is_file($path . $datei)) {
  if ($dateityp['extension'] == $fileType) {
   if (floor((time() - filemtime($path . $datei)) / 86400) > $tage) {
    unlink($path . $datei);
   }
  }
 }
}

?>

In der B-Note für schönen Code gibt es bestimmt Abzüge, aber funktionieren tut's hier wunderbar.

[Spooky]

... es ist schade, dass nicht rechtzeitig an eine Backup/Roll-out-Strategie für C4 gearbeitet bzw. das Vorgehen offenherziger propagiert wurde...

selbst "größere" Agenturen (für die ich ab und an mal was mache) sind in die Falle getappt und haben wie zu C3-Zeiten "einige Stunden vor Deadline" den Roll-out per FTP gemacht... so wie immer halt...

Die Flucherei, was für ein besch*** System C4 geworden ist, müsste ich an Zeit bei der nächsten Rechnung eigentlich mit eintakten ;-)

Die Argumente von "man muss nur ein, zwei Befehle auf der Konsole..." greifen hier m.E. zu kurz - die Agenturen hatten mit Contao (1/2/3) ein robustes und einfach zu handhabendes System. Da sich nun C4 anschickt, etwas nach den "Enterprise-Kirschen zu hangeln", verschreckt das eine ganze Reihe von "alten Contao-Kunden" - aber gut, auf Typo3 schwören ja auch viele...

Sofern sich jemand anschickt, so was zu programmieren, könnte ich gern beim "Geldsammeln" helfen - bei MetaModels 2.1 gelingt mit das ja auch ganz gut ;-)
... und auch selbst was spenden

zonky

Dann sollen die Agenturen halt ein anderes CMS verwenden .

Statt die Konsole für Contao zu benutzen können sie dann die Konsole für das andere CMS benutzen...

[zonky]

Ahoi,

ich habe mir mal vor einiger Zeit ein PHP-Script zusammen gedengelt, ...

so i.E. - wobei die DB-Daten auch aus der parameter.yml entnommen werden können...

cache löschen wäre auch noch möglich und ein Script, was bei einem Umzug die Sachen wieder entpackt und ggf. symlinks korrigiert

Dann sollen die Agenturen halt ein anderes CMS verwenden .

Auf das (hohe) Ross kann man sich natürlich setzen... bisher hatte ich den Eindruck, "Leo & Co." sind eher an einer Verbreitung als an einer "klein, aber fein"-Strategie arbeiten

[electricarts]

Dann sollen die Agenturen halt ein anderes CMS verwenden .

Statt die Konsole für Contao zu benutzen können sie dann die Konsole für das andere CMS benutzen...

Ist das das Ziel? Erst die „Normalos“ vergraulen und dann auch dem Agenturleben etwas mehr Risikofreude geben?

Bei welchem anderen CMS muss ich denn mit der Konsole arbeiten?

[Samson1964]

Bei welchem anderen CMS muss ich denn mit der Konsole arbeiten?

Das bringt mich glatt auf die Idee die populärsten CMS mal zu installieren, um zu sehen wie anwenderfreundlich die Installation ist. Werde ich nach dem 28. März mal machen und dann berichten.

[Stefko]

so i.E. - wobei die DB-Daten auch aus der parameter.yml entnommen werden können...
cache löschen wäre auch noch möglich und ein Script, was bei einem Umzug die Sachen wieder entpackt und ggf. symlinks korrigiert

Klar, ich hatte das nur absichtlich recht allgemein gehalten, da es so auch bei anderen Projekten (WordPress, ...) funktioniert.

[Spooky]

Bei welchem anderen CMS muss ich denn mit der Konsole arbeiten?

Prinzipiell kannst du das bei jedem, denn ein einfaches FTP Deployment einer mehr oder weniger aufwändigen Web Applikation sollte ja nur eine Ausweichmöglichkeit bei unzureichender Server Umgebung.

Davon abgesehen:

• In WordPress können Themes und Plugins auch über Composer verwaltet werden.
• Auch für WordPress gibt es Command Line Tools.
• Joomla hat ebenfalls Command Line Tools.
• Drupal 8 kann komplett über Composer verwaltet werden.
• Drupal verwendet drush.
• Typo3 hat ein Command Line Interface.
• Auch in Typo3 können Extensions über Composer verwaltet werden.
• Siehe auch andere Threads über weitere, alternative CMS, die auch über Composer verwaltet werden.

Auf das (hohe) Ross kann man sich natürlich setzen... bisher hatte ich den Eindruck, "Leo & Co." sind eher an einer Verbreitung als an einer "klein, aber fein"-Strategie arbeiten

Siehe https://leofeyer.github.io/agenturtag-2016/ zur Zielgruppe und zur Positionierung von Contao.

[electricarts]

Ich weiß, dass das bei anderen geht und nutze das (CLI) z. B. bei WordPress (Synchronisation von lokaler- und Liveinstallation) recht gerne. Der Punkt ist: Ich komme bei allen anderen auch anders ans Ziel. Und habe eine einfache und funktionierende Backup- und Übertragungsstrategie.

[Spooky]

Prinzipiell brauchst du das auch bei Contao 4 (Managed Edition) nicht.

[electricarts]

Ich habe das Ding (Contao 4.4) jetzt mal lokal installiert. Damit kann ich noch leben.

Was mich echt nervt ist das Geraffel bei der Übertragung einer bestehenden Installation und eine scheinbar nicht vorhandene Backup-Strategie. Wenn es sowas von offizielle Seite gäbe, würde diese Diskussion hier nicht existieren.

[Spooky]

Warum brauchst du eine Offizielle Backup Strategie?

Wie und was du oder jemand anderst sicherst kann ja nicht vorgegeben werden.

[electricarts]

Ich habe eine aktuelle Contao 3.5 Installation, bei der ich jedesmal alles runterladen, lokal updaten und wieder hochladen muss. Weil selbst bei einem Managed Server der ach so tolle Composer mit 1 GB Memory Limit nicht klar kommt.

Ich ich habe null Bock, dass das spätestens Mai 2019 (wenn die 3.5 LTS ausläuft) mit 4.4 noch schlimmer und aufwendiger wird. Bis jetzt war das noch überschaubar. Daten einfach sichern, DB sichern, fertig.

[Spooky]

Ich habe eine aktuelle Contao 3.5 Installation, bei der ich jedesmal alles runterladen, lokal updaten und wieder hochladen muss. Weil selbst bei einem Managed Server der ach so tolle Composer mit 1 GB Memory Limit nicht klar kommt.

Ich ich habe null Bock, dass das spätestens Mai 2019 (wenn die 3.5 LTS ausläuft) mit 4.4 noch schlimmer und aufwendiger wird. Bis jetzt war das noch überschaubar.

Das hat aber nichts mit einer Backup Strategie zu tun.

Und deine Problematik ist mit Contao 4 viel einfacher und bequemer.

[electricarts]

Für ich schon. Ich mache ein Komplettbackup. Mache Updates und lade dann alles wieder hoch. Wenn was schief geht habe ich noch das Backup.

Ich kenne die Anleitung von Erdmann & Freunde zur Übertragung einer Installation. Gibt es sowas von offizieller Seite? Wie lautet die Empfehlung? Das sind doch essentiell wichtige Tasks wenn jemand eine Webseite betreibt. Soll jeder rumbasteln bis er für sich was brauchbares gefunden hat?

Braucht der Composer denn unter 4 nicht mehr diese wahnwitzigen Ressourcen? Oder was sollte bei dieser 3.5 Installation unter 4.4 besser werden?

[Spooky]

Oder was sollte bei dieser 3.5 Installation unter 4.4 besser werden?

Du brauchst nur mehr die composer.json und composer.lock. Damit machst du das composer update lokal und kopierst dann die composer.json und composer.lock Datei auf den Server. Dort führst du dann entweder direkt über die Konsole oder über den Contao Manager ein composer install aus.

In Contao 3 ist es ein wenig komplizierter - nur die /composer/composer.json und /composer/composer.lock reicht nicht. Denn das composer-plugin benötigt die Info um welche Contao 3 Version es sich handelt, damit es diese Information in der Abhängigkeitsfindung einschleusen kann. Darüberhinaus kannst du in Contao 3 das composer install Kommando (zumindest von Haus aus) nur über die Konsole anstoßen.

[electricarts]

Ok. Das klingt ja schon nach einem Fortschritt. Aber das geht nur unter 4 und nicht unter 3.5? Also auch wenn ich die Konsole bemühen wurde geht sowas unter 3.5 nicht?

[Spooky]

Doch, siehe mein edit. In Contao 3 geht das genau so - nur brauchst du halt tatsächlich die gesamte lokale Kopie der Contao 3 Installation, auf dem richtigen Versionsstand.

Technisch gesehen bräuchtest du nur gewisse Dateien aus denen das composer-plugin abliest um welche Contao 3 Version es sich handelt. Müsste ich mal rausfinden wie genau das composer-plugin das macht - dann muss man seine lokale Kopie nicht immer komplett synchron mit dem Stand am Server halten.

[Spooky]

Wenn was schief geht habe ich noch das Backup.

Das ist dann aber eine Sache von Server Backups. Und da ist es ja egal, welche Web Applikation sich dahinter verbirgt - und daher kann es da auch keine Empfehlung geben. Jeder Server Administrator muss das für sich entscheiden, wie das im einzelnen Fall am besten gemacht wird.

[mlweb]

@zonky
Hast Du Dir schon mal das neue BackupDB angeschaut?