Unicode-Encoder

Ist ja eigentlich nicht mehr zeitgemäß, dass solche Codierungsfehler (Kommentarfunktion mit aktuellem Wordpress) auftauchen. Der Betreiber der Website sollte sich wohl mal mit dir auf Fehlersuche begeben.

Stimmt – bei einem aktuellen WordPress sollte so etwas eigentlich nicht passieren.
Das Kernproblem ist fast nie WordPress selbst, sondern irgendein altes oder schlecht konfiguriertes Plugin/Theme, das

die Datenbankverbindung nicht auf utf8mb4 gestellt hat,
die DB-Tabelle(n) noch auf utf8 / latin1 stehen lässt,
SET NAMES oder den Zeichensatz-Header selbst überschreibt,
oder vor dem Speichern willkürlich utf8_encode() / substr() ohne Multibyte-Unterstützung drüberläuft.

Wenn der Betreiber Lust hat, kann er in fünf Minuten prüfen, ob die klassischen Stolpersteine vorliegen:

wp-config.php:

php

复制

define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', '');

MySQL selbst:

sql

复制

SELECT CCSA.character_set_name, CCSA.collation_name
FROM information_schema.`TABLES` T,
     information_schema.`COLLATION_CHARACTER_SET_APPLICABILITY` CCSA
WHERE CCSA.collation_name = T.table_collation
  AND T.table_schema = 'dbname'
  AND T.table_name LIKE '%comments%';

→ Sollte überall utf8mb4 stehen.

Im Plugin-Order mal nach Kommentar-/Gästebuch-Plugins suchen, die htmlspecialchars(), strip_tags() oder substr() ohne mb_-Prefix auf den Rohtext anwenden.
Falls ein Caching-/Optimierungs-Plugin aktiv ist, prüfen, ob es „HTML minify“ oder „DB cache“ macht und dabei den Content-Type-Header vermurkst.

Wenn er mir (oder jedem anderen Entwickler) SSH/FTP- und wp-admin-Zugang gibt, findet man so etwas in 10–15 Minuten – meist reicht schon ein Blick in die ersten paar Zeilen des verdächtigen Plugins.

Kurz: ja, das ist 2025 unnötig, aber leider noch häufig ein Konfigurations- bzw. Legacy-Problem, kein WordPress-Core-Fehler.