WordPress 6.5, sorti le 2 avril 2024, introduit un en-tête de plugin jusque-là absent du cœur : Requires Plugins. Une extension peut désormais déclarer explicitement les autres extensions dont elle dépend, avec leurs identifiants de dépôt, et WordPress bloque son activation si l’une d’elles manque. Pour un éditeur d’extension, c’est une amélioration de confort. Pour un hébergeur infogéré qui gère des mises à jour automatiques sur plusieurs centaines d’installations, c’est un paramètre supplémentaire à intégrer dans ses scripts avant que la première mise à jour automatique de la semaine ne s’exécute.
Le risque n’est pas théorique. Un script de mise à jour qui traite chaque extension indépendamment, sans tenir compte de l’ordre des dépendances, peut désactiver une extension satellite avant l’extension principale, ou inversement mettre à jour une extension principale vers une version qui exige une nouvelle fonctionnalité de sa dépendance restée en version antérieure.
Ce que change concrètement l’en-tête Requires Plugins
Techniquement, l’information se lit avec la fonction get_plugin_data(), qui retourne désormais un champ RequiresPlugins sous forme de chaîne d’identifiants séparés par des virgules, correspondant aux slugs du dépôt officiel d’extensions. WordPress s’en sert en interne pour désactiver une extension dépendante si sa dépendance est absente, et pour empêcher l’activation manuelle tant que la dépendance n’est pas installée.
Un script de gestion de parc peut interroger cette information sans attendre que WordPress affiche une erreur à l’utilisateur :
$plugins = get_plugins();
foreach ( $plugins as $file => $data ) {
if ( ! empty( $data['RequiresPlugins'] ) ) {
$deps = array_map( 'trim', explode( ',', $data['RequiresPlugins'] ) );
error_log( sprintf( '%s dépend de : %s', $file, implode( ', ', $deps ) ) );
}
}
Adapter l’ordre des mises à jour automatiques
Un script de mise à jour de parc doit désormais construire un graphe de dépendances avant d’appliquer quoi que ce soit, plutôt que de parcourir la liste des extensions dans un ordre arbitraire ou alphabétique. La logique proposée pour ce parc a été la suivante : lire les en-têtes de toutes les extensions actives sur un site, trier la liste pour que chaque dépendance soit traitée avant l’extension qui la déclare, puis appliquer les mises à jour dans cet ordre. Le WP-CLI reste l’outil le plus fiable pour cette opération, avec wp plugin list --fields=name,update_version --format=json pour obtenir un état exploitable par un script externe avant de lancer wp plugin update --all.
Le cas des extensions qui n’ont pas encore adopté l’en-tête
Beaucoup d’extensions publiées avant avril 2024 n’ont évidemment pas encore ajouté cet en-tête, et ne l’ajouteront que progressivement. Le script de mise à jour ne peut donc pas s’appuyer uniquement sur cette déclaration : elle vient compléter, sans le remplacer, un système existant de vérification de compatibilité par le champ Requires PHP et par les tests de sites témoins déjà en place sur la plupart des infrastructures infogérées sérieuses.
Un site témoin par famille de configuration
La pratique la plus robuste reste de maintenir, pour chaque combinaison représentative d’extensions rencontrée dans le parc, un site de test qui reçoit la mise à jour avant tous les autres. L’en-tête Requires Plugins réduit le nombre de combinaisons à surveiller de près, puisqu’il rend visibles des dépendances qui, avant WordPress 6.5, n’étaient documentées que dans la description textuelle de l’extension, quand elles l’étaient.
- Recenser les extensions qui déclarent désormais l’en-tête sur le parc concerné.
- Construire, pour chacune, la liste de ses dépendances directes.
- Vérifier qu’aucune mise à jour planifiée ne désactive une dépendance avant l’extension qui en a besoin.
- Conserver un site témoin par combinaison fréquente, mis à jour une heure avant le reste du parc.
Un en-tête de dépendance ne remplace pas une politique de test, mais il donne enfin un signal fiable à un script qui, avant WordPress 6.5, devait deviner.
Ce qui reste hors du périmètre de cet en-tête
Il faut garder à l’esprit une limite importante : Requires Plugins ne vérifie pas la compatibilité des versions, seulement la présence de l’extension. Une extension peut très bien être présente mais dans une version trop ancienne pour fonctionner avec la nouvelle version de sa dépendante. Le champ ne couvre donc qu’une partie du problème, celle de l’absence pure et simple, et un hébergeur sérieux continue de croiser cette information avec ses propres relevés de version.
Ce qu’on retient
WordPress 6.5 ne bouleverse pas la mécanique des mises à jour automatiques, mais il donne enfin un signal structuré là où un script de parc devait auparavant se contenter d’hypothèses. Pour un hébergeur infogéré, le travail consiste à lire cet en-tête avant chaque campagne de mise à jour, à réordonner les opérations en conséquence, et à ne pas relâcher pour autant la vigilance sur les sites témoins, qui restent le seul filet de sécurité contre les incompatibilités de version que cet en-tête ne couvre pas.
