Hieroglyphen statt ä, ö, ü, ß und anderer Sonderzeichen. Damit überraschte mich teufelsmoor.eu nach dem Wechsel der PHP-Version von 7.4 zu 8.0. Im Internet finden sich verschiedene mögliche Ursachen und demzufolge auch Lösungswege, nur einer davon hat bei mir funktioniert. Hat mich einen halben Tag gekostet, deswegen hier ein Kurzbericht, um evtl. Leidensgenossen vielleicht etwas Mühe zu sparen.
Hintergrund
Beim Wechsel der PHP-Version hatte ich schon öfter mal Probleme, bislang zum Glück nur kleinere, die meist durch inkompatible Plugins verursacht waren. Diesmal aber lag es an meiner mittlerweile uralten mySQL-Datenbank, angelegt 2007 mit der damals für WordPress-Datenbanken üblichen Latin-1-Kodierung nach ISO 8859-1. Irgendwann in den späten 2000er-Jahren hat WordPress bei Neu-Installationen auf UTF-8 umgestellt, blieb aber bis inkl. PHP-Version 7.4 in der Lage, die in meiner Datenbank gespeicherten Artikel korrekt darzustellen.
Damit war es jetzt plötzlich vorbei. Von Strato sanft überredet (… extended support für PHP 7.4 ab Februar monatlich € 7.81) wechselte ich zu PHP 8.0 und hatte schlagartig Buchstabensalat. Zunächst habe ich probatorisch das Theme gewechselt und alle Plugins deaktiviert. Ohne Erfolg. Die Analyse der Datenbank mittels PhpMyAdmin (auf der STRATO-Admin-Seite unter Datenbanken und Webspace > Datenbankverwaltung) zeigte eine wilde Mischung von Zeichensätzen (=Kollationen) bei den Tabellen. Für die originären Text-Tabellen wie wp_posts und wp_comments war latin-1 eingestellt und ein Blick in diese Tabellen zeigte auch, dass der Text in den Feldern post_content bzw. comment_content latin-1-kodiert war.
Lösungswege
Im Internet kursieren diverse Lösungswege, die bei zumindest ähnlichen Konstellationen wie der meinigen geholfen haben sollen. Bei mir aber nicht … bis auf eine.
Nichts geändert haben diverse Versuche, den CHARSET UTF-8 zu „erzwingen“, weder im Header noch in der wp_config.php oder der .htaccess-Datei. Ebenfalls unwirksam war das Umstellen der Tabellen-Kollation auf UTF-8 oder eine der „moderneren“ UTF-8-Derivate mit Hilfe von PhpMyAdmin.
Die Lösung war letztlich diese zusätzliche Zeile in der wp_config.php:
define('DB_CHARSET', 'latin1');
In meinem Setting also latin1 und nicht utf-8, wie in einigen Quellen zu lesen war. Und es war auch nicht egal, wo ich diese Zeile eingefügt hatte. Es funktionierte nur an dieser Stelle,
// ** MySQL Einstellungen ** // //define('WP_CACHE', true); //Added by WP-Cache Manager define('DB_NAME', '???????'); // Der Name der Datenbank, die du benutzt. define('DB_USER', '???????'); // Dein MySQL-Datenbank-Benutzername. define('DB_PASSWORD', '??????????'); // Dein MySQL-Passwort. define('DB_HOST', 'rdbms.strato.de'); // In 99% der Fälle musst du hier nichts ändern. define('DB_CHARSET', 'latin1');
und nicht, wenn sie weiter hinten in der Datei stand.
Anmerkungen
Ältere WordPress-Installationen sind im Zuge diverser Aktualisierungen offenbar recht uneinheitlich, was die verwendeten Zeichensätze und deren Interpretationen angeht. Was bei Anderen hilfreich war, hat bei mir nicht funktioniert. Ich drücke die Daumen, dass dieser Lösungsweg dem Einen oder Anderen nützlich ist, letztlich muss man wahrscheinlich einfach ein bisschen herumprobieren.
Wenn alle Wege scheitern, hilft nur eine systematische Bereinigung der Datenbank selbst.