Un rédacteur ouvre un article resté inchangé depuis des mois et tombe sur un message inattendu : « Ce bloc contient une erreur inattendue. Vous pouvez la corriger ou résoudre le problème dans l’éditeur de code. » Juste en dessous, un bouton « Tenter la récupération ». Par réflexe de prudence, beaucoup n’osent pas cliquer, de peur de perdre définitivement le contenu, et préfèrent contacter leur développeur en urgence. Ce réflexe est compréhensible, mais dans l’immense majorité des cas, ce bouton effectue une opération parfaitement sûre et réversible tant que l’article n’a pas été republié après coup.
Comprendre ce que ce mécanisme fait réellement, ce qu’il tente de réparer et pourquoi il apparaît, permet de réagir sereinement plutôt que dans la précipitation quand ce message survient sur un site en production.
Pourquoi ce message apparaît
À l’ouverture d’un article, l’éditeur recalcule le rendu attendu de chaque bloc en appelant sa fonction save() actuelle avec les attributs stockés en base, puis compare le résultat obtenu au HTML réellement présent dans post_content. Si les deux ne correspondent pas exactement, le bloc est marqué comme invalide. Cette divergence survient typiquement après une mise à jour d’extension qui a modifié la structure du balisage produit par save(), sans mécanisme de dépréciation correctement déclaré pour gérer l’ancien format.
Ce que fait réellement la récupération
Le bouton « Tenter la récupération » ne restaure aucune sauvegarde ni aucune version antérieure de l’article : il réapplique simplement le résultat de la fonction save() actuelle sur les attributs tels qu’ils ont été extraits du contenu existant, puis remplace le HTML stocké par ce nouveau résultat. En clair, il aligne le contenu enregistré sur ce que la version actuellement installée du bloc considère comme correct, sans toucher aux valeurs des attributs eux-mêmes.
// Simplification du mécanisme interne
const nouveauHTML = save( { attributes: attributsExistants } );
remplacerContenuStocke( blocId, nouveauHTML );
Quand la récupération échoue
Cette opération suppose que les attributs stockés restent structurellement compatibles avec ce qu’attend la version actuelle du bloc. Si un attribut a changé de type (un nombre devenu une chaîne de caractères, par exemple) ou si un attribut a été purement et simplement supprimé de la définition du bloc sans dépréciation associée, la récupération échoue ou produit un résultat incohérent, et le bouton reste inopérant malgré plusieurs tentatives.
- Un simple changement de classe CSS dans save() se résout presque toujours sans problème.
- Un changement de structure DOM plus profond nécessite en général une déprecation explicite pour fonctionner correctement.
- Un attribut renommé ou supprimé casse la récupération automatique, quelle que soit la simplicité apparente du changement.
La bonne pratique pour l’éviter en amont
Ce message ne devrait jamais surprendre un développeur qui maintient correctement ses blocs : chaque changement dans save() susceptible d’affecter du contenu déjà publié doit s’accompagner d’une entrée dans le tableau deprecated du bloc, qui décrit précisément l’ancien format attendu et permet à l’éditeur de migrer automatiquement le contenu existant, sans jamais afficher ce message d’erreur au rédacteur.
deprecated: [
{
attributes: ancienSchema,
save: ancienneFonctionSave,
},
],Que faire en pratique face au message
Avant de cliquer sur le bouton de récupération, il reste prudent de basculer sur le mode « Éditeur de code » pour observer le contenu brut et confirmer qu’aucune donnée essentielle ne semble manquante. Une fois cette vérification faite, la récupération peut être tentée sans crainte : elle n’affecte que la structure du HTML de sortie, jamais le contenu textuel proprement dit saisi par le rédacteur.
Le bouton de récupération n’est pas une opération de dernier recours risquée : c’est un outil de réconciliation entre un contenu figé et une définition de bloc qui a évolué depuis sa publication. Le vrai risque se situe en amont, dans l’absence de dépréciation correctement déclarée.
Ce qu’il faut retenir
Ce bouton mystérieux répond à une mécanique précise et documentée : réconcilier un contenu publié avec la version actuelle d’un bloc, sans toucher aux données réellement saisies par le rédacteur. Sa présence répétée sur un site signale presque toujours un défaut de gestion des dépréciations côté développement, un signal à traiter à la source plutôt qu’à ignorer clic après clic.
