Gutenberg facilite la construction de contenu avec des blocs, mais parfois, vous avez besoin de contrôler quels blocs sont disponibles. Peut-être que vous travaillez sur le site d’un client et que vous voulez l’empêcher d’utiliser certains blocs. Ou peut-être que vous rationalisez l’expérience d’édition en supprimant les options inutiles.
Dans ce guide, nous allons explorer différentes façons de désactiver les blocs de Gutenberg, notamment :
- Utiliser l’interface utilisateur (UI) de WordPress pour masquer les blocs dans l’outil d’insertion.
- Verrouiller les blocs pour les empêcher d’être déplacés ou supprimés.
- Appliquer les restrictions des blocs avec PHP, y compris l’accès basé sur les rôles.
Cela dit, nous ne parlerons pas de la visibilité des blocs (afficher/masquer le contenu en fonction de conditions) ou de la désactivation de réglages spécifiques des blocs comme le texte ou les couleurs d’arrière-plan, ce qui est traité dans la section theme.json. Cependant, nous parlerons du verrouillage des blocs, qui est étroitement lié à la désactivation des blocs.
Toutes les méthodes de ce guide fonctionnent sans extension et s’appliquent à n’importe quel thème basé sur des blocs. C’est parti !
Désactiver les blocs avec l’interface utilisateur de WordPress
La suppression des blocs inutiles permet de rationaliser l’expérience d’édition et peut légèrement améliorer les performances du backend, car les blocs désactivés ne sont pas chargés en mémoire.
Tout utilisateur peut désactiver les blocs à partir du menu Préférences de l’éditeur de blocs. Vous pouvez le faire en cliquant sur le menu à trois points Réglages (⋮) dans le coin supérieur droit ouvre les préférences de l’éditeur. Ensuite, sous l’onglet Blocs, les utilisateurs peuvent décocher n’importe quel bloc pour le supprimer de l’outil d’insertion de blocs.
Par exemple, vous pouvez désactiver le bloc Citation en décochant simplement sa case, comme indiqué ci-dessous.
Si vous voulez aller plus loin, vous pouvez désactiver une catégorie de bloc entière. Par exemple, si vous décochez la catégorie Texte, tous les blocs liés au texte seront supprimés de l’outil d’insertion, ce qui garantit qu’ils ne seront plus utilisables. Cela peut être utile pour rationaliser l’éditeur et empêcher les utilisateurs d’accéder à des blocs inutiles.
Désactivation des blocs avec PHP
Il existe deux approches fondamentales et très distinctes pour autoriser ou empêcher l’utilisation d’un bloc avec WordPress. En fonction de vos besoins, vous pouvez choisir d’autoriser ou de refuser qu’un bloc soit disponible dans l’outil d’insertion.
Les deux approches peuvent être mises en œuvre à l’aide de PHP ou de JavaScript, chacune ayant ses propres avantages et inconvénients. PHP est généralement plus simple lorsqu’il s’agit d’autoriser des blocs, tandis que JavaScript est souvent plus efficace lorsqu’il s’agit de les refuser.
Nous utilisons PHP pour tous nos exemples afin de démontrer les différents cas d’utilisation.
Autoriser les blocs
Pour n’autoriser que des blocs spécifiques dans l’outil d’insertion, utilisez le filtre suivant. Cela permet de s’assurer que seuls les blocs désignés sont disponibles pour tous les utilisateurs :
add_filter('allowed_block_types_all', 'allowed_block_types_all_users', 10, 2 );
function allowed_block_types_all_users( $allowed_blocks, $block_editor_context ) {
return array(
'core/paragraph',
'core/heading',
'core/image',
'core/cover',
'core/list',
'core/list-item'
);
}Ce code doit être ajouté au fichier functions.php d’un thème enfant pour éviter que les modifications ne soient perdues lors de la mise à jour du thème.
Lorsque vous utilisez cette méthode, assurez-vous que tous les blocs enfants nécessaires sont inclus. Par exemple, si vous autorisez le bloc core/list, vous devez également inclure core/list-item pour éviter les erreurs.
Le filtre allowed_block_types_all permet aux développeurs de contrôler les blocs disponibles dans l’outil d’insertion. Il accepte deux paramètres :
$allowed_block_types– Un tableau ou un booléen définissant les blocs autorisés (par défaut : true).$block_editor_context– Fournit des informations sur l’état actuel de l’éditeur de blocs, y compris la publication en cours d’édition.
Autoriser des blocs spécifiques pour les contributeurs et les auteurs
Le code suivant restreint les blocs disponibles pour les utilisateurs qui n’ont pas la capacité publish_pages (contributeurs et auteurs) :
add_filter('allowed_block_types_all', 'allowed_block_types_for_non_admins', 10, 2);
function allowed_block_types_for_non_admins($allowed_blocks, $block_editor_context) {
// Apply restrictions if the user does not have the 'publish_pages' capability
if (!current_user_can('publish_pages')) {
// Define the allowed blocks for users without 'publish_pages' capability
$allowed_blocks = array(
'core/paragraph',
'core/heading',
'core/image',
'core/cover',
'core/list',
'core/list-item'
);
}
return $allowed_blocks;
}Dans l’exemple ci-dessus, les contributeurs et les auteurs ne peuvent utiliser que les blocs de paragraphe, d’en-tête, d’image, de couverture et de liste.
Autoriser les blocs pour des types de publication et des utilisateurs spécifiques
Le code suivant ajoute le bloc Codes courts à l’outil d’insertion lors de l’édition d’une page, mais le maintient indisponible pour les autres types de publications :
add_filter('allowed_block_types_all', 'allowed_block_types', 25, 2);
function allowed_block_types($allowed_blocks, $editor_context) {
$allowed_blocks = array(
'core/paragraph',
'core/heading',
'core/image',
'core/cover',
'core/list',
'core/list-item'
);
// Check if the editor context has a post object and if its type is 'page'
if (!empty($editor_context->post) && 'page' === $editor_context->post->post_type) {
$allowed_blocks[] = 'core/shortcode';
}
return $allowed_blocks;
}Gardez à l’esprit que puisque les contributeurs ajoutent les auteurs ne peuvent pas créer ou modifier des pages, le résultat n’apparaîtra que dans un article.
Tous les utilisateurs ne verront que six blocs, mais les administrateurs et les éditeurs verront également le bloc Code court disponible uniquement pour une page.
Dans notre exemple, l’impact que cela a sur les contributeurs et les auteurs est nul car, par défaut, ils ne peuvent pas ajouter de nouvelles pages. Cependant, l’utilisation d’une extension de gestion des rôles pourrait modifier cette capacité.
Autoriser les blocs basés sur l’ID de l’article
Si, dans certains cas, vous souhaitez autoriser un ensemble de blocs uniquement pour certains articles, voici comment vous pouvez le faire :
add_filter('allowed_block_types_all', 'allowed_block_types', 10, 2);
function allowed_block_types($allowed_blocks, $editor_context) {
// Check if the editor context has a post object
if (!empty($editor_context->post)) {
$post_id = $editor_context->post->ID;
// Define allowed blocks for specific post IDs
$allowed_blocks_by_post = array(
2 => array('core/paragraph', 'core/heading', 'core/image'),
3 => array('core/paragraph', 'core/heading', 'core/image')
);
// Check if the current post ID has a defined allowed blocks array
if (array_key_exists($post_id, $allowed_blocks_by_post)) {
return $allowed_blocks_by_post[$post_id];
}
}
return $allowed_blocks;
}Dans cet exemple, seuls les blocs de paragraphe, d’en-tête et d’image seront disponibles pour les articles 2 et 3.
C’est très bien pour un petit ensemble d’identifiants d’articles. Mais si vous avez une situation dynamique où des pages ou des articles sont ajoutés en continu, alors envisagez de filtrer sur les taxonomies et les champs personnalisés.
Refus de blocs
La liste d’autorisations est implicitement une forme de liste de refus, car les blocs qui ne sont pas disponibles sont refusés. Mais vous pouvez adopter une approche inverse si vous préférez autoriser la plupart des blocs à l’exception de quelques-uns. Dans cet exemple, les blocs d’en-tête et de couverture ne sont plus accessibles à aucun utilisateur.
add_filter('allowed_block_types_all', 'deny_blocks');
function deny_blocks($allowed_blocks) {
// Get all registered blocks
$blocks = WP_Block_Type_Registry::get_instance()->get_all_registered();
// Disable two specific blocks
unset($blocks['core/heading']);
unset($blocks['core/cover']);
return array_keys($blocks);
}Essentiellement, nous trouvons tous les blocs enregistrés, puis nous supprimons les blocs d’en-tête et de couverture.
Fais attention si vous pensez pouvoir désactiver n’importe quel bloc avec cette méthode. Si un bloc – central ou autre – est enregistré avec JavaScript, vous devez le désenregistrer avec JavaScript.
Refuser l’inscription de catégories entières de blocs
Si vous voulez supprimer des catégories entières de blocs, comme les Widgets, les Embeds ou les blocs de thème, utilisez cette approche :
add_filter('allowed_block_types_all', 'disable_blocks_by_categories', 10, 2);
function disable_blocks_by_categories($allowed_blocks, $editor_context) {
// Get all registered blocks
$registered_blocks = WP_Block_Type_Registry::get_instance()->get_all_registered();
// Specify the categories to disable
$categories_to_disable = array('widgets', 'embed', 'theme');
// Initialize an array to hold allowed block names
$allowed_block_names = array();
// Loop through registered blocks
foreach ($registered_blocks as $block_name => $block_type) {
// Check if the block has categories defined
if (isset($block_type->category)) {
// If the block's category is NOT in the disabled list, allow it
if (!in_array($block_type->category, $categories_to_disable, true)) {
$allowed_block_names[] = $block_name;
}
} else {
// If the block has no category defined, allow it by default
$allowed_block_names[] = $block_name;
}
}
return $allowed_block_names;
}Cette approche filtre des catégories entières de blocs, ce qui simplifie l’expérience de l’éditeur de blocs.
Verrouiller les blocs avec l’interface utilisateur de WordPress
Le verrouillage d’un bloc empêche qu’il soit déplacé ou supprimé tout en permettant la modification du contenu. Tout utilisateur peut verrouiller ou déverrouiller un bloc à tout moment en utilisant l’option Verrouiller dans la barre d’outils du bloc.
Pour verrouiller ou déverrouiller un bloc, cliquez sur les Réglages à trois points (⋮) sur le bloc, cliquez sur Verrouiller, puis la sélection de l’option Tout verrouiller active automatiquement les options Empêcher le mouvement et Empêcher la suppression, mais ces options peuvent aussi être appliquées séparément.
Il est important de savoir que même lorsqu’un bloc est verrouillé, les utilisateurs peuvent toujours modifier son contenu et son style, sauf si d’autres restrictions sont appliquées.
Empêcher les changements de style n’est pas possible avec la seule fonction de verrouillage. Pour restreindre le style d’un bloc, des modifications doivent être apportées au fichier theme.json dans le fichier
Pour les blocs contenant des éléments imbriqués, il existe une option supplémentaire permettant de verrouiller uniquement le bloc parent ou de verrouiller également tous les blocs internes. Cela permet de s’assurer que les éléments groupés restent structurés tout en autorisant des modifications contrôlées à l’intérieur de ces éléments.
Verrouiller les blocs avec PHP
Bien que l’interface utilisateur de WordPress permette un verrouillage de base des blocs, elle n’applique pas de restrictions à l’ensemble du site. Tout utilisateur ayant accès à un éditeur peut déverrouiller un bloc, ce qui facilite l’annulation du contenu verrouillé. Pour restreindre de façon permanente le verrouillage des blocs, PHP est la meilleure solution.
Avec PHP, vous pouvez complètement supprimer la possibilité de verrouiller et de déverrouiller les blocs, en veillant à ce qu’aucun utilisateur ne puisse contourner les restrictions. C’est ainsi que WordPress fonctionnait avant la sortie de WordPress 5.9, lorsque le verrouillage des blocs a été introduit.
Le verrouillage des blocs est utile dans de nombreux scénarios, en particulier lorsqu’il s’agit de maintenir un contenu structuré. En appliquant des restrictions de blocs avec PHP, vous pouvez :
- Préserver l’intégrité de la conception en empêchant les utilisateurs de modifier les blocs clés.
- Empêcher les modifications accidentelles susceptibles de perturber la mise en page.
- Rationaliser la création de contenu en réduisant les options inutiles.
- Assurer la cohérence des modèles et des gabarits, en particulier pour les projets des clients.
Suppression de la fonctionnalité de verrouillage des blocs pour tous les utilisateurs
L’extrait PHP suivant désactive entièrement le verrouillage des blocs, empêchant ainsi tout utilisateur de verrouiller ou de déverrouiller des blocs :
add_filter('block_editor_settings_all', 'example_disable_block_locking', 10, 2);
function example_disable_block_locking($settings, $context) {
$settings['canLockBlocks'] = false;
return $settings;
}Avec cette application, la fonction de verrouillage des blocs est complètement supprimée de l’éditeur de blocs. Les utilisateurs ne verront pas les options de verrouillage, et personne, quel que soit son rôle, ne pourra verrouiller ou déverrouiller des blocs.
Pour les utilisateurs qui hébergent leur site chez Kinsta, apporter des modifications aux fichiers de thème est facile et sécurisé en utilisant SFTP, qui est activé par défaut pour tous les sites WordPress.
Restreindre le verrouillage des blocs en fonction des rôles des utilisateurs
Au lieu de supprimer complètement le verrouillage des blocs, vous pouvez vouloir restreindre qui peut verrouiller et déverrouiller les blocs. L’extrait PHP suivant permet uniquement aux administrateurs et aux éditeurs de modifier le verrouillage des blocs, tandis que les auteurs et les contributeurs ne peuvent pas déverrouiller un bloc défini par un administrateur ou un éditeur.
add_filter('block_editor_settings_all', 'example_disable_block', 10, 2);
function example_disable_block ($settings, $context ) {
if (
isset( $context->post ) &&
'post' === $context->post->post_type &&
! current_user_can( 'edit_theme_options' )
) {
$settings['canLockBlocks'] = false;
$settings['codeEditingEnabled'] = false;
}
return $settings;
}Cette approche limite le contrôle des blocs aux utilisateurs ayant la capacité edit_theme_options, généralement les administrateurs et les éditeurs. Les auteurs et les contributeurs ne pourront pas déverrouiller les blocs définis par les utilisateurs de niveau supérieur.
De plus, l’accès à l’éditeur de code est désactivé, ce qui empêche les utilisateurs de modifier manuellement le balisage des blocs pour contourner les restrictions. Cela garantit que les blocs verrouillés restent inchangés, même pour les utilisateurs ayant des connaissances en codage.
Résumé
Le choix d’autoriser ou de refuser des blocs – ou une combinaison des deux – dépend de vos besoins spécifiques. Vous pouvez vouloir restreindre certains blocs pour une expérience d’édition plus propre, renforcer la cohérence de la conception ou contrôler l’accès en fonction des rôles des utilisateurs.
En parlant de rôles d’utilisateurs, les capacités peuvent être modifiées pour personnaliser davantage la façon dont les blocs sont gérés. Cela ouvre encore plus de possibilités au-delà de ce que nous avons couvert ici.
Gardez à l’esprit que WordPress évolue avec le temps. Les futures mises à jour pourraient introduire de nouvelles façons de gérer les blocs ou modifier les fonctionnalités existantes, c’est pourquoi il est important de rester au courant du développement de WordPress pour s’assurer que votre approche reste efficace.
Vous cherchez une solution d’hébergement sécurisée et adaptée aux développeurs ? Kinsta facilite la gestion de vos fichiers WordPress, y compris l’édition des fichiers de thème via SFTP, ce qui garantit des personnalisations sûres et transparentes sans risquer de compromettre la stabilité du site.
Bud Kraus has been working with WordPress as an in-class and online instructor, site developer, and content creator since 2009. He has produced instructional videos and written many articles for WordPress businesses.
