# Panne de synchronisation WPML après une migration de staging vers production > Une mise en production a effacé silencieusement des liaisons de traduction WPML. Voici comment on a retrouvé la cause et comment l'éviter. - Auteur : Clément Hadrot - Publié le : 2023-11-22 - Mis à jour le : 2023-11-22 - Catégorie : Multilingue - URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/panne-synchronisation-wpml-migration/ ## L’essentiel - Identifier la table qui porte réellement les liaisons de traduction - Comprendre pourquoi un export SQL partiel casse tout - Restaurer les liaisons sans perdre le contenu déjà migré Le lundi matin suivant la mise en production, le client a écrit un message simple : « Le sélecteur de langue affiche toujours la version française, même quand je clique sur le drapeau anglais. » Le site fonctionnait, les pages existaient bien dans les deux langues, mais elles ne se parlaient plus. Le sélecteur de langue de WPML renvoyait vers la page d'accueil au lieu de la traduction correspondante, comme si chaque contenu était devenu orphelin de son pendant dans l'autre langue. Ce type de panne est particulièrement déstabilisant parce que rien ne semble cassé au premier regard : le contenu est là, les menus fonctionnent, les formulaires marchent. Seule la mécanique de correspondance entre langues a disparu. Le diagnostic a mené vers une cause précise et évitable, liée à la façon dont la migration de staging vers production avait été réalisée. ## Où vivent réellement les liaisons de traduction WPML ne stocke pas la correspondance entre un article français et sa traduction anglaise dans les tables standards de WordPress (`wp_posts`). Il utilise ses propres tables, en premier lieu `icl_translations`, qui associe à chaque contenu un `trid` (translation ID) commun à toutes ses traductions, et `icl_languages` pour la configuration des langues actives. C'est précisément ce détail qui a posé problème : l'équipe en charge de la migration avait utilisé un export de base de données réalisé via un outil de sauvegarde configuré pour ne cibler que les tables préfixées `wp_`, une pratique courante pour alléger les exports sur les gros sites. Sauf que les tables WPML ne portent pas ce préfixe standard dans certaines installations plus anciennes, et se sont donc retrouvées exclues de l'export sans que personne ne s'en aperçoive avant la mise en ligne. > L'essentiel à retenir : Identifier la table qui porte réellement les liaisons de traduction ; Comprendre pourquoi un export SQL partiel casse tout ; Restaurer les liaisons sans perdre le contenu déjà migré ## Le diagnostic, étape par étape Face à ce genre de symptôme, la première vérification consiste à comparer le nombre de lignes de la table `icl_translations` entre l'environnement de staging et celui de production. ``` SELECT COUNT(*) FROM icl_translations; ``` Sur le site concerné, staging retournait 680 lignes, production seulement 340. Le doute n'était plus permis : la moitié des liaisons manquait purement et simplement en production, alors que le contenu texte, lui, avait bien été migré via les tables `wp_posts` classiques. La deuxième vérification a consisté à ouvrir un article touché directement en base, en cherchant son `trid` : ``` SELECT element_id, trid, language_code FROM icl_translations WHERE element_id = 4821; ``` Le résultat ne renvoyait qu'une seule ligne pour la version française, sans aucune ligne correspondante pour l'anglais alors que la page anglaise existait bel et bien dans `wp_posts`. La conclusion s'imposait : le contenu était présent, mais totalement déconnecté de son jumeau linguistique du point de vue de WPML. ## Pourquoi un export partiel casse la cohérence Un export SQL n'est jamais une opération anodine sur un site utilisant des extensions qui ajoutent leurs propres tables. WPML, Advanced Custom Fields ou WooCommerce en ajoutent chacun plusieurs, avec des noms de préfixe parfois différents du préfixe standard de l'installation, notamment sur des sites migrés plusieurs fois au fil des années. - Un export limité aux tables `wp_%` ignore silencieusement toute table personnalisée sans préfixe identique. - Aucune erreur n'est levée au moment de l'import : les tables manquantes ne provoquent pas de blocage, juste une base de données incomplète. - Le contenu texte continue de fonctionner normalement, ce qui retarde souvent la détection du problème de plusieurs jours. ## La restauration, sans perdre le contenu déjà en production Impossible de simplement réimporter l'export de staging complet : entre-temps, deux articles avaient été publiés directement en production. La solution a consisté à importer uniquement les tables WPML manquantes depuis la sauvegarde de staging, dans un environnement de test séparé, puis à comparer les `trid` un par un avec la production actuelle avant de reconstituer les liaisons perdues via l'interface *WPML → Gérer les traductions*, qui permet de relier manuellement deux contenus existants sans les dupliquer. Pour les deux articles publiés uniquement en production, il a fallu recréer la liaison à la main, en utilisant la fonction native de WPML qui propose, sur chaque article non lié, de le rattacher à une traduction existante plutôt que d'en créer une nouvelle. > Depuis cet incident, chaque export de base de données destiné à une migration passe par une vérification préalable : lister toutes les tables de la base et confirmer qu'aucune n'est ignorée, plutôt que de se fier à un filtre par préfixe. ## Prévenir plutôt que guérir Trois réflexes évitent de reproduire cette panne sur un projet WPML. D'abord, toujours utiliser `SHOW TABLES;` avant un export pour lister l'intégralité des tables présentes et vérifier qu'aucune n'échappe au filtre configuré dans l'outil de sauvegarde. Ensuite, privilégier un export complet de la base plutôt qu'un filtre par préfixe dès que le site utilise des extensions connues pour créer leurs propres tables. Enfin, ajouter un contrôle post-migration systématique : un simple comptage de lignes sur `icl_translations` comparé entre les deux environnements, qui prend dix secondes et aurait révélé le problème avant même la mise en ligne. ## Ce qu'on retient Un site multilingue repose sur des tables qui ne sautent pas toujours aux yeux d'une checklist de migration classique. La panne décrite ici n'avait rien d'exotique : elle venait d'un outil de sauvegarde configuré pour un cas général, appliqué sans adaptation à un site qui sortait de ce cas général. Le réflexe à garder est simple : sur un site multilingue, ne jamais faire confiance à un filtre par préfixe de table sans l'avoir vérifié une première fois.