Vingt-trois sites, vingt-trois historiques différents : certains encore sur une version du cœur vieille de plusieurs années, d’autres à jour, quelques-uns avec des extensions maison jamais publiées sur le répertoire officiel. C’est le quotidien de toute agence qui a grandi par rachat de portefeuille client plutôt que par construction homogène depuis le départ. Sur un tel parc, WP-CLI devient l’outil qui évite de se connecter en SSH à chaque site pour vérifier un état ou lancer une mise à jour, à condition que l’outil lui-même reste fiable face à cette hétérogénéité.
Cet article ne couvre pas l’installation initiale de WP-CLI, déjà traitée ailleurs, mais se concentre sur ce que cette version récente change concrètement pour une équipe qui administre un parc de versions disparates au quotidien.
Des messages d’erreur enfin exploitables sur les mises à jour
Sur les versions précédentes, une commande wp core update échouant sur un site aux permissions de fichiers mal configurées renvoyait souvent un message générique, peu utile pour distinguer un problème de droits d’un problème de connexion réseau ou d’espace disque insuffisant. Cette version affine ces retours, ce qui change concrètement le travail quotidien d’une équipe qui exécute ces commandes en masse sur un parc hétérogène, via un script qui boucle sur une liste d’alias.
wp @toutlesite core update --dry-run 2>&1 | tee rapport-maj.log
Pourquoi ce détail compte sur un grand parc
Quand une même commande s’exécute sur plusieurs dizaines de sites via un alias groupé, la qualité du message d’erreur détermine directement le temps passé à trier les échecs. Un message qui distingue clairement « permissions insuffisantes sur wp-content » d’un « délai réseau dépassé » permet de router chaque échec vers la bonne personne sans reproduire manuellement chaque commande site par site.
Une gestion des alias plus robuste face aux architectures mixtes
Le fichier de configuration wp-cli.yml, quand il définit des alias vers des sites hébergés sur des architectures différentes (certains en SSH direct, d’autres via un conteneur, d’autres encore en accès local), pouvait auparavant produire des comportements incohérents selon l’ordre de résolution des alias imbriqués. Les correctifs apportés dans cette version stabilisent cette résolution, ce qui réduit le nombre de scripts de contournement qu’une agence doit maintenir pour compenser ces incohérences.
@production:
ssh: deploy@serveur-un.exemple.fr
@production-legacy:
ssh: deploy@serveur-deux.exemple.fr:2222
@local:
path: /var/www/local
Correctifs qui évitent des contournements maison
Sur un parc de sites hétérogène, il est fréquent que l’équipe développe, au fil des années, de petits scripts internes pour compenser un comportement jugé peu fiable d’une commande native. Cette version corrige plusieurs de ces comportements historiques, ce qui permet de revenir progressivement à la commande native plutôt que de maintenir un contournement devenu difficile à justifier :
- La commande
wp plugin list --format=jsonretourne désormais des champs plus cohérents entre les sites où l’extension est activée à l’échelle du réseau et ceux en simple installation. - La détection automatique du chemin de WordPress est plus fiable dans les arborescences profondes typiques des installations héritées, où
wp-config.phpa été déplacé hors de la racine. - Les messages liés à
wp db checkdistinguent mieux un problème de connexion d’un problème d’intégrité des tables, ce qui évite d’alerter à tort sur une base corrompue.
Ce qui reste à surveiller malgré ces améliorations
Ces correctifs ne dispensent pas de la vigilance habituelle sur un parc hétérogène. Les sites tournant encore sur une version ancienne du cœur peuvent présenter des incompatibilités avec certaines commandes récentes, en particulier celles qui s’appuient sur des fonctions internes introduites dans des versions plus modernes du cœur. La bonne pratique reste de vérifier la compatibilité annoncée de chaque commande avant de l’exécuter en masse sur l’ensemble du parc, plutôt que de supposer une compatibilité universelle.
| Avant cette version | Avec cette version |
|---|---|
| Message d’erreur générique sur core update | Cause distinguée (droits, réseau, espace disque) |
| Résolution incohérente des alias imbriqués | Résolution stabilisée quelle que soit l’architecture |
| Scripts maison pour contourner wp db check | Diagnostic natif suffisant dans la majorité des cas |
La règle que nous appliquons avant toute montée de version d’un outil aussi central que WP-CLI sur un parc de cette taille : la tester d’abord sur les trois ou quatre sites les plus atypiques du portefeuille, jamais sur le site le plus récent et le plus propre.
En résumé
Cette version de WP-CLI n’apporte pas de nouvelle commande spectaculaire, mais une série de correctifs qui, cumulés, réduisent sensiblement le nombre de scripts de contournement qu’une agence doit maintenir pour administrer un parc de sites d’âges et d’architectures différents. Sur ce type de portefeuille, ce sont souvent ces détails de fiabilité, plus que les nouvelles fonctionnalités visibles, qui justifient une montée de version rapide.
