# Un bloc perd son contenu après un rollback de version du plugin

> Un client revenu à une ancienne version d'extension après un incident a découvert que ses blocs stockaient des attributs incompatibles avec cette version antérieure.

- Auteur : Clément Hadrot
- Publié le : 2024-04-24
- Mis à jour le : 2024-04-24
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/bloc-perd-contenu-rollback-version-plugin/

## L’essentiel

- Un rollback n'est pas symétrique à une mise à jour
- Sauvegarder les attributs critiques dans le post content en clair
- Prévoir un export avant toute mise à jour risquée

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 );
        }
    }
} );
```

> L'essentiel à retenir : Un rollback n'est pas symétrique à une mise à jour ; Sauvegarder les attributs critiques dans le post content en clair ; Prévoir un export avant toute mise à jour risquée

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_posts` avant 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.