Backup einer 4.4 - so oder wie?

Durch die Symlinks und die große Anzahl Dateien macht ein Backup über (S)FTP / ZIP (windows) nicht wirklich Sinn.
Die Symlinks bleiben nicht erhalten bzw. werden in "echte" Dateien umgewandelt.

Spielt man so ein Backup wieder ein, meckert Symfony, dass die Symlinks nicht mehr angelegt werden können.

Ich will hier mal Eure Ideen hören und sammeln, vorab mal zwei von mir, auf Linux bezogen. (noch nicht getestet)

1. Komplett mit tar
   
   1. Ich lösche var/cache/prod und var/log/* , eventuell auch contao-manager/logs/*
   2. alternativ mittels "--exclude .." jeweils ausschließen bei nachfolgender Aktion
   3. das gesamte Installationsverzeichnis wird mit tar gepackt, dabei bleiben die Symlinks erhalten.
   4. Nachteil: das wird relativ groß
2. Teilweise mit tar
   
   1. es wird nur files/, templates/, app/config/ web/.htaccess sowie composer.json und composer.lock mit tar gepackt
   2. Vorteil: Archiv nicht ganz so groß, je nach Umfang in files/
   3. Nachteil: Restore bedarf nach dem Auspacken ein "composer install --no-dev --optimize-autoloader" Aufruf, und natürlich composer selbst, auf dem Server über Kommandozeile

Ach ja, für ein vollständiges Backup natürlich Backup der Datenbank nicht vergessen.


Nachtrag: Richtiger Hinweis von Spooky: bei Methode 2 eventuell noch system/modules/ beachten, siehe #5

Nachtrag: Korrekturen und Ergänzungen eingebaut. Hatte ich Teilweise auch im Kopf (--no-dev) aber hier nicht erwähnt.

Nachtrag: Generell mit Deployment Tools arbeiten, siehe auch hier, habe ich mal hier weggelassen. Mit Magallanes (magephp) habe ich bei 4.0/1 auch schon mal experiementiert nachdem das mal in einem Contao Camp glaub ich erwähnt wurde.

Wer "tar" nicht kennt: http://wiki.cbeier.net/linux/tar.gz_packen

Weitere Idee / Konzepte? Dann her damit, ich würde die hier oben dann drankleben als Sammlung.

Sprechen wir über ein Backup welches ohne große "Arbeit" eingespielt werden kann, oder von einem Backup woraus man seine Installation mit ein paar Zeilen wiederherstellen kann?

Finde Variante 2 definitiv am einfachsten als "Poweruser".
Denke aber das diese Variante nicht allen zusagt :P

Ich gehe mal von einem produktiven System aus - somit würde ich wie auch hier beschrieben
http://symfony.com/doc/current/deployment.html
beim Wiederherstellen:

Code:

---

composer install --no-dev --optimize-autoloader

---

Zitat:

---

The --optimize-autoloader flag improves Composer's autoloader performance significantly by building a "class map". The --no-dev flag ensures that development packages are not installed in the production environment.

---

Kann ich vollständig bestätigen.

@Methode 2 - warum löscht Du etwas, was Du eh nicht packst und mitnimmst? Vielleicht habe ich dort auch etwas falsch verstanden...

Ich packe mir alles wichtige inklusive db ein: d.h. alles ausser var, cache und vendor

Hmm, ja, muss man alles erst mal testen. Mit tar mache ich das bisher bei meinen 3.5 Installationen (Variante 1, natürlich gzip komprimiert). Wenn das weiterhin inklusive Symlinks so funktioniert, werde ich das wohl auch weiterhin so machen. Ist einfach am bequemsten für mich. Wobei ich das Backup dann online auf einen anderen Webspace verschiebe mit allen Vor- und Nachteilen. Nur das Backup vom Auslieferungszustand sichere ich dann nochmal zusätzlich lokal.
Vorteile: Geht sehr schnell, weil die Verbindung zwischen den Webservern wesentlich schneller ist als meine lokale Verbindung zu den Webservern. Auch das Restore geht sehr schnell.
Nachteil: Frisst Webspace.

Zwischen zwei Servern kann man eventuell alternativ rsync einsetzen, wenn man mehrere Entwicklungsstände sichern will. Also Installation auf den Zielserver syncen, dort Backup mit tar. Zeitlich dürfte das sogar eher langsamer sein, aber Traffic auf den Servern einsparen, falls man da Limits hat (oder trotz "unlimited traffic" irgendwann Ärger bekommt :D )

Ich würde nur das "teilweise" Backup machen, alles andere hat meiner Meinung nach keinen Sinn. Brauchen tut man (bei der Managed Edition) im Endeffekt eigentlich nur

• app/
• files/
• templates/
• system/modules/ [1]
• web/.htaccess
• composer.json
• composer.lock
• .env

[1] Schwierig wird es beim system/modules/ Ordner. Dort kann sich ein Mix aus Symlinks und regulären Ordnern befinden, wenn man manuell installierte Extensions verwendet. Daher müsste man also den system/modules/ Ordner so sichern, dass eben alle Symlinks ignoriert werden. (Related: https://github.com/contao-community-...ugin/issues/69)

Im web/ Ordner könnten sich auch zusätzliche Dateien befinden - aber nur wenn man selbst dort welche angelegt hat. Die muss man natürlich dann beachten.

Die .htaccess Datei aus dem web/ Verzeichnis sollte ebenfalls mit gesichert werden falls dort Anpassungen gemacht werden.

Guten Morgen zusammen,

irgendwie lese ich aus dem Thread hier, dass es scheinbar noch gar keinen ordentlichen "Backupplan" für Contao 4.4 gibt. Ich hoffe und denke dass ich mich da täusche, da ich derzeit sowieso Gefahr laufe, den Überblick über Contao 4.4 zu verlieren.

Wird denn eine Backupmöglichkeit offiziell empfohlen oder wird so etwas im Contao manager implementiert damit auch "nicht Poweruser" ein "sicheres" Backup machen können?

Gruß
tschero

Rate mal warum ich nach den ganzen Fragen im Forum hier mal einen Sammelthread erstelle :-)

Je nach System (Windows, Linux, MacOS, ...) müssen auch erstmal Erfahrungen gesammelt werden.
Andererseits wird ja empfohlen auf der Kommandozeile nicht unbegabt zu sein. Und wer da was drauf hat, der weiß auch wie man ein Backup macht unter Beachtung der neuen Randbedingungen.
DIE muss man natürlich kennen. (Symlinks, Composer, ...)

Es wird demnächst für DB Backup wieder eine Erweiterung geben (BackupDB) wie zu Contao 3 Zeiten.
Aber wie der Name sagt, macht die nur ein DB Backup, als kleines Bonbon wird auf Wunsch auch die composer.json und .lock mit in das ZIP gepackt.

Der Contao Manager soll auch mal eine Möglicheit bekommen für ein Backup, da weiß ich aber grad nicht ob nur für die DB oder komplett.

Ich hänge mich da mal dran. Jetzt, wo ich dachte nach zwei Jahren wird alles gut mit Contao 4 und ich kann mich endlich mal ernsthaft damit beschäftigen, lese ich so etwas.

Ich verstehe das richtig, wenn ich ganz „normal“ (wie bei jedem anderen CMS) einfach die DB sichere und die Installation (also die Dateien) per (s)FTP sichern möchte geht das schief? :eek:

Etwas weniger Kommandozeile fände ich auch zugänglicher für den technisch nicht ganz unversierten Designer (= mich). Zu WordPress gibt es Duplicator, für Joomla Akeeba – so wünschte ich mir das auch für Contao. Zum Glück lässt sich auf absehbare Zeit auch noch mit 3.5 arbeiten.

So long
Michael

Zitat:

---

....möchte geht das schief?

---

Kurz: Ja.
Grund: Weil dabei die Symlinks zu echten Dateien gewandelt werden. Bei einem Restore meckert Symfony dann, weil es die Symlinks nicht mehr anlegen kann.
Es gäbe da noch eine Möglichkeit:
- Die Symlinks auslassen beim kopieren/transferieren und mittels contao-console beim Restore wieder anlegen lassen.
- oder nach dem Restore die "falschen" Dateien löschen (dazu muss man aber wissen welche) und dann mittels contao-console wieder die Symlinks anlegen lassen.

Macht die Sache nicht einfacher, soll nur zeigen das es möglich ist, ein solches "falsches" Backup zu reparieren.

Zitat:

---

Zitat von amateur

Etwas weniger Kommandozeile fände ich auch zugänglicher für den technisch nicht ganz unversierten Designer (= mich). Zu WordPress gibt es Duplicator, für Joomla Akeeba – so wünschte ich mir das auch für Contao. Zum Glück lässt sich auf absehbare Zeit auch noch mit 3.5 arbeiten.

---

Wordpress und Jommla arbeiten aber nicht mit Symlinks, oder?

Und zu Contao 3.5: Auch da ist es in Verbindung mit Composer möglich bereits mit Symlinks zu arbeiten, je nach Einstellung in der Paketverwaltung.
Also Vorsicht! (in Normalfall sollten da keine sein, einfach mal schauen ob es in system/modules/ Symlinks gibt)

Achja, wozu gibt es die Admins? Die freuen sich wenn sie helfen können :-)

Danke für die Erklärungen und dein Engagement, BugBuster!

Danke, aber nein danke. Ich würde mich jetzt nicht als den totalen Terminal-Versager bezeichnen, aber dieses ganze Geraffel für ein simples Backup ist mir einfach too much.

Ist jetzt total OT, aber für wen genau soll Contao zukünftig sein? Muss man vorher einen Kommandozeilen-Kurs irgendwo belegt haben um profane alltägliche Dinge wie ein Backup ausführen zu können? Eine Vergrößerung der Nutzerbasis dürfte mit dieser Form der Bedienung eines CMS nicht zu erreichen sein. Schade. Sehr schade.

Der Composer ist nicht dafür da die Leute abzuschreckenn - ganz im Gegenteil dieses Ding ist sehr toll:

1. Die Pakete aktuell zu halten - nicht nur bzgl. der Features sondern vorallem der Sicherheit zu liebe
2. Konflikte/Abhängigkeiten mit anderen Erweiterungen aufzulösen und gar nicht erst entstehen zu lassen
3. 3th-Party Libs nicht im Core zu halten - Größe des Projektes wird um einiges vermindert
4. Die App an das System optimal anzupassen
5. etc.

Etwas zum Thema Symlinks: Die Dinger sind auch ganz toll - einfach ausgedrückt, ermöglichen sie die Integration einzelner Libs/Pakete/Bundels

Zitat:

---

Zitat von electricarts

Ist jetzt total OT, aber für wen genau soll Contao zukünftig sein? Muss man vorher einen Kommandozeilen-Kurs irgendwo belegt haben um profane alltägliche Dinge wie ein Backup ausführen zu können? Eine Vergrößerung der Nutzerbasis dürfte mit dieser Form der Bedienung eines CMS nicht zu erreichen sein. Schade. Sehr schade.

---

Contao ist halt kein Jimdo- oder Wix-Baukasten. Ebenso auch kein WP, was so aufgeblasen ist, das es für jeden möglichen Klick ein js existiertiert. Contao ist in meinen Augen sehr mächtig - was die Performance, Flexibilität und Usability angeht.

Wau, wau.
Ich bin zu Contao gekommen, weil ich den Zugang mit einem praxisggerechten Framework und CSS für mich überzeugend war, einfach 'Wow' – und ist, denn darin hat sich auch bei Version 4 ja nichts geändert. WP ist für mich schön, wenn man mit fertigen Templates arbeiten kann/muss. Mit Joomla muss ich mich leider auch auseiandersetzen, weil Kunde es verlangt. Ich habe mich zwangsläufig damit arrangiert – und finde die Back-uplösung sehr angenehm.

Tatsächlich bin ich in vielerlei Hinsicht völlig ahnungslos, kenne mich mit Symfony nicht aus und weiß noch nicht mal genau, was Symlinks sind. Trotzdem biete ich Kunden Websites an und muss sie gelegentlich von einem Server auf den anderen transferieren. Bisher ging das eigentlich ganz gut, und ich nehme an, dahin werden wir auch mit Contao (wieder) kommen. Außerdem geibt es ja noch diese engagierte und hilgsbereite Community. Verstehe nicht, warum man sich deshalb ans Bein gepisst fühlen muss!? Das ist nicht meine Absicht.

So long
Michael

P.S.: Was ist ein 'mentales Modell'?

Oder wie letztes Jahr mal festgestellt wurde.
Einsatz von Contao: https://leofeyer.de/files/slides/2016/konferenz/#18
Zielgruppe von Contao: https://leofeyer.de/files/slides/2016/konferenz/#19

Wie man sieht: Zielgruppe !== Nutzerbasis

Die Hoffnung ist, das die Homepage Baukasten Nutzer im Lauf der Zeit lernen und zum CMS Nutzer werden. ;)

Das habe ich schon verstanden. Hier ging es auch nicht um Webbaukästen. Contao ist auch kein ProcessWire, WordPress, Joomla, Drupal, Typo3, Craft ... whatever. Und weil es so „anders“ war habe ich gerne bis Version 3.5 damit gearbeitet.

Ich verstehe nur seit geraumer Zeit nicht mehr, für wen Contao sein soll. Welche Zielgruppe will man bedienen? Wenn man nur noch PHP/Terminal Cracks im Sinn hat ist das ja auch in Ordnung. Aber dann soll man das auch sagen. Dann können sich alle anderen mit ihrem popeligen Shared Hosting und alle, die nicht in der Commandozeile zuhause sind, was anderes suchen.

Wenn es um die Installation und Nutzung geht, dann brauchst du durch den Contao Manager keine Kommandozeile.
Aber es vereinfacht Dir die Arbeit, wenn es mal Probleme geben sollte. Der Composer kann mehr als der Contao Manager zur Zeit anbietet.

Administrative Dinge hat Dir Contao 3 auch nicht abgenommen, da musstes du auch mit (S)FTP oder ZIP, TAR, ... Bescheid wissen, je nachdem was der Zweck war.
Das ist also nun nicht anders. Nur haben sich eben die Randbedingungen geändert.

Warte mal ab, ich glaube das irgendwann von irgendwem ein Shellscript auftauchen wird, das brauchste dann nur aufrufen und der Rest erfolgt von selbst.
Oder eine gute ausformulierte Anleitung.

Zitat:

---

Zitat von electricarts

Ich verstehe nur seit geraumer Zeit nicht mehr, für wen Contao sein soll. Welche Zielgruppe will man bedienen? Wenn man nur noch PHP/Terminal Cracks im Sinn hat ist das ja auch in Ordnung. Aber dann soll man das auch sagen. Dann können sich alle anderen mit ihrem popeligen Shared Hosting und alle, die nicht in der Commandozeile zuhause sind, was anderes suchen.

---

... kann mich der Aussage nur voll und ganz anschließen.
Ich weiß die Entwicklungsarbeit die in Contao 4 gesteckt wird zu schätzen –
habe jedoch den Eindruck das der durchschnittliche End-Anwender aus den Augen verloren wird.

Aus meiner Sicht kann das Backup für Contao 4.4.x nur dann funktionieren, wenn auf dem Zielsystem die Datenbank und die dazugehörigen Konfigrationsdateien wiederhergestellt werden. Das Problem mit den Symlinks ist bei Hostern auf denen der Endanwender keinen Shell Zugriff hat dann das Ende des Backups. Damit ist für Contao 4.4.x ein SSH Zugriff erforderlich ob mit oder ohne contao-manager.

Ich selbst hatte auf den contao-manager gewartet, weil ich trotz "Konsolenfähigkeiten" und entsprechenden Servern, wissen wollte ob man das Ding (contao) tatsächlich noch ohne Konsole installiert bekommt.
Ich war erstaunt wie gut das schon mit dem contao-manager beta1 möglich und Problemlos war... Allerdings beim ersten kopieren der Daten via FTP kam dann der AHA Effekt :eek: Das kann ja gar nicht funktionieren. Adios günstige Webspaces für 5 EUR/Monat :(

Wenn ich heute einen Backup machen müsste, würde ich so vorgehen:

- Datenbanksichern,
- die Module welche ich per contao-manager installiert habe aufschreiben
- die Module die ich von Hand installiert habe aufschreiben -> ja die gibt es nach wie vor z.B. bei gekauften Themes die nie auf github erscheinen werden.

Auf dem Zielserver die Installation mit allen Modulen durchführen und die Datenbank wiederherstellen. Ob das so funktionieren könnte muss ich noch testen - aber aus meiner Sicht aktuell die einzige Möglichkeit.

Noch zum Thema aktualisierung via contao-manager -> das hat in den letzten Tagen immer wunderbar funktioniert.
Für die core Module und auch die selbst über den contao-manager installierten Module kann man da auch bestimmte Versionen vorgeben. Nicht aber für Grundlagen wie Symfony. Das hat gestern einen Update von 3.3.2 auf 3.3.3 erfahren... 3x dürft ihr raten was passiert -> so schlimm ist es nicht https://github.com/contao/core-bundle/issues/921 , verdeutlicht aber die Komplexität. Mit nur einem Klick kann man die Installation ins Nirvana befördern, wenn da schon am Symfony 3.3.2 zu 3.3.3 hunderte von PHP Warnings gibt.

Deshalb ist BACKUP immer die Grundlage jedes Updates - und dass man hierfür erwartet, dass es jeder via Konsole kann (sonst hätte man sich Gedanken beim Einsatz von Symlinks gemacht) finde ich schon bisschen traurig. Contao 4.4.x entwickelt sich aus meiner Sicht zum Werkzeug für spezielle Sachen.

EDIT-> ich wollte zum Backupvorschlag noch was schreiben:
via contao-manager die Einstellungen/Dateistruktur (DocRoot) prüfen oder falls nicht möglich den User eingeben lassen.
Dann per tar das System sichern - und die Datei als Download unter /files anbieten
Auf dem Zielsystem den contao-manager für die Rücksicherung bemühen (user muss die Tar Datei in ein Verzeichnis laden) und Dateien die auf Dateistrukturen basieren entsprechend neu generieren (Symlinks o.ä).

Ich denke schon, dass man den Contao-Manager dahin bringen kann, auch so ein "defektes" Backup mit Dateien statt Symlinks automatisch zu reparieren. Vereinfacht gesagt könnte man ihn ja so programmieren, dass er beim Anlegen der SymLinks eine eventuell gefundene Datei halt einfach löscht (oder eine Kopie davon irgendwo ablegt für alle Fälle) und dann den SymLink anlegt. Ich habe schon noch Hoffnung, dass man da ohne Kommandozeile auskommen kann.

Wobei ich die Aufregung um die Kommandozeile nicht so ganz verstehen kann. Es gibt durchaus günstige Webspaces um die 5 Euro oder sogar noch günstiger, die einen solchen SSH-Zugang anbieten. Freilich nicht bei jedem Anbieter, aber wer sparen will oder muss, der muss seinen Webspace halt da kaufen wo dies der Fall ist.

Zitat:

---

Zitat von tab

Wobei ich die Aufregung um die Kommandozeile nicht so ganz verstehen kann. Es gibt durchaus günstige Webspaces um die 5 Euro oder sogar noch günstiger, die einen solchen SSH-Zugang anbieten. Freilich nicht bei jedem Anbieter, aber wer sparen will oder muss, der muss seinen Webspace halt da kaufen wo dies der Fall ist.

---

Würde daher bedeuten (für nicht wenige) => Umstieg auf contao 4.4 = neuer Webspace!

Um jetzt einen direkten Vergleich mit contao 3.5 anzubieten: es wird nicht mehr das CMS sein, das überall läuft. Datenbank anlegen, Dateien per FTP hochzuladen und den Installer starten war mal. Und sollte der contao-manager alles das schön abdecken ist prima. Aber noch ist es nicht so weit, da wir uns momentan um die wichtigste Sache eines Projektes kümmern müssen: funktionierendes BACKUP! Ohne Backup kein Produktiveinsatz (meine Meinung)

Meine Server haben keine GUI, außer ich installiere mir dazu ISPConfig. Daher ist das nicht meine Sorge - aber ich denke hier an die User die "schnell mal ein CMS installierten". Die füllen dann demnächst das Forum: "wie ziehe ich eine Installation um" oder "habe Server neuinstalliert meine Contao Installation geht nicht mehr weil Symfony Pfade nicht findet"

Also der Contao Manager kann theoretisch die Symlinks neu anlegen, das macht er ja bei jeder Installation oder Update einer Erweiterung am Ende.
Wobei das die Post-Install Scripte von Contao sind, aber das spielt ja erstmal keine Rolle.

Nur gibt es dazu noch keinen eigenen Menüpunkt, so wie es jetzt ja bereits gibt "Cache neu erstellen".

Der Manager soll ja defekte Installationen auch reparieren können, das muss er aber noch lernen. Wobei ich das noch nicht probiert habe, vielleit kann er es ja in dem Fall schon.

Ich hatte gehofft das sich hier mal die großen Agenturen melden und sagen wie die es tun. Denn Contao ist schon seit vielen Monaten auf Live Seiten im Einsatz.

Backup != Deployment
Ich kann mir nicht die auf USB gesicherten MP3´s auf einem CD-Spieler anhören.

Zitat:

---

Zitat von ihkwdiopk

Backup != Deployment
Ich kann mir nicht die auf USB gesicherten MP3´s auf einem CD-Spieler anhören.

---

Wo bleibt die Innovation? :D

Zitat:

---

Zitat von planepix

Wo bleibt die Innovation? :D

---

Wollte zuerst schon Kassettenrecorder schreiben :rolleyes:

Zitat:

---

Zitat von ihkwdiopk

Backup != Deployment
Ich kann mir nicht die auf USB gesicherten MP3´s auf einem CD-Spieler anhören.

---

aber sehr wohl auf einem anderen Medium das USB Anschluss hat.

Hallo zusammen,

was spricht dagegen, folgendes zu tun:

• Sicherung der Datenbank
• Sicherung d. Composer-Daten
• Dateien und Module in jeweils eigene tars sichern
• Eine Art Build-Script, welches dann wieder "zurück" rollt nach einer Contao Installation

Also im Grunde den Weg geht: Installiere Contao -> Richte Website ein -> Erstelle backup. Das Backup wiederum geht den schritt dann Rückwärts, indem Contao installiert wird und die Sicherung eingespielt wird. Hiermit kann man also getrost, getrennt von Symlink oder Ordner, die Inhalte des jeweiligen Inhalts wieder herstellen.

Es müsste, so mein Gedanke, eine Möglichkeit einer "Automatisierten" Contao Installation geben mit der Rücksicherung.

Oder ist das vollkommen gaga? :o

Zitat:

---

Zitat von kretschi

Würde daher bedeuten (für nicht wenige) => Umstieg auf contao 4.4 = neuer Webspace!

Um jetzt einen direkten Vergleich mit contao 3.5 anzubieten: es wird nicht mehr das CMS sein, das überall läuft. Datenbank anlegen, Dateien per FTP hochzuladen und den Installer starten war mal. Und sollte der contao-manager alles das schön abdecken ist prima. Aber noch ist es nicht so weit, da wir uns momentan um die wichtigste Sache eines Projektes kümmern müssen: funktionierendes BACKUP! Ohne Backup kein Produktiveinsatz (meine Meinung)

Meine Server haben keine GUI, außer ich installiere mir dazu ISPConfig. Daher ist das nicht meine Sorge - aber ich denke hier an die User die "schnell mal ein CMS installierten". Die füllen dann demnächst das Forum: "wie ziehe ich eine Installation um" oder "habe Server neuinstalliert meine Contao Installation geht nicht mehr weil Symfony Pfade nicht findet"

---

Nur weil der Contao-Manager noch nicht so weit ist (Beta ...) heißt das ja nicht, dass man momentan kein funktionierendes Backup machen kann. Kann mir ja keiner weismachen, dass Leo nicht weiß, wie man ein funktionierendes Backup erstellt bzw wieder einspielt. Es ist halt nur noch nicht wieder so einfach wie früher, eventuell geht es auch nur etwas anders als früher und ist dann womöglich noch einfacher. Da muss man halt umlernen. Irgendwann mal haben wir den Umgang mit FTP-Tools und phpMyAdmin gelernt, jetzt müssen wir halt den Umgang mit neuen Tools lernen. Egal ob sie jetzt Contao-Manager oder Composer heißen. Alles entwickelt sich weiter, Dinge ändern sich. Nur wenig im Leben ist noch so, wie es vor 20 Jahren mal war. Im Softwarebereich geht es halt immer noch ein wenig schneller. Also ist lernen angesagt, wie überall im Leben heutzutage. Die User, die nach einer neuen Version das Forum mit Fragen füllen gab es auch schon beim Umstieg auf Contao 3. Wird es immer geben, wenn sich irgendwas ändert bzw nicht mehr so funktioniert wie früher.

Zitat:

---

Zitat von tab

Nur weil der Contao-Manager noch nicht so weit ist (Beta ...) heißt das ja nicht, dass man momentan kein funktionierendes Backup machen kann. Kann mir ja keiner weismachen, dass Leo nicht weiß, wie man ein funktionierendes Backup erstellt bzw wieder einspielt. Es ist halt nur noch nicht wieder so einfach wie früher, eventuell geht es auch nur etwas anders als früher und ist dann womöglich noch einfacher. Da muss man halt umlernen. Irgendwann mal haben wir den Umgang mit FTP-Tools und phpMyAdmin gelernt, jetzt müssen wir halt den Umgang mit neuen Tools lernen. Egal ob sie jetzt Contao-Manager oder Composer heißen. Alles entwickelt sich weiter, Dinge ändern sich. Nur wenig im Leben ist noch so, wie es vor 20 Jahren mal war. Im Softwarebereich geht es halt immer noch ein wenig schneller. Also ist lernen angesagt, wie überall im Leben heutzutage. Die User, die nach einer neuen Version das Forum mit Fragen füllen gab es auch schon beim Umstieg auf Contao 3. Wird es immer geben, wenn sich irgendwas ändert bzw nicht mehr so funktioniert wie früher.

---

Stimme ich soweit zu. Alles wird weiterentwickelt - ohne Weiterentwicklung könnten wir weiterhing mit der Version 2.x arbeiten.
Aaaaber: wir sprechen hier nicht von 4.x beta Test sondern von einer 4.4. LTS die eigentlich in Produktionsumbgebungen arbeiten könnte! Die Aussage ist doch klar: Contao 4.4 benutzen weil es besser ist! Hat man ja gesehen, warum so viele gewartet haben bis der contao-manager draußen war. Davor waren die wenigsten mit der Version 4.x beschäftigt...

Gerade mit meiner Erfahrung gestern und einem "Fehler" im Symfony ist der Einsatz von Contao 4.4 ohne vernünftiges Backupkonzept ein riskantes Spielchen. (

Der Fehler ist aber gerade über Kommandozeile und Composer reparierbar ohne ein Backup wieder einspielen zu müssen.
Dem hier folgen: https://community.contao.org/de/show...-unter-Windows
dann ein "composer update --no-dev --optimize-autoloader" und dann sollte das repariert sein.

Zitat:

---

Zitat von BugBuster

Der Fehler ist aber gerade über Kommandozeile und Composer reparierbar ohne ein Backup wieder einspielen zu müssen.
Dem hier folgen: https://community.contao.org/de/show...-unter-Windows
dann ein "composer update --no-dev --optimize-autoloader" und dann sollte das repariert sein.

---

Nö, das war nicht die Windows Meldung. Ich hatte mein Ticket von gestern gemeint: https://github.com/contao/core-bundle/issues/921
Mit dem Update auf Symfony 3.3.4 von eben ist wieder alles tutti.

Ich wollte damit nicht sagen, dass man ohne Backup das o.g. Problem nicht lösen kann - sondern, wenn es mal ein Paket gibt das gravierende Änderungen durchführt (DB und Files) dann könnte es ohne Backup schlecht aussehen.

Doch natürlich kannst du das lösen, die kannst jedes Update rückgängig machen. Und offenbar hat ja Symfony 3.3.4 den Fehler behoben, dann hätte man auch auf 3.3.2 zurückgehen können. (durch den conflict Eintrag automatisch, solange es keine 3.3.4 oder höher gibt)

Zitat:

---

Zitat von BugBuster

Doch natürlich kannst du das lösen, die kannst jedes Update rückgängig machen. Und offenbar hat ja Symfony 3.3.4 den Fehler behoben, dann hätte man auch auf 3.3.2 zurückgehen können. (durch den conflict Eintrag automatisch, solange es keine 3.3.4 oder höher gibt)

---

Und somit sind wir wieder beim Thema Composer - Tolles Teil!

Nicht nur Composer ist ein tolles Teil, sondern auch die Konsole rockt.

Ich synchronisiere schon seit Jahren alle meine Webprojekte mit meiner lokalen Testumgebung direkt auf der Konsole. Vom Server nach Lokal und umgekehrt. Das Linux Kommando dazu ist rsync:

Code:

---

rsync -avze ssh quelle/ ziel/

---

Dabei werden alle Dateien/Ordner aus der Quelle nach Ziel kopiert. Auch versteckte Dateien (die mit dem Punkt davor) z.B. .htaccess. Und das Wichtigste - zumindest unter Linux: Symlinks bleiben Symlinks. Beim ersten Einsatz wird alles kopiert, danach nur noch veränderte Dateien. Somit ist die Synchronisation recht schnell.

Der Aufruf aus meiner lokalen Linux-Umgebung lautet:

Code:

---

rsync -avze ssh --delete --exclude=<auszuschließende Datei(en) oder Ordner> Serveruser@server.tld:/pfad/zum/projektordner/ /pfad/zum/lokalen/backup/

---

Das ist ein komplettes Backup der Daten, die somit ohne Probleme wiederhergestellt werden können.

Mehr infos zu rsync und den verschiedenen Optionen(-avze --delete --exclude...): https://wiki.ubuntuusers.de/rsync/

EDIT: Typo

Voraussetzung:
Nur Contao4 – Bundles, Managed Edition, keine Contao3 Module

Umbenennen des Ordners

Zitat:

---

xampp

---

auf

Zitat:

---

xampp-old

---

Herunterladen der Installations- Datei xampp

https://www.apachefriends.org/xampp-...-installer.exe

Installation von xampp (bei mir auf D: )

Kopieren aller nicht vorhandener Dateien von

Zitat:

---

D:\xampp-old\htdocs\

---

nach

Zitat:

---

D:\xampp\htdocs\

---

!Aber keine Contao 4 Versionen!!!!

Kopieren aller nicht vorhandener Dateien von

Zitat:

---

D:\xampp-old\mysql\data

---

nach

Zitat:

---

D:\xampp\mysql\data

---

Folgende Dateien/Ordner aus

Zitat:

---

D:\xampp-old\htdocs\ …

---

der entsprechenden Contao4 Installationen nach

Zitat:

---

D:\xampp\htdocs\ …

---

der entsprechenden Contao4 kopieren:

.settings / Ordner Eclipse
Files / Ordner Contao
Files / Ordner Contao
.gitignore
.project / Datei Eclipse
Composer.json
Composer.lock
README.md

Ich spreche jetzt von WINDOWS!!!

Xampp- Kontrollpanel als Administrator starten, Apache und MySQL starten

Entweder Eclipse oder CMD als Administrator starten

Ins Verzeichnis der Contao4- Installation wechseln

Eingabe:

PHP-Code:

---

Composer update 


---

Vollständige Installation, inklusiv der Erweiterungen der Contoa4- Bundles

Explorer als Administrator öffnen (sicher ist sicher)

Aufruf des Install- Tools mit

PHP-Code:

---

 …/Contao/Install 


---

Eingabe des neuen Passwortes

Datenbank angeben

( jetzt bei mir Fehler bei DB- Update mit tl_image_size, Abhilfe mit löschen der Tabelle tl_image in PHPMyAdmin, irgendwie wurde das _size beim anlegen wohl abgeschnitten)

Danach Login im Backend

Systemwartung -> Daten bereinigung alles auswählen

Manchmal danach noch css- Probleme im Frontend

Im Backend unter Themes-> Seitenlayout Layout wählen, dort auf speichern gehen

Alles gut

Zitat:

---

Zitat von ihkwdiopk

Und somit sind wir wieder beim Thema Composer - Tolles Teil!

---

ohne ssh Zugang? Zeig mal wie geht das?

Zitat:

---

Zitat von BugBuster

Doch natürlich kannst du das lösen, die kannst jedes Update rückgängig machen. Und offenbar hat ja Symfony 3.3.4 den Fehler behoben, dann hätte man auch auf 3.3.2 zurückgehen können. (durch den conflict Eintrag automatisch, solange es keine 3.3.4 oder höher gibt)

---

Das ist doch das was ich beim contao manager vermisse -> hier schon für alle module die automatisch aktulisiert werden, entsprechende "bremsen" einzubauen. Ohne Konsole geht aber gar nicht.

Wenn ich zuerst per FTP Dateien editieren muss um anschließend per contao-manager zu aktualisieren, muss ich ja schon vorher wissen, dass das Update nicht durchgeführt werden darf.

Ich glaube aber, dass wir hier den Thread lieber wieder mit Backupideen füllen sollten und nicht über composer und Konsole.

Ich gebs zu, ich habe auch gewartet. Hauptsächlich auf die LTS, aber natürlich nehme ich den Contao-Manager gerne mit. Ich hatte auch nie eine Kundeninstallation mit Contao 3.3 oder 3.4 am laufen. Grundsätzlich nur LTS. Ok, hätte ich eines der neuen Features von 3.3 oder 3.4 ganz ganz dringend gebraucht ... aber war nicht. Habe alles von 3.2 auf 3.5 upgedatet, völlig problemlos, weil ich auch mit Erweiterungen sparsam umgehe. Und ich gehe davon aus, bis zum Ende der 3.5 LTS wird es mir auch genauso problemlos gelingen, alles nach und nach auf 4.4 zu bringen.

Grundsätzlich war es mir schon immer lieber, beim Kundenwebspace einen SSH-Zugang zu haben. Das vereinfacht vieles, auch ohne Composer. Es geht alles einfach unendlich viel schneller als per FTP, weil ich da meist von Server zu Server kopiere und wenn ich was lokal sichere, dann wird es zuerst mit tar gepackt und dann als eine Datei übertragen. Ist ja nicht so, dass ich der große Unix-Wizard wäre. Aber die paar Befehle, die ich regelmäßig brauche, die kann ich mir gerade noch merken. Was ich seltener brauche, hole ich mir im Zweifelsfall per Google oder aus diversen Wikis, unter anderem auch vom Asteroidenhoster, der vermutlich für Kommandozeilenhasser die Höchststrafe darstellen dürfte.

Wenn man bei WinSCP in den Directory Einstellungen "Follow symbolic links" nicht anhakt, und die Verbindung zum Hoster nicht mit FTP sondern SFTP oder SCP verbindet, zerstört der dann immer noch die Symlinks?
Habe kein Windows hier zum Testen, erst morgen wieder auf Arbeit. Mal testen.

Dann werden wahrscheinlich die Symlinks als solche kopiert. Und diese Symlinks funktionieren nur wenn Quelle und Ziel das gleiche bzw. ein kompatibles Dateisystem haben. Also von Windows auf Linux oder umgekehrt funktioniert das natürlich nicht.

Genau daran scheitere ich auch gerade andauernd.
Es funktioniert von Ubuntu(*.tar) per FileZilla nach Windows(entpacken mit WinRar(wichtig: als Administrator ausführen) und dann nach xampp) aber leider nicht umgekehrt.

Gruß
tschero

Zitat:

---

Zitat von Spooky

Dann werden wahrscheinlich die Symlinks als solche kopiert. Und diese Symlinks funktionieren nur wenn Quelle und Ziel das gleiche bzw. ein kompatibles Dateisystem haben. Also von Windows auf Linux oder umgekehrt funktioniert das natürlich nicht.

---

Hat bei mir eh nicht funktioniert, die Datei wie auch ein Verzeichnis was ich testweise per Symlink eingerichtet habe wurden beide weiterhin gefolgt. (Windows 7, WinSCP im Modus SCP ohne Symlink Folgung).
Hätte ja sein können da Windows ja symbolische Links seit Vista angeblich kann. (mklink auf Kommandozeile)
Ich probiere das mal unter Windows 10.

Zitat:

---

Zitat von BugBuster

Hätte ja sein können da Windows ja symbolische Links seit Vista angeblich kann. (mklink auf Kommandozeile)
Ich probiere das mal unter Windows 10.

---

Windows (NT) kann symlinks schon lange ;). Sonste würde ja auch Contao 4 gar nicht funktionieren.

siehe Beitrag:
https://community.contao.org/de/show...BCr-Contao-4-4

Das Backup-ZIP enthält auch ein PHP-Script, was die Symlinks, die es zum Zeitpunkt des Backup gab, wieder herstellt.
Man speichert das Script ins web-Verzeichnis und ruft es per URL auf - keine Kommandozeile!

siehe Anleitung:
https://github.com/do-while/contao-B...ontao-4.4-(DE)

Zitat:

---

Zitat von electricarts

Danke für die Erklärungen und dein Engagement, BugBuster!

Danke, aber nein danke. Ich würde mich jetzt nicht als den totalen Terminal-Versager bezeichnen, aber dieses ganze Geraffel für ein simples Backup ist mir einfach too much.

Ist jetzt total OT, aber für wen genau soll Contao zukünftig sein? Muss man vorher einen Kommandozeilen-Kurs irgendwo belegt haben um profane alltägliche Dinge wie ein Backup ausführen zu können? Eine Vergrößerung der Nutzerbasis dürfte mit dieser Form der Bedienung eines CMS nicht zu erreichen sein. Schade. Sehr schade.

---

Hallo electricarts

Ich stimme Dir vollständig zu. Die Vorgehensweise (wenigstens im Moment) für ein kompletes Contao 4.4.x Backup finde ich gelinde gesagt eine Zumutung.
Bisher hatte ich immer ein komplettes Backup, lokal auf meiner Kiste. Und wie gehe ich im Moment vor:

1. composer.json und composer.lock (beide sind notwendig) vom Live Server holen. Dann lokal installierter Composer, bei Windows, Eigabeaufforderung (cmd.exe) als Admin öffen und in das entsprechen Backupverzeichnis wechseln, dann composer install eingeben. Das funktionert auch anscheindend wunderbar.

Und jetzt kommt das Tolle. Per FTP/SFTP-Client muss ich dann noch die Ordner app, files, templates, system/config und system/modules (vorallem wenn dort Contao 3.5.x Erweiterungen vorhanden sind) lokal sichern.

Den umgekehrten Weg, also die Wiederherstellung einer Contao 4.4.x Installtion, habe ich noch nicht gewagt. Soll so funktioneren:

composer.json und composer.lock von Backup zurück auf den Server und dann ebenfals composer install aufrufen. Composer muss natürlich auf dem Live Server vorhanden sein.

Na ja, ist schon eine Symfonie. mit 12 Sätzen.

Noch etwas:

Zitat:

---

Eine Vergrößerung der Nutzerbasis dürfte mit dieser Form der Bedienung eines CMS nicht zu erreichen sein. Schade. Sehr schade.

---

Contao ist ein tolles CMS, aber bei mir kommt so langsam das Gefühl auf, dass man gar nicht mehr so daran interessier ist, dieses tolles CMS weiterhin unter die Leute zu bringen, wenigsten dann nicht, wenn man nicht Dr. PuTTY, Dr. Composer, Dr JavaScript, Dr. jQuery und Dr. PHP, habe ich noch etwas vergessen, ist. BugBuster ist aber immer sehr engagiert. Ohne ihn wären einige, auch ich, mit Contao 4.4.x am Anshlag.

Gruss pumukel

Ums mal ganz klar zu sagen, die Leute die Putty/SSH, Composer & Co. auch nur ansatzweise verstanden haben oder gar beherrschen, sind genau die Zielgruppe von Contao.
Von daher sehe ich da keine Probleme das Contao weiterhin seine Anwender findet. Auch neue Anwender die die neuen Möglichkeiten, durch die Umstellung auf Composer, zu schätzen wissen, werden sich finden. Es ist dadurch professioneller geworden.

Contao 3 wurde fast ausnahmslos für Anwender verbessert und erweitert. Contao 4 endlich mal grundlegend für Entwickler. Und das bedeutet für die Contao 3 only Hobby Entwickler wie meiner einer auch viel neues lernen, denn Symfony war für mich bisher ein Schreibfehler ;)
Da ist das Backup doch ein Klacks gegen.

-= WER WILL DER KANN =-

Und ihr könnt das auch.

Zitat:

---

Zitat von BugBuster

Ums mal ganz klar zu sagen, die Leute die Putty/SSH, Composer & Co. auch nur ansatzweise verstanden haben oder gar beherrschen, sind genau die Zielgruppe von Contao.
Contao 3 wurde fast ausnahmslos für Anwender verbessert und erweitert. Contao 4 endlich mal grundlegend für Entwickler. Und das bedeutet für die Contao 3 only Hobby Entwickler wie meiner einer auch viel neues lernen, denn Symfony war für mich bisher ein Schreibfehler ;)
Da ist das Backup doch ein Klacks gegen.

-= WER WILL DER KANN =-

Und ihr könnt das auch.

---

Hallo BugBuster

Nimm es nicht persönlich, aber genau dies meinte ich: Contao 4.x.x also hauptsächlich für Entwickler. Vielleich sind max. 30% derer die Contao 4.4.x auch bentzen wollen Entwicker, der Rest aber Anwender. Ich benutze inzwischen PuTTY und Composer. Habe mich also um diese Dinger bemüht und also neues gelernt!

Nun habe ich wieder ein neues Problem, dass ich den Debugmodus von Conta 4.4.1 nicht zum Leben erwecken kann kann, Bin genau nach https://community.contao.org/de/show...gen-Autoloader vorgegangen
leider ohne Erfolg.

nach z.B. http://vzwxwgvvy.cyon.link/app_dev.php/ueber-uns.html
You are not allowed to access this file. Check app_dev.php for more information.

Finde es schon schlimm, dass man nur um den Debugmodus zu aktvieren. solche Klimmzüge absolvieren muss und dann haut es nicht einmal hin. Ich brauche den Debug Modus dringend, denn bei einer Contao 3.5.27 Migraion nach Contao 4.4.0 gibt es doch einige Änderungen an den Stylesheets.

Schönes Wochenende
pumukel

Zitat:

---

Zitat von pumukel

Finde es schon schlimm, dass man nur um den Debugmodus zu aktvieren. solche Klimmzüge absolvieren muss und dann haut es nicht einmal hin.

---

Klimmzüge?
Geh in Root-Verzeichnis (web/..):

Code:

---

php vendor/contao/manager-bundle/bin/contao-console contao:install-web-dir --user=dev --password megaPassword

---

Ruf http://vzwxwgvvy.cyon.link/app_dev.php/ueber-uns.html auf und logge Dich mit Benutzer:dev und Passwort:megaPassword ein.
Tipp: Benutze vielleicht ein anderes Passwort; eins mit Sonderzeichen und keine Wörter aus dem Lexikon (also nix mit Pferd, Stapel und Batterie, fällt einem eh nur unsicherer Mist ein); am wichtigsten ist wie immer die Länge. Mein ssh Passwort ist zum Beispiel: 2xpqfqTsmVx322gTtu687EvMe

Auch hier kann man wieder sagen, durch den Wechsel des Debugmodus von Contao ehemals zur Debug Console von Symfony ist diese wesentlich mächtiger geworden.
Da Symfony kein Backend kennt, muss dieser eben so aktiviert werden. Lokal braucht es nicht das Login und Passwort, da geht's auch so.

Da niemand will, dass auf Live Seiten jedermann die Debug Console aufrufen kann, ist es eben geschützt.
Braucht man auch auf Live Seiten selten, wenn das was klemmt kann man auch in var/logs/prod-...log schauen was los ist. Klar ist das als Webseite natürlich einfacher.

Zitat:

---

Zitat von pumukel

Nimm es nicht persönlich, aber genau dies meinte ich: Contao 4.x.x also hauptsächlich für Entwickler.

---

Nein, so kann man das nicht sagen. Es wurde hauptsächlich für die Entwickler verändert, ja, aber für die Nutzer hat sich im Vergleich dazu kaum was geändert.
1-click Install Nutzer/Redakteure werden außer dem Backend Design gar nichts merken.

Wer gleichzeitig quasi Admin ist, für Installation und Backup zuständig, der muss einiges neues lernen, wovon es einiges aber zu Contao 3 Zeiten auch schon gab. (Composer, für Probleme auch Kommandozeile)

Und, wer eine Admin Aufgabe hat ....

Sollte man schon trennen. Passwort setzen für die app_dev ist ja auch nur ein Befehl den man einmal ausführt. Sollte nicht die Hürde sein.

Frage: reicht die Beschreibung hier nicht?

Code:

---

/***********************************************************************************************/
/*                              ###  READ FIRST  ###                                          */
/* Access to debug front controllers must only be allowed on localhost or with authentication. */
/* Use the "contao:install-web-dir" console command to set a password for the dev entry point. */
/***********************************************************************************************/

---

Ich selber musste auch erst mal schauen ob und welche Parameter es gibt. Wäre es hier besser die vollständige Befehlszeile anzugeben?

Zitat:

---

Zitat von BugBuster

Code:

---

/***********************************************************************************************/
/*                              ###  READ FIRST  ###                                          */
/* Access to debug front controllers must only be allowed on localhost or with authentication. */
/* Use the "contao:install-web-dir" console command to set a password for the dev entry point. */
/***********************************************************************************************/

---

Ich selber musste auch erst mal schauen ob und welche Parameter es gibt. Wäre es hier besser die vollständige Befehlszeile anzugeben?

---

Jap - von hier ein +1

Zitat:

---

Zitat von ihkwdiopk

Klimmzüge?
Geh in Root-Verzeichnis (web/..):

Code:

---

php vendor/contao/manager-bundle/bin/contao-console contao:install-web-dir --user=dev --password megaPassword

---

---

Das geht kürzer:

Code:

---

php vendor/bin/contao-console contao:install-web-dir --user=userfürdebug --password

---

Passwort auf Kommandozeile nicht mit angeben, es wird dann abgefragt. Grund ist, man kann es sonst in der Befehlshistory sehen, das will man nicht ;)

Zitat:

---

Zitat von BugBuster

Das geht kürzer:

Code:

---

php vendor/bin/contao-console contao:install-web-dir --user=userfürdebug --password

---

Passwort auf Kommandozeile nicht mit angeben, es wird dann abgefragt. Grund ist, man kann es sonst in der Befehlshistory sehen, das will man nicht ;)

---

Kommt:

Code:

---

[InvalidArgumentException]
  Cannot set a username without password.

---

Jedoch ist Dein Argument bzgl. Befehlshistory vollkommen richtig.

Sorry:

Code:

---

php vendor/bin/contao-console contao:install-web-dir --user=userfürdebug -p

---

Äh, komisch, geht auch nicht. Könnte wetten das ging mal. Ist eigentlich so üblich. OK, dann eben mit password, ist aber blöd.

Zitat:

---

Zitat von BugBuster

Sorry:

Code:

---

php vendor/bin/contao-console contao:install-web-dir --user=userfürdebug -p

---

Äh, komisch, geht auch nicht. Könnte wetten das ging mal. Ist eigentlich so üblich. OK, dann eben mit password, ist aber blöd.

---

Mit -pl geht es - jedoch, wo setzt man dann das Passwort?

Das ist gesetzt, alles was nach dem -p kommt ist das Passwort.
Guckst du in die Datei .env im Installationsverzeichnis.

Hab zwei Tickets erstellt:
https://github.com/contao/manager-bundle/issues/39
https://github.com/contao/manager-bundle/issues/40

Zitat:

---

Zitat von BugBuster

Hab zwei Tickets erstellt:
https://github.com/contao/manager-bundle/issues/39
https://github.com/contao/manager-bundle/issues/40

---

Hallo BugBuster

Danke für die Tickets. Es funktioniert wirklich nicht, den Debug Mode zu aktivieren. Habe es x-mal probiert.
Gruss pumukel

Zitat:

---

Zitat von pumukel

Hallo BugBuster

Danke für die Tickets. Es funktioniert wirklich nicht, den Debug Mode zu aktivieren. Habe es x-mal probiert.
Gruss pumukel

---

Was genau funktioniert nicht?

Der lange Weg sollte aber gehen, das setzen des Logins und Passwortes geht damit bei mir.

Code:

---

vendor/bin/contao-console contao:install-web-dir --user=meinDebugLogin --password=meinDebugPW

---

Zitat:

---

Zitat von pumukel

Hallo BugBuster

Danke für die Tickets. Es funktioniert wirklich nicht, den Debug Mode zu aktivieren. Habe es x-mal probiert.
Gruss pumukel

---

Sollte ja auch alles funktionieren bzw. ist sogar alles vorgesehen, jedoch machen die Zeilen hier das Problem aus: https://github.com/contao/manager-bu....php#L106-L112

Zitat:

---

Zitat von Spooky

Was genau funktioniert nicht?

---

Dies funktioniert nicht
von ihkwdiopk 16.07.2017 / 00:59
Klimmzüge?
Geh in Root-Verzeichnis (web/..):

Code:

---

php vendor/contao/manager-bundle/bin/contao-console contao:install-web-dir --user=dev --password megaPassword

---

Ruf http://vzwxwgvvy.cyon.link/app_dev.php/ueber-uns.html auf und logge Dich mit Benutzer:dev und Passwort:megaPassword ein.
Tipp: Benutze vielleicht ein anderes Passwort; eins mit Sonderzeichen und keine Wörter aus dem Lexikon (also nix mit Pferd, Stapel und Batterie, fällt einem eh nur unsicherer Mist ein); am wichtigsten ist wie immer die Länge. Mein ssh Passwort ist zum Beispiel: 2xpqfqTsmVx322gTtu687EvMe

Wobei ich für --user= und --password ******* andere Daten benutzte.

Gruss pumukel

Zitat:

---

Zitat von pumukel

Dies funktioniert nicht
von ihkwdiopk 16.07.2017 / 00:59
Klimmzüge?
Geh in Root-Verzeichnis (web/..):

Code:

---

php vendor/contao/manager-bundle/bin/contao-console contao:install-web-dir --user=dev --password megaPassword

---

Ruf http://vzwxwgvvy.cyon.link/app_dev.php/ueber-uns.html auf und logge Dich mit Benutzer:dev und Passwort:megaPassword ein.
Tipp: Benutze vielleicht ein anderes Passwort; eins mit Sonderzeichen und keine Wörter aus dem Lexikon (also nix mit Pferd, Stapel und Batterie, fällt einem eh nur unsicherer Mist ein); am wichtigsten ist wie immer die Länge. Mein ssh Passwort ist zum Beispiel: 2xpqfqTsmVx322gTtu687EvMe

Wobei ich für --user= und --password ******* andere Daten benutzte.

Gruss pumukel

---

Der Befehl lautet

Code:

---

vendor/bin/contao-console contao:install-web-dir --user=dev --password=password

---

vendor/bin/contao-console ist doch der Symlink auf vendor/contao/manager-bundle/bin/contao-console, müßte also beides funktionieren (ohne "php" natürlich ...).
Der Fehler liegt wohl darin, dass vendor/bin/contao-console - im Ordner /web ausgeführt - nicht gefunden wird. Der Befehl müßte dann lauten ../vendor/bin/contao-console.
Oder vorher ins root Verzeichnis wechseln, dann funktioniert der relative Pfad wieder ...

Solche Befehle gebe ich immer vom Installverzeichnis aus gesehen an, das ist auch so üblich würde ich mal behaupten.
Damit jeder weiß wo er sein muss.
Das jedes Mal dazu schreiben oder mit TL_ROOT arbeiten wäre mühsam. ;)

ich habe mich auf die Beiträge #64 und #65 bezogen, da hieß es, diese Befehle im Verzeichnis /web auszuführen.

Nö, das steht ganz genau:

Code:

---

Geh in Root-Verzeichnis (web/..):

---

und das ".." dahinter bewirkt, ein Verzeichnis höher, also das gleiche als wenn ich im web/ Verzeichnis ein "cd .." eingeben würde.

Zitat:

---

Zitat von Seefahrer

vendor/bin/contao-console ist doch der Symlink auf vendor/contao/manager-bundle/bin/contao-console, müßte also beides funktionieren (ohne "php" natürlich ...).
Der Fehler liegt wohl darin, dass vendor/bin/contao-console - im Ordner /web ausgeführt - nicht gefunden wird. Der Befehl müßte dann lauten ../vendor/bin/contao-console.
Oder vorher ins root Verzeichnis wechseln, dann funktioniert der relative Pfad wieder ...

---

Ob mit oder ohne php ist systeamabhängig. Auf Unix-System funktioniert es (http://php.net/manual/de/features.commandline.usage.php). Da meist 'php' als ein Alias auf die cli-Version zeigt; können somit alle diejenigen, die eh mit anderen php-cli Versionen arbeiten (siehe CM) entsprechend auch die contao-console ausführen.

Wenns es ohne php klappt: +1 für den Hoster.

Auf die Pfadangabe hat ja schon BugBuster hingewiesen.