wp scaffold : les générateurs WP-CLI que presque personne n’utilise

Un réflexe répandu chez les développeurs WordPress consiste à garder un vieux plugin personnel comme réserve de code à copier-coller à chaque nouveau projet : l’enregistrement d’un type de contenu, la déclaration d’une taxonomie, la structure d’un thème enfant. WP-CLI propose depuis longtemps une famille de commandes qui fait exactement ce travail, avec un code à jour et conforme aux conventions du cœur — la commande wp scaffold, étonnamment sous-utilisée dans les projets professionnels.

Ce tour d’horizon couvre cinq générateurs utiles au quotidien. Les tests générés automatiquement par certaines de ces commandes, destinés aux suites PHPUnit, répondent à un usage plus spécifique qui mérite un traitement séparé.

scaffold post-type

La commande la plus utilisée du groupe génère l’enregistrement complet d’un type de contenu personnalisé, prêt à coller dans un plugin ou un thème :

wp scaffold post-type produit --label=Produits --textdomain=mon-theme

Le résultat inclut les labels traduits, les arguments public, show_in_rest, supports, et surtout un hook correctement accroché à init — le genre de détail qu’on oublie facilement en écrivant à la main :

function mon_theme_produit_post_type() {
	$labels = array(
		'name'          => _x( 'Produits', 'Post Type General Name', 'mon-theme' ),
		'singular_name' => _x( 'Produit', 'Post Type Singular Name', 'mon-theme' ),
	);
	$args = array(
		'label'        => __( 'Produits', 'mon-theme' ),
		'labels'       => $labels,
		'public'       => true,
		'show_in_rest' => true,
	);
	register_post_type( 'produit', $args );
}
add_action( 'init', 'mon_theme_produit_post_type', 0 );

scaffold taxonomy

Même logique pour une taxonomie personnalisée, avec la liaison automatique au type de contenu concerné :

wp scaffold taxonomy categorie-produit --post_types=produit --textdomain=mon-theme

Le fichier généré déclare une taxonomie hiérarchique par défaut (comparable aux catégories natives). Pour une taxonomie non hiérarchique façon étiquettes, il suffit d’ajuster manuellement 'hierarchical' => false dans le résultat — le générateur ne propose pas ce choix en argument de ligne de commande, une limite à connaître avant de lancer la commande en pensant obtenir directement le bon comportement.

scaffold child-theme

Pour démarrer un thème enfant sur un thème existant, plutôt que de recréer style.css et functions.php à la main :

wp scaffold child-theme mon-theme-enfant --parent_theme=twentytwentyone \
    --theme_name="Mon Thème Enfant" --author="Clément Hadrot"

La commande crée un dossier complet avec l’en-tête de style correctement rempli et un functions.php qui enfile la feuille de style parente via wp_enqueue_style(), accroché au hook wp_enqueue_scripts — la méthode recommandée plutôt qu’un @import CSS, plus lent à charger.

scaffold block

Pour l’éditeur de blocs, la commande génère la structure minimale d’un bloc personnalisé, y compris le block.json :

wp scaffold block mon-bloc --title="Mon Bloc" --theme

L’option --theme place le bloc dans le thème actif plutôt que dans un plugin séparé. Le résultat inclut un squelette JavaScript d’enregistrement et un fichier PHP de rendu côté serveur, une base correcte pour un bloc simple, bien que les projets utilisant @wordpress/scripts et son propre outillage de build préfèrent souvent partir directement de @wordpress/create-block, plus complet pour un bloc en JavaScript pur.

scaffold plugin

Pour initialiser un plugin depuis zéro, avec en-tête conforme et structure de base :

wp scaffold plugin mon-plugin --plugin_name="Mon Plugin" \
    --plugin_author="Clément Hadrot" --plugin_description="Fonctionnalités internes"

Le fichier principal généré contient déjà l’en-tête standard reconnu par WordPress (Plugin Name, Version, Text Domain), une protection contre l’accès direct (defined( 'ABSPATH' ) || exit;), et une structure de dossiers cohérente — un point de départ nettement plus rapide qu’un fichier vide.

Ce que scaffold ne remplace pas

• La logique métier réelle du plugin ou du bloc reste entièrement à écrire
• Le code généré suit des conventions génériques, pas nécessairement le standard de codage spécifique d’une agence
• Les champs personnalisés (ACF ou natifs) ne sont pas générés, seule la structure du type de contenu l’est

Je considère wp scaffold comme un point de départ, pas comme un livrable : le code généré évite les oublis classiques, mais il mérite toujours d’être relu et adapté aux conventions du projet en cours.

Pour aller plus loin

Ces générateurs restent peu utilisés en agence, souvent par simple méconnaissance de leur existence. Leur intérêt réel n’est pas de gagner du temps de frappe — un bon extrait de code personnel fait aussi bien — mais de garantir que la structure de base respecte les conventions du cœur WordPress, sans dépendre de la mémoire ou de l’ancienneté du snippet copié-collé d’un projet à l’autre.