[3.2] [3.2.2] Nach dem Update von 3.1.10 auf 3.2.2 sind Umlaute in der DB unleserlich

[nx650]

Hallo Community,

ich habe bereits diverse Foreneinträge zu dem Umlaute-Problem durchgelesen, bin aber bislang nicht dahintergestiegen wie mein derzeitiges Problem verursacht wurde bzw. was ich dagegen tun kann.

Erstmal ein paar Infos.

• Forum: http://testforum.nx650.de
• phpBB-Version(en): Update von Version 3.1.10 auf 3.2.2 über manuelles Update
• Style: prosilver (prosilver_se deaktiviert)
• Alle Mods/Plugins deaktiviert
• Hoster: Strato.
• PHP-Version: 5.6.33
• MySQL Version: 5.6.37
• Server Zeichensatz: UTF-8 Unicode (utf8)
• Zeichensatz/Kollation der MySQL-Verbindung: utf8mb4_general_ci

Das Update lief problemlos. Ich habe sämtliche Extensions deaktiviert während des Updates. Als Style nutze ich einen leicht modifizierten prosilver_se. Auch diesen hatte ich deaktiviert.

Problem:
Nach dem Update musste ich feststellen, dass die Umlaute in vorhandenen Threads/Beiträgen unleserlich geworden sind. Aus ü wurde ü, aus Ö wurde Ö, aus ä wurde ä usw.
Das betrifft aber nur Daten, die aus der DB geholt werden (Überschriften von Threads, Beiträge, PNs, etc.) Im Style wird alles richtig angezeigt (z.B. der Satz ganz unten "Alle Cookies des Boards löschen").
Wenn ich einen neuen Beitrag schreibe mit Umlauten, werden diese korrekt angezeigt. Es betrifft daher "nur" den Bestand.

Meine Frage: Wie kann so etwas passieren?
An der MySQL-Version hat sich ja nichts geändert. Die PHP-Version habe ich erst nachträglich hochgesetzt. Das Forum läuft jetzt auf Version 7.1. Das Update wurde mit Version 5.6.33 durchgeführt. Jedoch hat die Umstellung auf 7.1 dahingehend nichts bewirkt.
Ist es evtl. möglich, dass ich in einer Datei im phpBB-Paket eine Einstellung ändern muss bevor ich das Update durchführe?

Natürlich könnte ich per SQL die Umlaute umschießen. Aber mir wäre eine saubere Lösung lieber. Ich würde lieber das Update nochmal wiederholen wenn es tatsächlich an einer falschen Einstellung liegt. Nur weiß ich aktuell nicht wo ich diesbezüglich Hand anlegen muss.
Ach so: Forum-Cache habe ich natürlich gelöscht. Das hat aber nichts gebracht.

Den modifizierten prosilver_se Style habe ich mittlerweile wieder so weit angepasst, dass er genauso aussieht wie unter 3.1.10.
An und für sich wäre alles bestens, wenn denn die Umlaute lesbar wären.

Danke für Eure Unterstützung.

Gruß,
Steffen

[canonknipser]

Wie hast du denn den Update gemacht? Komplettpaket? Automatischer Updater?

[Mahony]

Hallo
Siehe dazu Die Umlautproblematik.
Da wird dir alles wichtige zum Thema erklärt.

Grüße: Mahony

[nx650]

Wie hast du denn den Update gemacht? Komplettpaket? Automatischer Updater?

Mit dem deutschsprachigen Komplettpaket per manuellem Update wie unter II. Manuelles Update beschrieben.

Hallo
Siehe dazu Die Umlautproblematik.
Da wird dir alles wichtige zum Thema erklärt.

Grüße: Mahony

Danke für die Info. Habe mir den Artikel durchgelesen. Ich scheine wohl ein Kandidat für "Szenario 3" zu sein.
Trotzdem wundere ich mich darüber wie das passieren konnte. Ich habe ja schließlich keinen Umzug vollzogen. Die Datenbank blieb an Ort und Stelle. Es wurde lediglich das Update von 3.1.10 auf 3.2.2 durchgeführt. Das heißt die Zeichensätze von DB und Server sollten sich eigentlich nicht verändert haben. Aber ich werde mal bei meinem Provider nachfragen, ob nicht doch irgendwo eine Einstellung auf latin1 steht.

Gruß,
Steffen

[nx650]

Fehler gefunden!

Ich habe mich in die Irre führen lassen.
Im MyPHPAdmin steht drin: Server Zeichensatz: UTF-8 Unicode (utf8)
Somit war ich der Annahme, dass der Zeichensatz der DB auch auf UTF-8 eingestellt ist. Das war ein Trugschluss.
Herausgefunden habe ich es durch folgendes SQL:

Code: Alles auswählen

SELECT @@global.character_set_database

Das Ergebnis: latin1

In der phpBB-Software ist der Default UTF-8 (siehe includes/functions.php):

Code: Alles auswählen

'S_CONTENT_ENCODING'	=> 'UTF-8'

Somit war klar, dass das nicht zusammenpasst.

Ich werde in Kürze nochmal einen Migrationstest machen und zuvor den Eintrag in der functions.php auf latin1 stellen. Dann hoffe ich, dass die Umlaute dies überleben werden.

Gruß,
Steffen

[canonknipser]

Ne, das ist glaube ich der falsche Weg. Du musst die Zeichenkodierung deiner Datenverbindung anpassen - in der functions.php steht das Encoding für den Browser. Das sollte immer UTF-8 sein.
Wenn deine Tabellen UTF-8 codiert sind, musst du "nur" in deiner MySQL-Konfiguration die Datenverbindung auf UTF-8 umstellen, wenn nicht, solltest du die Tabellen umcodieren (export und in eine neue DB mit UTF-8 importieren - s. dazu auch den Artikel von MySQLDumper).

[Mahony]

Hallo

Im MyPHPAdmin steht drin: Server Zeichensatz: UTF-8 Unicode (utf8)
Somit war ich der Annahme, dass der Zeichensatz der DB auch auf UTF-8 eingestellt ist. Das war ein Trugschluss.
Herausgefunden habe ich es durch folgendes SQL:

Code: Alles auswählen

SELECT @@global.character_set_database

Um herauszufinden, welchen Zeichensatz die Datenbank hat musst du folgenden SQL-Befehl absetzen

Code: Alles auswählen

SHOW VARIABLES LIKE 'character_set%';

In der Ausgabe schaust Du dann, was bei character_set_client und bei character_set_connection steht.

Das ist dann der Zeichensatz.

Ich nehme an, Dein Hoster hat etwas an der Datenbank geändert und somit kommt es zu dem Zeichensalat.
Am phpBB-Update liegt es jedenfalls definitiv nicht.


Grüße: Mahony

[nx650]

Hallo

Um herauszufinden, welchen Zeichensatz die Datenbank hat musst du folgenden SQL-Befehl absetzen

Code: Alles auswählen

SHOW VARIABLES LIKE 'character_set%';

In der Ausgabe schaust Du dann, was bei character_set_client und bei character_set_connection steht.
Das ist dann der Zeichensatz.

Ich nehme an, Dein Hoster hat etwas an der Datenbank geändert und somit kommt es zu dem Zeichensalat.
Am phpBB-Update liegt es jedenfalls definitiv nicht.

Grüße: Mahony

Ok, dann schauen wir mal:

Ich habe hier die Angaben von meinem Live-Forum, das aktuell in Betrieb ist und noch unter phpBB 3.1.10 läuft. An dieser MySQL DB habe ich noch nichts verändert.

Hier die Ausgabe des SQLs:

Code: Alles auswählen

Variable_name				Value

character_set_client		utf8mb4
character_set_connection	utf8mb4
character_set_database		latin1
character_set_filesystem	binary
character_set_results		utf8mb4
character_set_server		latin1
character_set_system		utf8
character_sets_dir			/opt/RZmysql56/share/charsets/

Das von mir auf phpBB 3.2.2 migrierte Testforum hat als Basis eine Kopie dieser DB und liegt auf derselben Plattform unter derselben Domain (nur die Subdomain ist unterschiedlich). Somit sind auch die MySQL- und PHP-Versionen identisch (siehe mein Eingangspost).
Wenn ich auf der migrierten DB das SQL absende, bekomme ich als Ergebnis exakt die gleichen Angaben. Daher glaube ich nicht, dass mein Hoster etwas verändert hat. Wenn, dann passt etwas von vornherein nicht zusammen.
Auf jeden Fall zerschießt mir die Migration von 3.1.10 auf 3.2.2 trotzdem die Umlaute.

[Mahony]

Hallo
Also dann mal Butter bei die Fische, nech...

Mache bitte ein Backup von der Original-Datenbank mit dem Mysqldumper für PHP7 und spiele es auch wieder mit dem Mysqldumper auf der Test-Datenbank ein. Somit ist sichergestellt, dass die Daten in der Datenbank im richtigen Zeichensatz eingespielt wurden.

Anschließend machst Du das Update dann noch einmal. Jetzt sollten keine Fehler mehr auftreten.

Grüße: Mahony

[nx650]

Mache bitte ein Backup von der Original-Datenbank mit dem Mysqldumper für PHP7 und spiele es auch wieder mit dem Mysqldumper auf der Test-Datenbank ein. Somit ist sichergestellt, dass die Daten in der Datenbank im richtigen Zeichensatz eingespielt wurden.

Anschließend machst Du das Update dann noch einmal. Jetzt sollten keine Fehler mehr auftreten.

Grüße: Mahony

Hi Mahony,

ja, jetzt passt es.
Das bedeutet für mein Live-Forum dann letztendlich, dass ich ein Backup mit dem MySQLDumper machen, und dieses Backup gleich im Anschluss wieder einspielen soll?

Was genau "fixt" der MySQLDumper hier? Der SQL

Code: Alles auswählen

SHOW VARIABLES LIKE 'character_set%';

zeigt mir nämlich nach wie vor die gleiche Zeichensatzcodierung an wie in meinem Beitrag vom 08.02.2018 beschrieben.

Letztendlich habe ich jetzt zwar die Lösung meines Problems, aber die Ursache kann ich immer noch nicht wirklich nachvollziehen. Irgendetwas macht der MySQLDumper auf jeden Fall anders, als wenn ich per Kommandozeile

Code: Alles auswählen

mysql -h rdbms -u BENUTZERNAME -pPASSWORT DBxxxxxx < datei.sql

die Datenbank zurückspiele.

Sorry für die evtl. nervigen Fragen, aber ich möchte einfach nur verstehen was das Problem war/ist.
Ein ganz dickes Dankeschön an Dich für Deine Unterstützung.

Gruß,
Steffen