# Révision de contenu restaurée : elle efface une traduction validée la veille > Un clic sur « Restaurer cette révision » a suffi à faire disparaître une traduction validée depuis vingt-quatre heures. Diagnostic d'un effet de bord méconnu. - Auteur : WordPress Développement - Publié le : 2022-11-17 - Mis à jour le : 2022-11-17 - Catégorie : Multilingue - URL : https://www.wpmoderne.fr/multilingue/revision-restauree-efface-traduction-validee/ ## L’essentiel - Les révisions WordPress ignorent les données de traduction en postmeta - wp_restore_post_revision ne restaure que le contenu de post_content - Un hook save_post mal ordonné aggrave le problème `wp_restore_post_revision` restaure exactement ce que son nom indique : le contenu d'une révision antérieure d'un article. Rien de plus. C'est précisément ce comportement, documenté mais rarement lu jusqu'au bout, qui a provoqué la disparition d'une traduction validée la veille sur un site d'actualités locales gérant sa traduction avec une couche maison plutôt qu'avec Polylang ou WPML. Ce texte reconstitue le diagnostic mené après le signalement d'un rédacteur : « ma traduction en anglais a disparu, alors que je l'avais validée hier ». Le coupable n'était ni un bug de synchronisation ni une erreur humaine, mais un usage tout à fait normal de la fonctionnalité de révisions de WordPress, combiné à une architecture de traduction qui n'en tenait pas compte. ## Symptôme : une traduction validée disparaît sans action apparente Le rédacteur en chef signale qu'un article, dont la version anglaise avait été relue et validée la veille, s'affiche de nouveau en français sur la version `/en/` du site. Aucune modification n'a été enregistrée dans l'intervalle sur cet article, ni par lui, ni par personne d'autre dans les journaux d'activité visibles. Le contenu français, lui, est resté intact et cohérent avec l'historique connu. ## Diagnostic : remonter la piste par le journal des révisions L'onglet des révisions de l'article, accessible depuis l'éditeur classique, révèle l'explication : un contributeur a corrigé une coquille dans le texte français ce matin-là, puis a utilisé le bouton « Comparer les révisions » pour vérifier son ajout, avant de cliquer par erreur sur « Restaurer cette révision » sur une version antérieure à la coquille — une version qui datait d'avant la mise en place de la traduction personnalisée. ``` // Simplification du système de traduction maison utilisé sur ce site add_post_meta( $post_id, '_traduction_en', $texte_traduit ); // Le contenu traduit est stocké en postmeta, PAS en tant que post distinct ``` > L'essentiel à retenir : Les révisions WordPress ignorent les données de traduction en postmeta ; wp_restore_post_revision ne restaure que le contenu de post_content ; Un hook save_post mal ordonné aggrave le problème Le point clé est là : la traduction anglaise n'était pas un article WordPress séparé, mais une valeur stockée en *postmeta* sur l'article français lui-même, via une méta-clé `_traduction_en`. Or la fonction `wp_restore_post_revision()` ne restaure que les champs présents dans la table `wp_posts` — le titre, le contenu, l'extrait — et ignore par défaut les métadonnées personnalisées, sauf si elles sont explicitement enregistrées comme faisant partie de la révision via le filtre `_wp_post_revision_field_*` ou `wp_save_post_revision_check_for_changes`. ## Ce que fait réellement la restauration d'une révision Ici, la métadonnée `_traduction_en` n'avait pas été supprimée : elle contenait toujours la traduction validée. Le vrai problème venait d'ailleurs, dans le code du thème : la fonction qui affichait le contenu traduit vérifiait, avant d'utiliser `_traduction_en`, que le contenu français associé correspondait bien à un condensé (*hash*) enregistré au moment de la validation de la traduction. La restauration d'une révision antérieure a changé le `post_content`, donc le condensé recalculé, ce qui a fait échouer la vérification et basculé l'affichage sur un repli automatique en français. ``` function afficher_contenu_langue( $post_id, $langue ) { $traduction = get_post_meta( $post_id, "_traduction_{$langue}", true ); $hash_valide = get_post_meta( $post_id, "_traduction_{$langue}_hash", true ); $hash_actuel = md5( get_post_field( 'post_content', $post_id ) ); if ( $traduction && $hash_valide === $hash_actuel ) { return $traduction; } return get_post_field( 'post_content', $post_id ); // repli silencieux } ``` ## Le correctif : recalculer le hash après restauration Le correctif retenu accroche une fonction au hook `wp_restore_post_revision`, qui reçoit l'identifiant de l'article et celui de la révision restaurée, pour avertir explicitement le rédacteur que la traduction associée doit être revalidée plutôt que de la faire disparaître silencieusement derrière un repli en français. ``` add_action( 'wp_restore_post_revision', function ( $post_id, $revision_id ) { foreach ( array( 'en', 'es' ) as $langue ) { $hash_valide = get_post_meta( $post_id, "_traduction_{$langue}_hash", true ); if ( $hash_valide ) { update_post_meta( $post_id, "_traduction_{$langue}_a_revalider", 1 ); } } }, 10, 2 ); ``` Un bandeau d'avertissement dans l'éditeur, affiché quand la méta `_a_revalider` est présente, informe désormais le rédacteur qu'une restauration de révision impose de revalider la traduction avant publication, plutôt que de laisser le site retomber sur le français sans prévenir personne. ## Prévention : documenter le comportement des révisions dans l'architecture Ce type d'incident est spécifique aux architectures de traduction construites maison, où le contenu traduit ne vit pas dans un article WordPress distinct comme le font Polylang ou WPML, mais dans des métadonnées rattachées à l'article source. Toute équipe qui choisit cette architecture doit documenter explicitement ce que fait, et ne fait pas, la restauration d'une révision vis-à-vis des métadonnées liées à la traduction, et prévoir un mécanisme de détection plutôt que de découvrir le problème via un rédacteur inquiet. ## En résumé Le système de révisions de WordPress ne restaure que le contenu principal d'un article, jamais ses métadonnées personnalisées par défaut. Une architecture de traduction qui s'appuie sur ces métadonnées, sans le documenter ni le tester, s'expose à des effets de bord silencieux dès qu'un contributeur restaure une ancienne révision, même pour un motif aussi anodin que corriger une coquille.