Des commandes WP-CLI personnalisées écrites directement dans le fichier functions.php ou dans un plugin maison, chargées une seule fois sur un poste, rendent service tant qu’elles restent l’affaire d’un seul développeur. Le problème apparaît dès qu’un deuxième membre de l’équipe a besoin de la même commande sur son propre poste : copier-coller le fichier, oublier de le mettre à jour à la prochaine évolution, perdre la trace de quelle version tourne où. La solution la plus propre consiste à sortir ces commandes du projet et à les publier comme un vrai package WP-CLI, installable via wp package install par n’importe qui dans l’équipe, à n’importe quel moment.
Ce cheminement, du script local au package public, demande une structure précise mais reste accessible : un package WP-CLI n’est finalement qu’un package Composer normal, avec un fichier de déclaration en plus indiquant à WP-CLI où trouver les commandes.
Structure minimale d’un package
Un package WP-CLI repose sur trois éléments : un fichier composer.json déclarant le type wp-cli-package, un fichier PHP contenant la ou les classes de commande, et un fichier de bootstrap qui enregistre ces commandes auprès de WP-CLI.
{
"name": "mon-agence/wp-cli-outils-client",
"type": "wp-cli-package",
"require": {
"wp-cli/wp-cli": "^2.5"
},
"autoload": {
"psr-4": { "MonAgence\\WpCliOutils\\": "src/" }
},
"extra": {
"bundled": true,
"commands": ["outils client:audit", "outils client:purge"]
}
}Écrire la commande
La classe de commande hérite implicitement du système d’annotations WP-CLI via des commentaires PHPDoc, qui documentent aussi l’aide affichée par wp help :
namespace MonAgence\WpCliOutils;
use WP_CLI;
use WP_CLI\Utils;
class AuditCommand {
/**
* Vérifie les extensions inactives depuis plus de 90 jours.
*
* ## EXAMPLES
*
* wp outils-client audit
*/
public function audit( $args, $assoc_args ) {
$plugins = get_plugins();
foreach ( $plugins as $fichier => $donnees ) {
if ( ! is_plugin_active( $fichier ) ) {
WP_CLI::log( "Extension inactive : {$donnees['Name']}" );
}
}
WP_CLI::success( 'Audit terminé.' );
}
}
WP_CLI::add_command( 'outils-client audit', [ AuditCommand::class, 'audit' ] );Publier sur Packagist
Une fois le dépôt Git public (ou accessible via un Packagist privé pour un usage interne à l’agence), la publication suit le processus Packagist standard : créer un compte, soumettre l’URL du dépôt, puis activer le webhook GitHub pour que Packagist se mette à jour automatiquement à chaque nouveau tag. Chaque tag Git suivant le versionnage sémantique (v1.0.0, v1.1.0) devient une version installable indépendamment par l’équipe.
Installer le package une fois publié
Une fois indexé, le package s’installe comme n’importe quel autre package WP-CLI officiel, sans configuration Composer manuelle côté poste de développement :
wp package install mon-agence/wp-cli-outils-client:^1.0Ce mécanisme est distinct de la simple écriture d’une commande personnalisée dans un plugin de site : ici, la commande devient disponible globalement sur le poste, pour tous les projets, indépendamment du site WordPress actif au moment de l’appel.
Points d’attention
- Un package WP-CLI mal versionné (sans tags Git propres) complique la mise à jour côté équipe : privilégier un versionnage sémantique strict dès le premier tag.
- Toute dépendance Composer supplémentaire déclarée dans le package s’ajoute à l’environnement global WP-CLI de la machine, pas au projet WordPress lui-même : éviter les dépendances lourdes ou conflictuelles.
- Un Packagist privé (via Packagist.com payant ou un miroir Satis interne) permet de garder ces commandes propriétaires hors du domaine public tout en gardant le même flux d’installation.
La règle qu’on applique : dès qu’une commande WP-CLI maison sert sur plus d’un projet, elle sort du plugin local pour devenir un package versionné. C’est la seule façon de garantir que toute l’équipe utilise la même version, au même moment.
En résumé
Transformer des commandes WP-CLI locales en un vrai package Packagist demande peu de structure supplémentaire mais change complètement la donne pour une équipe : la commande devient un outil partagé, versionné et documenté, plutôt qu’un script isolé sur le poste d’une seule personne. Pour une agence qui accumule ce genre de petits utilitaires au fil des projets, ce passage vaut la peine dès que la deuxième personne en a besoin.
