Druckbare Version
Da ist im Backup auch ein Script vorhanden, was die vorhandenen Symlinks wieder herstellt.Zitat:
Zitat von mlweb
Damit ist eine Dateisicherung mit ZIP auch für einen Umzug geeignet, auch wenn die Symlinks dabei kaputt gehen, denn das Script korrigiert sie wieder.
https://github.com/do-while/contao-B...ontao-4.4-(DE)
Nur für den Fall, dass jemand einen anderen Port als 3306 hat:Zitat:
Zitat von Stefko
PHP-Code:<?php
// Variablen für das Backup
$dbHost = '127.0.0.1'; // Datenbank Host
$dbPort = 3307; // Datenbank Port
...
// Datenbank sichern und als gz-Archiv ablegen
shell_exec('mysqldump -h '.$dbHost.' -P '.$dbPort.' -u '.$dbUser.' -p'.$dbPass.' '.$dbDatabase.' | gzip > '.$path.'/'.$date.'_'.$dbDatabase.'.sql.gz');
...
Erwähnte ich oben auch schon leider reicht das @zonky offenbar nicht.Zitat:
Zitat von do_while
Wahrscheinlich habe ich leichte Verständnisschwierigkeiten. ;)
Ich finde ein Umzug eigentlich echt easy, egal ob man jetzt auf Depoyment Tools zurückgreift oder mit Backup DB arbeitet, eher manuell eine Neuinstalltion und Übernahme der "eigenen Daten per FTP" macht.
Hallo Stefko,
so ganz versteh ich das nict:
Wo legst du bei Contao 4 dieses Script ab und wie rufst du es auf?Zitat:
Zitat von Stefko
Es kann ja nicht im /web liegen, denn sonst würde es nicht alles ins tar.gz packen...
Vielleicht hab ich ja auch nur Tomaten auf den Augen ;)
folkfreund
@folkfreund: Ne, keine Tomaten ;-)
Das Ding fand bisher nur bei 3.5 Installationen Anwendung, lag im root und wurde (standardmäßig) per Cronjob aufgerufen.
Du hast recht, der direkte Aufruf würde unter 4.x so nicht mehr funktionieren.
Evtl. müsste man dann im /web einen Symlink erstellen, der auf das Script im root linkt. Muss ich nachher mal ausprobieren ...
mir schon... ich habe nur das "Zusammengefasste Meinungsbild" einiger Agenturen wiedergegeben...Zitat:
Zitat von mlweb
BackupDB habe ich unter C4 noch nicht getestet - kenne es nur unter C3...
... was passiert mit /templates, /files, /src (mit AppBundle) ggf. /app (mit AppBundle), /modules mit eigenen/gekauften Moduln, die nicht über composer installiert werden können - das bei BackupDB jetzt alles dabei?
Bei BackupDB ist die Datenbank gesichert, alles andere sicherst Du, wie bisher, als Datei-Backup.
Lediglich ein paar wichtige Dateien werden mit ins ZIP gepackt: die composer.json, die composer.lock und das Script zum Wiederherstellen der Symlinks.
also doch wie gehabt... :DZitat:
Zitat von do_while
Nochmal zur Klarstellung: es geht nicht darum wie ich die Sachen umherschaufle... bekomme ich soweit hin - es geht um einen Weg für "Agenturen" ohne eigene Admin-Riege oder Programmierer, die ein Roll-out vom eigenen Entwicklungssystem auf einen Kundenserver... und das ohne "man muss auf der Konsole nur die folgenden 10 Schritte..."
Meiner Meinung nach nützt es Contao nichts zu sagen, "stellt euch nicht so blöd an" und auch nicht deren Wechsel "nach unten" zu WP...
Verstehe ich nicht, wenn Agenturen mit dem Hochladen der verschiedenen benötigten Verzeichnisse und Dateien nicht klarkommen, sind sie doch auch schon bei allen früheren Contao-Versionen an diesem Punkt gescheitert.Zitat:
Zitat von zonky
... die haben per FTP alle Dateien rüber geschaufelt, DB-Zugangsdaten eingetragen => fertigZitat:
Zitat von bjarke
mit C4 funktioniert das nun eben nicht mehr - hat denen offensichtlich keiner gesagt ;-)
Da hast du das Wort "Agenturen" aber aus gutem Grund in Anführungszeichen gesetzt. :D
Ich bin nun wirklich kein Admin, geschweige denn eine ganze Admin-Riege. Aber eine hier gefundene Anweisung abzutippen, das schaffe ich gerade noch. Naja, meistens bin ich faul, füge sie einfach per Copy&Paste in der Konsole ein und korrigiere dann nötigenfalls noch eventuell abweichende Pfade usw.
Man kann auf der Konsole aber man muss nicht.Zitat:
Zitat von zonky
Ich denke, es geht hauptsächlich um Symlinks, von denen manche Betriebssysteme andere Vorstellungen haben und sie damit "kaputt" machen. Bei Contao 3 gab es dieses Thema ja noch nicht. Aber vielleicht habe ich auch noch ein Problem verpasst.
Aus meiner Sicht ist es wie zuvor: es gibt den Inhalt der Datenbank, den ich via Datenbankdump sichere/umziehe/... und die Dateien im Contao-Verzeichnis. Hier packe ich alles in in tar. Auf der anderen Seite packe ich das tar wieder aus und fertig. Solange ich unter Linux/MacOs/... arbeite funktioniert das auch alles wunderbar. Bei Windows muss ich mich dann mit Symlinks beschäftigen, die nicht "richtig" angelegt wurden.
Wenn ich die Probleme also richtig verstanden habe geht es (nur) um die Symlinks und die Windows-User benötigen dafür eine Lösung.
Hmm, es geht @zonky nach meinem Verständnis auch darum, das tar ohne Konsole zu erzeugen und wieder auszupacken. Und zwar am besten gleich so, dass die Symlinks auf dem Zielsystem funktionieren. Und weiterhin so, dass der Agenturangehörige ;) unanständige Wörter wie "tar" und "Konsole" gar nicht erst zu sehen bekommt. Man packt das anderswo gepackte tar aus, kopiert die Datenbank und fertig. Oder, noch besser, gleich so, dass beim Packen automatisch ein Datenbankdump mit erzeugt und meinetwegen in das Archiv integriert wird. Dann wählt man am Zielsystem nur noch das Archiv aus, gibt die Datenbankzugangsdaten ein und den Rest macht - der Contao-Manager. Darauf läuft es ja letztendlich raus. Hier hat man schon ein Webinterface für die Konsole, das "nur" noch erweitert werden müsste.
Würde mir auch gefallen, das meine ich sogar ernst. ABER, man darf dabei natürlich nicht vergessen, dass das alles vom Hosting abhängt! Nicht überall hat man bei über den Contao-Manager erzeugten Konsolenprozessen die selben Limits in Bezug auf RAM und Skriptlaufzeit wie bei direkt in der Konsole gestarteten Prozessen. Und dass viele Hostings bereits jetzt ein Problem mit den Voraussetzungen für den Manager haben, ist ja hinlänglich bekannt.
BINGO!Zitat:
Zitat von tab
Da man unter Windows normalerweise kein tar zur Verfügung hat, muss es auch mit ZIp gehen, so wie früher bei C3. Da ZIP beim Entpacken die Symlinks zu Verzeichnissen macht, bringt auch der Composer (auch im Contao Manager) Fehlermeldungen. Anders ist es beim BackupDB-Script, dort werden die Symlinks korrekt wiederhergestellt. Auch die Konvertierung der Symlinks von Windows zu Linux und umgekehrt wird ausgeführt. Das alles aus dem Web-Verzeichnis heraus, also komplett ohne Konsole.
ich müsste mal ausprobieren, was tar unter Windows macht - der Cmder bringt das mit (u.a. SSH, composer usw. auch)
Ist die Unterstützung da seitens PHP genauso mangelhaft wie bei den Symlinks? Immerhin sollte es laut PHP-Manual eigentlich funktionieren, ein tar-File per PHP zu erzeugen.
Ich bin Windows Nutzer. Das Problem mit den Symlinks kann man mit Backup DB umgehen oder damit, dass man nicht die gesamte Installation kopiert sondern auf dem Server neu installiert und nur die spezifischen Dateien (files. templates, Konfiguration und ggf. manuell installierte Module) mitnimmt (derzeit mein Weg). Eine Alternative ist ein Deployment mit Magalanes etc. Habe ich mal getestet, bin ich aber noch nicht ganz warm geworden. Mir geht der "manuelle Weg" im Moment noch schneller von der Hand.Zitat:
Zitat von fiedsch
Ich denke einen dieser Wege sollte auch eine Agentur hinbekommen ;).
Zitat:
Zitat von tab
Hört sich zwar gut an, ist m.E. aber nur die halbe Wahrheit. Wenn dann mal was schief läuft wissen die Agenturen auch nicht was sie tuen sollen und werden nicht glücklich sein. Meistens geht ja etwas schief wenn die Zeit ohnehin drängt ;).Zitat:
Zitat von zonky
Ich finde schon, dass eine Website-Agentur oder ein Freelancer, der sich auf die Fahne schreibt Websites erstellen zu wollen mit diesen unanständigen Wörtern was anfangen können sollte. Contao ist doch kein Baukasten-System :D.
Sehe ich natürlich genauso. So ein um eine Umzugs-/Backupfunktion erweiterter Contao-Manager ist schön, ersetzt aber die Konsole nicht vollständig. Besonders wenn eben mal was nicht so funktioniert wie erwartet, oder wenn der Contao-Manager auf dem Garnichtsobillig-Webspace des Kunden bei einem der "Marktführer" nicht funktioniert. Das könnte sich eine Agentur vielleicht bestenfalls erlauben, wenn sie dem Kunden zwingend eins von mehreren bekannt funktionierenden Hostings zur Bedingung macht.Zitat:
Zitat von mlweb
Dringend gesucht :D;): CMS mit den Features von morgen, lauffähig auf allen Hostings - auch mit der Technik von vorgestern.
Ich vermute eher das die Agenturen mit < C4 bisher ein gutes und in der Handhabung einfaches CMS hatten. In Bezug auf das Hosting im Prinzip einfaches Copy & Paste.
Auch wird nicht jeder täglich mit der Console arbeiten müssen, sodass man in dem Zusammenhang C4 schon als aufwändiger betrachten muss.
C4 ist für die Zukunft gerüstet, keine Frage aber auf Kosten der Systemanforderungen und entsprechendes Wissen. Daher kann auch ich nachvollziehen, dass C4 gerade für kleine Projekte vielleicht doch zu anspruchsvoll geworden ist.
Stimmt. Aber ich finde, Contao sollte trotzdem auch für Nicht-Profis attraktiv sein/bleiben (ich gehöre auch dazu).Zitat:
Zitat von mlweb
Und falls es möglich ist, eine gute Unterstützung durch Tools zu schaffen, dann bin ich auf jeden Fall dafür! Das Bessere ist der Feind des Guten... Abgesehen davon werden gute Tool Zeit einsparen - und gerade für die Profis ist Zeit = Geld ;).
Mir ist auch bewusst, dass es aktuell oft an den Gegebenheiten des Hostings hängt. Aber vor 10 Jahren gab es nicht mal überall PHP, heute gehören SSL Zertifikate und oft ein SSH-Zugang zur Grundausstattung. Das wird sich alles in naher Zukunft relativieren, davon bin ich überzeugt.
gebe Y-Nell und folkfreund recht... meine ersten E-Mails habe ich auch auf Konsole abgesetzt und Bilder wurde per uuencode/uudecode umgewandelt als ASCII-Block... will heute sicher keiner mehr
Naja, das hat jetzt hiermit aber auch sowas von gar nichts zu tun. Und selbst damals gab es für so etwas schon Programme. Ein Zugriff auf den Webserver ist halt entweder indirekt über den Apache oder direkt per Konsole möglich. Und wenn du beim Umweg über den Apache nicht genug Ressourcen bekommst, dann nimmst du halt was übrig bleibt. Zumal der direkte Weg nicht grundsätzlich der schlechtere oder langsamere ist. Das mit den Ressourcen wird sich irgendwann ändern, da bin ich auch überzeugt. Aber im Moment ist es eben häufig noch nicht so. Und beim Eintippen von Befehlen oder Kopieren per Copy&Paste ist auch noch niemand ein Finger abgebrochen. Selbst Scotty konnte noch die Formel für transparentes Aluminium in Sekundenschnelle per Tastatur eingeben, als der Computer auf seine Sprachbefehle partout nicht reagieren wollte :D. Hier wird ja teilweise so getan, als ob man für die Eingabe einfacher und nachlesbarer Befehle ein versierter Linux-Admin sein müsste. Hoffentlich kommt nicht noch einer auf die Idee, das man das alles über Siri durchführen können muss anstatt über veraltete Interfaces wie Tastatur und Maus.
Wenn ihr aufhören würdet immer die ganze Installation zu sichern, hättet ihr auch keine Probleme mit Symlinks. :-) Das Problem ist wirklich nicht das System, sondern vermutlich der Versuch irgendein altes gelerntes Muster darauf anzuwenden.
Wie schon unzählige Male erwähnt reicht es neben dem DBDump in der Regel Files, Templates, composer.json/lock + ggf. angepasste Config-Files zu sichern und gut ist. Und wer sich gegen Repositories und Deployment verwehrt, macht das halt per FTP.
Moin in die Runde!
Ich möchte auch noch mal meinen "Senf" zu diesem Thema dazugeben, die ich aktuell vor genau dem Problem stehe, Contao4 auf einen anderen Server zu "kopieren".
Vieles, was hier gesagt wird, von beiden Seiten, hat durchaus seine Berechtigung, aber man muss es einfach differenzieren.
Contao 4 läuft auf einigen Servern wirklich richtig gut und gerade der Manager ist schon eine große Hilfe, gerade beim Updaten.
ABER, wenn ein Kunde schon einen Server hat (bspw. bei 1und1, was aufgrund der Populaität nicht unwahrscheinlich ist!) und auch nicht wechseln möchte oder aufgrund der Kosten oder Vertragslaufzeiten nicht kann/will, dann ist man mit Contao 4 schon aufgeschmissen. Contao 4 ist so anspruchsvoll geworden, dass viele Server damit nicht klar kommen. Und das nervt wirklich total! Da helfen auch die Sprüche "1und1 taugt doch eh nichts" oder "muss man sich halt einen richtigen Server holen" so überhaupt nicht weiter! Da wurde aus meiner Sicht etwas an der Realität vorbei entwickelt....
Ich bin seit Jahren totaler Contao Fan! Ich liebe dieses System! Aber mit Contao 4 haben die Entwickler uns "Normalos" wirklich keinen Gefallen getan!
Natürlich muss man bei einem neuen System umdenken, sich neu einarbeiten und lernen, aber die Lernkurve scheint mir hier doch sehr hoch!
Das ich jetzt noch nicht einmal, ein einfaches Backup, bzw. einen einfachen Umzug auf einen anderen Server realisieren kann, das stimmt micht echt traurig.
Natürlich gibt es diverse Lösungen und Ansätze hier, aber das funktioniert ja in der Realität auf sehr vielen Server so überhaupt nicht!
Ich habe viele der hier genannten Ansätze ausprobiert, habe mich echt reingekniet und viele Tage damit verbracht, aber glücklich bin ich dabei nicht geworden!
Ich kann nicht überall per Konsole arbeiten, auch der Contao Manager funktioniert auf so vielen Servern nicht (bspw. 1und1) oder Erweiterungen können hier nicht installiert werden, die Symlink-Problematik nervt zusätzlich und und und .....
Eine einfache Komplett-Sicherung, so wie es bei den meisten anderen CMSen möglich ist, also Ordner (zippen und) sichern, Datenbank-Dump anlegen, das ganz dann auf einen anderen Server schupsen, Datenbank einspielen und alles ist gut, gibt es mit Contao 4 nun nicht mehr.
Contao hat mit der 4 Version wirklich viel verloren, was Contao ausgezeichnet hat! Leider! Die Zeilgruppe dafür ist leider eine andere geworden und Contao wird dadurch sehr an Popularität verlieren und den Anschluss an andere CMSe verlieren ....
Ich stehe nun vor dem Problem, wenn ein Kundenserver nicht für Contao geeignet ist (einige Kunden haben nunmal ihre Provider und wollen nicht wechseln!), was ich tun soll? Contao 3.5 ist spitze, aber wird nicht mehr so lange supportet, Wordpress finde ich absolut schei**.....
Dies ist natürlich nur meine Meinung, andere sehen das ganz anders und viele fühlen sich dadurch vielleicht auf den Schlipps getreten, aber so ganz sollten die Entwickler, die ja wirklich grandiose Arbeit leisten und ihre Freizeit opfern, die Stimmung, die gerade herrscht nicht einfach ignorieren ...
Moin,
also ich sehe nur einen einzigen Show-Stopper, der gegen den Einsatz von Contao4 spricht und das ist ein nicht vorhandener SSH-Zugang. Ist dieser nicht vorhanden hat man uU wirklich die Pappnase auf und steht wie gerade mit dem Symfony-Problem blöde da (zwar lässt sich dieses wohl auch ohne SSH lösen, aber wesentlich aufwändiger).
Aber um SSH zu haben braucht man nicht gleich einen V-Server oder den Hoster zu wechseln. Im besten Fall genügt ein Anruf, meist ein einfacher Wechsel in ein etwas größeres Paket (hatte ich bei einigen Kunden und die hatten zT so alte Verträge, dass der neue auch nicht teurer war (1&1)).
Contao4 läuft bei 1&1, wie hier im Forum schon zigfach erklärt wurde ist lediglich die Abhängigkeitsauflösung durch den Composer die Hürde.Zitat:
Zitat von ok99
Das habe ich selbst bei mehreren Installationen. Einfachste Lösung: Eine lokale Installation auf welcher die Auflösung durchgeführt wird und anschließend composer.json und composer.lock auf den Produktiv-Server spielen und anschließend auf der Konsole ein composer install ausführen. Das geht mittlerweile auch mit dem Manager (habe ich selbst aber noch nicht getestet, da überall SSH vorhanden.
Ein Weg zu dem ich auch raten würde, selbst wenn der Server ausreichend RAM hätte, denn es vermindert die Downtime der Seite auf ein Minimum und man kann zuvor alles in einer Testumgebung testen. Teufel, Eichhörnchen und so weiter ... Ich bin einfach kein Freund von Operationen am "offenen Herzen" ;)
Doch das geht, habe ich anfangs selbst so gemacht. Komplette Contao-Installation auf der Konsole .tar.gz packen auf dem Testserver wieder auspacken, DB-Verbindung anpassen und fertig. Die Sym-Links stellen wohl vor allem unter Windows ein Problem da, wenn man sie einfach per FTP runterlädt.Zitat:
Eine einfache Komplett-Sicherung, so wie es bei den meisten anderen CMSen möglich ist, also Ordner (zippen und) sichern, Datenbank-Dump anlegen, das ganz dann auf einen anderen Server schupsen, Datenbank einspielen und alles ist gut, gibt es mit Contao 4 nun nicht mehr.
Aber wie hier auch schon erklärt wurde, ist das eigentlich gar nicht nötig -> "files/, templates/, composer.json/lock + ggf. angepasste Config-Files zu sichern und gut ist"
Ich vermute eher, dass andere CMSe über lang oder kurz den gleichen Weg gehen werden/müssenZitat:
Contao hat mit der 4 Version wirklich viel verloren, was Contao ausgezeichnet hat! Leider! Die Zeilgruppe dafür ist leider eine andere geworden und Contao wird dadurch sehr an Popularität verlieren und den Anschluss an andere CMSe verlieren ....
vielleicht wäre ein CONTAOlight für Dich das Richtige ;-)Zitat:
Zitat von ok99
Hi ok99,
was Du schreibst ist richtig. Auch ich finde es echt schade, dass Contao ein Stück Einfachheit verloren hat. Die Lernkurve ist schon ordentlich nach oben gegangen, was den Installations- und Updatebereich angeht.
Ich sehe Contao im Gegensatz zur Version 3.5 – wie Du – zur Zeit auch nicht als geeignetes CMS, um damit mal eben eine kleine Kundenseite zu machen, mit der man anschließend nie wieder etwas zu tun hat. Das Know-how in dem Bereich ist beim Kunden einfach nicht da. Deshalb mache ich die ganz kleinen Aufträge im Moment mit WordPress, macht keinen Spaß, geht aber gerade nicht anders.
Ich habe aber auch festgestellt, dass das eigentliche Problem nicht die Kunden sind, sondern ich anfangs keinen überragenden Job gemacht habe. Ich habe meinen Kunden einfach nicht gut genug erklärt, wie genau sie die Updates machen und wo sie klicken müssen. Je länger ich aber mit der C4 unterwegs bin, desto besser kenne ich mich aus und desto besser kann ich meine Kunden schulen.
Was ich dagegen bei der C$ schmerzlich vermisse ist eine Auflistung der installierten Bundles und den Hinweis auf neue Contaoversionen. Ich denke nämlich, dass das Fehlen eines Hinweise Contao auf Dauer unsicherer macht, weil Sicherheitsupdates schlichtweg vergessen werden, weil der entsprechende Hinweis fehlt.
Providerwechsel. Das ist ja nun wirklich kein Hexenwerk, wenn die Servervoraussetzungen stimmen. Mach doch einfach mal einen Thread auf, dann wird Dir hier mit Sicherheit geholfen.
Gegenüber dem Kunden ist das dann wiederum eine Frage der Argumentation, auf die Du Dich vorbereiten kannst. Die Änderungen sind ja schlie0lich nicht deswegen da, um uns zu ärgern, sondern damit Contao für die Zukunft gut aufgestellt ist.
Im Augenblick nervt es zwar, dass Contao nicht überall reibungslos oder zum, Teil gar nicht läuft, aber hey, das gibt sich. Auch die anderen CMS Systeme werden bald vor dem Problem stehen, dass deren Systeme in der jetzigen Form ausgereist sind und sie nachlegen müssen. Überlege mal, wie umständlich es bis vor kurzem noch war, ein HTTPS- Zertifikat zu installieren. ;)
Vorab vielen Dank für deine Informationen!
Ich durchblicke das aber irgendwie nicht ..... :o
Dass das bei 1und1 laufen soll, habe ich bisher noch nicht entdecken können. Und zum laufen gebracht habe ich es bei 1und1 auch noch nicht fehlerfrei. AUch mit deiner "Anleitung" kann ich erstmal so nichts anfangen.... Wie soll ich eine bestehende Installation, die nicht lokal liegt, sondern auf einem anderen Entwicklungsserver, sauber zu 1und1 transferieren???Zitat:
Zitat von Stefko
Mein Ansatz war bisher, Contao per Manager auf 1und1 Server zu installieren (mit PHP 7 hat das auch geklappt), nur dann konnte ich die benötigten Erweiterungen nicht installieren und damit ist dann Theme importieren und Db einspielen hinfällig.
Ich habe leider absolut keine Möglichkeit per Konsole zu arbeiten, kann also die Installation nicht .tar.gz packen! Ich habe bisher auch noch kein PHP Script gefunden, was mir dies erledigt. Als .zip packen habe ich diverse Scripte gefunden, aber die helfen mir ja nicht weiter.Zitat:
Zitat von Stefko
Ich stehe einfach auf dem Schlauch, vielleicht blockiere ich innerlich auch, weil mich das echt ärgert .....
Vielen Dank für die äußerst konstruktive Antwort!Zitat:
Zitat von zonky
All meine Probleme und Sorgen haben sich damit quasi in Luft aufgelöst! Contao 4 ist einfach nur super! Alles läuft! ;)
Um die benötigten Erweierungen zu installieren, musst du lediglich die composer.json und composer.lock vom Entwicklungsserver auf den 1&1 Server transferieren. Danach kannst du sie entweder in der Konsole mit "composer install" oder im Manager (Systemwartung->Installer ausführen) installieren lassen. Da hier nur die Erweiterungen installiert werden müssen und die Abhängigkeiten nicht neu aufgelöst werden, reicht das RAM auch bei 1&1 normalerweise dicke.Zitat:
Zitat von ok99
Kein Konsolenzugang bei 1&1? Dann ist das aber entweder ein uraltes Paket oder ein "Starter" Paket ("Für überwiegend statische HTML-Seiten"). Oder geht es dabei gar nicht um 1&1?Zitat:
Zitat von ok99
Starter Paket hat auch SSH Zugang.
Ich kann mich da nur anschliessen, früher war alles so einfach - ein Klick und zack war die Webseite fertig. Ich konnte damit ohne Probleme leicht meinen Lebensunterhalt als Quereinsteiger bestreiten. Doch mit Contao 4 hat sich alles geändert. Seit dem kann ich nicht ...mimimi... und was mich total aufregt ist ...mimimi... Es ist nicht zu fassen, dass die Entwickler ...mimimi... und der Knopf für die fertige Webseite ist auch verschwunden.
Ich habe mich dann dazu entschlossen eine Ausbildung zum Informatiker zu absolvieren; habe mehrere Bücher gelesen und viel selber ausprobiert. Nun ja - ich muss sagen, es hat sich viel geändert. Ich verstehe jetzt das Konzept hinter Contao4 und finde die eingebrachten Ideen super und zukunftsorientiert. Nach dem ganzen Lernen fühle ich mich nun auch bei all meinen Projekten viel besser, da ich für meine Kompetenz diesmal tatsächlich bezahlt werde. Es reichte einfach für mich nicht mehr aus, zu wissen, dass "www.domain.tdl" eine Subdomain ist.
Du meinst also, ich kann Contao 4 auf dem 1und1 Server über den Contao Manager installieren (geht meines Wissens aber nur mit PHP 7, aber nicht mit PHP7.1..) , dann die beiden composer-Dateien per FTP überspielen und dann im Manager über die Systemwartung den Installer "Composer Abhängigkeiten" ausführen? Damit werden dann die Erweiterungen nachinstalliert ohne das es zum Fehler/Abbruch kommt?Zitat:
Zitat von tab
Verstehe ich das richtig? Das wäre ja ein Träumchen .....
Ich habe keine Konsole, auf dem Server, wo ich mein Contao-Projekt entwickelt habe. Deshalb kann ich das hier nicht .tar.gz'tten und auf 1und1 transferieren.Zitat:
Zitat von tab
Du kannst auch folgendes machen:Zitat:
Zitat von ok99
- composer.json & composer.lock auf den Server kopieren.
- Per SSH verbinden.
- wget https://getcomposer.org/download/1.6.4/composer.phar
- /usr/bin/php7.1-cli composer.phar install -o
- Templates, Dateien & sonstige selbst erzeugte Dateien auf den Server kopieren.
- DocumentRoot setzen.
- Contao Install Tool aufrufen.
Im Prinzip ja. Wie die Situation dazu gerade bei 1&1 ist, weiss ich nicht. Ich habe da keinen Webspace mehr. Und die PHP-Versionen müssen übereinstimmen, sonst müssen noch Einträge in der composer.json gemacht werden. Ist aber alles irgendwo hier im Forum beschrieben. Z.B. hierZitat:
Zitat von ok99
Das ist natürlich ganz schlecht. Aber nicht hoffnungslos. Schau dir mal die Erweiterung BackupDB an. Die liefert auf Wunsch ein Skript mit, mit dem beim Dateitransfer zerstörte SymLinks automatisch wieder hergestellt werden können. Allerdings würde ich den Server dann auch nicht unbedingt als Entwicklungsserver hernehmen und eher lokal entwickeln (z.B. XAMPP). Da hast du dann zwar unter Windows auch keinen funktionierenden Manager, aber einen prima funktionierenden composer in der Konsole.Zitat:
Zitat von ok99
Da dieser Vorschlag immer wieder gemacht wird, würde mich mal interessieren wie das überhaupt funktioniert?! Ohne Vorwissen würde ich jetzt versuchen (unter Windows) möglichst genau mit XAMPP die Konfiguration inkl. aller Dateien und der Datenbank vom Server lokal nachzubauen - und dann die Erweiterungen lokal installieren und die beiden Dateien hochladen. Doch wie ist es bei mehreren Webseiten mit unterschiedlichen PHP-Versionen? Wie kriege ich denn das gewuppt? Kann man denn XAMPP mit unterschiedlichen PHP-Versionen betreiben?Zitat:
Zitat von tab
Die PHP Version kannst du in der "platform" Definition unter "config" in der composer.json festlegen.
Kann man im Prinzip. Muss man aber nicht. Man muss nur in der composer.json die auf dem Server verwendete PHP-Version eintragen wie im Link beschrieben. Dazu sollte die PHP-Version nicht älter sein als die auf dem Server. Ob das Problem bei 1&1 mit neueren PHP-Versionen als 7.0 mittlerweile überhaupt noch besteht, wäre natürlich auch erst nochmals zu überprüfen. Ist ja doch schon einige Monate alt der Thread. Die neuesten PHP-Versionen bei 1&1 funktionieren meistens noch nicht einwandfrei, zumindest wenn sie noch als "experimentell" oder ähnliches gelistet sind bei der PHP-Versionsauswahl. Das dürfte ja aber mittlerweile für PHP 7.1 nicht mehr gelten. Ich kann es leider (oder zum Glück) nicht mehr nachprüfen.
Auch wenn die PHP Version, die du lokal verwendest, neuer ist als die auf dem Server, kann es zu Problemen komen. Angenonmmen du verwendest auf dem Server nur PHP 7.0, lokal aber PHP 7.2. Dann würdest du lokal alle Abhängigkeiten für PHP 7.2 installieren, was aber im Falle von doctrine bspw. dann zu einem Fehler auf dem Server führen wird.
Ich meine natürlich mit in de rcomposer.json eingetragener "Plattform". Die ersten beiden Sätze bezogen sich auf XAMPP mit mehreren PHP-Versionen. Das geht, aber es wird eben nicht benötigt, weil man ja den "platform" Eintrag jeweils passend für die einzelnen Installationen machen kann in der composer.json.
Das Thema mit den untersschiedlichen PHP-Versionen wurde ja bereits diskutiert.Zitat:
Zitat von Samson1964
Darüber hinaus müsstest Du lokal keinen Webserver und keien Datenbank betreiben -- also keine vollständige/lauffähige Contao-Installation. Du brauchst eigentlich nur die composer.json und PHP um eine aktualisierte composer.lock zu erzeugen.
Die composer.json und die composer.lock gehen dann auf den Server und dort führst Du ein composer install aus.
Die lokal heruntergeladenen Dateien im vendor Ordner könntest Du theroretisch wieder löschen. Sie sparen aber wahrscheinlich Traffic bei nicht aktualisierten Paketen, wenn Du das das nächste Mal wiederholst.
Sollte noch jemand am Mac lokal deployen und einen Tipp / Link haben, wie ich mehrere PHP-Version lokal verwalten kann: Her damit ;). Danke.
Hallo Thomas,Zitat:
Zitat von planepix
meinst Du lokal verschiedene PHP-Versionen betreiben oder von lokal deployen für verschiedene PHP-Versionen auf verschiedenen Servern?
Hallo Andreas,
lokal würde ich gerne die ~relevanten PHP-Versionen verwenden können ohne MAMP, Docker etc.. Ggf. macht das dann dennoch Sinn - ich würde mir eben einfach für das Update der composer.json und composer.lock - wie in eurem Blogpost vom Stammtisch beschrieben - je Projekt einen lokalen Ordner anlegen, dann via Konsole die PHP-Version passend zur Version, die online verwendet wird, aufrufen wollen und das Update ausführen.
In einem Test habe ich lokal hier die 7.1.2, auf dem Server die 7.0.25. Damit habe ich einmal ein Update ausgeführt und hatte - wenn wunderts - alle Verzeichnisse einer Contao-Installation lokal in dem Ordner; nicht nur den beschriebenen Vendor-Ordner.
Wenn ich es richtig verstanden habe, musst Du für das Auflösen für (z.B.) PHP 7.2 Anfordeungen (Server) lokal nicht PHP 7.2 haben sondern nur die "platform" im Abschnitt "config" passend -- also "7.2" -- eintragen (siehe #180).
Wenn ich es nicht richtig verstanden habe, wird mir sicher bald jemand widersprechen ;-)
Das macht ja aber nichts, die Ordner könntest Du ignorieren oder wieder löschen. Wichtig ist die so erzeugte composer.lockZitat:
In einem Test habe ich lokal hier die 7.1.2, auf dem Server die 7.0.25. Damit habe ich einmal ein Update ausgeführt und hatte - wenn wunderts - alle Verzeichnisse einer Contao-Installation lokal in dem Ordner; nicht nur den beschriebenen Vendor-Ordner.
Danke dir Andreas. Dann teste ich das so einmal. Und wir schauen wer ergänzt oder widerspricht :D
So Testlauf beendet.
Spannend:
Rufe ich online „php -v” auf, wird mit PHP 7.0.25 (cli) angezeigt.
Hoster ist allinkl.
IM KAS ist PHP 7.2.1 eingestellt; das ist ja „nur” die PHP-Version für Webanwendungen und ist nicht zwingend die gleiche Version wir die für den Aufruf via Konsole.
Habe nun in der composer.json ergänzt:
Und erhalte dann beim Testlauf mit „composer update --dry-run” folgende Ausgabe:Code:"config": {
"component-dir": "assets",
"platform": {"php": "7.0.25"}
Bedeutet?Code:Your requirements could not be resolved to an installable set of packages.
Problem 1
- ausi/contao-slug-backport v1.0.2 requires ausi/slug-generator ^1.0.1 -> satisfiable by ausi/slug-generator[v1.0.1].
- ausi/contao-slug-backport v1.0.3 requires ausi/slug-generator ^1.0.1 -> satisfiable by ausi/slug-generator[v1.0.1].
- ausi/contao-slug-backport v1.0.0 requires ausi/slug-generator ^1.0 -> satisfiable by ausi/slug-generator[v1.0.0, v1.0.1].
- ausi/contao-slug-backport v1.0.1 requires ausi/slug-generator ^1.0 -> satisfiable by ausi/slug-generator[v1.0.0, v1.0.1].
- ausi/slug-generator v1.0.1 requires php ^7.1 -> your PHP version (7.1.12) overridden by "config.platform.php" version (7.0.25) does not satisfy that requirement.
- ausi/slug-generator v1.0.0 requires php ^7.1 -> your PHP version (7.1.12) overridden by "config.platform.php" version (7.0.25) does not satisfy that requirement.
- Installation request for ausi/contao-slug-backport ^1.0 -> satisfiable by ausi/contao-slug-backport[v1.0.0, v1.0.1, v1.0.2, v1.0.3].
Entweder ist die PHP-Version online nicht richtig oder nur die Erweiterungen klappt online auch unter 7.0.25?
Bekommen wir auch noch raus :).
Siehe https://github.com/contao/contao-manager/wiki/All-Inkl
Wenn du PHP 7.2.1 eingestellt hast, musst duverwenden. Nicht einfach nurCode:/usr/bin/php72
Code:php
Danke Spooky.
Ok. ich frage mich woher ich diese Zeilen haben…
Ich habe eben in der lokalen composer.json die PHP-Version 7.1.0 eingestellt und erhalte in der Konsole dann:Code:php72 composer.phar update
.Code:Package operations: 145 installs, 0 updates, 0 removals
Keine extra Ordner - es wird :)
Es ist eigentlich schade, dass man nicht nur die neue composer.lock erzeugen kann, ohne irgendwelche Pakete herunterzuladen. Das wäre jetzt für Contao 4 eine ziemlich praktische Funktion. Habe aber leider nichts dergleichen gefunden. --dry-run ändert ja wohl gar nichts, also auch nicht die composer.lock :(.
Die Idee dahinter ist, das du im Testsystem, in dem du das composer update ausführst, sowieso erst einmal testest. Und dazu benötigst du den Vendor Ordner.Zitat:
Zitat von tab
(Der Usecase wie für Yannicks Cloud Resolver ist nur bei programmatischer Interaktion mit Composer möglich.)
@toflar hatte das mal vorgeschlagen, wurde aber abgelehnt bzw. nicht für sinnvoll erachtet: https://github.com/composer/composer/pull/4946
Tja, ich will ja unter anderem die Downloads auf mein lokales System minimieren. Testen werde ich dort mit Sicherheit nicht in jedem Fall, sondern meistens in einer extra für diesen Zweck angelegten Kopie auf dem selben Server wie das Live-System. Ich sehe keinen großen Sinn darin, das lokal auf einem Windows-Rechner zu machen, der von der Konfiguration her vom Zielserver eine ganze Ecke entfernt ist. Das würde nur Sinn machen, wenn ich etwas entwickeln würde und es debuggen müsste. Aber selbst dann würde ich wohl den finalen Test auf dem Zielserver machen. Aber gut, abgelehnt ist abgelehnt. Dann bleibt es halt beim Update auf meinem eigenen Webspace, werde dann halt eventuell bei mehreren Hostern jeweils ein geeignetes Paket brauchen, um möglichst nah am Zielsystem zu sein :(.
Und die Begründung ist ja auch durchaus nachzuvollziehen. Die Frage ist wie esoterisch der Usecase ist. :-)Zitat:
Zitat von tab
Der Download auf deinen 'Resolving'-Rechner wird aber vermutlich auch nicht der Bottleneck sein.
Naja, esoterisch,..., ich mag jetzt nicht Wikipedia dazu zitieren. Ich habe jetzt leider bei Unitymedia zwar schnelles Internet, aber nur wenn es gerade funktioniert. Und wie es der Zufall so will, gerade wenn man es dringend braucht, ist es weg. So geschehen bereits mehrfach wieder heute Morgen. Habe zwar in weiser Voraussicht immer einen Surfstick als Reserve, aber natürlich da kein unbegrenztes Datenvolumen. Sofern Unitymedia - wie im Moment - funktioniert, trage ich aber gern meinen Teil zur Überlastung des Internets bei, indem ich pro Kundeninstallation bei einem notwendigen Update (wie z.B. heute) jeweils mehrere hundert Pakete runterlade, die ich hinterher zu mindestens 99,9% unbenutzt wieder lösche. Zum Glück sind die meisten Installationen noch Contao 3, da kann ich mir den lokalen Zwischenschritt sowieso sparen.
Den abschliessenden Funktionstest irgendeiner Software NICHT auf dem Zielsystem (oder zumindest einem 100 %-igen Klon des Zielsystems) durchzuführen, halte ich zwar meinerseits nicht für esoterisch, aber für, sagen wir mal einfach blauäugig. Bei der Art von Software, die ich früher entwickelt habe, hätte ich eher das Wort "unverantwortlich" benutzt. Bei einer Website belasse ich es bei "blauäugig", da geht es ja schlimmstenfalls um materielle Werte. Soviel zum Thema Esoterik allgemein und zum Thema esoterischer Usecase im Besonderen.;)
Ich denke, Du lädst es nur einmal runter, beim zweiten Kunden sollte es aus dem Cache kommen. Das macht es zumindest etwas besser.Zitat:
Zitat von tab
M.E. geht es auch nicht darum mit einem lokalen Test zu "beweisen", daß es auch auf dem Server laufen wird. Das muss ich auf jeden Fall verifizieren. Aber wenn es lokal schon kracht, kann ich erst mal den Grund suchen und brauche auf dem Serber erst gar nicht mehr weiter zu machen.Zitat:
Den abschliessenden Funktionstest irgendeiner Software NICHT auf dem Zielsystem (oder zumindest einem 100 %-igen Klon des Zielsystems) durchzuführen, halte ich zwar meinerseits nicht für esoterisch, aber für, sagen wir mal einfach blauäugig.
Ist schon richtig, das Ganze ist jetzt auch nicht der Untergang der Welt. Natürlich kann ich damit leben, was bleibt mir auch anderes übrig, auch wenn mir die andere Lösung lieber gewesen wäre. An den Cache hatte ich noch gar nicht gedacht, das macht es in der Tat um einiges besser. Zur Not klone ich das Composer-Projekt, baue den Pull-Request von @Toflar ein und stelle es unter dem Namen esotericComposer zur Verfügung :D;).
Wenn denn in allen Fällen dieselbe PHP Version genutzt wird. Oder spielt das hier keine Rolle?Zitat:
Zitat von fiedsch
Das spielt keine Rolle.
Schau Dir mal die Erweiterung [BackupDB] an. Die bringt ein Script mit, mit dem Symlinks wieder hergestellt werden können. Ich habe das zwar selbst noch nicht getestet, aber es soll funktionieren.Zitat:
Zitat von ok99
https://github.com/do-while/contao-B...ontao-4.4-(DE)
Da ein Backup ohne erfolgreiche Wiederherstellung wertlos ist (Schrödingers Backup), möchte ich kurz meine Erfahrung teilen.
Ausgangslage: Ich habe Contao 4.4.x auf einem ubuntu Server 17.10 installiert. Auf diesem wird täglich per cron die Datenbank und die Dateien
- web/.htaccess
- templates/
- system/config/
- files/
- app/config
- composer.*
als .tar.gz gesichert. Das neue System ist ein ubuntu Server 18.04 (beta). Beide Maschinen sind virtuell und ich habe SSH-Zugriff.
Auf diesem System habe ich die notwendigen Pakete (PHP, MariaDB, Composer etc.) installiert.
Anschließend habe ich die Konfiguration das Apache vom alten, auf das neue System kopiert.
Dann in MariaDB den gleichen Benutzer angelegt, entsprechende Rechte vergeben und die DB aus dem SQL-Dump im neuen System eingespielt.
Darauf habe ich via composer die Version 4.4 von Contao installiert und die Dateien aus der Sicherung per
die oben angegebenen Dateien wiederhergestellt.Code:rsync -a backup/ /var/www/<contao>
Sowohl mv, als auch cp verweigern das Überschreiben der vorhandenen Dateien.
Anschließend mit composer die Installation aktualisieren lassen:
Dann auf der Installations-Webseite prüfen, ob auch alle Sym-Links korrekt erstellt wurden.Code:composer update --no-plugins --no-scripts --optimize-autoloader
Nun die Startseite aufrufen und Contao läuft auf dem neuen System.
Die Vorgehensweise setzt SSH-Zugriff voraus und etwas Erfahrung in der Shell, von daher sicher nicht unbedingt für jeden geeignet, aber vielleicht als Anhaltspunkt zum Ablauf brauchbar.
liebe community,
ich nutze contao 4.6.7 auf einem windows-system. der hoster (all-inkl.com) hostet meine seite vermutlich auf linux-servern. in meinem zugang habe ich keinen ssh-zugriff (gibt es erst bei doppelt so teuren paketen).
jetzt habe ich das bundle backupdb per contao-manager installiert (was problemlos geklappt hat) und als ich die datenbank sichern wollte, kam ein internal server error mit folgender meldung: "Error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 19338240 bytes)." was tun?, sprach zeus...
ich habe natürlich die option zur späteren reparatur der symlinks angehakt (weil das bei meinen bisherigen versuchen, sicherungen mittels ftp einzuspielen, genau der fehler war), aber er macht eben erst gar kein datenbank-backup.
ist das ein fehler, der aus irgendwelchen gründen nur bei mir auftaucht? oder ist der bekannt? gibt es abseits der sicherungsvariante mit backupdb mittlerweile noch einfachere methoden, backups nicht nur von der datenbank, sondern auch von den installationsdateien zu erstellen und wieder einzuspielen (ohne ssh-zugang)? wenn das backupdb-script funktionieren würde, könnte ich dann tatsächlich die installation mittels ftp sichern, wieder einspielen und die datenbank ebenfalls neu einspielen? würde das dann funktionieren / ausreichen?
vielen dank vorab für eure meinung...
grashalm
In der Version 4.6.7 gibt es einen Fehler bzgl. der Symlink Generierung. Du musst auf Contao 4.6.8 aktualisieren.
Das hat aber nichts mit dem Out of memory error zu tun. Poste die geamte Fehlermeldung.
hallo spooky,
das ist die komplette errormeldung, die im frontend unter der fetten überschrift "Internal Server Error" angezeigt wird:
Was ist das Problem?
Error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 19338240 bytes)
Bei welcher Operation genau?
// du hast nur 64 MiB RAM zur Verfügung. Das ist generell sehr wenig. Erhöhre den verfügbaren Arbeitsspeicher auf 128 MiB zB.
beim versuch, das mysql-backup von der funktion backupdb downzuloaden...
wo kann ich den arbeitsspeicher erhöhen? im backend unter einstellungen?
Nein, das ist eine Einstellung der Server Umgebung (also beim Hoster). Je nach Hosting geht das über verschiedene Art und Weisen (php.ini, .htaccess, Administrationssystem, etc.).