# Le mode STRICT de MySQL change ce qu’une meta_query silencieusement ignorait > Une valeur numérique tronquée sans erreur hier peut, sur MySQL 8 en mode strict, provoquer un échec net de la requête qui la manipule. - Auteur : WordPress Développement - Publié le : 2023-12-20 - Mis à jour le : 2023-12-20 - Catégorie : Performance - URL : https://www.wpmoderne.fr/performance/mysql-strict-mode-meta-query/ ## L’essentiel - MySQL 8 active STRICT_TRANS_TABLES par défaut - Une valeur hors format provoquait autrefois un simple avertissement - Le même cas peut désormais interrompre la requête `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()`. > L'essentiel à retenir : MySQL 8 active STRICT_TRANS_TABLES par défaut ; Une valeur hors format provoquait autrefois un simple avertissement ; Le même cas peut désormais interrompre la requête ## 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.