Un bloc, à lui seul, n’est qu’un composant d’affichage : ce qui le rend réellement utile, c’est la donnée qu’il conserve entre deux sessions d’édition. Cette donnée est structurée en attributs, chacun déclaré avec un type (string, number, boolean, array, object), une source d’extraction et éventuellement une valeur par défaut. Le bloc Paragraphe stocke ainsi son texte dans un attribut content, le bloc Image ses attributs url, alt et id.
Fonctionnement dans WordPress
Les attributs se déclarent dans block.json, sous la clé attributes, avec pour chacun une source comme html (extraite d’une balise du balisage sauvegardé), attribute (une valeur d’attribut HTML), query (une liste extraite d’éléments répétés) ou aucune source, auquel cas la valeur est stockée directement dans les commentaires HTML délimitant le bloc. C’est cette déclaration qui permet à l’éditeur de relire correctement un bloc après l’avoir enregistré, en réanalysant le contenu sauvegardé.
Exemple
{
"attributes": {
"niveau": { "type": "number", "default": 2 },
"contenu": { "type": "string", "source": "html", "selector": "p" }
}
}Pièges fréquents
- Changer la structure d’un attribut existant sans prévoir de migration casse les blocs déjà publiés avec l’ancienne forme : l’éditeur affiche alors une alerte de validation.
- Un attribut sans source stockée dans les commentaires HTML gonfle le contenu de l’article en base de données ; à l’inverse, une source mal choisie peut perdre une valeur lors du nettoyage du HTML.
- Les attributs liés à une source externe (champ personnalisé, entité) passent aujourd’hui plutôt par la liaison de données que par une déclaration statique dans
block.json.