Migration 4.8.11, Frontend weiß

[abaumg]

Hallo,

nachdem ich einen Nachmittag erfolglos in diesem Forum gestöbert habe, möchte ich mein Problem hier schildern. Ich versuche, ein Contenido 4.8.11 von Server auf den anderen zu migrieren - so weit, so gut.

Ausgangslage:
Alter Server:
PHP: 5.0.3-0.4 (Debian GNU/Linux)
MySQL: 4.0.24_Debian-10sarge3 / character set: latin1
phpMyAdmin: 2.11.9.6
Contenido: 4.8.11

Neuer Server:
PHP: 5.2.0-8+etch15
MySQL: 5.0.32-Debian_7etch11-log / character set database: latin1, character set results: utf8
phpMyAdmin: 2.11.9.6

Was ich unternommen habe:

• alle Dateien aus dem WWW-Root per FTP vom alten auf den neuen Server kopiert
• Ordner- und Dateizugriffsrechte richtiggestellt (CHMOD laut readme.txt)
• SQL-Dump mit phpMyAdmin gezogen
• alle Pfade und SQL-Zugangsdaten in contenido/includes/config.php geändert
• SQL-Dump in die neue Datenbank geladen
• Pfade unter Administration -> Mandanten geändert
• /cms/cache geleert
• Tabelle con_code geleert

Mein Problem:
Der Login ins Backend funktioniert einwandfrei, ich sehe alle Benutzer, Kategorien, Artikel aufgelistet etc. Wenn ich jedoch auf einen Artikel klicke ("Editor" und "Vorschau"), bleibt die Seite weiß.

Auch das Frontend bleibt komplett weiß, kein HTML-Code wird generiert. Nun ist es ja nicht so, dass ich der erste mit diesem Problem bin... aber anscheinend der erste mit dieser Konstellation. Nach meiner stundenlangen Lektüre hier bin ich der Meinung, eigentlich alles richtig gemacht zu haben - aber vielleicht habe ich auch ein Brett vor dem Kopf.

Könnt ihr mir vielleicht weiterhelfen?

Dankeschön und liebe Grüße,
Andreas

[Oldperl]

Hallo Andreas,

zuerst einmal willkommen im Contenido Forum.

Hast du es schon mal mit der Migration per Setup versucht?

Gruß aus Franken

Ortwin

[abaumg]

Hallo Oldperl,

das ging ja flott

Ja, Migration via Setup habe ich auch zweimal probiert - allerdings erst, nachdem ich die Pfade eh schon in der config.php geändert habe. Lief natürlich ohne Probleme durch.

Inzwischen habe ich noch probiert, die Dumps mit dem mySQLdumper zu erstellen und wieder zu laden, doch das hat nicht den gewünschten Erfolg gebracht. Also scheint es auch keine Sache der DB-Kodierung zu sein. Was könnte ich sonst noch unternehmen bzw. wie kann ich dem Problem auf die Spur kommen? Die /contenido/logs/errorlog.txt ist leer, und auf die error.log des Apachen habe ich keinen Zugriff :/

[Oldperl]

Hallo Andreas,

hast du das AMR-Plugin installiert?

Gruß aus Franken

Ortwin

[abaumg]

Nein.

[Oldperl]

Hmm, gibt es Einträge im Errorlog?

Gruß aus Franken

Ortwin

[abaumg]

Nein, das ist leer. Ich bin mit meinem Latein am Ende...

Das einzige, was ich nachher noch versuchen kann, ist, die Dateien nochmals zu übertragen. Oder sollte ich besser eine originale Neuinstallation von 4.8.11 machen, die Datenbank überschreiben und das Mandantenverzeichnis kopieren? Gehen dabei meine angepassten Module verloren?

[Oldperl]

Hallo Andreas,

also ich tippe nun einfach mal (Glaskugel bemüh), daß sich irgendwo beim DB-Dump/-Restore ein Fehler eingeschlichen hat, da ja offensichtlich nur Inhalte zur Frontenddarstellung betroffen sind. Das Backend geht ja laut deiner Aussage bis auf den Artikelbereich soweit.

Mein Vorschlag wäre mal ein anderes Tool als phpMyAdmin zu nehmen. Ich empfehle dort immer MySQLDumper, da dieser viel besser mit Dumps umgehen kann, vor Allem bei großen Dumps.

Leider kann ich dir da, ohne realen Zugriff, kaum eine weitere Hilfe sein.

Gruß aus Franken

Ortwin

[abaumg]

So, jetzt habe ich den (bzw. die) Schuldigen gefunden. Es lag weder an einer fehlerhaften Datenübertragung noch an einer falschen Zeichensatzkodierung. Schuld war dieser Code in der front_content.php:

Code: Alles auswählen

/*
 * local configuration
 */
if (file_exists("config.local.php"))
{
    @ include ("config.local.php");
}

Dieser verursachte einen Fatal error ("Cannot redeclare class InvalidArgumentException in /var/www/xxxxxxxx/cms/config.local.php on line 8"), der jedoch durch das @ abgefangen bzw. einfach verschluckt wurde (ganz schlechter Programmierstil IMHO, sowas muss "ordentlich" abgefangen werden).

Ich weiß nicht, ob der Fehler nur bei mir auftrat bzw. ob der Code geändert werden sollte, vielleicht kannst du das beurteilen. Ich bin jedenfalls erleichtert, dass der Fehler behoben wurde und ich mit der Migration fortfahren kann.

Liebe Grüße,
Andreas

[Oldperl]

Hallo Andreas,

nun, schlechter Programmierstil würde ich so nicht sagen, denn das Unterdrücken von Fehlermeldungen mit Hilfe des Klammeraffen wurde sogar in anerkannten Fachbüchern immer wieder angewandt. Generell stimme ich dir aber zu, daß man heutzutage in anderer Weise mit der Fehlerbehandlung umgehen sollte.

Wobei ich aber stutzte, als ich diese las

"Cannot redeclare class InvalidArgumentException in /var/www/xxxxxxxx/cms/config.local.php on line 8"

da es mir hier so aussieht, als wenn in einer config-Datei eine Klassendeklaration vorgenommen würde, was ich dann unter

ganz schlechter Programmierstil

einordnen würde. Ich denke das hier ein Zusammentreffen ungünstiger Umstände zu deinem Fehlerbild geführt haben, wobei ich das Klammeraffenproblem im Auge behalten werde für eine der nächsten Releases.

Gruß aus Franken

Ortwin