# Vingt blocs enregistrés dans vingt fichiers sans registre central

> Symptômes de maintenance d'un plugin où chaque bloc s'enregistre indépendamment sans point d'entrée commun, et méthode de centralisation appliquée.

- Auteur : Clément Hadrot
- Publié le : 2026-09-02
- Mis à jour le : 2026-09-02
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/vingt-blocs-vingt-fichiers-sans-registre-central/

## L’essentiel

- Chaque bloc appelait sa propre fonction d'enregistrement dupliquée
- Un registre central évite d'oublier un bloc lors d'un changement global
- glob() suffit à automatiser la découverte des dossiers de blocs

Kaolin a repris la maintenance d'un plugin de blocs pour un client, développé sur plusieurs années par différents prestataires successifs. Le plugin comptait vingt blocs, chacun dans son propre dossier, chacun avec son propre appel à `register_block_type` placé dans son propre fichier PHP, lui-même accroché individuellement au hook `init` par sa propre fonction anonyme. Aucun fichier central ne listait les vingt blocs existants : il fallait parcourir l'arborescence entière pour savoir combien de blocs le plugin contenait réellement.

## Ce qu'on voit

```
// blocks/bandeau-promo/index.php
add_action( 'init', function () {
    register_block_type( __DIR__ );
} );

// blocks/fiche-produit/index.php
add_action( 'init', function () {
    register_block_type( __DIR__ );
} );

// ... répété dix-huit fois de plus, dans dix-huit fichiers différents
```

Chaque nouveau bloc ajouté au fil des années avait simplement copié ce même schéma en changeant le chemin, sans que personne ne remette en question cette répétition. Le fichier principal du plugin se contentait de charger chacun de ces fichiers via une longue liste de `require_once`, elle-même mise à jour manuellement à chaque ajout.

## Pourquoi c'est un problème

Le symptôme le plus concret est apparu lors d'un audit de sécurité commandé par le client : impossible de répondre rapidement à la question « combien de blocs ce plugin enregistre-t-il, et lesquels exposent des attributs en `show_in_rest` » sans parcourir intégralement l'arborescence à la main. Un second symptôme, plus coûteux, est apparu quand il a fallu appliquer une même modification à tous les blocs (l'ajout d'un support `anchor` uniforme) : impossible de vérifier par une simple recherche si tous les vingt fichiers avaient bien été mis à jour, faute de point d'entrée commun à partir duquel raisonner sur l'ensemble.

> L'essentiel à retenir : Chaque bloc appelait sa propre fonction d'enregistrement dupliquée ; Un registre central évite d'oublier un bloc lors d'un changement global ; glob() suffit à automatiser la découverte des dossiers de blocs

## Quoi faire : un registre central avec découverte automatique

La centralisation retenue s'appuie sur `glob()` pour découvrir automatiquement chaque dossier de bloc contenant un `block.json`, plutôt que de maintenir une liste statique à mettre à jour manuellement à chaque ajout :

```
add_action( 'init', function () {
    $dossiers = glob( __DIR__ . '/blocks/*/block.json' );

    foreach ( $dossiers as $chemin_manifeste ) {
        register_block_type( dirname( $chemin_manifeste ) );
    }
} );
```

Cette approche suppose au préalable d'avoir migré chaque bloc vers une déclaration par `block.json`, ce qui a représenté une partie non négligeable du travail de reprise, plusieurs des vingt blocs originaux datant d'avant la généralisation de ce fichier de manifeste.

## Ajouter un registre lisible pour l'audit

Au-delà de l'enregistrement automatique, un second fichier, généré cette fois manuellement mais court, liste les vingt blocs avec une ligne de description chacun, à des fins purement documentaires pour toute personne reprenant le plugin par la suite :

```
{
  "bandeau-promo": "Bandeau promotionnel avec compte à rebours optionnel",
  "fiche-produit": "Fiche produit avec galerie et note stellaire",
  "temoignage": "Bloc de témoignage client avec photo de profil"
}
```

## Ce que la centralisation a changé concrètement

- Ajouter un nouveau bloc ne demande plus qu'un nouveau dossier avec son `block.json`, sans aucune ligne à ajouter dans un fichier d'enregistrement central.
- Répondre à la question « combien de blocs, lesquels » se fait désormais en une commande `ls` sur le dossier `blocks/`.
- Une modification transverse (ajouter un support commun) se vérifie désormais par une recherche unique sur les `block.json`, plutôt que par une inspection fichier par fichier.

> Vingt fichiers qui font la même chose ne sont pas vingt blocs bien séparés, ce sont vingt copies du même oubli qui attend de se reproduire.

## Ce que cet article ne couvre pas

L'organisation en monorepo avec plusieurs paquets publiés séparément relève d'une échelle différente, pertinente pour une agence qui distribue ses blocs à travers plusieurs plugins indépendants. Ce cas concerne un unique plugin, avec un unique point d'entrée d'enregistrement à centraliser, un problème plus modeste mais bien plus répandu.

## Notre verdict

La centralisation via `glob()` a ramené la maintenance de ce plugin à un niveau raisonnable pour Kaolin : l'audit de sécurité suivant, mené un an plus tard sur ce même plugin, a pris une fraction du temps du premier, simplement parce que la structure elle-même répondait désormais à la question posée.