Reconnaître un fournisseur de bloc absent
Après avoir désactivé une extension, vous ouvrez une page et WordPress annonce qu’il ne prend pas en charge un bloc. Le contenu peut rester partiellement visible, apparaître sous forme de code ou disparaître de l’aperçu. Vous cherchez à retrouver son édition et sa fonction sans effacer ce qui a été enregistré.
Recopiez le message exact et le nom technique du bloc lorsqu’il apparaît. Un bloc indisponible n’est pas le même problème qu’un bloc encore reconnu dont le contenu est déclaré inattendu ou non valide. Dans le premier cas, son fournisseur ou ses ressources doivent être identifiés ; dans le second, la validation du contenu demande un autre diagnostic.
Consultez aussi la page publique sans la modifier. Certains blocs conservent une représentation enregistrée qui reste visible ; d’autres dépendent d’un calcul du serveur. Un résultat public encore présent ne prouve pas que le composant est devenu inutile ou que ses fonctions interactives répondent.
Ne cliquez pas immédiatement sur Supprimer ou Conserver en HTML. Ces actions peuvent transformer le contenu à sauver. Commencez par l’inventaire du bloc, du composant désactivé et de la raison de cette désactivation.
Préserver l’état enregistré avant toute conversion
Gardez la page d’origine et une copie extérieure de son contenu accessible. Utilisez les commandes de copie lorsque l’éditeur les propose et contrôlez le titre, la section concernée et la fin du document. Ajoutez des captures pour conserver les réglages visibles et le résultat attendu.
Avant une réactivation, une restauration ou une migration, préparez une sauvegarde récupérable de la base et des fichiers. Les contenus du bloc et ses données peuvent être répartis entre l’article et le composant ; une image de l’écran ne les sauvegarde pas. Faites vérifier ce périmètre par la personne qui connaît l’outil.
Travaillez sur une copie séparée pour tester les changements. Évitez d’enregistrer l’original pendant que le fournisseur manque, surtout si vous avez commencé une conversion ou retiré une occurrence. Une sauvegarde enregistrée après transformation ne constitue pas forcément le retour à la structure initiale.
Gardez également la raison de la désactivation : simple essai, incident, remplacement prévu ou problème de sécurité confirmé. Elle détermine la suite. Réactiver un composant retiré pour une raison importante demande de résoudre cette cause, pas seulement de faire disparaître un message dans l’éditeur.
Identifier le nom du bloc et son fournisseur
Relevez le libellé visible et l’identifiant technique, s’il est fourni. Cet identifiant comprend généralement un espace de noms et un nom de bloc. Il aide à retrouver le fournisseur dans sa documentation, mais sa ressemblance avec le nom d’une extension ne constitue pas une preuve suffisante.
Dans Extensions, Extensions installées, un administrateur autorisé peut comparer les composants actifs et inactifs. Notez le nom exact, l’auteur, la version et les dépendances indiquées. Une extension peut fournir plusieurs blocs ; le titre de la section visible dans la page n’est pas nécessairement celui du produit.
Vérifiez l’historique récent : désactivation manuelle, mise à jour, changement de thème ou migration. Si le fournisseur venait d’un thème ou d’un ensemble livré avec lui, cherchez aussi dans sa documentation. N’installez pas une extension portant un nom proche en supposant qu’elle reconnaîtra automatiquement les anciens contenus.
Si vous ne pouvez pas identifier le composant, transmettez le nom du bloc et une capture nettoyée au responsable du site. Un accès de rédaction n’autorise pas forcément la gestion des extensions. Ne partagez pas de mot de passe et ne supprimez pas le bloc pour simplifier cette recherche.
Choisir entre réactivation, extraction et remplacement
La première approche cherche à remettre le fournisseur connu dans un état compatible. Elle convient à une désactivation accidentelle ou à une dépendance manquante, lorsque le composant peut être utilisé avec confiance. Elle ne demande pas d’ajouter un outil de réparation supplémentaire.
La deuxième récupère les éléments réellement présents dans le contenu enregistré. Elle peut convenir à un texte ou une illustration statique dont la fonction ne dépend pas d’un traitement particulier. Elle ne garantit pas la récupération de données qu’un composant devait calculer ou chercher ailleurs.
La troisième prépare un remplacement lorsque le fournisseur ne peut pas être conservé ou qu’une migration documentée est nécessaire. Elle demande de définir la fonction du bloc et de valider un remplacement sur une occurrence avant de généraliser.
Si vous ignorez encore la nature du bloc ou la raison de sa désactivation, restez à l’identification et à la préservation. La disparition du cadre d’avertissement ne constitue pas un critère suffisant : le contenu, son édition et ses usages doivent être comparés. Gardez la possibilité de revenir à la copie initiale à chaque étape.
Approche 1 : examiner l’extension déjà installée
Avec les droits requis, ouvrez Extensions, Extensions installées et cherchez le fournisseur confirmé. Consultez son état et les messages affichés. Si l’extension est présente mais inactive, ne la supprimez pas pour la réinstaller : cette opération peut avoir des effets différents d’une simple activation.
Lisez toute indication d’erreur ou de dépendance. Un composant peut avoir été désactivé parce que des fichiers sont incomplets, qu’une autre extension manque ou qu’une incompatibilité empêche son fonctionnement. Notez le message plutôt que de cliquer plusieurs fois sur Activer.
Si l’extension n’apparaît pas, faites vérifier par le responsable si elle a été supprimée, fournie autrement ou gérée par le réseau. Pour une réinstallation nécessaire, utilisez uniquement le fournisseur identifié et une source autorisée, avec sa procédure de compatibilité. Une archive trouvée au hasard ne constitue pas un retour fiable au composant d’origine.
Le répertoire de blocs peut parfois proposer un bouton d’installation à la place du bloc manquant. Ce bouton installe un composant ; il ne prouve pas à lui seul que cette version convient au site ni que la désactivation précédente était accidentelle. Faites valider ce choix avant de l’utiliser, particulièrement si l’original a été retiré volontairement.
Vérifier le thème, le réseau et les dépendances
Sur un réseau multisite, une extension peut être activée au niveau du réseau ou soumise à des règles qu’un administrateur de site ne contrôle pas. Demandez au responsable du réseau de vérifier son état sur le site exact. Le fait qu’elle fonctionne ailleurs dans le réseau ne suffit pas à établir le même contexte.
Sur WordPress.com, utilisez les fonctions disponibles dans le compte et le support lorsque la gestion nécessaire n’est pas accessible. N’essayez pas d’appliquer une procédure de fichiers conçue pour un hébergement indépendant si vous ne disposez pas de cet accès.
Comparez également les versions du cœur, du thème, du fournisseur et de ses dépendances avec sa documentation actuelle. Une version plus récente peut avoir changé un bloc ou ses prérequis ; une ancienne version retrouvée dans une sauvegarde peut ne plus convenir à l’environnement présent.
Si le fournisseur est actif mais que le bloc reste indisponible, faites vérifier ses réglages et le chargement de ses ressources. Une erreur dans l’éditeur peut empêcher une partie du composant de se déclarer correctement. N’ajoutez pas une seconde extension de blocs au hasard : un bloc similaire visuellement n’utilise pas nécessairement le même identifiant ni les mêmes données.
Isoler le bloc qui manque dans une composition copiée
Dans une instance de travail, copiez les blocs d’une composition non synchronisée. Collez-les dans le brouillon du site de destination, entre deux paragraphes témoins. Le transfert du contenu ne charge pas le fournisseur du bloc. Dans l’exercice, elle vient d’un site fictif et contient un cartouche « À emporter ». Les paragraphes « Repère avant la composition » et « Repère après la composition » indiquent l’endroit où il doit apparaître. Gardez le balisage reçu dans un fichier local et conservez une révision avant toute conversion. Si la composition reçue est synchronisée dans le site de destination, repérez ses usages avant de modifier sa source.
Lorsque le bloc est annoncé comme indisponible, ouvrez le code du document en lecture seule et relevez le nom technique du bloc. La copie de l’exercice contient atelier03/cartouche, avec un titre et un texte enregistrés dans les attributs du bloc. Le fournisseur n’est pas chargé. Le parseur de blocs du cœur le classe comme manquant, tandis que les deux paragraphes restent valides. Dans le rendu public, le cartouche dynamique est vide et les deux repères sont présents.
Gardez séparé le cas d’un bloc dont le type est reconnu mais dont le contenu enregistré ne correspond plus à ce que le bloc attend. Le témoin statique de la recette est inscrit au registre de l’éditeur, puis le parseur rejette son balisage volontairement incompatible. La présence du type et le verdict de validation répondent à deux questions différentes. Une réactivation peut faire revenir un bloc absent. Elle ne corrige pas automatiquement le balisage d’un bloc déjà reconnu.
Voici le commentaire de bloc de la recette. Il identifie le fournisseur fictif et permet de retrouver le titre et le texte même si le cartouche ne s’affiche plus. Relevez le nom technique dans votre propre copie.
<!-- wp:atelier03/cartouche {"title":"À emporter","text":"Le carnet de démonstration est fourni."} /-->Reconstruire le passage avec des blocs du cœur
Si le cartouche sert uniquement à présenter un titre et une phrase, reprenez ces données dans un bloc Titre et un bloc Paragraphe. Travaillez entre les deux repères dans la copie. Vérifiez que la phrase figure bien dans les données conservées ou dans une source éditoriale approuvée. Un rendu vide ne permet pas de deviner le contenu d’origine. S’il manque du texte, faites compléter la source avant de remplacer le bloc.
Dans l’exercice, le titre « À emporter » et la phrase « Le carnet de démonstration est fourni » sont récupérables. La reconstruction les rétablit dans le même ordre entre les deux repères, avec des blocs que le parseur reconnaît comme valides. Elle ne rétablit pas la présentation ni les fonctions spécifiques du fournisseur. Si le bloc d’origine calcule une valeur, affiche des données liées ou propose une interaction, relevez ce qui doit être conservé avant de retenir un remplacement statique.
Pour comparer l’autre approche, restaurez la révision de la composition copiée. Le nom du bloc tiers doit revenir dans le contenu enregistré. Tant que le fournisseur reste absent, le cartouche est de nouveau vide dans le rendu de la recette et les deux repères restent visibles. Gardez cette étape dans le relevé. Elle permet de tester ensuite la dépendance sur le même balisage, sans conserver la reconstruction en parallèle.
Rétablir la dépendance documentée et vérifier le retour
Si vous avez besoin du bloc d’origine, confirmez son nom technique, son fournisseur et la version prévue avant de remettre quoi que ce soit sur la copie. Un nom commercial proche ou un bloc visuellement semblable ne suffit pas à établir que le composant lit les mêmes données. Si le fournisseur est inconnu ou que la version compatible n’est pas établie, conservez la copie du bloc et utilisez les repères pour expliquer ce qui manque.
Le fournisseur de l’exercice est une extension fictive fournie avec la recette. Son manifeste indique le nom du bloc, la version 1.0.0 et les empreintes de ses fichiers. Lorsqu’elle est chargée dans l’instance locale, le bloc d’origine redevient reconnu et rend le cartouche avec le titre et la phrase attendus. Les deux paragraphes témoins restent en place. Le contenu enregistré est identique à celui de la composition copiée. C’est le fournisseur qui rétablit le rendu.
Désactivez ensuite cette dépendance de recette et rechargez la copie. Le parseur retrouve le bloc manquant et le rendu revient à celui de l’arrivée. Dans un site qui utilise le même fournisseur ailleurs, vérifiez la portée de sa désactivation avant de reproduire ce retour. Le test compare le registre côté éditeur et le rendu serveur avec des données fictives. Le collage, l’import visuel de la composition et la compatibilité d’un produit réel restent à vérifier dans leur propre environnement.
Réactiver le fournisseur sur une copie préparée
Faites d’abord confirmer que le composant peut être remis en service. Dans la préproduction séparée, conservez son état initial et les sauvegardes nécessaires. Neutralisez les notifications, paiements et intégrations externes avant les essais si le composant intervient dans ces fonctions.
Dans Extensions, Extensions installées, activez uniquement le fournisseur identifié et ses dépendances validées. Relevez le résultat de l’activation. Si un message d’erreur apparaît ou si le site ne répond plus normalement, arrêtez l’essai et faites revenir le composant à son état précédent avec le responsable technique.
Une activation peut exécuter des opérations propres à l’extension. La désactiver ensuite ne constitue donc pas une restauration automatique des données. Le retour arrière doit être prévu avec sa documentation et une copie récupérable, pas réduit à une succession de clics.
Ouvrez ensuite la page de contrôle sans accepter de conversion. Le bloc doit retrouver son nom et ses réglages, puis conserver son contenu après un enregistrement maîtrisé. Vérifiez aussi le rendu et la fonction. Si le bloc est reconnu mais affiche désormais une erreur de validation, gardez cette distinction et demandez au fournisseur sa procédure de compatibilité avec les anciennes versions.
Approche 2 : récupérer les éléments réellement conservés
Lorsque le fournisseur ne peut pas être remis en service immédiatement, examinez ce qui reste accessible sur la copie. Un passage textuel, des liens ou des références d’images peuvent être copiés dans un document local, puis reconstruits dans des blocs ordinaires adaptés.
Si l’éditeur propose Conserver en HTML, cette commande peut transformer le contenu conservé en bloc HTML personnalisé. Essayez-la uniquement sur la copie préservée et comparez le résultat à l’état de départ. HTML désigne le balisage qui structure une page ; conserver ce balisage ne rend pas automatiquement le bloc éditable avec les commandes de son ancien fournisseur.
Ne complétez pas le résultat avec un script trouvé sur un forum pour tenter de rendre un formulaire ou une animation fonctionnels. Si une fonction essentielle manque, passez à un remplacement documenté plutôt que de publier une représentation trompeuse.
Vérifiez le texte, les liens et les médias récupérés avant toute suppression de l’occurrence initiale. Si la conversion donne un bloc vide ou retire des informations, annulez-la et conservez la version d’origine. Après sauvegarde, le retour peut demander la copie ou une révision encore disponible ; réactiver l’extension ne reconstitue pas nécessairement un bloc que vous avez déjà transformé.
Comprendre les limites d’un rendu dynamique
Un bloc statique conserve une représentation de son contenu dans l’article. Un bloc dynamique peut calculer son résultat au moment de l’affichage : une liste filtrée, une information du site ou une fonction reliée à un service. Certains blocs combinent les deux mécanismes.
Un bloc dynamique peut enregistrer un contenu de secours, mais cette possibilité doit avoir été prévue par son fournisseur. D’autres conservent surtout leur identité et leurs paramètres, sans enregistrer tout le résultat visible. La présence d’une option HTML ne garantit donc ni un texte complet ni la récupération des données nécessaires.
Demandez au fournisseur ce qui est stocké dans l’article, dans ses propres réglages et dans des données extérieures. Pour une récupération depuis sauvegarde, faites identifier les éléments nécessaires et une extraction ciblée. Ne remplacez pas la base actuelle du site pour tenter de retrouver une seule zone de contenu.
Si vous disposez d’une capture ou d’une ancienne page visible, utilisez-la comme référence, sans confondre sa reproduction visuelle avec la restauration de la fonction. Un formulaire dessiné ou un nombre figé peut sembler correct tout en ne répondant plus au besoin des visiteurs. Faites accepter explicitement toute fonction temporairement indisponible avant de publier une solution simplifiée.
Approche 3 : préparer un remplacement adapté à la fonction
Si le composant est abandonné, incompatible sans correctif ou retiré pour une raison confirmée, décrivez ce que le bloc apporte réellement. Séparez le texte, la mise en page et la fonction : une carte de présentation n’a pas les mêmes besoins qu’un formulaire, une recherche ou un affichage de données actualisées.
Pour un contenu simple, les blocs déjà présents peuvent suffire. Reconstruisez sur la copie un ensemble de titres, paragraphes, images ou boutons et réintroduisez les données utiles. Ne cherchez pas à faire accepter l’identifiant de l’ancien bloc par un autre en modifiant son balisage à la main.
Pour une fonction particulière, demandez une migration ou un remplacement documenté. Faites vérifier les données reprises, les connexions externes et les limites du nouvel outil avant de l’installer. Un produit ressemblant dans une démonstration ne garantit pas qu’il saura importer les paramètres de l’ancien.
Ajoutez le remplacement à côté de l’ancienne occurrence dans l’environnement de test, comparez puis retirez seulement la copie devenue inutile. Gardez l’original préservé jusqu’à validation complète. Si une fonction manque encore, consignez-la et ne qualifiez pas la migration de terminée uniquement parce que le message d’indisponibilité a disparu.
Tester une occurrence avant de généraliser
Choisissez une page représentative, avec les réglages et contenus qui rendent ce bloc utile. Vérifiez son édition, son enregistrement et son affichage sur écran large puis étroit. Pour un élément interactif, préparez un essai dont les effets restent dans l’environnement isolé.
Contrôlez les liens, les médias, les éléments accessibles au clavier et les éventuelles données calculées. Une vérification d’apparence ne prouve pas qu’un formulaire traite ses réponses. À l’inverse, n’envoyez pas une réponse réelle à des destinataires de production pour terminer le test d’une copie.
Si plusieurs pages utilisent le bloc, établissez leur liste avant tout remplacement général. Vérifiez aussi les modèles et les compositions synchronisées : une modification d’un original partagé peut toucher plusieurs occurrences. Un résultat correct sur une page ne suffit pas à autoriser une conversion de masse.
Conservez pour chaque type d’usage la version de départ, le choix retenu et les contrôles réussis. Si les occurrences diffèrent fortement, préparez plusieurs cas représentatifs. Évitez les recherches et remplacements globaux dans la base : des blocs imbriqués, paramètres ou fonctions distincts pourraient être modifiés sans que vous puissiez les reconnaître ensuite.
Réintégrer la correction et conserver un retour fiable
Lorsque le résultat est validé, préparez le report de la seule correction nécessaire dans le site actif. Ne remplacez pas toute la production par une ancienne copie pour retrouver un fournisseur ou quelques blocs. Préservez les contenus récents et les réglages qui n’ont pas participé à l’essai.
Pour une réactivation, appliquez le parcours confirmé avec le responsable, puis vérifiez les pages concernées et les autres fonctions du composant. Pour un remplacement, réintroduisez les contenus validés dans leurs documents d’origine, avec les droits et le statut attendus. Contrôlez les adresses des médias pour éviter de dépendre de la préproduction.
Enregistrez puis rouvrez les documents. Comparez l’état du bloc, son contenu et son fonctionnement avec la référence. Gardez les copies jusqu’à cette validation et notez ce qui a été récupéré, remplacé ou laissé indisponible. Si le défaut revient, arrêtez les conversions et transmettez le cas reproductible au fournisseur.
Le dossier d’assistance doit contenir le nom du bloc, les versions, l’état de l’extension, la raison de sa désactivation, l’heure des essais et leurs résultats. Retirez les données privées et les secrets d’authentification. Pour les prochains changements, conservez cet inventaire de dépendances et vérifiez quelques pages avant de retirer définitivement un composant qui fournit leurs blocs.
