Vous publiez du code ou du texte dans WordPress et les caractères accentués disparaissent, s’affichent sous forme de symboles étranges ou coupent une partie du contenu ? Avant de modifier la base de données, il faut déterminer où la transformation se produit : dans le texte enregistré, dans la réponse du serveur ou au moment où l’extension met le code en forme.
J’avais rencontré ce problème avec Crayon Syntax Highlighter et ses blocs en lang="text". À l’époque, un alias m’avait permis de retrouver les accents. Cette astuce est conservée plus bas pour expliquer le contexte historique, mais ce n’est plus la première solution à appliquer aujourd’hui.
État de Crayon : sa fiche WordPress.org indique que l’extension a été retirée du téléchargement le 13 décembre 2022 pour un problème de sécurité. Si vous l’utilisez encore, préparez son remplacement et la vérification des contenus concernés.
Pourquoi les accents disparaissent-ils dans un bloc de code ?
Les symptômes se ressemblent, mais les causes peuvent être différentes :
- le texte stocké dans l’article est déjà incorrect ;
- le texte est correct dans l’éditeur mais un traitement côté serveur ou une extension le transforme à l’affichage ;
- la page est envoyée ou interprétée avec un encodage différent de celui de son contenu ;
- un script ou une règle du coloriseur modifie le texte rendu ;
- un copier-coller ou une conversion antérieure a altéré le contenu.
Le fait qu’un accent soit mal affiché ne prouve pas à lui seul que toute la base doit être convertie en UTF-8. Un changement global de jeu de caractères peut compliquer la récupération des données si la cause est ailleurs.
Étape 1 : vérifier le texte enregistré
Ouvrez l’article dans l’éditeur WordPress et comparez le texte saisi avec le résultat affiché sur le site. Prenez une phrase qui contient plusieurs caractères, par exemple :
J’ai mangé une tarte à la crème à Noël.Effectuez les vérifications suivantes :
- Dans l’éditeur, les accents sont-ils présents dans le contenu original ?
- Le problème touche-t-il uniquement un bloc de code, ou aussi les paragraphes ordinaires ?
- Apparaît-il sur une seule page ou sur plusieurs articles ?
- Un copier-coller du texte affiché restitue-t-il les bons caractères ?
- Le résultat change-t-il selon le navigateur ou après vidage du cache concerné ?
Si le texte est déjà corrompu dans l’éditeur, désactiver un coloriseur ne suffira pas à reconstruire les caractères perdus. Recherchez une révision WordPress, une sauvegarde ou la source originale avant de corriger le contenu.
Étape 2 : distinguer la réponse HTML du rendu du coloriseur
Si le contenu est correct dans l’éditeur mais incorrect sur la page publiée, comparez la source HTML reçue avec le texte qui apparaît à l’écran. Les outils de développement du navigateur permettent aussi d’examiner l’en-tête Content-Type de la réponse.
Un exemple d’en-tête indiquant UTF-8 ressemble à ceci :
Content-Type: text/html; charset=UTF-8Langage du code : HTTP (http)Cet en-tête, à lui seul, ne garantit pas que les données en amont sont correctes. L’objectif est de localiser la différence : le texte arrive-t-il déjà altéré dans la réponse, ou est-il transformé après son chargement ? Vérifiez également si un cache ou un CDN sert encore une ancienne version de la page.
Si le problème ne concerne que le rendu d’une extension, testez sa désactivation sur une copie du site. Si toutes les zones du site sont touchées, examinez aussi les étapes d’importation et de stockage avant de conclure.
Attention aux modifications de la base de données
Avant toute intervention sur l’encodage de la base, sauvegardez les fichiers et les données, puis vérifiez que la sauvegarde est restaurable. Ne remplacez pas les valeurs DB_CHARSET et DB_COLLATE au hasard : la documentation WordPress sur wp-config.php met en garde contre des modifications non maîtrisées sur un site existant.
Une conversion peut être nécessaire dans certains cas, notamment après une migration, mais elle doit être décidée après diagnostic et testée sur une copie. Si le souci est apparu à la suite d’un transfert, mon guide sur l’import d’une base WordPress en SSH reprend les vérifications de base.
Crayon Syntax Highlighter : que faire si le plugin est encore installé ?
Le retrait de Crayon de WordPress.org pour raison de sécurité justifie de revoir son utilisation. La page du répertoire ne détaille pas à elle seule le périmètre exact du problème : vérifiez la version installée et les informations de sécurité applicables à votre site, sans supposer que tous les forks ou extensions de nom voisin présentent le même comportement.
La désactivation peut modifier le rendu des anciens exemples. Selon la façon dont ils ont été insérés, il peut rester des shortcodes ou du HTML spécifique à l’extension. Il faut donc protéger le site et préparer la transition sans perdre les contenus.
Plan de migration conseillé
- Sauvegardez la base et les fichiers et vérifiez la possibilité de revenir en arrière.
- Sur une copie du site, inventoriez les articles qui utilisent Crayon : recherchez ses shortcodes et le balisage utilisé dans votre installation.
- Choisissez un échantillon représentatif : textes accentués, longs extraits, langages différents, blocs contenant des caractères HTML et exemples avec options particulières.
- Désactivez Crayon sur la copie et examinez ce qui reste lisible dans l’éditeur et sur le site.
- Convertissez un petit nombre d’articles vers un bloc ou une extension de remplacement, sans supprimer le texte source avant vérification.
- Comparez les accents, les indentations, les retours à la ligne, les caractères spéciaux et le code copié dans le presse-papiers.
- Étendez la migration par lots, puis surveillez les articles après mise en ligne.
Un remplacement automatisé peut être utile sur un grand nombre d’articles, mais seulement après analyse des formats présents et tests sur des copies. Ne partez pas du principe que tous les shortcodes Crayon seront compris par un autre plugin.
Quelles alternatives utiliser pour afficher du code ?
Le bloc Code de WordPress
Pour afficher un extrait lisible sans fonction avancée de coloration, commencez par le bloc Code natif. Dans l’éditeur, ajoutez un bloc Code, collez votre extrait puis vérifiez le résultat dans l’aperçu et sur la page publiée.
Il évite de dépendre d’un ancien format de shortcode pour les nouveaux exemples. Vérifiez toutefois la lisibilité sur mobile et la possibilité de copier correctement les lignes longues. Le bloc natif ne convertit pas automatiquement les anciens contenus Crayon.
Une extension de coloration compatible avec les blocs
Si la coloration par langage est nécessaire, comparez les extensions maintenues et vérifiez leur compatibilité avec votre version de WordPress et votre thème. Par exemple, Syntax-highlighting Code Block étend le bloc Code natif et indique effectuer la coloration côté serveur. Sa fiche précise que les blocs Code existants peuvent être pris en charge ; cela ne signifie pas qu’elle convertit les anciens shortcodes Crayon.
Autre option à examiner, Enlighter propose ses propres blocs et une intégration avec l’éditeur. Son fonctionnement et ses formats diffèrent : testez les fonctionnalités et la conservation des extraits avant de choisir.
Dans les deux cas, vérifiez la date de mise à jour, la version de WordPress testée, les dépendances et le rendu du code sur votre site. L’objectif n’est pas seulement d’obtenir de la couleur : le lecteur doit pouvoir lire et copier un exemple intact.
L’ancienne astuce Crayon : un alias pour les accents
Dans la première version de cet article, j’avais constaté que, sur mon installation, le langage batch conservait les accents alors que certains blocs déclarés en text les affichaient mal. J’avais ajouté l’alias suivant dans le fichier langs/aliases.txt de Crayon :
batch textCette manipulation était une rustine propre à la configuration observée à l’époque. Elle ne démontre pas la cause exacte du problème, ne corrige pas le problème de sécurité signalé par WordPress.org et peut être écrasée lors d’une mise à jour ou d’une réinstallation. Je la conserve pour les personnes qui retrouvent une ancienne configuration ; je ne recommande pas de modifier les fichiers du plugin comme solution actuelle.
Comment vérifier qu’une migration est réussie ?
Avant de remplacer l’ancienne solution sur tous vos articles, contrôlez au minimum :
- les accents et caractères spéciaux dans le texte visible et dans le code copié ;
- les espaces, tabulations et retours à la ligne des extraits ;
- l’affichage des langages courants et le contraste des couleurs ;
- les blocs contenant du HTML, du PHP ou du texte brut ;
- les longues lignes sur mobile et la navigation au clavier ;
- les articles anciens dans l’éditeur et sur le site public ;
- les effets de cache après déploiement.
Si un extrait ne s’affiche plus ou si des caractères ont disparu, comparez-le avec la sauvegarde avant de poursuivre. WordPress explique également comment examiner les erreurs de validation de blocs ; certaines options de récupération peuvent modifier le contenu du bloc, d’où l’intérêt de disposer d’une copie.
Besoin d’aide pour moderniser vos articles techniques ?
Un audit WordPress permet d’identifier les extensions à risque, les formats de contenu concernés et les priorités. Je peux intervenir comme développeur WordPress pour préparer une conversion et vérifier son résultat. Pour un suivi régulier, découvrez aussi mes services de maintenance WordPress et de sécurité WordPress.
Questions fréquentes
Crayon Syntax Highlighter est-il encore disponible sur WordPress.org ?
Sa fiche indique qu’il n’est plus disponible au téléchargement depuis le 13 décembre 2022, à la suite d’un problème de sécurité. Consultez la fiche officielle et les informations de sécurité applicables à votre version.
Le bloc Code WordPress affiche-t-il les accents ?
Il peut afficher du texte accentué correctement lorsque le contenu et la chaîne d’encodage sont corrects. Testez toujours votre propre extrait dans l’éditeur et sur la page publiée.
Désactiver Crayon convertit-il automatiquement les anciens blocs ?
Ne le supposez pas. Les anciens contenus peuvent contenir des shortcodes ou un balisage spécifique. Vérifiez leur comportement sur une copie du site et prévoyez une conversion si nécessaire.
Faut-il convertir la base de données en UTF-8 ?
Pas automatiquement. Identifiez d’abord où les caractères sont altérés. Une conversion éventuelle doit être préparée et testée à partir d’une sauvegarde.
