Encodage de caractères dans MySQL et WordPress 2.7

Avec la pub­li­ca­tion, hier, de la ver­sion 2.7 “Coltrane” de Word­Press, les arti­cles et autres bil­lets détail­lant ses nom­breuses nou­veautés pleu­vent de toutes parts. Nous allons d’ailleurs prob­a­ble­ment y revenir nous-mêmes dans un proche avenir.

Lors des mises à jour de nos pro­pres sites, toute­fois, nous sommes tombés sur un aspect un peu moins plaisant apportés par la dernière mou­ture du pop­u­laire moteur de blogs/gestionnaire de con­tenus open source. Au tout le moins dans notre cas. Il ne s’agit pas d’un véri­ta­ble bug de Word­Press en soi, mais d’une sit­u­a­tion à laque­lle cer­tains d’entre vous pour­raient aussi se trou­ver con­fron­tés, en par­ti­c­ulier si votre site a déjà un cer­tain âge et un cer­tain nom­bre de mises à jour der­rière lui.

Nous avons nommé l’encodage de car­ac­tères. Le sujet est com­plexe, mais en gros la sit­u­a­tion est la suivante:

1. vous avez un site ou un blog mû par Word­Press (dans une ver­sion précé­dente) et écrit dans une langue autre que l’anglais (con­tenant en par­ti­c­ulier des signes dia­cri­tiques, comme le français
2. vous en faites une sauve­g­arde com­plète (fichiers, en par­ti­c­ulier le dossier wp-content et son con­tenu, ainsi que le fichier wp-config.php, et surtout le con­tenu de votre base de don­nées MySQL)
3. vous effectuez votre mise à jour en suiv­ant scrupuleuse­ment les instruc­tions (et en débaras­sant par la même occa­sion votre instal­la­tion de tous les fichiers obsolètes qui s’y sont cumulés avec le temps)
4. vous procédez à la mise à jour des tables de votre base de don­nées MySQL, en suiv­ant l’assistant de WordPress

Tout se passe bien, seule­ment voilà: en véri­fi­ant votre site, soudaine­ment tous les signes dia­cri­tiques, accents, cédilles, etc., sont rem­placés par des suites de car­ac­tères incom­préhen­si­bles! Ou plutôt incompréhensibles, devrait-on dire… Vous voyez de quoi on parle?

Bien­v­enue dans l’enfer des incom­pat­i­bil­ités d’encodages de caractères!

Le prob­lème n’est à vrai dire pas nou­veau; il a même touché notre pro­pre site à un tel nom­bre de reprises que nous avons préféré (entre autres raisons) utiliser cette excuse pour procéder à une opéra­tion Table rase cet été et met­tre au repos les archives de la pre­mière dizaine d’années d’Almaren.

La ques­tion des encodages de car­ac­tères est hor­ri­ble­ment com­plexe, et nous n’en sommes pas des spé­cial­istes, nous n’allons donc pas la détailler ici. Qu’il vous suff­ise de savoir que, par défaut, Word­Press utilise UTF-8 comme encodage de car­ac­tères dans sa base de don­nées. Mais les toutes pre­mières ver­sions de Word­Press util­i­saient un autre encodage (latin1 sauf erreur). Pire, cer­taines ver­sions de MySQL util­i­saient égale­ment un encodage de leurs tables du type latin1_swedish, et cet encodage est peut-être encore présent dans les tables de votre pro­pre base de données.

Cette sit­u­a­tion est d’autant plus prob­a­ble que votre site est vieux, et peut tout par­ti­c­ulière­ment sur­gir lors d’un change­ment d’hébergeurs (autres réglages MySQL?) ou d’une mise à jour du moteur de votre site (Word­Press dans le cas présent).

Peu importe d’ailleurs les détails tech­niques, la ques­tion pour vous est naturelle­ment: que faire pour remet­tre en état votre site?!

Du calme: avant tout vous avez une sauve­g­arde de l’ancienne ver­sion de votre site (n’est-ce pas? cf point 2. ci-dessus). Ensuite, des instruc­tions détail­lées exis­tent afin de vous aider à con­ver­tir l’encodage de votre base de don­nées. Trop détail­lées, prob­a­ble­ment, et absol­u­ment décourageantes pour les util­isa­teurs moins technophiles (ou anglophobes).

Eh bien, ne dés­espérez plus! Hier, en essayant de résoudre ce même prob­lème pour deux sites, nous sommes tombés sur une petite exten­sion Word­Press tout à fait adap­tée à nos besoins: UTF-8 Data­base Con­verter. Procédez comme suit:

1. Assurez-vous d’avoir bien sauve­g­ardé le con­tenu de votre base de don­nées. Si ce n’est pas le cas, faites-le main­tenant (vous pou­vez, par exem­ple, employer l’excellente exten­sion WP-DBManager, de Lester ‘GaMerZ’ Chan)
2. Installez l’extension UTF-8 Data­base Con­verter et activez-la
3. Allez dans l’onglet “UTF-8 Data­base Con­verter”, sous “Exten­sions” (entre par­en­thèses, avec la nou­velle inter­face util­isa­teur de Word­Press 2.7 il serait bon qu’une cer­taine stan­dard­i­s­a­tion de où les options des exten­sions sont placées prenne forme: entre “Exten­sions”, “Out­ils” et “Réglages”, on peut chercher longtemps! Avis aux auteurs d’extensions)
4. Vous recevrez un grand mes­sage rouge d’alerte, “WARNING - VERSION NOT SUPPORTED”: ignorez-le. Dans notre cas, l’extension a très bien marché avec Word­Press 2.7 (et de toutes manières vous avez fait une sauve­g­arde du con­tenu de votre base de don­nées, n’est-ce pas?)
5. Avant la dernière étape, vous recevez encore un aver­tisse­ment: “WARNING - DATA MAY BE LOST”. À nou­veau, ignorez-le et procédez
6. Lais­sez l’extension effectuer son tra­vail, sans refer­mer la fenêtre de votre navigateur
7. Rafraîchissez l’affichage de votre site: tout devrait être ren­tré dans l’ordre!

Si votre prob­lème est résolu, vous pou­vez sans autre dés­ac­tiver l’extension à présent.

Si cela n’a pas résolu votre prob­lème, restau­rez votre instal­la­tion Word­Press et essayez les con­seils don­nés sur la page Con­vert­ing Data­base Char­ac­ter Sets de la doc­u­men­ta­tion offi­cielle Word­Press. Cela reste votre meilleure chance et votre dernier ressort.

N.B.: ce bil­let vous pro­pose un tuyau pour résoudre un prob­lème d’encodages de car­ac­tères assez pré­cis et par­ti­c­ulier. Ce n’est pas une solu­tion mir­a­cle pour tous les cas de fig­ure, et nous n’assurons pas de sup­port sur ce sujet. Si vous avez besoin d’aide pour votre pro­pre site, je suis à louer pro­fes­sion­nelle­ment…