CONTENIDO Forum

Liebe Contenido-Gemeinde,

ich habe heute schon mehrere Stunden an einer (manuellen) Contenido 4.6.8-Migration (Entwicklungssystem > Server) gesessen.
Mein (hoffentlich letztes) Problem mit Contenido auf dem Zielsystem ist derzeit noch, dass ich eine leere HTML-Seite zurückgeliefert bekommen, im Backend ist alles soweit okay.

Ich weiss: Das Problem wurde hier schon x-TAUSEND mal besprochen, und ich dachte nicht, dass ich abermals einen entspr. Topic anstossen würde - nach nun doch schon einiges von mir durchgeführten Migrationen und Installationen - aber ich habe nun wirklich schon einiges versucht:

- Pfade in config.php und Mandanten-Datensatz angepasst (natürlich als Teil der Migration)
- Tabelle con_code geleert
- Verzeichnisrechte für cms/logs, contenido/logs und contenido/cronjobs gesetzt (unter Win2003/IIS auf "Vollzugriff" - danach konnte ich bspw. das Error-log auch mal löschen)
- debug-code-ausgabe in config.misc.php eingeschaltet

Bringt alles nix - das Frontend bleibt hartneckig leer. Im übrigen finde ich auch in der errorlog keine anhaltspunkt, die bleibt nämlich auch leer.
Inzwischen hab ich sogar testweise auf cms und contenido Vollzugriff gewährt, um ein Verzeichnis-Rechte-Problem auszuschliessen.

Ich *wette* förmlich drauf, dass ich nur eine Kleinigkeit vergessen habe, die vermutlich schonmal hier erwähnt wurde, aber ich finde im Forum (und FAQ) einfach keine zusätzlichen auf meine Situation passenden Infos.

Aber vielleicht kann mir ja auf diesem Weg ein versierter Contenido-Spezialist sagen, woran der Fehler typischer noch liegen könnte, oder alternativ, wie ich front_content zu irgendeiner Fehlerausgabe motivieren kann - denn nicht nur die seite bleibt leer, sondern auch in der errorlog gibt es keine einträge.

vielen vielen Dank im Voraus!

Grüße,

Daniel

komisch komisch

kannst du mal in stichpunkten abreissen was und wie du migriert hast

ich persönlich verkürze immer auf

quelle:
db dump erstelle
verzeichnisse packen

ziel:
leere db erstellen
verzeichnisse per ftp uppen, entpacken, rechte setzen, pfade und db parameter anpassen in der config
quell-db-dump auf dem zielserver einspielen

backend aufrufen und checken ob die mandantenpfade auch passen

frontend testen

standard wäre erst ne installation auf dem zielserver machen, dann per ftp nochmal alles überschrieben, db dump einspielen und erneut das setup mit migration aufrufen

nachtrag:

ne einfache manuelle index.html kannste schon aufrufen?
Mod rewrite?
wie sieht die url der blankpage aus?

richtig, diese von Dir erwähnten manuellen Migrations-Schritte habe ich vorgenommen.

mvf hat geschrieben:nachtrag:
ne einfache manuelle index.html kannste schon aufrufen?
Mod rewrite?
wie sieht die url der blankpage aus?

statische Dateien klappen problemlos (auch im CMS-Verz),
das Backend im selben Webspace läfut ja auch tadellos.

Okay, hab die Ursache gefunden, durch "Steinzeit-Debugging" (stückweises auskommentieren/Marker-Ausgabe) der front_content.php:

In der Pseudo-Crons-Include-Datei wurde ein "cannot redeclare" - Fehler geworfen (hab den genauen Wortlaut nicht parat) - kann mir den Fehler nicht erklären, hab mich aber auch nicht länger damit aufgehalten, sondern einfach die von mir nicht benötigten Pseudocrons in der config.misc.php deaktiviert.

Damit wärst Du der Erste, der mit diesen Funktionen und der Fehlermeldung ein Problem hat.

Das mag zwar jetzt zunächst das Problem gelöst haben, aber die Ursache war das nicht.

Sind denn das cronjobs-Verzeichnis und die Dateien darin schreibbar?

Gruß
HerrB

Hallo

Hatte soeben das gleiche Problem und suchte lange:

Die Ursache war denkbar einfach: In der front_content.php wird die config.local.php per @ includert.

Ich hatte dort lokal eine Funktionalität verwendet, die offenbar auf den Hosting-Server nicht verfügbar war. Die Feherausgabe wurde natürlich so unterdrückt und das Skript ohne jegliche Fehlerausgabe unterbrochen.