À quoi ressemble le problème
Avant
INSERT INTO wp_posts (post_title) VALUES ('Menu du café – crème brûlée');Après
INSERT INTO wp_posts (post_title) VALUES ('Menu du café – crème brûlée');D’où vient l’erreur
WordPress stocke le texte en UTF-8. Beaucoup d’anciennes installations ont toutefois créé leurs tables en latin1 ou se sont connectées en latin1. Tant que l’écriture et la lecture font la même erreur, personne ne s’en aperçoit. Après un déménagement vers un nouveau serveur, un export avec phpMyAdmin ou un changement du jeu de caractères de connexion, chaque lettre accentuée se transforme soudain en deux caractères.
DB_CHARSETdanswp-config.phpvautlatin1ou ne correspond pas aux tables.- Le dump a été exporté en
latin1et importé enutf8mb4, ou l’inverse. - Une extension ou un script d’import a converti une nouvelle fois un texte déjà abîmé. Cela donne du texte doublement encodé comme
é.
Réparer l’export
- Faites une sauvegarde de la base avant de modifier quoi que ce soit.
- Exportez les tables concernées dans un fichier
.sql, par exemple avec phpMyAdmin oumysqldump --default-character-set=utf8mb4. - Déposez le fichier dans la zone ci-dessus. Mojibuster ne répare que les endroits abîmés et vous montre chaque modification.
- Téléchargez le fichier réparé et importez-le en
utf8mb4dans une base de test vide. - Vérifiez le site. Si tout est correct, importez-le dans la base de production.
Le dump n’est jamais envoyé sur un serveur, ce qui compte : il contient en général des comptes utilisateurs, des adresses e-mail et des commentaires. Plus de détails pour les entreprises et les DPO.
Attention aux données sérialisées
WordPress enregistre certains réglages dans wp_options et wp_postmeta sous forme de valeurs PHP sérialisées, par exemple s:5:"Café";. Le nombre est la longueur en octets. Quand é redevient é, il ne correspond plus et WordPress rejette la valeur. Réparez donc d’abord les tables de contenu comme wp_posts, wp_comments et wp_terms. Pour les options, wp search-replace de WP-CLI est le meilleur outil, car il met à jour les longueurs.
Corriger la cause dans MySQL
- Passez les tables et la connexion en
utf8mb4et définissezdefine('DB_CHARSET', 'utf8mb4');danswp-config.php. - Si une colonne
latin1contient des octets UTF-8, ne la convertissez pas directement : cela l’encoderait une seconde fois. Le chemin habituel passe par un type binaire : d’abordMODIFY … LONGBLOB, puisMODIFY … LONGTEXT CHARACTER SET utf8mb4. - Testez chaque modification d’abord sur une copie de la base.
Questions fréquentes
Puis-je réparer toute une base WordPress d’un coup ?
Oui, même de gros dumps SQL. Attention toutefois aux données sérialisées dans wp_options et wp_postmeta : WP-CLI s’en charge mieux.
Les caractères corrects du dump seront-ils modifiés ?
Non. Mojibuster ne répare que les suites clairement abîmées. Le texte correct reste tel quel.
Quelle différence entre utf8 et utf8mb4 ?
Dans MySQL, utf8 ne stocke que des caractères d’au plus trois octets : les émojis sont perdus. utf8mb4 est du vrai UTF-8, le bon choix pour WordPress.
Cela fonctionne-t-il avec d’autres systèmes que WordPress ?
Oui. Joomla, Drupal, Magento ou votre propre application sur MySQL ou MariaDB ont le même problème et la même solution.