« Bloc non conforme aux directives d’enregistrement » : ce message est apparu dans les journaux d’erreur d’un site de test après l’installation d’une version bêta de WordPress 7.0, sur un bloc personnalisé qui fonctionnait sans problème depuis plusieurs années. Aucune modification n’avait pourtant été apportée au code du bloc lui-même avant l’apparition de cette erreur, ce qui pointait vers un changement de comportement du cœur plutôt que vers une régression du bloc.
Le symptôme se manifestait précisément à l’appel de register_block_type() pour ce bloc particulier : au lieu de s’enregistrer normalement, WordPress consignait ce message dans les journaux et le bloc disparaissait purement et simplement de l’inserteur, sans planter le reste du site. À la date de rédaction, aucune note de version ni aucune page du manuel du développeur ne documentait ce comportement de façon officielle : ce qui suit reste donc une hypothèse de diagnostic construite sur une version de test, pas une description d’API stabilisée.
Symptôme : un bloc qui disparaît sans erreur fatale
Contrairement à une erreur PHP classique, ce contrôle observé sur cette bêta de WordPress 7.0 ne provoque pas d’écran blanc : le bloc concerné est simplement ignoré à l’enregistrement, comme s’il n’existait pas. Sans consultation active des journaux d’erreur (WP_DEBUG_LOG activé), rien ne signale directement la cause du problème — seul un utilisateur cherchant en vain le bloc dans l’inserteur alerte l’équipe technique.
Diagnostic : identifier la métadonnée en cause
Le journal d’erreur, une fois consulté sur cet environnement de test, précisait la métadonnée soupçonnée :
PHP Notice: Bloc "agence/temoignage" non conforme aux directives d'enregistrement :
le champ "textdomain" semble requis sur cette version de test pour les blocs
déclarant des chaînes traduisibles via translations.
Le block.json du bloc concerné déclarait bien des chaînes traduisibles dans son attribut title localisé, mais sans le champ textdomain explicitement renseigné — une omission restée sans conséquence sur les versions stables de WordPress, apparemment bloquante avec ce contrôle observé sur la bêta de 7.0 :
{
"apiVersion": 3,
"name": "agence/temoignage",
"title": "Témoignage client",
"category": "widgets",
"attributes": {
"citation": { "type": "string" }
}
}Piste corrective : ajouter le champ suspecté manquant
La piste corrective testée s’est limitée à ajouter le champ textdomain, correspondant au domaine de traduction déjà utilisé ailleurs dans le plugin, directement dans le block.json :
{
"apiVersion": 3,
"name": "agence/temoignage",
"title": "Témoignage client",
"category": "widgets",
"textdomain": "agence-blocs",
"attributes": {
"citation": { "type": "string" }
}
}Après cet ajout, le bloc réapparaît normalement dans l’inserteur dès le rechargement de l’éditeur, sans qu’aucune autre modification n’ait été nécessaire côté JavaScript ou PHP, sur cette version de test précise. Le message d’erreur disparaît des journaux dès l’enregistrement suivant. Rien ne garantit toutefois que ce comportement soit conservé tel quel jusqu’à la sortie stable de WordPress 7.0 : une bêta peut voir ses contrôles internes ajustés, assouplis ou retirés avant la version finale.
Pourquoi ce contrôle pourrait avoir été introduit
Si cette hypothèse se confirme, un tel durcissement viserait vraisemblablement à fiabiliser la traduction des blocs affichés dans l’inserteur : sans domaine de traduction correctement déclaré, certaines chaînes de blocs restent affichées dans leur langue d’origine sur des sites multilingues, un défaut déjà signalé de façon informelle par des contributeurs sur des sites de blocs personnalisés. Cela reste une supposition raisonnable, pas une confirmation lue dans une note de version.
- Sur cette bêta, le contrôle ne semblait s’appliquer qu’aux blocs déclarant explicitement des chaînes traduisibles dans leur métadonnée.
- Un bloc sans chaîne traduisible dans son
block.jsonn’était pas concerné par cette vérification, dans les tests menés. - La vérification observée se faisait uniquement à l’enregistrement, pas à l’exécution : aucun impact de performance constaté en dehors du chargement initial du bloc.
Un contrôle qui échoue silencieusement, sans écran blanc, reste le plus difficile à diagnostiquer : c’est souvent le journal d’erreur, pas l’écran du navigateur, qui donne la vraie réponse. Et sur une version bêta, mieux vaut toujours vérifier deux fois avant de généraliser une observation isolée.
Se prémunir avant une montée de version, confirmée ou non
- Activer
WP_DEBUG_LOGsur un environnement de préproduction avant toute mise à jour majeure, pour repérer ce genre de message dès son apparition plutôt qu’en production. - Auditer les fichiers
block.jsondu projet à la recherche de champs recommandés mais non obligatoires sur les versions précédentes, susceptibles de devenir requis lors d’une montée de version majeure. - Attendre la publication des notes de version officielles de WordPress 7.0 avant de généraliser une correction observée sur une bêta à l’ensemble d’un parc de sites en production.
Ce que cette observation ne permet pas d’affirmer
Cette piste, construite sur une seule version de test, n’a aucun rapport confirmé avec le processus de revue appliqué aux extensions soumises au répertoire officiel de WordPress.org, qui reste un processus humain distinct, déjà traité par ailleurs. Elle ne permet pas non plus d’affirmer que ce contrôle figurera tel quel dans la version stable de WordPress 7.0 : tant qu’aucune note de version ni page du manuel du développeur ne le confirme, ce billet documente une observation de terrain, pas une spécification.
En résumé
Le message « bloc non conforme aux directives », observé sur une bêta de WordPress 7.0, semble sanctionner une métadonnée manquante dans block.json, ici le champ textdomain pour un bloc déclarant des chaînes traduisibles. La piste corrective reste simple une fois la cause suspectée, mais son diagnostic a exigé de consulter activement les journaux d’erreur — et sa généralisation à la version stable de WordPress 7.0 reste, à ce stade, à confirmer par la documentation officielle.
