Umlauteproblem nach Migration

[Banduron]

Hi,

Ich habe ein Conpresso umgezogen. Nun habe ich keine Umlaute mehr und Teile der Seite werden nicht angezeigt. =8-0

Das alte System hatte die Version 4.1.2, die DB war MySQL 5.0.67. Das neue System hat eine DB MySQL 5.5.39. Die Conpresso-Version scheint bei den Symptomen keine Rolle zu spielen.

Mein erster Versuch war das Conpresso-Verzeichnis zu kopieren und die DB mittels SQL-Dump und einzuspielen (mysqladmin -u root -p .... < cpo-dump.sql) des Dumps in die neue DB. Datenbankname, DB-User und Pwd sind gleich geblieben. Der Conpresso DB-User hat immer alle Rechte auf die DB.

Anschließend habe ich statt Umlauten überall Sonderzeichen (möglicher statt möglicher; GerÀte statt Geräte) sowohl in den statischen Teilen der Seite als auch in den dynamischen Teilen.

Zudem fehlen bei allen Rubriken die globalen und lokalen Header ebenso wie die Footer. Stattdessne erscheint:
This is the global header of ConPresso (_cfg/global_header.php). It is displayed first on all dynamically generated pages.
This is the local header of ConPresso (_rubric/_local_header.php). It is displayed after the global header and is followed by the dynamically generated content.
Ähnliches gilt für die Footer.

Mein zweiter Versuch war statt der kopierten 4.1.2 die Version 4.1.6 zu nehmen (einfach drüberkopiert) und statt des normalen SQL-Dumps den Export aus Conpresso zu nutzen und ihn in die neue Version zu importieren. Vorher haben ich die DB neu erstellt.
Hier war das Ergebnis das die Beiträge nur bis zum ersten Umlaut angezeigt werden(!). Danach ist der Artikel zu Ende! Das Symptom bei den Headern ist hierbei gleich.

Wo kann ich anfangen zu suchen? // Welche Infos brauchen die Gurus noch?

Hmm, ich kann noch was ergänzen ...

Wenn ich den Browser in der Ansicht auf UTF-8 stelle wird die Seite korrekt dargestellt. allerdings steht bei Contenttype: text/html; charset=iso-8859-15
Das wird wohl ein Teil des Problems sein. ISO-8859-15 oder iso-8859-15 steht aber in über 70 Dateien Es wir wohl nicht der Weg sien die alle zu ändern, oder? Damit würde ich ja recht massiv im Code rumpfuschen. Das muss doch anders gehen.

OK, nach dem ich nun character-set und collate auf latin1 und latin1_swedish_ci stehen habe werden die Umlaute alle als ? (Fragezeichen) angezeigt. Und zwar kommen die so schon im html-Quelltext an. Der Browser ist da mal ziemlich sicher nicht involviert.

Im Dump der DB stehen die Umlaute auch richtig drin. Hm, darin werden die Tabellen auch alle mit DEFAULT CHARSET=latin1 angelegt. In sofern hätte das doch auch bei einer DB ohne explizites angeben von character-set und collate klappen müssen?!

Wer verdreht also die Umlaute?

[MarkusR]

Ach herrje, wenn ich jetzt doch nur mehr Zeit hätte...

Aber zuerst: Was steht denn nun in _cfg/global_header.php drin?
Hast Du denn bisher Header und Footer oder Seitentemplates benutzt?

Das Umlautproblem wird wohl (wie in einem der letzten Threads) an der vom Apache gesendeten Codierung liegen. ConPresso sendet grundsätzlich kein UTF8 sondern eben ISO. Wenn der Apache jetzt immer UTF8 als Header vorrausschickt, dann muss der Browser Probleme bekommen. Suche mal nach einem der letzten Threads, da wurde mit einer Header()-Angabe für eine korrekte Ausgabe gesorgt, besser wäre es natürlich den Apache auch auf ISO senden zu lassen, aber wenn Du das beeinflussen könntest, dann würdest Du vermutlich gar nicht hier fragen.

[Banduron]

Aber zuerst: Was steht denn nun in _cfg/global_header.php drin?

Diese Dateien gibt es weder im Quell- noch im Zielsystem.

Das Umlautproblem wird wohl (wie in einem der letzten Threads) an der vom Apache gesendeten Codierung liegen. ConPresso sendet grundsätzlich kein UTF8 sondern eben ISO. Wenn der Apache jetzt immer UTF8 als Header vorrausschickt, dann muss der Browser Probleme bekommen. Suche mal nach einem der letzten Threads, da wurde mit einer Header()-Angabe für eine korrekte Ausgabe gesorgt, besser wäre es natürlich den Apache auch auf ISO senden zu lassen, aber wenn Du das beeinflussen könntest, dann würdest Du vermutlich gar nicht hier fragen.

Nochmal der Reihe nach:
*Quellsystem ist problemlos;
*MySQL-Dump mittels mysqldump -u user -ppwd db > db.sql

(Hier habe ich auch den Ex-& Import via --tab oder --xml versucht. Ebenso erfolglos ...)

In der db.sql sind die Umlaute korrekt. (Zumindest wenn man sie mit einem System anschaut was mit UTF-8 läuft. Kann hier was beim Export passieren? Wenn der mysqldump-Befehl von einer Konsole abgesetzt wird die UFT-8 eingestellt hat?)
Antwort: Nein, auch ein mysqldump mit --skip-charset kommt zum gleichen Ergebnis.

*Copy der CPO-Dateien an die gleichen Stellen wie beim Quellsystem.
*Erstellen der leeren DB: CREATE DATABASE db CHARACTER SET latin1 COLLATE latin1_swedish_ci
*GRANT ALL PRIVILEGES & FLUSH PRIVILEGES
*Import der Daten mit: mysql -u user -p pwd < db.sql

Danach kommt die Seite mit:

Code: Alles auswählen

<?xml version="1.0" encoding="iso-8859-15" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15" />
    <meta http-equiv="imagetoolbar" content="no" />

an. Sie enthält aber UTF-8 Umlaute!

Der Browser sieht den charset eintrag im html header und nimmt an das es iso-8859-15 ist. So werden die Umlaute falsch dargestellt. (Stelle ich den Browser manuell auf iso-8859-15 werden die Umlaute richtig dargestellt.)

Die Umlaute werden schon im Seitenquelltext falsch angezeigt:

Code: Alles auswählen

<div style="background: url(../images/bg_navi_top.gif) no-repeat; height: 49px;"><div class="navi2"><ul><li><a href="http://www.example.de/_rubric/index.php?rubric=DE+Ueber-uns">Ãœber uns</a>

(SNIP)
Der Ex- & Import der Daten aus Conpresso heraus. (System / Export- Import) als XML führt übrigens dazu, dass -unabhängig von der Codierung- alle Umlaute als ? (Fragezeichen) dargestellt werden. Dann werden allerdings die Rubriken korrekt dargestellt.
(/SNIP)

Das lässt mich vermuten das irgendwas in der DB zermüllt ist, da ja offenbar auch Teile die für Conpresso selber nötig sind nicht mehr gefunden werden.

[MarkusR]

Wenn ich den Browser in der Ansicht auf UTF-8 stelle wird die Seite korrekt dargestellt

Stelle ich den Browser manuell auf iso-8859-15 werden die Umlaute richtig dargestellt.

Das will mir jetzt nicht einleuchten...

Nochmal die Frage: Benutzt Du Header und Footer oder Seitentemplates?

Wenn es _cfg/global_header.php nicht gibt, gibt es denn die serienmäßige _cfg/global_header.php.dist?

Da die meisten Export- und Import-Funktionen bei Systemwechseln versagen habe ich mod_backup so gebaut, dass es zwar wenige Optionen hat, aber eben auch mit wechselnden Zeichensätzen zurechtkommt, wobei phpmyadmin beim Setzen der richtigen Optionen auch funktioniert, nur eben mit großen Dumps ebenfalls scheitert.

Vielleicht sollte sich das jemand anschauen, der solche Umzüge schon mal gemacht hat.
Du scheinst ja in der glücklichen Lage zu sein noch auf das ursprüngliche System zugreifen zu können. Die meisten kommen ja erst wenn gar nichts mehr geht...

Ich gehe davon aus, dass schlichtweg beim SQL-Transport irgendwas mit der Codierung nicht stimmt. War gerade auf einer Seite eines Ex-Kunden, der auch meinte einen "Fachmann" seine Seite portieren zu lassen. Da sind beim Transfer auch alle Umlaute flöten gegangen. Aber statt den Transfer nochmal korrekt durchzuführen hat dann jemand von Hand die Umlaute umgeschrieben, aber leider nicht überall (es werden z.B. die Platzhalternamen binär transferiert, da hilft dann auch keine Kodierungsangabe... es sei denn man hat beim Export bereits angegeben Binärdaten als ASCII zu exportieren, also das entsprechende Häkchen in phpmyadmin gesetzt. Ob mysqldump da auch einen Parameter besitzt weiß ich nicht...)

Falls Du bisher Seitentemplates benutzt haben solltest, dann könnte durch einen fehlerhaften Transfer das Seitentemplate beschädigt sein und daher wird auf Header und Footer zurückgegriffen, die aber eben nie benutzt wurden und daher der Fallback auf die .dist-Dateien stattfindet.
Dass der Transfer fehlerhaft war zeigen ja die fehlenden Umlaute.
Vermutlich liegt bei Dir das Problem in der im Zielsystem geänderten Kommunikation PHP zu mySQL. Durch Nutzung von mysqldump hast Du diese Kommunikation ja einfach umgangen und mögliche Konvertierungen verloren.

[Banduron]

Wenn ich den Browser in der Ansicht auf UTF-8 stelle wird die Seite korrekt dargestellt

Stelle ich den Browser manuell auf iso-8859-15 werden die Umlaute richtig dargestellt.

Das will mir jetzt nicht einleuchten...

Nochmal die Frage: Benutzt Du Header und Footer oder Seitentemplates?

Wohl Seitentemplates, da es Header- und Footer-Dateien nicht gibt. (Ich habe die ursprüngliche Seite nicht gemacht

Wenn es _cfg/global_header.php nicht gibt, gibt es denn die serienmäßige _cfg/global_header.php.dist?

Ja, klar die sind vorhanden. Sie werden ja auch angezeigt.

Du scheinst ja in der glücklichen Lage zu sein noch auf das ursprüngliche System zugreifen zu können. Die meisten kommen ja erst wenn gar nichts mehr geht...

Gebranntes Kind

Ich gehe davon aus, dass schlichtweg beim SQL-Transport irgendwas mit der Codierung nicht stimmt. (...)
es werden z.B. die Platzhalternamen binär transferiert, da hilft dann auch keine Kodierungsangabe... es sei denn man hat beim Export bereits angegeben Binärdaten als ASCII zu exportieren, also das entsprechende Häkchen in phpmyadmin gesetzt. Ob mysqldump da auch einen Parameter besitzt weiß ich nicht...)

'So etwas ahnte ich, deswegen habe ich vom ändern der DB-Inhalte abgesehen ....

Falls Du bisher Seitentemplates benutzt haben solltest, dann könnte durch einen fehlerhaften Transfer das Seitentemplate beschädigt sein und daher wird auf Header und Footer zurückgegriffen, die aber eben nie benutzt wurden und daher der Fallback auf die .dist-Dateien stattfindet.

Das ist auch meine Vermutung.

Dass der Transfer fehlerhaft war zeigen ja die fehlenden Umlaute.
Vermutlich liegt bei Dir das Problem in der im Zielsystem geänderten Kommunikation PHP zu mySQL. Durch Nutzung von mysqldump hast Du diese Kommunikation ja einfach umgangen und mögliche Konvertierungen verloren.

Sehr gut möglich, es ist ja eine Migration auf ein moderneres System mit aktuelleren PHP, MySQL, etc. (Nur phpmyadmin ist eben nicht vorhanden

Aber es ist eben auch so das das XML-Backup die Umlaute nicht sauber rüberbringt ... nach dem Import der Datei funktionieren zwar die Seiten-Templates aber die Umlaute werden alle als ? (Fragezeichen) dargestellt. Das habe ich schon öfters im Zusammenhang mit XML und Umlauten gesehen.

Und auch der Ex- & Import das DB via Tabulator separierter Dump-Dateien, gibt das gleiche Ergebnis. Wobei hier der Dump auch gut (= mit korrekten Umlauten) aussieht.

Die alten Einstellungen der DB habe ich mittlerweile alle übernommen, auch wenn gerade die Charset-Einstellungen immer mit im Dump stehen.

Im Moment bin ich etwas ratlos ... habe aber im Moment noch andere Baustellen.

Gut das diese Migration nur eine mittlere Prio. hat ...

Ich werde nochmal in das Thema MySQL Charset, Collate, etc. einsteigen müssen.

Wenn hier noch Ideen vorhanden sind, sind die gerne gelesen.

[Mr. Magpie]

Markus meinte den folgenden Beitrag: http://community.conpresso.de/viewtopic.php?t=4665 wg. PHP 5.6 und der verbuxelten Umlaute

[MarkusR]

Mein Vorschlag ist:
Benutze phpmyadmin (schnell mal installiert) und setze die korrekten Parameter.
Oder benutze mod_backup.
Oder lass jemanden drübergucken, der das schon mal gemacht hat. Ist nämlich wirklich simpel.