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

> Restreindre un bloc à un parent direct ou à un ancêtre plus lointain (nouveauté de WordPress 6.0), et limiter les blocs enfants autorisés dans un conteneur.

- Auteur : Clément Hadrot
- Publié le : 2022-08-19
- Mis à jour le : 2022-08-19
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/parent-ancestor-allowedblocks-controler-insertion/

## L’essentiel

- parent exige un parent direct, ancestor tolère un ancêtre éloigné
- ancestor est disponible depuis WordPress 6.0, sorti en mai 2022
- allowedBlocks agit côté conteneur, parent et ancestor côté bloc lui-même

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é

> L'essentiel à retenir : parent exige un parent direct, ancestor tolère un ancêtre éloigné ; ancestor est disponible depuis WordPress 6.0, sorti en mai 2022 ; allowedBlocks agit côté conteneur, parent et ancestor côté bloc lui-même

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.