Reconnaître le message et délimiter le problème
Dans l’éditeur, un encadré annonce qu’un bloc contient un contenu inattendu ou non valide. Le texte ou l’image reste parfois visible sur le site public, tandis que ce bloc devient difficile à modifier. Le résultat recherché n’est pas seulement de fermer l’avertissement : il faut retrouver un contenu complet, modifiable et correctement enregistré.
Pour certains blocs, WordPress compare la structure enregistrée avec celle que le bloc sait produire. Une différence peut déclencher cette validation : modification manuelle du HTML, collage inhabituel ou changement du composant qui fournit le bloc. Le HTML est le balisage qui décrit les éléments d’une page. Ce message ne démontre pas, à lui seul, que la base de données est corrompue.
Ne confondez pas cette situation avec une réponse JSON non valide lors de l’enregistrement. Cette autre erreur concerne l’échange avec le serveur. Si elle apparaît également, conservez votre travail et faites traiter ce second problème séparément. Un bloc indiqué comme indisponible, un verrouillage et une erreur de fonctionnement JavaScript demandent eux aussi un diagnostic distinct.
Conserver une copie avant de tenter la récupération
Gardez l’onglet original ouvert. Dans le menu général de l’éditeur, recherchez la commande de copie de tout le contenu, puis collez le résultat dans un fichier texte local. Vérifiez que la copie contient le début, la fin et la partie affectée. Ne remplacez pas cette copie par la version obtenue après un essai : conservez les deux fichiers séparément.
Si la copie globale échoue, sélectionnez le bloc concerné et cherchez Copier dans son menu à trois points. Sauvegardez aussi les textes encore accessibles, les adresses des médias et des captures de la disposition. Une capture aide à reconstruire l’apparence, mais ne conserve ni les réglages interactifs ni la structure des blocs.
Créez ensuite un brouillon de travail distinct, sans le publier, dans Articles ou Pages, puis Ajouter. Collez-y la copie pour les premiers essais. Cette précaution évite de remplacer immédiatement la version que consultent les visiteurs. Elle ne constitue toutefois pas une sauvegarde complète : les médias et les composants du site restent partagés.
Avant une mise à jour d’extension ou une intervention plus large, demandez une sauvegarde de la base et des fichiers, avec une procédure de restauration connue. Une copie du texte ne permet pas de remettre en état une extension ou une configuration modifiée.
Vérifier les accès et la portée du bloc
Il faut pouvoir modifier le contenu concerné ; les opérations sur les extensions nécessitent d’autres droits. Notez la version de WordPress, le thème, le nom du bloc et le changement ayant précédé l’erreur. Indiquez aussi si vous utilisez WordPress autohébergé, WordPress.com ou un réseau multisite. Les accès à l’hébergement et les menus disponibles ne sont pas interchangeables.
Ouvrez la Vue en liste depuis l’aperçu du document, en haut de l’éditeur. Dépliez le groupe qui contient le bloc et repérez son emplacement exact. Sélectionner le groupe entier au lieu d’un paragraphe peut entraîner une conversion beaucoup plus large que prévu.
Vérifiez enfin si ce contenu appartient à une composition synchronisée, anciennement appelée bloc réutilisable. Modifier son original peut affecter toutes ses utilisations. Copier une page ne supprime pas nécessairement cette relation. Pour un essai local, utilisez le détachement lorsqu’il est proposé et que vous êtes autorisé à le faire ; sinon, demandez l’intervention du responsable avant de poursuivre.
Choisir entre les trois approches
Commencez par la récupération ciblée si un bloc isolé affiche le message après une modification de son contenu. L’objectif est de comparer une correction limitée avec votre copie, sans toucher au reste du document.
Choisissez les révisions si vous savez qu’une version correcte a déjà été enregistrée et souhaitez retrouver ce contenu. Cette démarche est particulièrement utile lorsque la récupération retire des éléments importants. Elle ne répare pas automatiquement un composant devenu incompatible.
Passez au diagnostic du bloc tiers si plusieurs anciens contenus se dégradent après une mise à jour, ou si le bloc dépend d’une extension absente. Dans ce cas, répéter une conversion sur chaque page peut masquer la cause et faire perdre des fonctions. Aucun de ces parcours n’exige l’installation d’une nouvelle extension de dépannage.
Approche 1 : tenter une récupération sur la copie
Dans le brouillon de travail, sélectionnez uniquement le bloc affecté. Utilisez le bouton de récupération affiché dans l’avertissement, souvent nommé Tenter la récupération ou Attempt Recovery selon la langue et la version. Comparez immédiatement le résultat avec l’original conservé.
Contrôlez les mots, les liens, les images et la présentation personnalisée. Une récupération peut retirer du balisage non reconnu : la disparition de l’erreur n’est donc pas une garantie de conservation intégrale. Si un élément manque, utilisez Annuler avant de multiplier les essais, puis revenez à votre copie initiale.
Lorsque le résultat semble correct, enregistrez le brouillon et rouvrez-le. Le contrôle doit porter sur une version réellement enregistrée, pas seulement sur l’affichage momentané de l’éditeur. Si l’avertissement revient, notez à quel moment : immédiatement, après enregistrement ou lors de la réouverture.
Évitez d’appliquer d’abord cette commande à toute une page. Corrigez un cas représentatif, vérifiez-le, puis décidez si la même méthode convient aux autres occurrences. Une récupération satisfaisante sur un paragraphe ne prouve rien pour une galerie ou un bloc commercial.
Comparer une conversion sans sacrifier le contenu
Si la récupération ne convient pas, ouvrez le menu à trois points de l’avertissement. Lorsque Résoudre est proposé, examinez la comparaison entre le contenu existant et la version attendue. Repérez les suppressions annoncées avant de choisir la conversion en blocs. Si vous ne comprenez pas les différences, quittez cette comparaison sans accepter la transformation.
La conversion en HTML personnalisé constitue une autre possibilité, surtout pour conserver un fragment de balisage à faire examiner. Elle ne redonne pas les réglages du bloc d’origine. Ce choix convient davantage à une personne capable de vérifier le HTML ; pour un débutant, reconstruire un paragraphe simple dans un bloc natif peut être plus facile à maintenir.
Ne collez pas de code inconnu pour faire disparaître l’erreur. Certains éléments HTML peuvent être filtrés à l’enregistrement selon les permissions et l’environnement. Un aperçu correct avant sauvegarde ne suffit pas. Ne demandez pas de droits plus étendus ni de désactivation du filtrage pour contourner cette protection.
Restez sur la copie pendant cette comparaison. Si une conversion retire du texte, modifie les liens ou remplace le contenu par un bloc vide, arrêtez cette piste et utilisez l’original préservé pour la reconstruction ou la recherche d’une révision.
Quand utiliser le bloc Classique ou reconstruire le bloc
Certaines interfaces proposent une conversion en bloc Classique. Il s’agit d’un bloc intégré à l’éditeur de blocs, avec des outils proches de l’ancien éditeur ; ce n’est pas une invitation à installer l’extension Classic Editor ni à changer tout le site d’éditeur.
Essayez cette conversion uniquement sur la copie, si elle est disponible. Vérifiez les éléments conservés avant toute nouvelle transformation. Passer ensuite de Classique à plusieurs blocs est encore une conversion : ne l’enchaînez pas automatiquement pendant le diagnostic.
Pour un contenu simple, vous pouvez plutôt ajouter un bloc Paragraphe, Titre ou Image à côté du bloc défectueux. Réintroduisez le texte sans sa mise en forme problématique, recréez les liens et sélectionnez les images dans la médiathèque. Comparez les deux versions avant de retirer la mauvaise occurrence de la copie. Si cette reconstruction est correcte après réouverture, vous disposez d’une réparation ciblée à reporter, pas d’une raison de refaire toute la page.
Approche 2 : retrouver une version exploitable dans les révisions
Depuis l’éditeur du contenu original, ouvrez les réglages du document, puis l’onglet Article ou Page et la rubrique Révisions. Recherchez une version enregistrée avant l’apparition de l’erreur. Selon la version de WordPress, l’écran peut présenter un aperçu visuel ou une comparaison du contenu sous forme de HTML.
Repérez l’heure, l’auteur et les différences avant de choisir une version. Une sauvegarde automatique n’est pas un historique infini : la présence de révisions dépend aussi de ce qui a effectivement été enregistré et conservé. Si la rubrique n’offre aucune version utile, ne promettez pas de récupérer un texte jamais sauvegardé.
Avant de cliquer sur Restaurer, vérifiez la portée de cette commande. Une restauration complète peut remplacer les changements récents du document. Sur WordPress.com, la commande Restaurer peut rétablir directement la révision sur le site public. Organisez cette opération avec la personne responsable de la publication, plutôt que de la traiter comme un simple aperçu.
Conservez donc l’état actuel hors de WordPress et privilégiez la récupération de la seule partie nécessaire. Si vous ne possédez pas les droits permettant de consulter l’historique, transmettez la demande à un éditeur ou administrateur autorisé.
Récupérer une partie sans restaurer toute la page
Lorsque l’historique visuel permet de sélectionner les blocs, copiez la partie utile depuis la révision, puis quittez l’historique sans restauration complète. Collez ce contenu dans votre brouillon de travail et contrôlez-le. Cette méthode est documentée sur WordPress.com ; ne supposez pas que toutes les anciennes interfaces possèdent les mêmes commandes.
Si vous disposez seulement d’une comparaison HTML, utilisez-la pour identifier le passage recherché. Ne copiez pas une sélection approximative qui couperait les limites d’un bloc ou laisserait un groupe incomplet. Faites extraire le fragment correctement par une personne compétente si nécessaire, ou reconstruisez le contenu simple à partir du texte retrouvé.
Enregistrez et rouvrez la copie récupérée. Si le même bloc redevient non valide, l’ancienne version du contenu ne suffit pas : le problème peut tenir à la version actuelle du composant. Passez alors à la troisième approche au lieu de restaurer successivement plusieurs dates sur la page publique.
Approche 3 : identifier le composant qui fournit le bloc tiers
Un bloc tiers est fourni par une extension ou un thème, plutôt que par les blocs ordinaires du cœur WordPress. Relevez son nom affiché et, si l’avertissement le donne, son identifiant technique. Un administrateur pourra le rapprocher des composants installés, sans chercher une extension de remplacement au hasard.
Distinguez deux cas. Le bloc existe encore mais son ancien contenu ne se valide plus : une évolution de son format peut nécessiter une prise en charge par son éditeur. Le site annonce au contraire qu’il ne prend pas en charge ce bloc : il faut vérifier si son fournisseur est désactivé, absent ou non disponible dans ce contexte.
Ne supprimez pas les blocs manquants avant cet inventaire. Certains proposent de conserver leur contenu comme HTML, mais cela ne rétablit pas leurs fonctions. Sur un réseau multisite, faites intervenir le responsable du réseau pour les composants qu’un administrateur de site ne peut pas gérer. Sur WordPress.com, utilisez les accès réellement disponibles et le support du service si vous ne pouvez pas examiner le composant.
Vérifier une incompatibilité avant une migration
Comparez la date d’apparition du problème avec les mises à jour récentes. Consultez la documentation et les notes de version du fournisseur pour le bloc exact. Une simple proximité de dates ne prouve pas la cause : il faut reproduire le problème dans un environnement de test et changer un seul élément à la fois.
Une préproduction est une copie séparée du site destinée aux essais. Faites confirmer qu’elle utilise sa propre base et que les paiements, notifications et envois réels sont neutralisés. Testez d’abord le composant suspect, avec une sauvegarde et la possibilité de revenir à sa configuration précédente. Ne désactivez pas globalement les extensions en production.
Pour les blocs dont le format enregistré change, la compatibilité avec les anciens contenus relève du développeur du bloc. Transmettez-lui un exemple minimal et les versions concernées. Ne modifiez pas ses fichiers pour improviser une migration, et ne revenez pas durablement à une version ancienne sans examiner les conséquences de sécurité et de compatibilité.
Migrer vers des blocs maintenus lorsque c’est nécessaire
Si le composant est abandonné ou si une migration est recommandée par son fournisseur, établissez d’abord ce que chaque bloc accomplit. Un texte et une image peuvent souvent être reconstruits avec les blocs déjà présents. Un formulaire, une recherche ou un affichage calculé exige un remplacement fonctionnel, pas une simple copie de son apparence.
Certains blocs produisent leur résultat sur le serveur. Leur contenu enregistré peut ne pas contenir tout le rendu final ; conserver du HTML ne garantit donc ni le fonctionnement ni même la présence de toutes les informations. Faites valider la solution pour le type de bloc concerné avant de retirer son fournisseur.
Sur la copie, ajoutez le remplacement à côté de l’ancienne occurrence, réintroduisez les données utiles et contrôlez les fonctions. N’enlevez l’ancien bloc qu’après comparaison et sauvegarde. Pour plusieurs pages, commencez par une seule occurrence représentative et tenez une liste des contenus à reprendre. Une migration réussie se mesure aux usages conservés, pas au nombre d’avertissements supprimés.
Valider la réparation avant de modifier la page publique
Rouvrez le brouillon après enregistrement. Vérifiez que le bloc reste modifiable et que le message ne revient pas. Ouvrez ensuite son aperçu sur un écran large puis étroit. Contrôlez les titres, les textes alternatifs, l’ordre des éléments, les liens et les contenus masqués derrière un accordéon ou un onglet.
Pour un élément interactif, définissez un essai sans effet réel. Vérifier qu’un formulaire affiche ses champs ne prouve pas qu’il traite les réponses ; inversement, ne déclenchez pas un envoi vers de vrais destinataires pour tester une copie. Faites préparer un environnement adapté si une fonction importante doit être validée.
Une fois le résultat approuvé, reportez uniquement la correction nécessaire dans le contenu original avec les droits requis. Avant d’enregistrer une page déjà publiée, comparez la liste des éléments modifiés et évitez les changements simultanés d’un autre auteur. Contrôlez ensuite la page publique et rouvrez l’éditeur. Gardez les copies jusqu’à validation de ces deux contrôles.
Savoir quand arrêter et demander une aide ciblée
Arrêtez les conversions lorsque le contenu disparaît, qu’une fonction essentielle est perdue ou que plusieurs blocs reviennent en erreur. Adressez le dossier au développeur du bloc pour une incompatibilité précise ; sollicitez l’hébergeur pour une sauvegarde, une préproduction ou des erreurs côté serveur. Sur WordPress.com, le support peut orienter les contrôles propres au service.
Transmettez le message exact, les versions, le nom du bloc, les étapes de reproduction et le résultat d’un seul essai documenté. Retirez du contenu d’exemple les données personnelles, informations commerciales privées et valeurs d’authentification. Ne publiez pas un export complet de votre page confidentielle sur un forum.
Pour prévenir la répétition, gardez une sauvegarde avant les changements de composants et vérifiez quelques pages représentatives après mise à jour. Évitez les modifications manuelles de structure HTML dans les blocs que vous souhaitez continuer à éditer visuellement. La réparation est terminée lorsque le contenu utile et ses fonctions sont préservés, pas seulement lorsque l’encadré d’erreur a disparu.
