# Auditer tous les blocs enregistrés sur un site, script à l’appui

> Avant de facturer un audit de performance, encore faut-il savoir exactement combien de blocs un site charge réellement. Un script WP-CLI répond en quelques secondes.

- Auteur : Clément Hadrot
- Publié le : 2021-12-02
- Mis à jour le : 2021-12-02
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/auditer-blocs-enregistres-script/

## L’essentiel

- get_dynamic_block_names liste les blocs à rendu serveur
- WP_Block_Type_Registry expose tout le registre côté PHP
- Un export CSV facilite la présentation au client

Une agence reprenait la maintenance d'un site institutionnel après le départ du prestataire précédent, sans aucune documentation technique transmise. Douze extensions actives, un thème enfant modifié à la main, et une question simple à laquelle personne ne pouvait répondre avec certitude : combien de blocs différents ce site propose-t-il réellement à ses rédacteurs, et lesquels sont effectivement utilisés dans le contenu existant ? Cette question, anodine en apparence, conditionnait pourtant tout le reste de l'audit à venir : impossible d'évaluer un risque de dépréciation ou un souci de performance sans connaître précisément le périmètre concerné.

Plutôt que de parcourir manuellement le code de chaque extension à la recherche d'appels à `register_block_type`, la solution la plus fiable consiste à interroger directement le registre de blocs de WordPress une fois toutes les extensions chargées, via un script WP-CLI dédié.

## Le registre central : WP_Block_Type_Registry

WordPress maintient en mémoire un registre unique de tous les types de blocs enregistrés, accessible via la classe `WP_Block_Type_Registry`. Sa méthode `get_all_registered()` retourne un tableau associatif de tous les blocs connus, chacun sous la forme d'un objet `WP_Block_Type` exposant son nom, sa catégorie, ses attributs déclarés et, si applicable, son callback de rendu.

```
<?php
// audit-blocs.php — à exécuter via wp eval-file
$registre = WP_Block_Type_Registry::get_instance();
$blocs    = $registre->get_all_registered();

foreach ( $blocs as $nom => $bloc ) {
    $dynamique = ! empty( $bloc->render_callback ) ? 'oui' : 'non';
    WP_CLI::line( sprintf(
        '%-40s | catégorie: %-15s | dynamique: %s',
        $nom,
        $bloc->category ?? 'n/a',
        $dynamique
    ) );
}
```

```
wp eval-file audit-blocs.php
```

## Distinguer les blocs réellement dynamiques

Pour se concentrer uniquement sur les blocs dont le rendu dépend d'un calcul serveur, souvent les plus sensibles en matière de performance, la fonction native `get_dynamic_block_names()` filtre directement le registre pour ne retourner que les noms des blocs disposant d'un `render_callback`, sans avoir à réimplémenter cette logique de filtrage soi-même.

```
$dynamiques = get_dynamic_block_names();
WP_CLI::line( 'Blocs dynamiques trouvés : ' . count( $dynamiques ) );
foreach ( $dynamiques as $nom ) {
    WP_CLI::line( '  - ' . $nom );
}
```

> L'essentiel à retenir : get_dynamic_block_names liste les blocs à rendu serveur ; WP_Block_Type_Registry expose tout le registre côté PHP ; Un export CSV facilite la présentation au client

## Croiser avec les blocs réellement utilisés

Connaître les blocs disponibles ne dit rien de ceux qui sont réellement présents dans le contenu publié. Une deuxième passe, appuyée sur `parse_blocks()` exécutée sur chaque article de la base, permet de constituer une liste des noms de blocs effectivement rencontrés dans `post_content`, puis de comparer les deux listes.

```
global $wpdb;
$utilises = array();
$posts = $wpdb->get_results( "SELECT ID, post_content FROM {$wpdb->posts} WHERE post_status = 'publish'" );

foreach ( $posts as $post ) {
    foreach ( parse_blocks( $post->post_content ) as $bloc ) {
        if ( $bloc['blockName'] ) {
            $utilises[ $bloc['blockName'] ] = true;
        }
    }
}

$jamais_utilises = array_diff( array_keys( $blocs ), array_keys( $utilises ) );
WP_CLI::line( 'Blocs enregistrés mais jamais utilisés : ' . count( $jamais_utilises ) );
```

Sur l'audit mené pour l'agence évoquée en introduction, ce croisement a révélé que près de la moitié des quarante-sept blocs enregistrés n'apparaissaient dans aucun article publié, souvent des vestiges d'extensions partiellement désinstallées ou de fonctionnalités testées puis abandonnées sans nettoyage du code correspondant.

## Exporter un rapport exploitable

Pour présenter ce résultat à un client sans jargon technique, un export au format CSV reste le plus lisible, avec une colonne indiquant le statut de chaque bloc.

```
$fp = fopen( 'audit-blocs.csv', 'w' );
fputcsv( $fp, array( 'Nom du bloc', 'Catégorie', 'Dynamique', 'Utilisé' ) );
foreach ( $blocs as $nom => $bloc ) {
    fputcsv( $fp, array(
        $nom,
        $bloc->category ?? 'n/a',
        in_array( $nom, $dynamiques, true ) ? 'oui' : 'non',
        isset( $utilises[ $nom ] ) ? 'oui' : 'non',
    ) );
}
fclose( $fp );
```

- Un audit de ce type prend quelques minutes d'exécution même sur une base de contenu conséquente.
- Le résultat sert de base objective à une discussion sur le nettoyage d'extensions inutiles.
- Rejouer ce script régulièrement permet de suivre l'évolution du nombre de blocs dans le temps.

> Un audit basé sur la lecture du code source d'extensions tierces prend des heures et reste incomplet. Un audit basé sur le registre de blocs prend quelques minutes et reste exhaustif, puisqu'il interroge directement ce que WordPress a réellement chargé.

## Ce qu'il faut retenir

Avant tout audit de performance ou de dépréciation portant sur les blocs d'un site, ce script d'inventaire devrait constituer la toute première étape, avant même d'ouvrir le code source d'une seule extension. Il fournit en quelques minutes une photographie précise et objective du périmètre réel à traiter, une donnée qui manque cruellement lors d'une reprise de site sans documentation.