HILFE! Up-and Downgrade zu 2.11.5 - Backend zerschossen / FE tot

**HorseBadorties** · 06.04.2016, 18:33

Hallo,
ich bin gerade ziemlich verzweifelt... habe für einen Kunden ein Upgrade und dann wieder ein Downgrade seiner Seite vorgenommen. Leider funzte das alles nicht so, wie ich mir das vorgestellt habe.
Der Upgrade erfolgte mit LiveUpdate von 2.11.5 über die ganzen Zwischenschritte nach 3.5.9, allerdings kam da die Avisota Erweiterung nicht mit. Habe dann die DB Tabellen im BE gelöscht.... da war dann Feierabend. Das BE funzte noch, aber die Website war leer.
Also alles wieder zurück und das DB-BackUp wieder aufgespielt. Tja... und dann ging gar nichts mehr. Erst einmal sehen der Login und das BE so aus:
http://www.l-eye.de/diverses/contao_login_corrupt.jpg bzw. so: http://www.l-eye.de/diverses/contao_BE_corrupt.jpg

Bei der Website selber war zwischendurch nur die Startseite erreichbar... die Links zu den Unterseiten funktionierten zwar, aber die Seite wurde nicht dargestellt...

Zudem sind die Ladezeiten etwas - äh- lang.
Der Contapo-Check sagt, ich brauche den Safe Mode Hack, aber der ist in der /system/config/localconfig.php enthalten...

Bin gerade ziemlich ratlos... und brauche dringend Hilfe!
Danke schon mal im Voraus!!!

**BugBuster** · 06.04.2016, 18:46

Hast du nach dem Downgrade mal die install.php aufgerufen?
Sieht so aus als wenn der websitePath fehlt oder falsch ist. Der ist in der 3er Version in eine extra Datei gewandert.

Und, gibt es ein Backup auf Dateiebene?

Auch den Contao Cache löschen könnte helfen.

**HorseBadorties** · 06.04.2016, 19:06

Ja, die Install-Datei habe ich auch aufgerufen, die sieht genauso aus wie auf bei den anderen Screens.
Wie genau kann ich den Contao-Cache löschen? In /System finde ich da nichts.
Habe auch die Schreibrechte alle vergeben...

**BugBuster** · 06.04.2016, 20:00

Haste mal ein Link zum Frontend?

**HorseBadorties** · 06.04.2016, 20:41

www.owt.de bzw. www.owt.de/home.html
Aktuell wird man sofort zur Install-Seite weitergeleitet (ändere ich aber wieder zur "In Berarbeitung").
Habe nochmal rumprobiert und festgestellt, dass es an einer Erweiterung liegen muss... offenbar muss ich die dann wieder per Hand installieren... bin noch am Testen...

**Samson1964** · 06.04.2016, 20:45

Zitat von BugBuster

Und, gibt es ein Backup auf Dateiebene?

Offensichtlich nicht, sonst gäbe es ja keine Probleme. Bei einem so großem Update sollte man nie am Original schrauben. Oder von allem ein Backup haben.

**HorseBadorties** · 06.04.2016, 20:50

Doch gibt es!

**BugBuster** · 06.04.2016, 20:50

Die Generierung der CSS scheint wohl nicht zu funktionieren. ( in system/scripts/ )
z.B. hat http://www.owt.de/system/scripts/656607f3b420.css keinen Inhalt.

**BugBuster** · 06.04.2016, 20:53

Na wenn Backup da, warum nicht zurückspielen? DB + Files natürlich.

~~Ansonsten stimme ich Frank zu, es wäre einfacher gewesen glaube ich die Erweiterung passend für 3.5 zu machen.~~
(Falscher Thread)

**HorseBadorties** · 06.04.2016, 20:57

Zitat von BugBuster

Die Generierung der CSS scheint wohl nicht zu funktionieren. ( in system/scripts/ )
z.B. hat http://www.owt.de/system/scripts/656607f3b420.css keinen Inhalt.

Und was mache ich da (die Files sind ja alle soweit wieder hochgeladen)?

**BugBuster** · 06.04.2016, 21:00

Ursache suchen. Die werden ja generiert aus den internen CSS. Die müssen natürlich auch dort erstmal ankommen.
Wenn das alles lange dauert, ist das ein Hinweis darauf, das der safe-mode-hack (ftp) nicht funktioniert.
Hier nochmals prüfen ob der User zu den Eigentümer der Dateien und Verzeichnisse passt.

Besser wäre es, wenn der safe-mode-hack nicht mehr nötig ist.

Irgendwas in system/error.log ?

**HorseBadorties** · 06.04.2016, 21:05

Zitat von BugBuster

Ursache suchen. Die werden ja generiert aus den internen CSS. Die müssen natürlich auch dort erstmal ankommen.
Wenn das alles lange dauert, ist das ein Hinweis darauf, das der safe-mode-hack (ftp) nicht funktioniert.
Hier nochmals prüfen ob der User zu den Eigentümer der Dateien und Verzeichnisse passt.

Besser wäre es, wenn der safe-mode-hack nicht mehr nötig ist.

Irgendwas in system/error.log ?

Nee, im error.log steht nichts.
Was mich wundert, ist, dass der Check anmeckert, dass ich SMH brauche, obwohl ich ihn doch in der localconfig.php habe... (http://www.owt.de/check/) - oder ist das jetzt ein Denkfehler meinerseits?

**BugBuster** · 06.04.2016, 21:53

Der Check nutzt deine localconfig nicht, daher sagt er Dir völlig richtig, das du den benötigst.

**BugBuster** · 06.04.2016, 21:58

Also nochmal, haben die Verzeichnis den selben user wie in den ftp Daten eingetragen?
Prüfe das doch mal direkt, in dem du mit diesen ftp Daten dich anmeldest und versuchst im Verzeichnis system/script eine Datei zu übertragen.
Wenn das nicht geht, dann stimmt was nicht mit den Eigentümer und/oder Rechten der Verzeichnisse.

**HorseBadorties** · 07.04.2016, 07:03

Ins Scriptverzeichnis kann ich etwas hochladen. Habe es mal mit den alten Skripten gemacht und siehe da... es funzt wieder!
Zumindest, was das Aussehen des Backends angeht... äh, aber nur kurz! Ich habe zwar dem Verzeichnis zwar alle Rechte gegeben, aber es scheint in der Tat hier das Problem zu liegen...
Werde mich mal an den Provider wenden.

Um den Safe Mode Hack auszuschalten, reicht es dann, in der php.ini "safe_mode=On" zu schreiben bzw. eine höhere php-Version zu installieren (aktuell: 5.4.45)?

**HorseBadorties** · 07.04.2016, 08:41

Also, obwohl die Rechte vom Provider gesetzt wurden, diverse Male das install-Tool aufgerufen wurde, ist es nun so, dass die Skripte nicht in das Script-Verzeichnis geschrieben werden bzw die hochgeladenen nach Aufrufen einer Unterseite wieder gelöscht werden. Sehr seltsam, aber ich weiß nun leider nicht, was da zu tun ist...