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

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 );
}

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.