wp_register_ability( 'wpmoderne/toggle-popup', [...] ) : cette seule ligne suffit, avec le plugin expérimental Abilities API installé en marge du cœur WordPress, à déclarer une action que n’importe quel assistant compatible pourra découvrir et déclencher. Au moment où ces lignes sont écrites, cette API n’est pas encore fusionnée dans le cœur de WordPress ; elle circule sous forme de plugin de fonctionnalité, disponible pour qui veut l’expérimenter avant son éventuelle inclusion future.
Sur un projet Elementor, l’intérêt est direct : transformer une action de widget — ouvrir une popup, filtrer une liste de produits, déclencher un formulaire — en une capacité que l’IA peut invoquer sans passer par une interface graphique. Ce billet documente un premier essai concret, volontairement limité à une seule action, sans prétendre couvrir le protocole MCP dans son ensemble ni l’exhaustivité des capacités déjà déclarées ailleurs dans le cœur.
Ce qu’est une capacité (ability) dans ce plugin expérimental
Une « ability » se déclare comme une fonction PHP identifiée par un espace de noms, accompagnée d’une description en langage naturel, d’un schéma d’entrée et d’un callback d’exécution. L’objectif du projet est de donner à un assistant IA une liste de capacités qu’il peut comprendre et invoquer, un peu à la manière d’une API REST mais pensée dès le départ pour être consommée par un modèle de langage plutôt que par un développeur humain.
La fonction centrale exposée par le plugin est wp_register_ability(), à appeler typiquement sur le hook wp_abilities_api_init :
add_action( 'wp_abilities_api_init', function() {
wp_register_ability( 'wpmoderne/toggle-popup', [
'label' => 'Ouvrir une popup Elementor',
'description' => 'Déclenche l\'affichage d\'une popup Elementor par son ID.',
'input_schema' => [
'type' => 'object',
'properties' => [
'popup_id' => [ 'type' => 'integer' ],
],
'required' => [ 'popup_id' ],
],
'execute_callback' => 'wpmoderne_trigger_popup',
] );
} );Relier la capacité à une action de widget Elementor
Elementor Pro gère l’affichage de ses popups via une classe interne accessible sous \ElementorPro\Modules\Popup\Module, qui expose des méthodes pour afficher un modèle de popup enregistré par son identifiant. La fonction de rappel déclarée plus haut peut s’appuyer directement dessus :
function wpmoderne_trigger_popup( $input ) {
$popup_id = absint( $input['popup_id'] );
if ( ! get_post( $popup_id ) ) {
return new WP_Error( 'invalid_popup', 'Popup introuvable.' );
}
return [
'status' => 'triggered',
'popup_id' => $popup_id,
'markup' => \Elementor\Plugin::instance()->frontend->get_builder_content_for_display( $popup_id ),
];
}Ce callback ne déclenche rien côté navigateur à lui seul : il retourne le balisage de la popup, à charge du client (l’assistant, ou l’application qui l’héberge) de l’insérer dans la page et de gérer son affichage effectif. C’est une limite importante à garder en tête : les capacités déclarées ici s’exécutent côté serveur, elles ne pilotent pas directement le DOM du navigateur.
Ce qu’Elementor ne propose pas nativement
Il faut être clair sur un point : à ce stade, Elementor ne propose aucune intégration native avec l’Abilities API. Tout le travail de déclaration, de validation des entrées et de connexion aux méthodes internes d’Elementor Pro repose sur du code maison, écrit dans un plugin d’extension du site. Les méthodes internes utilisées, comme get_builder_content_for_display(), ne font pas partie d’une API publique documentée et peuvent changer sans préavis d’une version à l’autre.
- Aucune capacité Elementor n’est déclarée par défaut, tout est à écrire manuellement
- Les méthodes internes utilisées ne sont pas garanties stables entre versions
- Le plugin Abilities API lui-même reste expérimental et son API peut évoluer avant toute fusion dans le cœur
Pourquoi s’y intéresser dès maintenant malgré tout
Même à ce stade précoce, l’exercice est utile pour comprendre la logique de conception : une capacité bien pensée n’expose jamais un accès brut à une fonction interne, mais une action métier claire, avec un schéma d’entrée validé et un message d’erreur explicite en cas de problème. C’est cette discipline qui rendra, le jour où l’API sera stabilisée et éventuellement intégrée au cœur, la connexion entre Elementor et des assistants IA réellement fiable.
Notre règle sur ce type d’expérimentation : ne jamais exposer une capacité qui touche à la suppression ou à la modification irréversible de contenu sans une validation explicite côté humain, quel que soit le niveau de confiance dans l’assistant appelant.
Pour aller plus loin
Ce premier essai reste volontairement modeste : une seule capacité, un seul widget, aucune gestion avancée des permissions. La suite logique consisterait à explorer la déclaration de plusieurs capacités liées à un même Kit Elementor, ou à croiser cette approche avec le protocole MCP une fois que les deux briques auront gagné en maturité — un sujet qui mérite un article à part entière plutôt qu’un paragraphe de conclusion.
