parent, ancestor et allowedBlocks : contrôler où un bloc peut s’insérer

Un bloc « bouton d’ajout au panier » qui n’a de sens qu’à l’intérieur d’un bloc « fiche produit », et qui pourtant apparaît dans l’inserteur sur n’importe quel article du site : c’est le genre de confusion qu’évitent trois propriétés de block.json encore mal connues en dehors des projets qui les ont réellement expérimentées.

parent : un parent direct, rien d’autre

{
	"name": "mon-projet/bouton-panier",
	"parent": [ "mon-projet/fiche-produit" ]
}

Avec parent, le bloc ne peut être inséré que directement à l’intérieur d’un bloc mon-projet/fiche-produit, comme enfant immédiat. S’il est niché plus profondément — par exemple à l’intérieur d’une colonne elle-même contenue dans la fiche produit — l’inserteur ne le proposera pas, car la relation n’est plus directe.

ancestor : un ancêtre, même éloigné

WordPress 6.0, sorti en mai 2022, introduit ancestor, qui assouplit cette contrainte : le bloc reste disponible tant qu’il se trouve n’importe où dans la descendance d’un bloc du type indiqué, même à plusieurs niveaux d’imbrication.

{
	"name": "mon-projet/badge-promo",
	"ancestor": [ "mon-projet/fiche-produit" ]
}

Ce badge peut alors être inséré dans une colonne, elle-même dans un groupe, lui-même dans la fiche produit, sans que la relation directe parent-enfant soit exigée. La différence entre les deux propriétés se résume simplement : parent vérifie le niveau immédiatement supérieur, ancestor vérifie toute la lignée jusqu’à la racine du bloc.

allowedBlocks : la restriction vue depuis le conteneur

Alors que parent et ancestor se déclarent sur le bloc enfant lui-même, allowedBlocks se déclare sur le bloc conteneur, dans son appel à InnerBlocks côté edit :

import { InnerBlocks } from '@wordpress/block-editor';

const ALLOWED_BLOCKS = [
	'mon-projet/bouton-panier',
	'mon-projet/badge-promo',
	'core/paragraph',
];

<InnerBlocks allowedBlocks={ ALLOWED_BLOCKS } />

Cette approche limite ce que l’auteur peut insérer à l’intérieur du conteneur, indépendamment de ce que les blocs enfants déclarent eux-mêmes via parent ou ancestor. Les deux mécanismes se complètent : allowedBlocks filtre depuis le conteneur, parent/ancestor filtre depuis le bloc lui-même, et un bloc qui échoue à l’un ou l’autre test reste absent de l’inserteur.

Combiner les trois pour un cas réel

Un bloc « fiche produit » qui doit accepter uniquement un bouton panier, un badge promo et du texte libre, tout en s’assurant que le bouton panier et le badge n’ont de sens nulle part ailleurs sur le site, combine les trois propriétés :

• La fiche produit déclare allowedBlocks pour limiter ce qui peut y être inséré.
• Le bouton panier déclare parent, car il doit rester directement enfant de la fiche.
• Le badge promo déclare ancestor, car il peut légitimement se retrouver niché dans une mise en page plus élaborée à l’intérieur de la fiche.

Un piège à surveiller

Une restriction trop stricte, posée trop tôt dans un projet, peut bloquer un usage légitime imaginé plus tard par l’équipe éditoriale, sans message d’erreur explicite pour l’utilisateur : le bloc disparaît simplement de l’inserteur, ce qui donne l’impression d’un bug plutôt que d’une restriction volontaire.

Avant de restreindre un bloc avec parent, mieux vaut se demander si ancestor ne conviendrait pas mieux : la contrainte stricte de parent se retourne souvent contre l’équipe éditoriale dès qu’elle imagine une mise en page un peu plus riche que prévu initialement.

En résumé

Ces trois propriétés, combinées avec discernement, évitent qu’un bloc pensé pour un contexte précis se retrouve inséré n’importe où sur le site, sans pour autant recourir à une validation manuelle côté PHP. L’arrivée de ancestor avec WordPress 6.0 comble une lacune réelle que parent, seul, laissait ouverte depuis les premières versions de l’éditeur de blocs.