Une extension qui étend les fonctionnalités de WooCommerce, un module complémentaire qui nécessite une extension de base : les dépendances entre extensions existent depuis toujours dans l’écosystème WordPress, mais jusqu’en avril 2024, chaque auteur devait implémenter sa propre vérification, généralement via un message d’avertissement affiché dans l’administration après coup, une fois l’extension déjà activée sans son prérequis.
WordPress 6.5 a changé la donne avec l’en-tête Requires Plugins, une déclaration native qui permet à WordPress de vérifier et de bloquer l’activation d’une extension si ses dépendances ne sont pas satisfaites, avant même que le code de l’extension ne s’exécute. Un an après son introduction, cet article fait le point sur son fonctionnement réel et son niveau d’adoption.
Déclarer une dépendance
/**
* Plugin Name: Mon Module Complémentaire pour Acme CRM
* Requires Plugins: acme-crm
* Version: 1.0.0
*/La valeur attendue par Requires Plugins est le slug de l’extension requise tel qu’il apparaît dans son en-tête Plugin Slug ou, plus couramment, tel qu’il correspond au nom du dossier de l’extension sur WordPress.org. Plusieurs dépendances se déclarent en les séparant par une virgule :
Requires Plugins: acme-crm, woocommerceCe qui se passe concrètement dans l’administration
Si l’extension requise n’est pas installée, WordPress désactive le lien d’activation de l’extension dépendante dans la liste des extensions et affiche un message explicite indiquant quelle extension doit d’abord être installée. Si l’extension requise est installée mais désactivée, WordPress propose une activation combinée des deux extensions en une seule action, une amélioration d’ergonomie notable par rapport à l’ancien système de messages d’avertissement isolés.
// Vérification native, plus besoin de coder ceci soi-même :
add_action( 'admin_init', function () {
if ( ! is_plugin_active( 'acme-crm/acme-crm.php' ) ) {
deactivate_plugins( plugin_basename( __FILE__ ) );
add_action( 'admin_notices', function () {
echo '<div class="notice notice-error"><p>Ce module nécessite Acme CRM.</p></div>';
} );
}
} );Ce code, autrefois nécessaire dans presque chaque extension dépendante, devient largement redondant pour la vérification de base : WordPress empêche désormais l’activation en amont. Il conserve un intérêt pour des vérifications plus fines, comme une contrainte de version minimale de l’extension requise, que l’en-tête natif ne couvre pas à lui seul dans sa première implémentation.
La classe WP_Plugin_Dependencies pour aller plus loin
Pour des besoins programmatiques (afficher soi-même l’état des dépendances dans un écran personnalisé, par exemple), l’API expose des fonctions utilitaires accessibles côté PHP :
if ( function_exists( 'validate_plugin_requires' ) ) {
$resultat = validate_plugin_requires( plugin_basename( __FILE__ ) );
if ( is_wp_error( $resultat ) ) {
// Une ou plusieurs dépendances ne sont pas satisfaites
error_log( $resultat->get_error_message() );
}
}Cette vérification s’appuie en interne sur la classe WP_Plugin_Dependencies, introduite avec la même version, qui centralise la résolution des dépendances déclarées par l’ensemble des extensions actives du site.
Les limites actuelles de l’API
- Pas de contrainte de version :
Requires Pluginsvérifie uniquement la présence de l’extension requise, pas sa version minimale. Une extension dépendante activée avec une version trop ancienne de son prérequis ne sera pas bloquée par ce mécanisme seul. - Dépendance au slug WordPress.org : le mécanisme fonctionne nativement pour les extensions installées depuis le répertoire officiel ; une extension premium distribuée hors de ce circuit doit s’assurer que son slug déclaré correspond exactement au dossier réellement utilisé, sans quoi la vérification échoue silencieusement.
- Pas de gestion des dépendances circulaires : deux extensions qui se déclareraient mutuellement dépendantes l’une de l’autre créeraient une situation que l’API ne résout pas explicitement à ce jour.
Adoption encore partielle un an après
Un an après l’introduction de cette API, son adoption sur le répertoire WordPress.org reste inégale. De nombreuses extensions établies continuent d’utiliser leur système maison de vérification, par habitude ou pour conserver la compatibilité avec des versions de WordPress antérieures à 6.5 encore significativement représentées sur le parc installé. Les nouvelles extensions, en revanche, adoptent plus systématiquement Requires Plugins, sa mise en place représentant un coût de développement minimal comparé à l’ancien système de vérification manuelle.
Sur nos extensions publiées depuis l’an dernier, l’adoption de
Requires Pluginsa immédiatement réduit le volume de tickets de support liés à des activations dans le désordre, un problème auparavant récurrent chez les utilisateurs les moins techniques.
Coexister avec une vérification maison, le temps de la transition
/**
* Plugin Name: Mon Module Complémentaire pour Acme CRM
* Requires Plugins: acme-crm
* Requires at least: 6.5
*/
// Vérification de repli pour les sites encore sous WordPress 6.4 ou antérieur
add_action( 'admin_init', function () {
if ( version_compare( get_bloginfo( 'version' ), '6.5', '<' )
&& ! is_plugin_active( 'acme-crm/acme-crm.php' ) ) {
deactivate_plugins( plugin_basename( __FILE__ ) );
}
} );Cette double approche, en-tête natif pour WordPress 6.5 et au-delà, vérification manuelle en repli pour les sites plus anciens, reste la pratique la plus prudente tant qu'une part significative du parc installé n'a pas encore migré vers une version récente du cœur.
En résumé
L'en-tête Requires Plugins, introduit avec WordPress 6.5, standardise enfin la déclaration de dépendances entre extensions, un besoin resté sans solution native pendant près de vingt ans. Son adoption progresse mais reste incomplète, notamment à cause de l'absence de contrainte de version minimale, un manque que les auteurs d'extensions continuent de combler avec leurs propres vérifications complémentaires.
