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
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.
