Thread Verfasser: adlatus
Thread ID: 1720
Thread Info
Es gibt 8 Beiträge zu diesem Thema, und es wurde 446 Mal angesehen.  Ausserdem wurden Dateien angehängt.
 Thema drucken
Umlautfehler nach Serverwechsel
adlatus
Hallo, liebe php-Gemeinde,

vor einem Monat hat mein Serveranbieter meinen Vertrag / Account auf einen neuen Server umziehen lassen. Folge war, dass auf meiner Homepage die allbekannten Umlautfehler entstanden und Umlaute als Raute mit ? angezeigt wurden.

Nach Rücksprache mit dem Support wurde das geändert und lag (angeblich) an einer "ungenau kodierten Datenbanktabelle". Das hat man behoben und etwa einen Monat lief die Homepage fehlerfrei.

Wir haben aufgrund corona und Urlaubszeit keine Änderungen an der Seite vorgenommen und trotzdem ist das Problem nun wieder da. Nach Rücksprache mit dem Serveranbieter hat dieser keine Änderungen mehr an den Servern vorgenommen und ist der Meinung, dass es an "meinen scripten" liegt und man das nicht beheben kann.

Ich habe natürlich schon die Suche bemüht und alles versucht, was ich finden konnte. Leider ohne Erfolg.

Auffällig ist, dass wenn ich die global.php aus /locale/German entferne alles richtig läuft und es zu keinen Umlautfehlern kommt (Text wird mit Umlauten angezeigt). So lassen geht aber natürlich nicht, weil dann die in der global.php befindlichen deutschen Begriffe nicht mehr auf der Seite angezeigt werden und andere Probleme entstehen.

diverse Einträge in der global.php habe ich Testweise schon geändert oder ausgeklammert. Das führt aber zu keinem Erfolg. Daher glaube ich nicht, dass die Lösung die global.php ist.

// Sprachdatei Einstellungen
setlocale(LC_TIME, "de_DE.UTF8", "de", "DE"Wink;
$locale['charset'] = "utf-8"; <-- hier habe ich auch bereits "iso-8859-1" getestet
$locale['xml_lang'] = "de";
$locale['tinymce'] = "de";
$locale['phpmailer'] = "de";

auch in der maincore.php und im genutzten theme habe ich nach dem Grund für den Fehler gesucht, diesen aber einfach nicht lokalisieren können.

Ich habe auch schon versucht auf dem Server die "Zeichensatz/Kollation der Verbindung zum Server" zu ändern, aber auch das hat nichts gebracht. Oder hat diese Einstellung nichts damit zu tun? Sie steht akutell auf

utf8_german2_ci

Ich bin mit meinem Latein leider am Ende und weiss nicht weiter Sad
Kann mir vielleicht jemand helfen?

Ich lasse die global.php nun erst einmal drin, damit der Fehler sichtbar ist. Die Seite lautet:

https://www.kletterkirche.de

Auf der Startseite habe ich es so hinbekommen, dass wenigstens dort optisch erst einmal alles passt. Gut sehen kann man aber den Fehler, wenn man eine Seite aufruft, z.B.

https://www.kletterkirche.de/viewpage...page_id=45


Ich danke Euch vielmals für Eure Hilfe!!!

Grüße
addi
 
Systemweb
Das Problem liegt in der Regel beim Import der Datenbank. Leider ist es nämlich in der Regel so, dass bei Fusion 7 noch mit alter Zeichensatz-Kollation gearbeitet wurde. So lange man mit einer alten bestehenden Datenbank weiterarbeitet stößt man nicht auf Probleme. Aber sobald die Datenbank kopiert wird, kommen die Zeichensätze durcheinander.
Hinzu kommt, dass innerhalb der Datenbank jede Tabelle andere Zeichensätze verwendet. Das Grundsystem der originalen Fusion 7 erstellt Tabellen mit UTF-8 Zeichensatz. In manchen älteren Serverumgebungen war stattdessen der Zeichensatz Latin-1 bzw. Latin-2 als Standard definiert. Das bedeutet, jede Infusion, die neue Tabellen anlegt und dessen Entwickler für diese Tabellen nicht den zu verwendenden Zeichensatz auf UTF-8 festgelegt hat, benutzt dann Tabellen mit anderen Zeichensätzen.
Es bringt also leider wenig, beim Import den zu verwendenden Zeichensatz festzulegen, da die Daten in verschiedenen Zeichensätzen vorliegen und irgendwas dann folglich immer "verstümmelt" wird. Bestes Beispiel sind die Beiträge der Shoutbox, die sind bei den meisten Imports mit Umlautfehlern versehen.

Wenn du dich mit phpMyAdmin ein wenig kennst, kannst du dieses Problem aber relativ einfach lösen:
Du loggst dich in PMA ein, öffnest die Datenbank deiner Fusion-Installation. Du darfst noch keine Tabelle auswählen, solltest also den Inhalt der Datenbank im Hauptfenster sehen (die Liste der enthaltenen Tabellen).
Nun gehst du im oberen Bereich auf den Punkt "Operationen".
Auf der dann folgenden Seite scrollst du ganz nach unten und findest dort Einstellungen zur "Kollation".
Das stellst du folgendermaßen ein:
www.krelli.com/forum/attachments/db_konvertieren.png
und bestätigst mit ok.
Bei einer großen Datenbank kann es etwas länger dauern, also ruhig warten bis zur Erfolgsmeldung.
Normalerweise funktioniert das sehr gut, nur wenn die Datenbank mehrfach exportiert/importiert wurde, sind die Zeichen bereits zu sehr verstümmelt.
Wenn du beim Umwandeln eine Timeout Meldung bekommst, ist deine Datenbank zu groß, in dem Fall musst du jede Tabelle einzeln nacheinander auswählen und nach und nach wie beschrieben konvertieren.

Natürlich wie immer vorher nochmal sicherstellen, dass du ein aktuelles Backup der Datenbank hast, falls was schiefgeht.

Zum Schluss gehts du nochmal in die global.php und korrigierst die Angabe des Zeichensatzes, denn du hast dort ein Minus vergessen. Richtig muss es lauten: utf-8, nicht wie aktuell angegeben uft8
 
adlatus
Vielen Dank für die Information und den Lösungsansatz.

Ich habe das genau so gemacht, wie beschrieben. Leider hat es das Problem nicht gelöst Heul doch

Zitat: // Sprachdatei Einstellungen
setlocale(LC_TIME, "de_DE.UTF8", "de", "DE"Wink;
$locale['charset'] = "utf-8";
$locale['xml_lang'] = "de";
$locale['tinymce'] = "de";
$locale['phpmailer'] = "de";


Das "-" habe ich auch zunächst nur an die eine Stelle gesetzt. Als das keine Veränderung gebracht hat, habe ich die Groß- / Kleinschreibung geändert (hat das überhaupt auswirkungen?), also von UTF-8 auf utf-8. Danach habe ich alle Stellen in der global.php geändert, bei denen utf8 (egal in welcher Schreibweise) steht.

Zitat: // BITTE AB HIER NICHT MEHR BEARBEITEN !!
#$locale['global_060'] = utf8_encode($locale['global_060']);
#$locale['global_441'] = utf8_encode($locale['global_441']);
#$locale['global_442'] = utf8_encode($locale['global_442']);
#$locale['global_451'] = utf8_encode($locale['global_451']);
#$locale['global_452'] = utf8_encode($locale['global_452']);
#$locale['global_453'] = utf8_encode($locale['global_453']);
#$locale['global_454'] = utf8_encode($locale['global_454']);
#$locale['global_455'] = utf8_encode($locale['global_455']);


Auch hier habe ich das "-" eingefügt. Ohne Erfolg.

Auffällig war, dass ich unter verschiedenen PHPMyAdmin-Versionen (3, 4, 5)gearbeitet habe / arbeiten musste, um die Einstellung zu finden, wie sie oben im Bild angezeigt ist (Operationen zur Änderung der Kollationen).

Ich habe dann auch noch die "Allgemeinen Einstellungen" bearbeitet und dort die Kollation identisch eingestellt (siehe Foto). Auch danach war der Fehler noch da.

Gibt es ggf. noch etwas anderes, was ich ändern / versuchen könnte?

Danke nochmals und vielen Dank!

Gruß
addi
adlatus hat folgende Datei angehängt:
Du hast nicht die Berechtigung die Anhäge dieses Themas zu sehen.

 
Systemweb
In meiner Anleitung hatte ich beschrieben, dass du erst die betreffende Datenbank auswählen/öffnen musst um den entspr. Menüpunkt zu finden
 
adlatus
Zitat: Systemweb schrieb:

In meiner Anleitung hatte ich beschrieben, dass du erst die betreffende Datenbank auswählen/öffnen musst um den entspr. Menüpunkt zu finden


Das habe ich natürlich gemacht. Leider hat das aber eben nicht zum Erfolg geführt. Vielleicht habe ich mich ja in meinem letzten Posting missverständlich ausgedrückt Heul doch Ich habe Deine Schritte genau so abgearbeitet und war nicht erfolgreich.


Beste Grüße
addi
 
Systemweb
Sieht für mich danach aus, dass die Sonderzeichen in der Datenbank bereits verstümmelt sind.

Bevor du weiter experimentierst kannst du auch einfach die Bereiche manuell nachbearbeiten, also editieren. Wenn du an den betreffenden Stellen einfach die korrekten Sonderzeichen einsetzt und abspeicherst bleibt das dann so stehen.
 
adlatus
Ich habe auch das schon probiert und zuvor in der Datenbank nachgeschaut. Beispiel soll diese "Eigene Seite" sein:

https://www.kletterkirche.de/viewpage.php?page_id=54

In der Datenbank sind im betreffenden Text unter "page-content" tatsächlich die Umlaute und Sonderzeichen verstümmelt, wie du es bezeichnest. Wenn ich sie auf der Homepage von Hand ändere, werden die Änderungen auch übernommen und bleiben dauerhaft (exemplarisch zu Beginn o.g. Seite gemacht).

Ich gehe davon aus, dass damit klar sein dürfte, dass ich hier automatisch eine Änderung aller "verstümmelten" Zeichen nicht mehr vornehmen kann, oder? Das würde dann bedeuten, dass ich tatsächlich die gesamten Inhalte händisch korrigieren müsste, oder?

Vielen Dank für die Geduld Wink

Gruß
addi
 
Systemweb
Zitat: In der Datenbank sind im betreffenden Text unter "page-content" tatsächlich die Umlaute und Sonderzeichen verstümmelt, wie du es bezeichnest. Wenn ich sie auf der Homepage von Hand ändere, werden die Änderungen auch übernommen und bleiben dauerhaft (exemplarisch zu Beginn o.g. Seite gemacht).
Das bedeutet, beim Export bzw. Import sind die Umlaute mit Platzhaltern versehen worden. Das passiert z.B., wenn man beim Export/Import einen falschen Zeichensatz auswählt. Am besten gar nichts auswählen statt falsch,
Wenn die originalen Zeichen bereits verstümmelt sind kann man das nicht mehr autom. bereinigen lassen.
 
Springe ins Forum: