Un rédacteur qui tape « galerie » dans l’inserteur de blocs et voit surgir une suggestion d’extension à installer depuis le répertoire WordPress.org : sur un site client, ce genre de proposition sème le doute. « Faut-il l’installer ? C’est officiel ? » Sur des projets d’agence où chaque extension passe par une validation, ce comportement par défaut n’a pas sa place.
WordPress propose deux mécanismes distincts qui vont chercher du contenu à distance dans l’éditeur : le répertoire de blocs (suggestions d’extensions) et les patterns de la bibliothèque WordPress.org. Les couper tous les deux redonne un éditeur qui ne dépend que de ce qui est réellement installé.
Couper les suggestions du répertoire de blocs
Depuis WordPress 5.5, l’inserteur propose d’installer des extensions fournissant un bloc correspondant à la recherche tapée. Ce comportement est piloté côté PHP par la capacité install_plugins, mais aussi par un filtre dédié qui coupe l’appel réseau vers l’API des extensions :
add_filter( 'block_editor_settings_all', function ( $settings ) {
$settings['__experimentalBlockDirectory'] = false;
return $settings;
} );Sur les versions plus récentes, la méthode la plus fiable reste de retirer la capacité d’installation de blocs distants pour les rôles qui n’en ont pas l’usage, via un filtre sur map_meta_cap ou en ajustant les capacités du rôle avec add_cap() / remove_cap().
Couper les patterns distants de WordPress.org
Depuis WordPress 5.8, l’onglet « Modèles » de l’inserteur télécharge en direct des patterns depuis le répertoire de patterns WordPress.org. Sur un projet où seuls les patterns du thème doivent apparaître, on coupe cet appel avec :
remove_theme_support( 'core-block-patterns' );Cette instruction s’ajoute simplement dans functions.php, au niveau racine (pas dans un hook after_setup_theme obligatoirement, mais c’est l’endroit conventionnel) :
add_action( 'after_setup_theme', function () {
remove_theme_support( 'core-block-patterns' );
} );Vérifier que rien ne reste chargé
Après application des deux filtres, j’ouvre l’onglet réseau des outils de développement du navigateur et je filtre sur wordpress.org en ouvrant l’inserteur de blocs. Aucune requête ne doit plus partir vers api.wordpress.org/patterns ni vers le point d’entrée du répertoire de blocs.
- Ouvrir l’inserteur (icône « + ») et rechercher un mot-clé absent du site, par exemple « calendrier ».
- Vérifier qu’aucune carte « Installer » n’apparaît sous les résultats.
- Ouvrir l’onglet « Modèles » et vérifier qu’il ne présente que les patterns enregistrés par le thème.
Cas particulier : les sites multisites
Sur un réseau multisite, ces filtres doivent être appliqués soit dans une extension mu-plugin (chargée automatiquement sur tous les sites du réseau), soit dans le thème s’il est partagé par l’ensemble des sites. Un mu-plugin évite d’avoir à reconfigurer chaque nouveau site créé sur le réseau.
// wp-content/mu-plugins/couper-suggestions-distantes.php
<?php
add_action( 'after_setup_theme', function () {
remove_theme_support( 'core-block-patterns' );
} );
add_filter( 'block_editor_settings_all', function ( $settings ) {
$settings['__experimentalBlockDirectory'] = false;
return $settings;
} );Un éditeur qui ne propose que ce qui est validé par l’agence évite bien des allers-retours avec le service support, surtout sur des comptes rédacteurs sans droit d’installation.
Ce que cette désactivation ne couvre pas
Ces deux filtres ne touchent pas aux patterns déclarés par le thème actif via register_block_pattern(), ni à ceux fournis par des extensions installées localement. Ils ne bloquent pas non plus les appels de vérification des mises à jour de WordPress, qui suivent un mécanisme distinct.
Notre verdict
Sur un site géré en agence, avec un catalogue d’extensions validées et un thème qui fournit déjà ses propres patterns, couper ces deux mécanismes distants est presque toujours une bonne idée : l’éditeur gagne en rapidité de chargement et le rédacteur ne se retrouve jamais face à une proposition d’installation qu’il ne saurait pas juger.
