English post here.
TL;DR: Pour éviter les problèmes d'accents lors du passage de MySQL 5.7 à 8.0, vérifiez que le paramètre DB_CHARSET est bien présent dans le wp-config.php de votre Wordpress.
----------
MySQL 8.0 arrive bientôt sur les bases de données livrées avec vos hébergement web, appelées également «SharedSQL» ou «Bases de données MySQL mutualisées» (plus d'infos prochainement). En attendant, vous pouvez vous préparer. J'ai plusieurs sujets pour vous, et voici le premier. Il concerne les sites Wordpress créés avant 2007 (plus précisément: les sites Wordpress créés avant la version 2.2 de Wordpress, sortie en 2007).
Attention, si votre site a été créé avec un Wordpress antérieur à la 2.2, et ensuite mis à jour, alors vous pouvez être impacté, même si vous êtes sur la dernière version de Wordpress. Explications et solution simple, c'est parti ! 😃
**Contexte technique**
Tout d'abord, un peu de contexte. C'est toujours bien de savoir de où on vient pour savoir où on va 🙂
En 2001, Michael Widenius co-fonde MySQL. Michael vient de Finlande. Alors il a choisi latin1 / swedish comme les character set / collation par défaut pour MySQL (le finlandais utilise un alphabet dérivé du suédois).
À l'époque, c'était pas bien important, Michael était loin d'imaginer que son SGBD serait l'un des plus massivement utilisés au monde quelques années plus tard.
Mais c'est vite devenu un problème, parceque l'alphabet suédois n'est pas vraiment le plus populaire ni le plus adapté pour une utilisation mondiale. Et c'est un vrai gros problème, parceque bouger d'un character set / collation à un autre se fait généralement dans la douleur.
La preuve: 22 ans plus tard, latin1 / swedish sont toujours les character set / collation par défaut en MySQL 5.7!
Depuis MySQL 8.0, le character set par défaut est UTF-8 (appelé "utf8mb4" par MySQL).
**Le character set de Wordpress**
Par défaut, Wordpress utilise le character set défini dans wp-config.php:
/** Database charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8' );
Ce paramètre est UTF-8 par défaut, et existe depuis Wordpress 2.2, sorti il y a 17 ans, en 2007.
Si ce paramètre n'est pas présent (ce qui est le cas des Wordpress créés avant septembre 2007), alors Wordpress utilise le character set par défaut de la base.
Comme MySQL 8.0 change son character set par défaut de latin1 à utf8mb4, les Wordpress qui n'ont pas ce paramètre (et qui fonctionnent dont en latin1) vont rencontrer des problèmes d'accent (par exemple: un "é" vu comme "é"). En effet, les données sont en latin1 en base (elles ne bougent pas), mais elles seront vues comme de l'UTF-8.
**Impact**
Si vous avez:
1. Un Wordpress
2. ET que le contenu de votre base de données est en latin 1 (ce qui signifie que votre base a été créée avec un Wordpress avant 2007)
3. ET que vous n'avez pas spécifié de DB_CHARSET
Alors, votre site va rencontrer des problèmes d'accent.
**Solution**
La solution est simple, et vous pouvez la mettre en place dès maintenant:
* Si vous avez un DB_CHARSET dans votre wp-config.php, n'y touchez pas.
* Si vous n'avez pas de DB_CHARSET dans votre wp-config.php, alors ajoutez ça dans votre fichier, dès maintenant:
define( 'DB_CHARSET', 'latin1' );
Mikaël
MySQL 8.0: Préparez vos (très) vieux Wordpress
Sujets apparentés
- [RESOLU] Server unable to read htaccess file, denying access to be safe
25627 
24.11.2019 19:11
- Version php 7.0 sur Ovh mais php 5.4.45 sur mon wordpress
22904 10.01.2019 11:14
- Comment récupérer son mot de passe phpmyadmin ?
19820 14.11.2016 10:32
- Changer la version d'une base de donnée en mutualisé
19723 22.12.2016 11:46
- Variable upload_max_filesize plus grande que post_max_size
19671 11.06.2017 16:01
- Résiliation hébergement+domaine
15423 11.09.2018 20:28
- Résiliation hébergement
14559 27.07.2018 10:39
- Transfert hebergement et domaine .fr entre client OVH ?
13738 21.12.2016 15:10
- Ne supporte pas FTP sur TLS
13713 11.12.2018 18:48
- Nouvelle fonctionnalité : SFTP pour tous
13417 06.01.2017 14:50
Merci @MikaelD1 pour toutes ces précisions.
Okay je l'ai !
> /** Database Charset to use in creating database tables. */
> define('DB_CHARSET', 'utf8');
Ouf !
Un Charset réglé à 'utf8' est un alias de utf8mb3.
On peut vérifier via phpmyadmin de la valeur réelle de cet utf8 lors de la création des tables ...
Pour éviter toute ambiguïté, il vaut mieux utiliser la valeur réelle du charset, soit utf8mb4 plutôt que l'alias utf8 et préciser par la même occasion la collation (collate) utf8mb4_unicode_ci pour une meilleure portabilité.
Normalement, ces valeurs renseignées dans un fichier de configuration, permettent de forcer les paramètres par défaut du moteur de base de données.
Wordpress précise bien en commentaire que ce charset est utilisé lors de la création des tables...
Certains CMS rajoutent d'ailleurs une autre variable charset réglé à utf8, indépendante, pour l'affichage html. Pas sûr donc que Wordpress l'utilise hors création des tables.
Dans tous les cas, Le simple changement de cette valeur en cours de route pourrait avoir une incidence sur des données déjà existantes car elle reviendrait à faire un ALTER TABLE sur la structure de la table mais sans conversion des données. Or une vraie conversion consiste à modifier la structure et convertir les données existantes avec CONVERT.
À manipuler donc avec précaution et en connaissance de cause.
Bonjour,
Justement d'après le message de @MikaelD1 c'est pour ne pas que cette valeur change entre MySQL 5.7 et 8.0 pour les vieux WordPress :
Puis :
Et en arbre de décisions cela donnerai :
Cordialement, janus57
Merci Janus57 pour cette explication illustrée qui permet de mieux re-situer la réponse de Mikaël.
Cette réponse est une recommandation pour limiter la casse de cette migration mais comme je le suggère ici :
https://community.ovh.com/t/Mont%C3%A9e-en-version-de-MySQL-sur-offre-WebCloud/63248/5
il est temps de profiter de cette migration pour upgrader aussi ses tables et convertir ses données qui ont été créés dans ces anciens formats que plus personne ne peut recommander de conserver une fois que l'on est passé sous Mysql8. Ce n'est que mon humble avis, après chacun voit midi à sa porte entre "ne rien toucher tant que ça marche " et "rester à jour pour maintenir un niveau de sécurité et de performance".
Les deux paradigmes ont leur lot de bénéfice/risque et chacun choisira en fonction de ses compétences, moyens, enjeux commerciaux, etc.
Tout le monde n'étant pas informaticien parmi les clients d'OVH, je suggère juste c'est autre solution pour que chacun puisse avoir toutes les billes pour décider d'évoluer sans trop attendre car malheureusement, par expérience, certaines mises à jour deviennent de véritables casse-têtes quand les versions PHP/MySql sont trop éloignées des versions initiales .
Après ce passage à utf8, n'est pas non plus un gros chamboulement qui a, par ailleurs, déjà commencé il y a déjà quelques années. Cela reste de la gestion classique de données avec son lot potentiel de bugs si non effectué dans les règles de l'art...