Avant qu’un bloc n’apparaisse dans le menu d’insertion de l’éditeur, WordPress doit savoir qu’il existe, quel nom il porte, quelle icône l’accompagne et quels attributs il accepte. C’est ce référentiel partagé qui centralise toutes ces informations.
Deux registres qui se répondent
Côté PHP, un bloc est ajouté au registre du serveur avec register_block_type(), qui lit typiquement un fichier block.json. Côté JavaScript, la fonction équivalente de la bibliothèque @wordpress/blocks inscrit le bloc dans le registre de l’éditeur :
import { registerBlockType } from '@wordpress/blocks';
import metadata from './block.json';
registerBlockType( metadata.name, {
edit: () => <p>Aperçu dans l'éditeur</p>,
save: () => <p>Contenu enregistré</p>,
} );Le fichier block.json agit comme source commune entre les deux mondes, évitant de dupliquer manuellement le nom, la catégorie ou les attributs à deux endroits différents du code.
Bon à savoir
- La fonction
get_dynamic_block_names()permet d’interroger côté PHP la liste des blocs enregistrés comme dynamiques, utile pour du débogage. - Un bloc absent du registre JavaScript mais présent côté PHP s’affiche dans l’éditeur comme un bloc « non reconnu », même si son rendu public fonctionne normalement.
- La fonction
unregister_block_type()retire un bloc du registre côté serveur, une opération parfois utilisée pour masquer un bloc du cœur jugé indésirable sur un site donné. - Retirer un bloc du registre alors que du contenu existant l’utilise déjà ne supprime rien en base : l’éditeur affiche simplement ce contenu comme un bloc non reconnu à la prochaine ouverture.