# Enregistrer vos blocs plus vite avec wp_register_block_metadata_collection > Générer un manifeste de métadonnées avec wp-scripts build-blocks-manifest évite à WordPress de lire chaque block.json un par un au chargement, un gain net sur les extensions à nombreux blocs. - Auteur : Clément Hadrot - Publié le : 2024-11-14 - Mis à jour le : 2024-11-14 - Catégorie : Blocs Gutenberg - URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/wp-register-block-metadata-collection-manifeste/ ## L’essentiel - Un manifeste PHP évite une lecture disque et un décodage JSON par bloc - La commande build-blocks-manifest génère le fichier automatiquement - Le gain se mesure surtout sur les extensions à dix blocs ou plus Une extension interne à l'agence regroupe vingt-deux blocs pour différents besoins de mise en page. Avec l'enregistrement classique — un appel à `register_block_type()` pointant vers le dossier de chaque bloc — WordPress lit et décode vingt-deux fichiers `block.json` à chaque chargement de page admin, ce qui ajoute des opérations disque et un travail de décodage JSON répété inutilement, puisque ces fichiers ne changent qu'au déploiement d'une nouvelle version. `wp_register_block_metadata_collection()`, disponible depuis WordPress 6.7 (novembre 2024), permet de précompiler l'ensemble de ces métadonnées dans un unique fichier PHP généré au moment du build, que WordPress charge en une seule opération au lieu de vingt-deux lectures de fichiers séparées. ## Le problème que ça résout Sur un site avec plusieurs extensions de blocs actives, additionnées aux blocs natifs du cœur, le nombre total de fichiers `block.json` lus à chaque chargement d'écran d'administration grimpe vite. Chaque lecture implique un accès disque (ou au cache OPcache pour le PHP, mais pas pour le contenu JSON lui-même) suivi d'un `json_decode()`. Sur un hébergement avec un système de fichiers lent (stockage réseau, certains environnements mutualisés), cette accumulation devient mesurable. ## Générer le manifeste avec wp-scripts La commande `build-blocks-manifest`, ajoutée à `@wordpress/scripts`, parcourt un dossier de blocs et génère un fichier `blocks-manifest.php` qui contient un tableau PHP avec toutes les métadonnées déjà décodées, prêtes à l'emploi : ``` npx wp-scripts build-blocks-manifest --input=./src/blocks --output=./build/blocks-manifest.php ``` Le fichier généré ressemble à un simple tableau associatif PHP, sans aucune logique, uniquement des données : ``` array( 'apiVersion' => 3, 'name' => 'agence/bandeau-cta', 'title' => 'Bandeau CTA', // ... reste des métadonnées du block.json ), 'carte-info' => array( 'apiVersion' => 3, 'name' => 'agence/carte-info', // ... ), // ... vingt autres entrées ); ``` > L'essentiel à retenir : Un manifeste PHP évite une lecture disque et un décodage JSON par bloc ; La commande build-blocks-manifest génère le fichier automatiquement ; Le gain se mesure surtout sur les extensions à dix blocs ou plus ## Enregistrer le manifeste côté PHP Une fois le fichier généré, `wp_register_block_metadata_collection()` l'associe au dossier des blocs, puis chaque appel ultérieur à `register_block_type()` pointant vers ce même dossier consulte automatiquement le manifeste plutôt que de relire le `block.json` individuel : ``` add_action( 'init', function () { wp_register_block_metadata_collection( __DIR__ . '/build/blocks', __DIR__ . '/build/blocks-manifest.php' ); $dossiers_blocs = glob( __DIR__ . '/build/blocks/*', GLOB_ONLYDIR ); foreach ( $dossiers_blocs as $dossier ) { register_block_type( $dossier ); } } ); ``` Le comportement de `register_block_type()` reste identique du point de vue de l'API : elle continue d'accepter un chemin de dossier. La différence se joue en interne, dans la manière dont WordPress résout les métadonnées associées à ce chemin. ## Automatiser la génération dans le build Pour que le manifeste reste synchronisé avec les `block.json` sources, on l'ajoute comme étape du script de build dans `package.json`, après la compilation habituelle de `wp-scripts build` : ``` { "scripts": { "build": "wp-scripts build && wp-scripts build-blocks-manifest --input=./build/blocks --output=./build/blocks-manifest.php" } } ``` Oublier cette étape après une modification de `block.json` ne casse rien immédiatement, mais fait tourner un manifeste périmé : les nouveaux attributs ou supports ajoutés n'apparaîtraient pas tant que le manifeste n'est pas régénéré. On surveille ce point en intégrant la génération à la CI plutôt qu'en la laissant à la discipline individuelle des développeurs. ## Quand ça vaut vraiment le coup - Extensions à dix blocs ou plus : le gain devient perceptible sur le temps de chargement des écrans d'administration, en particulier sur des hébergements avec accès disque lent. - Sites avec plusieurs extensions de blocs maison actives simultanément : les manifestes s'additionnent sans conflit, chacun couvrant son propre dossier. - Pour une extension à deux ou trois blocs, le gain reste marginal ; la complexité ajoutée par l'étape de build supplémentaire n'est pas toujours justifiée. > Sur nos projets, on réserve cette optimisation aux extensions qui dépassent la dizaine de blocs, ou aux sites où plusieurs équipes empilent leurs propres extensions de blocs sans coordination — c'est précisément là que l'accumulation de lectures de fichiers devient un problème réel plutôt que théorique. ## En résumé `wp_register_block_metadata_collection()` ne change rien à la façon dont on écrit un bloc individuel : elle optimise uniquement la façon dont WordPress découvre et charge les métadonnées de plusieurs blocs à la fois. Une étape de build supplémentaire suffit à en profiter, à condition de l'intégrer proprement au pipeline pour ne jamais servir un manifeste désynchronisé de son `block.json` source.