1. Herzlich willkommen bei WPDE.org, dem grössten und ältesten deutschsprachigen Community-Forum rund um das Thema WordPress. Du musst angemeldet oder registriert sein, um Beiträge verfassen zu können.
    Information ausblenden

Spezielle Umlautprobleme nach Serverupdate

Dieses Thema im Forum "Installation" wurde erstellt von Loewenherz, 15. April 2010.

  1. Loewenherz

    Loewenherz Well-Known Member

    Registriert seit:
    23. März 2005
    Beiträge:
    123
    Zustimmungen:
    0
    Hallo,
    Umlautprobleme nach einem Serverwechsel sind nichts ungewöhnliches. Aber diesmal ist mein Problem spezieller als sonst, deshalb dieser neue Threat.

    Die bisherigen Probleme und Lösungsstrategien habe ich hier beschrieben: http://www.meinhosting.de/wordpress/umlautproblem-nach-serverumzug-in-wordpress-beheben-73.html

    Diesmal war dasselbe: Ein WP-Blog mit 2.8.6, wo das Update auf 2.9.2 nicht möglich war aufgrund des alten Servers. Also Serverwechsel bei all-inkl.de mit Update der MySQl-Datenbank von 4 auf 5. Danach das übliche Umlautproblem.

    Hier war Wordpress teilweise außerstande, im Backend beim Bearbeiten die Titel anzuzeigen, Tags waren verschwunden etc. Das in oben genanntem Artikel beschriebene Procedere funktionierte ausnahmsweise nicht. Die zu ersetzenden Zeichen wurden nicht gefunden. Nachdem ich in den Einstellungen von UTF8 zu ISO8859-1 gewechselt bin, war der Content korrekt, aber seitdem werden die ganzen Sprachdateien etc. verstümmelt. Also wieder zurück.

    all-inkl.de schrieb:
    >wenn wir die Sicherung einspielen, sind nur ein Teil der Inhalte mit
    >Umlaute hinterlegt, was aber auch eher unüblich ist, wenn alles aus
    >der DB geladen wird, sofern es nicht dadrin falsch steht.

    Meine Antwort:
    Das einzige, was ich in Wordpress getan hatte, war unter
    http://www.sozial-wissenschaft.de/wp-admin/options-reading.php also
    Einstellungen > Lesen > "Zeichensatz für Seiten und Feeds" von UTF-8
    auf ISO umzustellen. Auch das erst nach dem Serverwechsel, dem Update
    von 2.8.6 auf 2.9.2 und der Unmöglichkeit, die Fehler direkt durch
    Suchen/Ersetzen in phpMyAdmin zu beseitigen. Zumal eben auch so
    seltsame Phänomene auftauchen, dass beispielsweise die Titel der
    Artikel m Edit-Modus verschwinden. Während die Seite im Frontend noch
    passabel aussieht, ist es im Backend gruselig.

    Die Seite ist jetzt seit Januar 2007 in dieser Form im Netz und
    durchgehend bei all-inkl. Dabei gab es nur die üblichen
    Wordpress-Updates. Von den vielen Blogs, die ich bei all-inkl.de
    betreibe - oft mit denselben Einstellungen und Plugins - ist es das
    Einzige, dass beim Serverwechsel neben den üblichen Phänomenen
    (Umlaute, wpSEO weg) zusätzlich zickt. Erklärungen habe ich keine.
    Die einzig wirklich spezielle Sache, die ich bei diesem Blog gemacht
    habe, ist hier dokumentiert:
    http://www.meinhosting.de/wordpress/wordpress-howto-umwandeln-von-seiten-in-artikel-34.html - ob das einen Einfluss hatte?

    Letzte Antwort des Support:
    wir haben hierzu erstmal keine Lösung, da auch ein Teil der Webseiten mit Umlauten richtig angezeigt wird. Es wird womöglich durch das alte MySQL 4.0 in der DB so sein, dass Umlaute im Klartext drin stehen und andere wieder nicht, was aber die aktuellere MySQL Version nicht anders auslesen kann.

    Hat jemand von euch eine Idee? Die betroffene Seite ist http://www.sozial-wissenschaft.de/ - und wie gesagt: Das Umlautproblem ist von außen nur teilweise erkennbar (bei mir im Firefox an und an rechteckige Klötzchen an Stelle von Umlauten), und spielt sich vor allem im Backend ab.
     
  2. Ammaletu

    Ammaletu Well-Known Member
    Ehrenmitglied

    Registriert seit:
    14. Juli 2007
    Beiträge:
    4.696
    Zustimmungen:
    0
    Also wenn ich mir das so von außen anschaue, sieht es doch alles korrekt aus. Die Seite wird als UTF-8 dargestellt und alle Umlaute stimmen. Was kaputt ist, sind die Anführungszeichen, allerdings sollten die nicht in der DB stehen sondern bei der Anzeige per Filter ergänzt werden. Im Editor im Backend müsste das also richtig als die normalen, geraden Anführungszeichen angezeigt werden. Hier müsstest Du vielleicht mal schauen, welche WP-Datei diese Ersetzung vornimmt (Funktion texturize?!) und ob diese Datei eventuell falsch abgespeichert ist (ISO statt UTF-8).

    Alternativ könntest Du auch probieren, ob ein Plugin wie InTypo oder WP-Typography eine Verbesserung bringt.

    Und generell wann immer möglich mit UTF-8 arbeiten statt ISO, das spart auf lange Sicht viel Ärger. Also auch nicht jetzt auf ISO zurückstellen, dann lieber das zugrundeliegende Problem lösen. ;)
     
    #2 Ammaletu, 15. April 2010
    Zuletzt bearbeitet: 15. April 2010
  3. Loewenherz

    Loewenherz Well-Known Member

    Registriert seit:
    23. März 2005
    Beiträge:
    123
    Zustimmungen:
    0
    Hey, danke für die Antwort.
    Genau das hab ich vor :)

    Wie gesagt: Im Frontend sieht es noch ganz annehmbar aus. Am gruseligsten sind die Autorenseiten wie http://www.sozial-wissenschaft.de/author/andreasmueller/ oder die Tags. Da sind die Umlaute komplett zerschossen.

    Richtig übel sieht es im Backend aus. Bei allen Artikeln, wo Umlaute im Titel sind, bleibt der Titel im Edit-Modus komplett leer. Nix, nada. Dito die Tags. Ich hab keine Idee, wo ich da ansetzen könnte, da die Zeilen, die ich für automatisches Suchen/ersetzen via phpMyAdmin nutzen wollte, überhaupt nicht greifen.
     
  4. Ammaletu

    Ammaletu Well-Known Member
    Ehrenmitglied

    Registriert seit:
    14. Juli 2007
    Beiträge:
    4.696
    Zustimmungen:
    0
    Interessant, die Autoreninfos werden offenbar als ISO-Zeichen im UTF-8-Text ausgegeben. Tja, wo setzt man da an? Zuerst mal schauen, dass die Datenbank aktuell auf jeden Fall UTF-8 ist und das auch so ausgelesen wird (wp-config.php). Dann vielleicht mal einen aktuellen Dump ziehen und die Zeichen darin reparieren? Zum Beispiel mal nach "Andreas M" suchen und schauen, was da für ein Zeichen statt des "ü" steht. Damit dann Suchen und Ersetzen im ganzen DB-Dump. Den Dump am Ende wieder in die DB einspielen. Und bei all dem natürlich Backups von allen Schritten aufheben bis das ganze behoben ist.
     
  5. Loewenherz

    Loewenherz Well-Known Member

    Registriert seit:
    23. März 2005
    Beiträge:
    123
    Zustimmungen:
    0
    Ein Blick in phpMyAdmin zeigt, dass "Kollation" auf latin1_swedish_ci steht. WP steht aber auf UTF8

    Ein Dump mit MySQLDumper als UTF-8, geöffnet mit Notepad++ zeigt keinen einzigen Umlaut-Fehler beim Test mit jenem Autorennamen...
     
  6. spickzettel

    spickzettel Well-Known Member

    Registriert seit:
    19. Januar 2006
    Beiträge:
    1.848
    Zustimmungen:
    0
  7. Loewenherz

    Loewenherz Well-Known Member

    Registriert seit:
    23. März 2005
    Beiträge:
    123
    Zustimmungen:
    0
    Mal grade mit dem all-inkl Support telefoniert. Er meinte, dass mit der Datenbank alles stimmt und die Bezeichnung unter Kollation kein Problem darstellen würde.

    Seiner Meinung nach arbeitet das Ganze mit zwei verschiedenen Charsets. Die Inhalte wären in UTF, irgendwas würde aber ISO erzwingen (oder umgekehrt). Als Beispiel habe ich im Firefox unter Ansicht > Zeichenkodierung geschaut, da stand UTF. Hab dann auf ISO Westlich (erster Eintrag) umgestellt und schwupps, stimmte alles. Außer Google AdSense, da waren plötzlích die Umlaute zerschossen. War auch nur als Beispiel, nicht als Dauerzustand, nutzt ja nichts wenn es nur bei mir richtig aussieht ;)

    Hab dann im Template nachgeschaut, da fand sich dann in den Meta-Tags die ISO-Angabe, habe ich denn mal umgestellt auf
    <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
    Auch die Theme-Dateien waren - aufgrund Phase5 - in ISO, konvertiere ich grade mittels Notepad++ um zu UTF-8 ohne BOM. Fehler bleiben im Moment aber noch.

    Gefunden habe ich noch http://www.mydigitallife.info/2007/06/23/how-to-convert-character-set-and-collation-of-wordpress-database/ - ob das was helfen könnte?
     
  8. Loewenherz

    Loewenherz Well-Known Member

    Registriert seit:
    23. März 2005
    Beiträge:
    123
    Zustimmungen:
    0
    Hi Spickzettel,
    danke. Wobei ich leider kein Backup der alten DB mehr machen kann.

    Schätze, das Problem könnte in diesem Eintrag liegen:
    ENGINE=MyISAM AUTO_INCREMENT=1791 DEFAULT CHARSET=latin1;
    wenn ich das umstelle... ;)
     
  9. Loewenherz

    Loewenherz Well-Known Member

    Registriert seit:
    23. März 2005
    Beiträge:
    123
    Zustimmungen:
    0
    Ok, die Sache hat sich erledigt. Laut MySQLDumper keine Chance auf Restaurierung, auch DUK ist fehlerfrei durchgelaufen. Also einzige Chance, es von Hand zu machen. Immerhin, nach 20 Minuten waren alle Tags korrigiert.
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden