# Requires Plugins : ce que WP 6.5 change pour les extensions dépendantes

> WordPress 6.5 a ajouté l'en-tête Requires Plugins pour déclarer une dépendance entre extensions. Ce qui change vraiment pour celles qui en dépendent d'une autre.

- Auteur : Clément Hadrot
- Publié le : 2024-07-28
- Mis à jour le : 2024-07-28
- Catégorie : Extensions
- URL : https://wpmoderne.dev.wordpress-developpement.fr/extensions/wordpress-6-5-requires-plugins-dependances-extensions/

## L’essentiel

- Un en-tête déclaratif, pas un gestionnaire de paquets
- Le message d'incompatibilité s'affiche avant l'activation
- Ne remplace ni Composer ni une vérification runtime

« WordPress vérifie désormais si les dépendances déclarées d'une extension sont installées et actives avant de l'activer. » C'est en substance ce qu'annonçait la note de version de WordPress 6.5, sortie en avril 2024, à propos de l'en-tête `Requires Plugins`. Une ligne de trois mots dans un fichier d'en-tête d'extension, mais un vrai changement pour tous ceux qui publient des add-ons pensés pour fonctionner par-dessus une extension tierce.

Avant cette version, la seule façon de gérer ce cas était artisanale : un message d'admin notice au chargement, ou pire, un plantage silencieux si la classe attendue n'existait pas. Six mois après la sortie de WP 6.5, la question qui revient côté agence est simple : qu'est-ce que `Requires Plugins` change concrètement, et qu'est-ce qu'il ne fait toujours pas.

## Ce que fait réellement l'en-tête

`Requires Plugins` se déclare dans l'en-tête du fichier principal de l'extension, au même endroit que `Plugin Name` ou `Version`, avec la liste des slugs WordPress.org des extensions requises séparés par des virgules :

```
/**
 * Plugin Name: Mon Extension Réservations
 * Requires Plugins: woocommerce, advanced-custom-fields
 * Version: 2.3.0
 */
```

Concrètement, si `woocommerce` n'est pas installé et actif, WordPress affiche un message explicite sur l'écran des extensions et empêche l'activation de l'extension dépendante. Fini le plantage brut à l'activation faute d'une classe manquante : l'utilisateur voit tout de suite pourquoi ça ne s'active pas, et quelle extension installer en premier.

## Les slugs, pas les noms de package Composer

> L'essentiel à retenir : Un en-tête déclaratif, pas un gestionnaire de paquets ; Le message d'incompatibilité s'affiche avant l'activation ; Ne remplace ni Composer ni une vérification runtime

Le piège le plus fréquent est de confondre le slug attendu par `Requires Plugins` avec le nom du package Composer équivalent. L'en-tête attend le slug du répertoire WordPress.org de l'extension — celui qu'on trouve dans l'URL de sa fiche, par exemple `advanced-custom-fields` — pas le nom de la marque, ni le chemin du fichier principal. Pour une extension qui n'est pas hébergée sur WordPress.org, il n'existe pas d'équivalent officiel : l'en-tête ne peut vérifier que des dépendances qui y sont référencées.

C'est une limite importante côté agence : la plupart des extensions premium (constructeurs de page, extensions de licence privée) ne sont pas sur le répertoire officiel. Pour elles, `Requires Plugins` ne peut rien vérifier automatiquement, et il faut continuer à coder une vérification manuelle au chargement.

## Ce qui reste à la charge du développeur

L'en-tête vérifie la présence et l'activation, pas la version. Une extension qui a besoin de la fonction `wc_get_order()` introduite dans une version précise de WooCommerce doit toujours vérifier la version chargée au runtime :

- `Requires Plugins` bloque l'activation si la dépendance est absente ou inactive.
- Il ne vérifie ni la version minimale de la dépendance, ni sa configuration.
- Une vérification `defined( 'WC_VERSION' ) && version_compare(...)` reste nécessaire pour les contraintes de version.

Autre limite : l'en-tête n'empêche pas la désactivation ultérieure de la dépendance. Si un administrateur désactive WooCommerce après coup, l'extension dépendante reste active mais dysfonctionnelle. Un contrôle défensif au chargement (`plugins_loaded`, vérification de l'existence de la classe attendue, notice d'admin si absente) reste indispensable en complément.

## Le cas des dépendances internes à un groupe de sites

Pour une agence qui construit un cœur commun partagé entre plusieurs extensions maison — un motif fréquent sur les grands comptes — `Requires Plugins` fonctionne aussi très bien tant que l'extension cœur porte un slug stable, même si elle n'est jamais publiée sur WordPress.org : l'en-tête se contente de vérifier qu'un plugin portant ce slug de dossier est actif, information disponible localement sans appel réseau.

> Notre règle depuis WP 6.5 : toute extension d'agence qui dépend d'une autre extension d'agence déclare `Requires Plugins` avec le slug du dossier, même en interne. Ça coûte une ligne et ça évite un ticket support « ça ne s'active pas ».

## En résumé

Requires Plugins n'est ni un gestionnaire de dépendances complet, ni un remplaçant de Composer pour la gestion de versions PHP : c'est une déclaration simple, vérifiée par WordPress au moment de l'activation, qui remplace avantageusement les vérifications manuelles bricolées avant WP 6.5. Pour toute extension qui suppose la présence d'une autre, l'ajouter coûte une ligne et améliore immédiatement l'expérience d'installation, à condition de garder en tête ses deux limites : pas de contrôle de version, et pas de protection contre une désactivation après coup.