Hallo SpookyZitat:
Zitat von Spooky
Vielen, vielen Dank! Dies haut hin.
Gruss pumukel
Druckbare Version
Hallo SpookyZitat:
Zitat von Spooky
Vielen, vielen Dank! Dies haut hin.
Gruss pumukel
Ts, ts ... glücklicherweise lernt man doch nie aus:rolleyes: ...Zitat:
Zitat von BugBuster
Meine langjährige Unix Erfahrung (mal abgesehen von Mac OSX) liegt nun auch schon mehr als 25 Jahre zurück (Interactive Systems, SCO und AT&T System V bzw. Sun OS). Hat dieser Shortcut (.. statt cd ..) damals eigentlich auch schon funktioniert?:eek: ... könnte ich ja mal ausprobieren, habe bei mir noch eine uralte Interactive Systems Developer Platform auf 5 1/4“ Disketten rumliegen. Leider ist der dazu passende Rechner (HP Vectra RS20c) schon vor vielen Jahren ausgeweidet worden ...
Also, nichts für ungut :o
Meine reichlich 20jährige Nichte würde jetzt fragen: Diskette??? Was ist das gleich noch mal?Zitat:
Zitat von electricarts
Du wirst lachen ..., aber ich habe sogar noch 8“ Flapper Disks in meinem Fundus (PDP 7 mit Fortran IV Compiler ..., Hauptspeicher sagenhafte 16 KB):rolleyes::cool:Zitat:
Zitat von mlweb
Es ist einfach mal wieder Zeit mich u.a bei Spooky und BugBuster für Ihre unermüdliche, freundliche, kompetente und offensichtlich 24h Arbeit hier im Forum zu bedanken ...
Alles wird gut
Franko
Hallo ihr Lieben,
ich muss mal wieder einen Post dieses Threads aus der Steinzeit in die Gegenwart holen. :)
Ich habe gestern meine erste Contao-4.4-Seite live gestellt und überlege jetzt, wie ich sie am besten backupe. Vom Entwicklungsserver hab ich den SSH-Zugang und sichere dort lockerflockig mit RSYNC (Danke an bizon der mich auf die Möglichkeit aufmerksam gemacht hat). Auf dem Kundenserver hab ich den natürlich nicht. (Wie fast nie, und das macht mir in Bezug auf Contao 4 immer noch etwas Bauchschmerzen.)
Lange Rede kurzer Sinn (und zu viele und zu lange Einschübe in Klammern...):
Was hab ich falsch gemacht, wenn ich keine .env-Datei habe? Und system/modules brauche ich nur, wenn ich Erweiterungen manuell installiert habe? Wenn ich ausschließlich den Manager nutze, brauch ich den ja nicht, richtig?Zitat:
Zitat von Spooky
Noch eine andere Frage: Der Umzug via FTP (über den MidnightComander, der die Symlinks erhalten sollte, zumindest ist das bei 3.5 mit Composer kein Problem und ich habe auch schon mal eine Contao4-Installation so auf meinen Server kopiert) hat nicht funktioniert. Irgendwas ist da mit den Rechten schief gegangen. Also hab ich eine frische 4.4 installiert, dann die Erweiterungen installiert, DB eingespielt, Files/Templates kopiert und Config-Dateien angepasst. Hat funktikoniert. Die Frage ist jetzt, kann ich dem Manager irgendwie eine alte Datei unterjubeln, so dass er automatisch alle Erweiterungen auf einmal installiert? Geht zwar mit dem Manager problemlos, aber je nach Anzahl ist es doch recht aufwändig, da ich ja immer nur eine Erweiterung einfügen kann, aktualisiere, warte, nächste Erweiterung suche...
LG
Nicole
Nichts, die existiert nur, wenn du einen Benutzername und ein Passwort für den Zugriff auf die app_dev.php gesetzt hast ;)Zitat:
Zitat von Webstylerin
Bei mir funktioniert ein Backup oder Transfer einer Contao 4.4.5 Installation eigentlich wie mit Contao 3.5.x.
Hierzu verwende ich die Erweiterung BackupDB von Hagen.
Meine Vorgehensweise für Contao 4.4.5 mit Contao-Manager:
1. Datenbank-Backup mit BackupDB erstellen und lokal speichern
2. Komplette Installation per SFTP (ich verwende WinSCP) lokal sichern
3. Komplette Installation per SFTP dann auf den neuen Webspace hochladen
4. Neue Datenbank anlegen
5. Zugangsdaten zur neuen DB dann unter /app/config/parameters.yml entsprechend korigieren/hinterlegen
6. BackupDB-Archiv entpacken und die .sql über phpMyAdmin in die neue Datenbank importieren
7. Die Datei restoreSymlinks.php aus dem BackupDB-Archiv per SFTP nach /web hochladen
8. Im Verzeichnis /web die contao-manager.phar.php der alten Installation löschen (gab bei mir Fehler beim Aufrufen und ich vermute mal wegen Binär-Modus beim SFTP-Transfer)
9. Eine originale contao-manager.phar im Binärmodus per SFTP nach /web hochladen und umbenennen in contao-manager-phar.php
10. Im Browser dann www.(meine Domain)/restoreSymlinks.php aufrufen
11. Dann Contao-Manager aufrufen und einloggen
12. Systemwartung > Cache neu erstellen aufrufen
13. Pakete aktualiseren durchführen
14. Tools > Installtool aufrufen und schauen ob mit der DB alles OK ist
15. Ins Contao BE einloggen
16. System > Systemwartung alles neu erstellen lassen
17. Wenn alles OK ist, die restoreSymlinks.php in /web löschen
Hinweis
Man sollte für den Contao Manager noch ein neues Passwort vergeben, wenn es eine gespigelte Installation für eine Kunden-Installation sein soll.
Hierzu kann man die contao-manager/users.json löschen, Contao Manager aufrufen und neues Passwort vergeben
Ja, ich weiß, die Datenübertragung dauert, ist aber egal weil es eh im Hintergrund läuft.
Über die Console komme ich aktuell nicht weiter und nicht jeder Webspace ermöglicht dies.
Die Vorgehensweise funktioniert bei mir unter PHP 7.1, Hoster ist df.
Folgende zusätzliche Erweiterung sind in meiner Installation vorhanden:
bugbuster/contao-dlstats-bundle
bugbuster/contao-visitors-bundle
codefog/contao-cookiebar
codefog/contao-mobile_menu
do-while/contao-backupdb-bundle
terminal42/contao-easy_themes
terminal42/notification_center
Bei anderen Hostern konnte ich dies noch nicht durchführen und es würde mich interessieren, ob die Vorgehensweise auch bei anderen Hostern funktioniert.
Aber alles auf eigene Verantwortung und nie ohne Backup ;)
VG,
Gregor
Wow! Danke für die ausführliche Vorgehensweise. Schön, dass es mit nem normalen Transfer gehen kann. Habe dasselbe am Montag versucht, auch zu Domainfactory, bin gescheitert.
Vielleicht war das mein Problem, weißt du noch, welcher Fehler kam?Zitat:
Zitat von gregor
Nicht mehr ganz genau.
Es war eine typische Fehlermeldung, die beim Ausführen eines PHP-Script meistens kommt.
Ich glaube Fehler in Zeile 100.
Da kam mir die Idee mit dem Binärmodus und es hat ja auch bei mir so funktioniert und ich mir deshalb keine weiteren Gedanken gemacht habe.
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. :cool:Zitat:
Zitat von gregor
Es wird sicher die Gelegenheit für mich kommen, bei der ich den FTP-Transfer noch mal testen muss. :D
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.
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.
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 :D, da wird die verlinkte Datei übertragen.
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.
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?
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.
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.
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?
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.
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.
Bis auf den CM-Cache hatte ich schon alles bereinigt.
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.
Problem umschifft dank BugBuster aus einem anderen Thread:
Meine Vorgehensweise war jetzt insgesamt folgende:Zitat:
Zitat von BugBuster
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:4. Webverzeichnis auf dem Hosting vorbereiten und Composer herunterladen:Code:tar cfvz contao-backup.tar.gz contao-kunde-xy
5. contao-manager.phar hochladen, umbenennen in contao-manager.phar.php und ein Clean-Install von Contao durchführen. Alternativ per KonsoleCode:wget https://getcomposer.org/download/1.4.2/composer.phar
6. Anpassung der parameters.yml in app/config.Code:/usr/local/bin/php7.0.13-cli composer.phar create-project contao/managed-edition <ziel> 4.4.*
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:und die Verzeichnisse und composer.lock entsprechend verschieben.Code:tar -xvzf contao-backup.tar.gz
8. Datenbank vom Clean-Install mit der aus BackupDB ersetzen.
9. restoreSymlinks.php aus BackupDB in /web kopieren und ausführen.
10. Composer updaten:11. Contao-Install aufrufen: sub.domain.de/contao/installCode:/usr/local/bin/php7.0.13-cli composer.phar update
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.
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.Zitat:
Zitat von Webstylerin
Angepasst und lief.Code:"php_cli": "\/Applications\/MAMP\/bin\/php\/php7.1.8\/bin\/php",
Für die Managed-Edition gehe ich bei einem Umzug aktuell wie folgt vor:
- Sicherung der Ausgangsdatenbank
- Archiv mit Bewegungsdaten ( files / templates / usw ) anlegen
- composer.lock und composer.json auf das Zielsystem kopieren
- in der Shell auf dem Zielsystem composer install --no-dev --optimize-autoloader ausführen
- Datenbankdump im Zielsystem importieren
- 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)
- /app/config/parameters.yml anlegen (entweder per Hand oder Upload und anpassen
- 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.
... 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... :D
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
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
... 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. :D
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...Zitat:
Aber wenn du noch Sponsoren auftreiben kannst, dann gibt es ja vielleicht im Bereich Contao-Manager Verwendung dafür...
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".
Was bedeutet den das "geht das ja auch alles" - den Button "mache Snapshot" habe ich noch nicht entdeckt...?!?Zitat:
Zitat von mlweb
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?
In der B-Note für schönen Code gibt es bestimmt Abzüge, aber funktionieren tut's hier wunderbar. :cool:PHP-Code:<?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);
}
}
}
}
?>
Dann sollen die Agenturen halt ein anderes CMS verwenden ;).Zitat:
Zitat von zonky
Statt die Konsole für Contao zu benutzen können sie dann die Konsole für das andere CMS benutzen...
so i.E. - wobei die DB-Daten auch aus der parameter.yml entnommen werden können...Zitat:
Zitat von Stefko
cache löschen wäre auch noch möglich und ein Script, was bei einem Umzug die Sachen wieder entpackt und ggf. symlinks korrigiert
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 arbeitenZitat:
Zitat von Spooky
Ist das das Ziel? Erst die „Normalos“ vergraulen und dann auch dem Agenturleben etwas mehr Risikofreude geben? :confused:Zitat:
Zitat von Spooky
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.Zitat:
Zitat von electricarts
Klar, ich hatte das nur absichtlich recht allgemein gehalten, da es so auch bei anderen Projekten (WordPress, ...) funktioniert.Zitat:
Zitat von zonky
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.Zitat:
Zitat von electricarts
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.
Siehe https://leofeyer.github.io/agenturtag-2016/ zur Zielgruppe und zur Positionierung von Contao.Zitat:
Zitat von zonky
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.
Prinzipiell brauchst du das auch bei Contao 4 (Managed Edition) nicht.
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.
Warum brauchst du eine Offizielle Backup Strategie?
Wie und was du oder jemand anderst sicherst kann ja nicht vorgegeben werden.
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.
Das hat aber nichts mit einer Backup Strategie zu tun.Zitat:
Zitat von electricarts
Und deine Problematik ist mit Contao 4 viel einfacher und bequemer.
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?
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.Zitat:
Zitat von electricarts
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.
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?
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.
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.Zitat:
Zitat von electricarts
@zonky
Hast Du Dir schon mal das neue BackupDB angeschaut?
Wenn sich in nächster Zeit nichts mit MetaModels in Bezug auf C4 tut, hat sich das Thema sowieso erledigt. Das ist nämlich (durch eine eingesetzte Umkreissuche) Pflicht. Ich kann nicht erst nächstes Jahr April entscheiden, ob ein Update auf C4 oder ein ganz anderes CMS in Frage kommt. Aber das ist OT.
Um die Datenbank mache ich mir die wenigsten Sorgen. Oder kann ich da bei Contao 4 mit phpMyAdmin auch nichts mehr ausrichten? :pZitat:
Zitat von mlweb
Zu diesem Thema haben Leo (respektive Oliver) und Peter am Contao Agenturtag 2018 folgendes erzählt:
- Contao Deployer Edition
- Contao 4 Deployment mit mage in der Praxis
BackupDB kann auch gesamte Website Templates für Contao erstellen (auch schon für Contao 3). Siehe auch https://github.com/do-while/contao-B...late-erstellenZitat:
Zitat von electricarts
Oooh, sehr schön :).Zitat:
Zitat von bjarke
Oh ja, das sieht sehr interessant aus!Zitat:
Zitat von bjarke
Ah, ok. Dann schaue ich mir das mal an.Zitat:
Zitat von Spooky
Meiner Meinung nach ist es ab der 4er Version sinnvoller denn je ein zweites parallel installiertes System auf dem Kundenserver zu haben. Die Lehre musste ich erst kürzlich wieder machen als es bei einer sehr einfachen Kundenseite zu Problemen kam und ich eine Nachtsicht einlegen musste.
Lokal oder auf einem eigenen Server zu entwickeln oder auch Updates durchzuführen wird halt nie 1:1 mit dem Server des Kunden übereinstimmen. Außerdem nimmt es etwas den Zeitdruck und ein Fallback kann nie schaden.
@electricarts
Wenn du eine Umkreissuche benötigst, dann schau dir mal den "catalog-manager" an. Kostet zwar etwas, lohnt sich aber. Der Support ist sehr gut und Feature-Wünsche werden bei Machbarkeit/Aufwand auch schnell umgesetzt.
Ich schätze die Arbeit von Christian, Sven und den Anderen an metamodels sehr, nur benötigte ich letztes Jahr für mehrere Projekte eine verläßliche Lösung um direkt mit 4.4 zu starten.
Den Catalog Manager schaue ich mir definitiv an! Ich investiere gerne in Erweiterungen, wenn dadurch die Weiterentwicklung gesichert wird.
Ich muss dann nur schauen, wie ich die ca. 600 Einträge bei der Umkreissuche in den Catalog Manager bekomme. :eek:
Dazu kann dir Alexander, der Entwickler, sicherlich mehr zu sagen. Die Erweiterung darf man auch kostenlos auf einer lokalen Kiste testen.
An die Experten.
Wäre es eigentlich möglich, dass man innerhalb der Installation ein projektbezogenes Verzeichnis hat, in dem alle relevanten Dateien und Verzeichnisse enthalten sind, also auch die composer.json, app/config/…? Per Symlinks evtl.?
und zusätzlich sichert die Version für Contao 4 die composer.json (bei der composer.lock bin ich mir gerade nicht sicher) und liefert ein Skript mit welches die Symlinks aufbaut.Zitat:
Zitat von Spooky
Ja, kenne ich - aber wie der Name sagt "DB"-Backup + composer.json/lock auf wunsch...Zitat:
Zitat von mlweb
das ist aber nur die halbe Miete.. in meinem Posting #97 habe ich die Probleme von Agenturen beschrieben, die einen unkomplizierten Wechsel von einem Server auf den nächsten haben möchten - und da ist es mit DB-Dump und composer.json nicht getan!
Hast Du die MM-News nicht verfolgt? MetaModels 2.1 für Contao 4.4 steht seit November 2017 für die "early-adopter" zur Verfügung...Zitat:
Zitat von electricarts
Alle MM-Anfragen gehen über "meinen Tisch" - nichts dergleichen von Dir gesehen... was verpasst?Zitat:
Zitat von Y-Nell
Wie schon gesagt sichert BackupDB nicht nur die Datenbank. https://community.contao.org/de/show...l=1#post468810Zitat:
Zitat von zonky
wenn ich das richtig verstehe, benötigt Deployer auf dem Zielserver ein git - soweit ich das gesehen habe, ist das bei den "Agentur=>Kunden-Servern" eher nicht vorhandenZitat:
Zitat von bjarke
nochwas gefunden: https://github.com/terminal42/mage-tools
Nein, am Zielserver brauchst du keine weiteren speziellen Services (außer SSH Zugriff).Zitat:
Zitat von zonky
@ zonky
Nein du hast nichts verpasst oder übersehen, da ich keine Anfrage gestellt habe.
Die erste News zum Thema mm & 4.4 kam doch erst am 30.6.17. Das war für die betroffenen Projekte aber schon zu spät. Bei so einem umfangreichen Projekt wie mm gehe ich davon aus, dass entsprechende Infos erst dann veröffentlich werden, wenn's wirklich spruchreif ist.
Ja, bitte werft nicht die beiden Aufgaben durcheinander
- Backup - erstellen einer Kopie des Filesystems (möglichst gepackt unter Erhaltung der Symlinks) und der DB, restore auf demselben Server = Auspacken des Backup und import der DB Daten
- Umzug auf einen anderen Server (z.B. Entwicklung -> Produktivsystem) entsprechend der zitierten Anleitung
Seit Contao 4 mit Composer (und mit Einschränkungen auch 3.5 - s.o.) kann man diese beiden Tasks gut unterscheiden. Mit C3.x ohne composer blieb meines Wissens nur die 'alles kopieren' Lösung, die deutlich langsamer war.
Das schwierigste und fehleranfälligste bei einem Umzug ist für mich, die Kopie der selbst angepassten Dateien. Klar: /files /templates, /app/config/parameter.yml, ggf. favicons etc.
Hab ich was vergessen?
Edit: Ooh - ich hab wohl nicht auf den letzten Post geantwortet... (Hier ist heute so viel passiert :))
Bin mir nicht sicher, ob contao-manager/ noch wichtig wäre?
Aber genau darauf zielte meine Frage vorhin ja ab, dass man nur ein Verzeichnis hat, in dem alle wichtigen Projektdaten samt Configs enthalten sind.