La Cave à vin Brumaire, un caviste en ligne, a connu un incident classique : une mise à jour d’extension a introduit un bug d’affichage sur son catalogue, l’équipe technique a réagi vite en revenant à la version précédente via WP-CLI, et tout semblait rentré dans l’ordre. Sauf que le lendemain, une quarantaine de pages produits affichaient des blocs vides à la place des fiches de dégustation, un contenu pourtant rédigé avec soin par l’équipe commerciale.
Le rollback n’était pas en cause dans l’incident initial, mais il en a créé un nouveau : la version de l’extension à laquelle on était revenu ne savait plus lire les attributs enregistrés par la version plus récente, brièvement active entre-temps.
Pourquoi un rollback casse ce qu’une mise à jour ne casse pas
Une mise à jour de bloc bien conçue prévoit une deprecated pour migrer les anciens formats d’attributs vers les nouveaux : c’est le sens même du tableau deprecated de registerBlockType. Mais l’inverse n’existe pas nativement. Rien dans l’API de blocs ne prévoit qu’une version plus ancienne sache lire un format d’attribut plus récent. Quand la version 2.4 du bloc « fiche de dégustation » a introduit un nouvel attribut structuré notesDegustation (un objet avec robe, nez, bouche), remplaçant l’ancien description en texte simple, revenir à la version 2.3 a laissé les pages avec un contenu que ce bloc plus ancien ne savait tout simplement pas interpréter.
Ce que l’éditeur a montré, et ce qu’il n’a pas montré
Dans l’éditeur, les blocs concernés s’affichaient avec l’avertissement classique « Ce bloc contient des données inattendues », proposant de tenter une récupération ou de convertir en HTML. Sur le site public en revanche, le rendu du bloc (dynamique, avec render.php) ne trouvait simplement pas l’attribut notesDegustation qu’il attendait, et affichait une fiche vide sans le moindre message d’erreur visible : le PHP traitait une valeur absente comme une chaîne vide, sans lever d’avertissement.
La stratégie de sauvegarde préventive
Après cet incident, l’équipe de Kaolin, intervenue en renfort, a mis en place une pratique systématique pour tous les blocs métier critiques du site : dupliquer les valeurs essentielles dans un champ de post meta simple, en parallèle de l’attribut de bloc structuré. Concrètement :
register_post_meta( 'produit', '_notes_degustation_texte', [
'type' => 'string',
'single' => true,
'show_in_rest' => true,
] );
add_action( 'save_post_produit', function ( $post_id ) {
$blocs = parse_blocks( get_post_field( 'post_content', $post_id ) );
foreach ( $blocs as $bloc ) {
if ( 'brumaire/fiche-degustation' === $bloc['blockName'] ) {
$notes = $bloc['attrs']['notesDegustation'] ?? [];
$texte = implode( ' — ', array_filter( $notes ) );
update_post_meta( $post_id, '_notes_degustation_texte', $texte );
}
}
} );
Ce champ de secours, en texte brut, n’est jamais affiché en temps normal : il ne sert qu’en cas de sinistre, comme filet de sécurité manuel pour reconstituer le contenu à la main si un rollback ou une migration ratée rend le bloc illisible.
Prévoir un export avant toute mise à jour risquée
Au-delà du filet de sécurité par post meta, la pratique la plus simple reste l’export complet du contenu avant toute mise à jour d’extension qui modifie la structure d’un bloc largement utilisé :
- Exporter la base de données ou au minimum la table
wp_postsavant la mise à jour. - Tester la mise à jour sur un environnement de recette avec un jeu de contenu représentatif, incluant les cas limites (attributs vides, anciens formats).
- Documenter dans le changelog de l’extension si un changement d’attribut n’est pas rétro-compatible avec un rollback.
Ce que ce cas ne couvre pas
Ce retour d’expérience concerne spécifiquement le cas d’un retour arrière de version, pas les déprécations classiques gérées par le tableau deprecated, qui elles fonctionnent très bien pour la migration en avant. Le problème n’est pas la déprécation elle-même, mais l’absence totale de mécanisme symétrique pour la migration en arrière.
Une mise à jour se pense dans les deux sens : ce qu’elle apporte, et ce qu’elle rend impossible à annuler proprement.
En résumé
Un rollback d’extension n’est jamais totalement sûr dès qu’un format d’attribut de bloc a changé entre les deux versions. La double sauvegarde des valeurs critiques dans un champ de post meta simple, combinée à un export systématique avant mise à jour, a permis à la Cave à vin Brumaire de reconstituer ses quarante fiches produits en une heure plutôt qu’en ressaisissant tout à la main.
