Faut-il laisser un client final accéder à un widget qui, chez WP Moderne, a déjà provoqué deux régressions visuelles en production depuis le passage à l’éditeur V4 d’Elementor ? La réponse évidente est non, mais Elementor ne propose pas nativement de granularité fine par widget selon le niveau de maîtrise de l’utilisateur — seulement des restrictions globales par rôle sur l’accès à l’éditeur lui-même.
La solution consiste à filtrer la liste des widgets disponibles au moment du chargement de l’éditeur, en se basant sur une capacité personnalisée plutôt que sur le rôle générique de l’utilisateur, ce qui permet d’accorder l’accès à une personne précise sans devoir créer un rôle entier pour ce cas particulier.
Repérer les widgets à restreindre
Sur un projet ayant migré vers les éléments atomiques d’Elementor, certains widgets restent marqués comme expérimentaux dans la documentation officielle ou se sont révélés instables lors de tests internes : rendu incohérent entre les classes globales et les styles locaux, ou comportement imprévisible lors de la duplication d’un composant. La liste de ces widgets à restreindre doit être maintenue à jour dans un tableau de constantes, réévalué à chaque montée de version d’Elementor.
Créer la capacité dédiée
Plutôt que de tester le rôle de l’utilisateur, on ajoute une capacité personnalisée, attribuable individuellement, qui distingue les profils avertis des autres :
add_action( 'admin_init', 'ajouter_capacite_widgets_avances' );
function ajouter_capacite_widgets_avances() {
$role = get_role( 'administrator' );
if ( $role && ! $role->has_cap( 'utiliser_widgets_elementor_avances' ) ) {
$role->add_cap( 'utiliser_widgets_elementor_avances' );
}
}Un profil éditeur particulier, formé sur les nouveaux widgets, peut ensuite recevoir individuellement cette capacité via $user->add_cap(), sans que l’ensemble des éditeurs du site n’y ait automatiquement accès.
Filtrer la liste des widgets côté éditeur
Elementor expose un filtre permettant de retirer des widgets de la liste avant leur enregistrement dans le panneau de l’éditeur :
add_action( 'elementor/widgets/register', 'restreindre_widgets_instables', 20 );
function restreindre_widgets_instables( $widgets_manager ) {
if ( current_user_can( 'utiliser_widgets_elementor_avances' ) ) {
return;
}
$widgets_a_restreindre = array(
'atomic-carousel',
'atomic-tabs-v2',
'atomic-accordion-nested',
);
foreach ( $widgets_a_restreindre as $slug ) {
$widgets_manager->unregister( $slug );
}
}Pourquoi une liste blanche est plus sûre qu’une liste noire
Sur ce type de restriction, mieux vaut inverser la logique dès que le nombre de widgets atomiques dépasse la dizaine : plutôt que d’énumérer les widgets à interdire (liste qui s’allonge à chaque version), on définit une liste blanche de widgets validés en production, et tout nouveau widget ajouté par une mise à jour d’Elementor reste masqué par défaut jusqu’à validation explicite par l’équipe technique.
Prévenir plutôt que simplement masquer
Un widget qui disparaît sans explication laisse un client perplexe s’il en a déjà entendu parler via une communauté Elementor. Un message dans l’interface, affiché à la place du widget masqué dans le panel, indique qu’il est en cours de validation interne et sera disponible prochainement, ce qui évite un ticket support inutile.
- Widget disponible : accès direct sans restriction
- Widget en validation : masqué avec message explicatif pour les profils non avertis
- Widget validé récemment : accès élargi à tous les éditeurs après une période de test interne
Restreindre temporairement un widget récent n’est pas un désaveu de la technologie ; c’est simplement reconnaître que la maîtrise d’un nouvel outil précède toujours sa mise entre toutes les mains.
Documenter la levée progressive des restrictions
Chaque widget retiré de la liste blanche doit porter une date de réévaluation prévue, consultée lors des mises à jour de l’équipe technique, pour éviter qu’un widget parfaitement stabilisé reste bloqué par oubli plusieurs mois après sa validation réelle.
Notre verdict
La granularité par capacité personnalisée, combinée à une liste blanche plutôt qu’une liste noire, offre un contrôle fin sans complexifier la gestion des rôles existants. Le coût de mise en place reste modeste face au gain en tranquillité d’esprit, particulièrement utile pendant la période de stabilisation qui accompagne toute transition majeure d’éditeur.
