Le mode STRICT de MySQL change ce qu’une meta_query silencieusement ignorait

SQLSTATE[22001]: String data, right truncated. Cette erreur, apparue après une migration de serveur vers une nouvelle version de MySQL, a interrompu net l’enregistrement d’une métadonnée qui fonctionnait sans problème depuis des années sur l’ancien serveur. Rien n’avait changé dans le code, seulement la version du moteur de base de données.

Ce type d’incident, silencieux jusqu’à ce qu’une migration l’expose brutalement, mérite d’être compris en détail avant de migrer un site vers une infrastructure plus récente, car son origine touche directement au comportement des meta_query et de l’enregistrement de métadonnées dans WordPress.

Ce que faisait l’ancien comportement

Sur des configurations MySQL plus anciennes, ou avec un mode SQL permissif, une valeur trop longue pour la colonne cible, ou d’un type incompatible avec la colonne (une chaîne de texte insérée dans un champ censé être numérique, par exemple), était simplement tronquée ou convertie de façon approximative, avec au pire un avertissement journalisé, mais sans jamais interrompre l’exécution de la requête.

Ce comportement permissif masquait des bugs applicatifs bénins en apparence : une métadonnée légèrement trop longue s’enregistrait quand même, tronquée silencieusement, sans que personne ne s’en aperçoive, tant que la valeur tronquée restait exploitable pour l’usage prévu.

Ce que change le mode strict

Depuis MySQL 5.7, le mode STRICT_TRANS_TABLES fait partie du mode SQL par défaut, et son application s’est généralisée sur les installations MySQL 8 fournies par les hébergeurs modernes. Ce mode transforme les avertissements silencieux précédents en véritables erreurs bloquantes pour les tables utilisant un moteur transactionnel comme InnoDB, celui utilisé par défaut par toutes les tables de WordPress, y compris wp_postmeta.

-- Exemple représentatif d'une insertion qui échoue en mode strict
INSERT INTO wp_postmeta (post_id, meta_key, meta_value)
VALUES (42, 'reference_produit', 'REF-000000000000000000001-BIS');
-- SQLSTATE[22001]: String data, right truncated

Dans ce cas concret, une extension qui construisait une référence produit trop longue pour la colonne cible fonctionnait « par erreur » sur l’ancien serveur, la valeur étant tronquée silencieusement à la taille maximale de la colonne. Sur le nouveau serveur en mode strict, la même opération provoque une erreur SQL explicite, remontée à WordPress sous forme d’échec de la fonction update_post_meta().

Comment diagnostiquer ce type d’échec après une migration

Le symptôme le plus courant est un retour false inattendu d’une fonction comme update_post_meta() ou wp_insert_post(), sans message d’erreur visible côté PHP par défaut. Pour obtenir le détail réel de l’échec SQL, il faut activer temporairement le mode de débogage de la base de données :

global $wpdb;
$wpdb->show_errors();
update_post_meta( $post_id, 'reference_produit', $valeur_longue );
echo $wpdb->last_error;

Cette vérification révèle immédiatement si l’échec provient effectivement d’une troncature refusée par le mode strict, plutôt que d’une autre cause moins évidente comme un verrou de table ou un problème de permissions.

Corriger sans réactiver le mode permissif

La tentation de désactiver le mode strict au niveau du serveur pour retrouver le comportement d’avant doit être évitée : ce mode protège aussi contre de véritables erreurs de données, pas seulement contre des cas limites bénins. La bonne réponse consiste à corriger la source du problème, en général en dimensionnant correctement les valeurs avant insertion :

• Valider la longueur d’une valeur avant de l’enregistrer, avec une troncature explicite et assumée côté PHP si nécessaire, plutôt que de laisser MySQL décider silencieusement.
• Vérifier le typage des valeurs transmises à update_post_meta(), en particulier après un import de données externes dont le format peut varier.
• Auditer les extensions tierces qui manipulent des métadonnées avec des valeurs de longueur variable, souvent la source la plus fréquente de ce type d’incident après une migration.

Pourquoi cette règle protège réellement les données

Un avertissement silencieux qui tronque une donnée sans le signaler n’est pas une fonctionnalité pratique, c’est une corruption de donnée qui attend simplement d’être découverte au pire moment. Le mode strict ne casse rien : il révèle des problèmes qui existaient déjà.

En résumé

Une migration vers un serveur MySQL 8 récent expose souvent des comportements applicatifs qui reposaient, sans le savoir, sur la tolérance d’un mode SQL permissif. Plutôt que de chercher à recréer artificiellement cette tolérance, le bon réflexe consiste à auditer et corriger les points de code qui manipulaient des données mal dimensionnées, pour repartir sur une base plus fiable une fois la migration terminée.