Contao 4.4 in einer VM (LAMP)

**p-b** · 22.02.2018, 14:16

Hallo,

Auf meinem Webspace funktioniert das Update einer Contao-Installation (4.4) mit dem Contao-Manager nicht.

Gestern habe ich nun von meinem Webspace-Anbieter die Grenzen meines Webhosting-Pakets aufgezeigt bekommen. Hier im Forum habe ich gelesen, dass eine lokale Contao-Installation eine Lösung wäre. Wobei ich noch nicht genau weiß, was nach dem Kopieren auf den Webspace noch zu tun ist.

Frage: Es gibt ja verschiedene Möglichkeiten PHP auf einem Linux-Server einzusetzen. Ist es für die reine Funktionalität von Contao wesentlich, ob PHP als Apache-Modul oder als CGI installiert ist?

Danke für die Unterstützung

**Franko** · 22.02.2018, 14:56

Zitat von p-b

Hallo,
Frage: Es gibt ja verschiedene Möglichkeiten PHP auf einem Linux-Server einzusetzen. Ist es für die reine Funktionalität von Contao wesentlich, ob PHP als Apache-Modul oder als CGI installiert ist?
Danke für die Unterstützung

Hallo, für Contao 4.4.x findest Du die Systemvoraussetzungen hier bzw.
Contao 4.5.x hier

Bei meiner lokalen Windows/Xampp Umgebung (nur via composer - unter Windows geht der CM noch nicht - siehe hier) ging es sowohl mit PHP als Modul und/oder FastCGI ...

**Franko** · 22.02.2018, 15:01

Zitat von p-b

Hallo,
Auf meinem Webspace funktioniert das Update einer Contao-Installation (4.4) mit dem Contao-Manager nicht.

Eventuell hilft dann auch das - von lokal nach Production - via composer.lock - siehe hier

**p-b** · 25.03.2018, 13:14

Für die Virtualisierungsumgebung verwende ich KVM auf einer Debian (Stretch) Installation. In der VM verwende ich die aktuelle Debian Testing. Contao und der Contao-Manager sind installiert. Alles funktioniert problemlos.

Verständnisfrage:

Wenn ich im Contao-Backend Inhalte - z.B. Text - einfüge, dann erfolgt lediglich eine Änderung in der Datenbank. Füge ich außerdem Bilder ein, müssen diese dann einfach nur in die richtigen Verzeichnisse kopiert werden und im Backend eingefügt werden. Ist das richtig, oder werden innerhalb der Contao-Installation weitere Änderungen automatisch vorgenommen?

**tab** · 25.03.2018, 15:53

Für die meisten Zwecke ist es erforderlich, dass deine Bilddateien im Dateisystem mit der Datenbank synchronisiert werden. Entweder in der Dateiverwaltung im Backend oder auf andere Weise.

**p-b** · 26.03.2018, 14:12

Das Synchronisieren findet ja schon auf der lokalen Contao-Installation statt. Mir geht es um einen der nächsten Schritte. Wenn ich Bilder und z.B. Text auf der Webseite aktualisiert habe, benügt es dann die neuen Bilder und die aktualisierte Datenbank von der lokalen Contao-Installation auf den Webspace zu übertragen?

**tab** · 26.03.2018, 14:29

Ja, weil damit sowohl die Datenbank als auch die Dateien lokal und auf dem Webspace wieder identisch sind. Der Text ist in der Datenbank, ebenso die Info über die neuen Bilder und das gesamte Dateisystem unterhalb von /files. Spannend wird es nur, wenn du lokal irgendwelche Ordner für die neuen Bilder neu angelegt hast.

**p-b** · 26.03.2018, 15:49

Dann würde man auf dem Webspace die neuen Ordner erstellen ...

In der Datenbank steht für jedes Bild und für jeden Ordner ein Hashwert? Das hat zur Folge, dass die Hashwerte für die nachträglich auf dem Webspace erstellten Ordner nicht mehr passen?

Wenn das so ist ... nimmt man die neu erstellten Ordner von der lokalen Installation mit ...

**tab** · 26.03.2018, 16:12

Ich denke kritischer als die Hashwerte sind die UUIDs. Allerdings stehen die ja schon in der Datenbank. Insofern könnte man in der Tat die Ordner einfach hochkopieren. Aber eventuell notwendige neue SymLinks oder Ordner unterhalb von /web/files muss man auch irgendwie mitnehmen oder ansonsten auf dem Server neu anlegen oder generieren lassen. Eventuell kann der Contao-Manager oder das Installtool das, habe ich aber noch nie im Detail ausprobiert.

**folkfreund** · 27.03.2018, 11:03

Es ist natürlich immer interessant die Hintergründe zu verstehen.
Aber warum ein Update der DB, nur wegen der Synchronisation mit dem Dateisystem? Dafür gibt es ja die Funktion im Backend...

**tab** · 27.03.2018, 11:17

Wegen der UUIDs. Ich bin mir zwar nicht 100% sicher, aber ich glaube nicht, dass die selben UUIDs für die Dateien rauskommen wie lokal, wenn man die Dateien hochlädt und dort synchronisiert. Und falls tatsächlich dabei eine andere UUID erzeugt wird, dann sind alle Referenzen auf das Bild, die man lokal erzeugt hat, eben verloren.

**folkfreund** · 27.03.2018, 13:59

Wenn das so wäre (und dich richtig verstanden habe) dann würde ja ein Umzug mit import der DB auch nicht (mehr) funktionieren... Da habe ich bislang einen anderen Eindruck, kann es aber gerade nicht an einem konkreten Beispiel belegen.

**tab** · 27.03.2018, 14:08

Wiso sollte das nicht funktionieren? In der DB (tl_files) sind alle Dateien, Verzeichnisse und (u.a.) ihre vorher lokal erstellten UUIDs vorhanden. Diese UUIDs bleiben dann erhalten und werden nicht auf dem Server nochmal neu berechnet. Insofern passt alles mit den ebenfalls lokal erstellten Referenzen zusammen und auch zukünftig wird für neue Referenzen die in der DB hinterlegte UUID verwendet.

**tab** · 27.03.2018, 14:27

Nach nochmaligem überlegen denke ich, das Hochladen von neu erzeugten Ordnern und Dateien plus Einspielen der kompletten lokalen Datenbank auf dem Server gemäß #6 bzw #8 wird doch genügen. Man muss halt nur vermeiden, dass eine Synchronisierung des Dateisystems durchgeführt wird bevor die neuen Dateien und Ordner hochgeladen sind. Wenn sie bei der ersten Synchronisierung auf dem Server bereits vorhanden sind sollten sie erkannt und in Ruhe gelassen werden, da sie ja bereits inklusive ihrer lokal berechneten UUID in der Datenbank drinstehen. Nur wenn sie zu diesem Zeitpunkt noch nicht vorhanden wären, dann würden sie aus der DB gelöscht und erhielten dann später eine neue UUID, wenn sie hochkopiert und synchronisiert würden.

**folkfreund** · 27.03.2018, 19:51

Jetzt möchte ich doch noch etwas über die Hintergründe wissen.
Soweit ich es verstanden habe werden Dateien wiedererkannt, auch wenn man sie umbenennt. D.h. es wird irgendwo ein Hash gebildet oder so. Das heißt aber auch, dass die Dateien nicht völlig 'in Ruhe gelassen' werden können. Die UUID allerdings vielleicht doch, falls sie nicht genau der vermutete Hash ist...

Ich habe eine Seite, in der es etliche ziemlich große PDFs zum Download gibt, die sich mit großer Sicherheit nicht mehr ändern. Ich vermeide aktuell die Synchronisation, da dadurch die Seite für Minuten unerreichbar wird. Ich vermute, dass die Berechnung der Hashes alles lahm legt.
Für solche Fälle fände ich es super, wenn man die Synchronisation auf bestimmte Ordner einschränken könnte.

Kann mir jemand vielleicht Tipps geben?

**p-b** · 27.03.2018, 19:56

Zitat von tab

Nach nochmaligem überlegen denke ich, das Hochladen von neu erzeugten Ordnern und Dateien plus Einspielen der kompletten lokalen Datenbank auf dem Server gemäß #6 bzw #8 wird doch genügen. ... Wenn sie bei der ersten Synchronisierung auf dem Server bereits vorhanden sind sollten sie erkannt und in Ruhe gelassen werden, da sie ja bereits inklusive ihrer lokal berechneten UUID in der Datenbank drinstehen. ...

Ich habe das mal ausprobiert: Auf der lokalen Installation Text und Bilder eingefügt. UUID und Hashwert von den Bildern (die auf der lokalen Installation liegen) notiert. Die Bilder dann über FTP auch in die entsprechenden Ordner auf den Webspace kopiert. Die aktualisierte Datenbank über phpmyadmin importiert. Danach ... auf dem Webspace nochmals in der Dateiverwaltung synchronisiert. Und dann UUID und Hashwert verglichen. UUID war identisch und der Hashwert auch. (Wobei der Hashwert sowieso identisch sein sollte ... also jedenfalls wenn mit "Hashwert" das gemeint ist ... was ich als "Hashwert" kenne. Hatte ich wohl gestern einen Denkfehler)

**folkfreund** · 27.03.2018, 20:07

Und ich hatte wohl auch einen Denkfehler

Zumindest habe ich gerade gesehen, dass die URLs der 'Synchronisieren'-Aktion sich unterscheiden, je nachdem welcher Unterordner von /files gewählt wurde.
Jetzt muss ich noch ausprobieren, ob das Synchronisieren eines Unterordners mit wenigen Dateien tatsächlich schneller geht.

Edit:
Leider nicht

.
Ich hatte ausdrücklich einen Ordner gewählt, der nur 2 kleine Bilder enthält.

Synchronisieren legt die Seite (Backend und Frontend) für Minuten lahm:

An internal server error occurred. Please try again later.

**tab** · 27.03.2018, 20:15

Ja, die Hashes sind dafür da, verschobene und auch umbenannte Dateien wiederzufinden. Dabei ändert sich aber die UUID nicht, es wird nur der neue Pfad eingetragen, eben der unter dem die Datei gefunden wird. deswegen bleiben auch alle Referenzen auf so eine Datei gültig. Wenn allerdings ein Eintrag in der DB besteht und beim angegebenen Pfad auch die gleichnamige Datei steht, dann wird zwar der Hash neu berechnet, aber die UUID bleibt erhalten. Überschreibt man also eine Datei mit einer gleichnamigen, geänderten Datei, dann bleibt die UUUID und damit alle Referenzen erhalten, es wird also anstatt der alten Datei überall die neue benutzt.

Das klappt sogar ohne Synchronisierung. Wichtig für die Ausgabe ist ja der Pfad und nicht der Hash. Kann höchstens passieren, dass die alte Version angezeigt wird, weil sie im Server- oder Browsercache steckt. Nach so einem Umzug/Update wie beschrieben stehen die Dateien alle genau an der Stelle, die auch in der DB eingetragen ist. Deswegen passiert da bei einer Synchronisierung gar nichts, außer dass eben alles überprüft wird, was natürlich trotzdem auch eine langwierige Angelegenheit sein kann.

**folkfreund** · 28.03.2018, 11:39

Das hätte ich lieber nicht oben als 'Edit' eingefügt:

Ich hatte ausdrücklich einen Ordner gewählt, der nur 2 kleine Bilder enthält.

Synchronisieren legt die Seite (Backend und Frontend) für Minuten lahm:

An internal server error occurred. Please try again later.

Sieht aus, als würde immer der gesamte Bestand unter /files synchronisiert

**tab** · 28.03.2018, 11:51

Ja, es wird immer alles synchronisiert. Falls du Konsolenzugang hast und dort mehr Skriptlaufzeit, kannst du den Sync auch über die contao-console anstossen.

**folkfreund** · 28.03.2018, 17:26

Zitat von tab

Ja, es wird immer alles synchronisiert. Falls du Konsolenzugang hast und dort mehr Skriptlaufzeit, kannst du den Sync auch über die contao-console anstossen.

Vielen Dank - schade...
Ja, Konsolenzugang habe ich. Das Skript bricht aber nicht wegen zu langer Laufzeit ab, nur sind alle Aufrufe der Seite blockiert.
Ich muss gestehen, dass ich die contao-console noch nicht benutzt habe. Wo finde ich Infos dazu?

**Hoch-3** · 08.11.2018, 08:41

Zitat von folkfreund

....

... legt die Seite (Backend und Frontend) für Minuten lahm:

An internal server error occurred. Please try again later.

...(

In den Log-Files finde ich nichts...

Passieren tuts bei einem Crone-Job der Daten aus einer anderen DB holt. Und bei der Suche, aber da nicht jedes mal.

Weiss jemand, wo ich den Fehler suchen soll?

http://jurapark-aargau.ch und dann nach einem Begriff suchen. Spätestens beim dritten Suchaufruf kommt der Fehler.

Memory Limit und Max. Execution Time hab ich sehr hoch eingestellt ( 1 GB und 600 Sekunden).