Gestion des environnements de développement WordPress avec WP-CLI et Robo

L'automatisation des tâches répétitives est l'un des meilleurs moyens de gagner du temps dans votre workflow de développement. Dans mon travail quotidien en tant que développeur de plugins, je dois souvent réinitialiser la base de données, réinstaller une version spécifique de WordPress, installer un ou plusieurs plugins et mettre à jour les paramètres. Cela devient rapidement fastidieux, c'est donc un choix naturel pour l'automatisation. Dans cet article, je vais vous montrer comment j'utilise WP-CLI en combinaison avec Robo pour automatiser les tâches nécessaires à la gestion de mon environnement de développement WordPress.

L'outil de ligne de commande WordPress, WP-CLI, est un bon début pour accélérer votre flux de travail. Si vous ne le connaissez pas, je vous recommande vivement de lire l'un de nos nombreux articles de blog. Notre guide d'installation est un excellent point de départ, expliquant comment l'installer sur votre système d'exploitation, configurer la complétion des onglets et créer un fichier de configuration.

Table des matières

1. Qu'est-ce que Robo ?
   1. Robo simplifie la ligne de commande PHP
   2. Installation de Robo
   3. Votre première commande
   4. Entrée et sortie
   5. Grands assistants
   6. Avantages de Robo
2. Maintenir WordPress avec Robo
   1. Les fichiers importants
   2. Mon environnement
   3. Utilisateur de la base de données
   4. Serveur Web
   5. Prendre soin des dépendances
3. Tirer parti de wp-cli.yml
   1. Qu'est-ce qu'un alias dans WP-CLI ?
   2. Valeurs par défaut des commandes
4. Création de commandes Robo personnalisées
   1. Configuration de la commande
   2. La commande de reset
   3. Étapes post-installation
   4. La commande de profile
5. Emballer

Qu'est-ce que Robo ?

Robo est un exécuteur de tâches moderne open source utilisé par un certain nombre de projets, notamment Drush et Codeception.

Robo est similaire à Gulp et Grunt, mais utilise PHP plutôt que JavaScript.

L'idée est que vous pouvez créer de petites commandes astucieuses comme celle-ci :

# Réinitialiser mon environnement de développement WP et le rendre multisite
robot réinitialiser --multi

# Installez et configurez le plugin WP Offload Media
profil robo ome-dev

L'exécuteur de tâches Robo facilite la documentation des commandes que vous créez en ajoutant des commentaires DocBlock à vos commandes, afin que vous puissiez fournir de l'aide pour les futures versions de vous-même :

# Robo sans aucun argument affichera les commandes disponibles.
robot

Commandes disponibles :
  help Affiche l'aide d'une commande
  list Répertorie les commandes
  profile Exécutez un ensemble de commandes wp-cli sur un environnement WordPress existant
  reset Réinitialiser l'environnement WordPress à un état connu

Demander plus d'informations sur une commande spécifique :

robo aide à réinitialiser

La description:
  Réinitialisez l'environnement WordPress à un état connu. Lit les environnements et la configuration 
  de robo.yml

Usage:
  réinitialiser [options]

Option :
      --env[=ENV] Environnement (dev, test, etc.) [défaut : "dev"]
      --multi Faire une installation multi-sites
      --ver[=VER] Version de WordPress [par défaut : "dernière"]

J'ai créé des commandes puissantes avec Robo que j'utilise tous les jours pour gérer mon environnement de développement WordPress. Dans cet article, je vais partager ces commandes avec vous et fournir une introduction aux commandes Robo en cours de route.

Robo simplifie la ligne de commande PHP

Vérifions un peu le rétroviseur. L'écriture de commandes PHP en ligne de commande n'est certainement pas nouvelle. Il a toujours été possible d'exécuter un script PHP depuis la ligne de commande comme ceci :

php monscript.php

Et PHP est disponible en tant qu'environnement de ligne de commande dans la plupart des environnements * NIX depuis aussi longtemps que je me souvienne. L'ajout du shebang PHP fonctionnera dans la plupart des environnements sur lesquels l'interpréteur PHP est installé.

 // file: myscript #!/usr/bin/env php <?php // do stuff here…

Ce qui permet d'exécuter le script depuis la ligne de commande sans préciser qu'il doit être parsé par PHP (ou inclure l'extension de fichier .php) :

monscript

L'inconvénient d'exécuter des scripts PHP bruts à partir de la ligne de commande est qu'il y a beaucoup de temps système pour l'entrée et la sortie à prendre en charge dans chaque script. Le processus d'acceptation des arguments de la ligne de commande, puis de sortie des messages sur la ligne de commande est un peu lourd et ne semble pas très flexible.

Robo vise à faciliter l'écriture de PHP en ligne de commande en prenant en charge une grande partie de la "plomberie" standard dont la plupart des scripts ont besoin. Cela vous permet de vous concentrer sur les fonctionnalités de base de vos scripts.

Installation de Robo

Vous devrez installer Robo avant de pouvoir commencer. Je garde Robo installé globalement sur ma machine, donc je l'ai installé comme ceci :

composer global nécessite une consolidation/robo

Mais comme pour tout ce qui est installé via Composer, vous pouvez le conserver en tant que dépendance de projet si vous êtes plus à l'aise avec cela. Alternativement, le GitHub a des instructions pour l'installer en téléchargeant robo.phar .

Votre première commande

Tout d'abord, nous devons initialiser Robo dans le dossier du projet :

cd /chemin/vers/monprojet
robot init

Cela crée simplement un nouveau RoboFile.php dans votre dossier avec le contenu suivant :

 <?php class RoboFile extends \Robo\Tasks { }

Pour ajouter notre première commande, nous ajoutons simplement une méthode publique :

 <?php class RoboFile extends \Robo\Tasks { public function hello($world) { $this->say("Hello, $world"); } }

Comme vous pouvez probablement le deviner, la méthode ci-dessus crée la commande hello et affiche simplement un message à l'écran.

Analyse des arguments

Le simple fait d'ajouter cette méthode comme nous l'avons fait ci-dessus est un excellent moyen de montrer l'une des raisons les plus importantes pour lesquelles j'aime Robo, à savoir l'analyse des arguments de ligne de commande.

Pour vous montrer ce que je veux dire, essayons d'exécuter cette commande :

robot bonjour

Pas assez d'arguments (manque : "monde").

bonjour [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [ -n|--non
-interaction] [--simulate] [--progress-delay PROGRESS-DELAY] [-D|--define DEFINE] [--]

Ah ! Robo me donne un message d'erreur car la commande hello attend en fait un paramètre $world , puis procède à l'écriture de la syntaxe d'utilisation complète de la commande.

Modifions un peu la méthode et rendons le paramètre optionnel :

 public function hello($world = 'from Robo') { $this->say("Hello, $world"); }

… et maintenant, réexécutons-le :

# Sans arguments
robot bonjour
Bonjour, de Robo

# Avec un argument simple
robo bonjour là!
Bonjour!

# Avec un argument contenant des espaces
robo bonjour "je vis sur la ligne de commande"
Bonjour, je vis sur la ligne de commande

C'est mieux! En rendant le paramètre facultatif, Robo exécute désormais notre méthode avec plaisir, même sans passer d'argument. Nous avons également vu que nous pouvons passer un argument simple et un argument entre guillemets et cela fonctionne.

Si vous avez déjà passé du temps à écrire des arguments pour vérifier la logique d'un script de ligne de commande, vous réalisez probablement pourquoi c'est une fonctionnalité intéressante. Cela enlève juste beaucoup de douleur.

L'exemple de commande hello utilise un seul argument positionnel. Robo prend également en charge l'utilisation d'indicateurs et d'arguments nommés en créant un argument de tableau avec des valeurs par défaut.

Modifions davantage la fonction pour éventuellement imprimer des caractères supplémentaires :

 public function hello( $world = 'from Robo', $flags = [ 'stars' => false, 'stripes' => false ] ) { if ( $flags['stars'] ) $this->say( '***************' ); if ( $flags['stripes'] ) $this->say( '===============' ); $this->say( "Hello, $world" ); if ( $flags['stripes'] ) $this->say( '==============='); if ( $flags['stars'] ) $this->say( '***************' ); }

Cela indiquera à Robo que nous pouvons éventuellement transmettre des arguments nommés en utilisant des doubles tirets :

# Juste en incluant un argument nommé, il obtiendra la valeur 'true'
robo bonjour --étoiles
 **************
 Bonjour, de Robo
 **************

Entrée et sortie

Nous avons également déjà vu un exemple utilisant IO. La fonction say() de l'objet de tâche Robo renvoie simplement une chaîne à l'utilisateur. Il existe également une fonction ask() qui vous permet de demander une entrée à l'utilisateur :

 public function hello() { $word = $this->ask("Tell me what to say:"); $this->say( $word ); }

robot bonjour
? Dis-moi quoi dire : foobar
foobar

Robo utilise Symfony Console pour créer des interactions utilisateur. Cela signifie qu'en plus des deux fonctions simples say() et ask() , nous avons accès à n'importe quelle fonction de Symfony Console, comme table() :

 public function table() { $this->io()->table( ['Header 1', 'Header 2'], [ ['Cell 1-1', 'Cell 1-2'], ['Cell 2-1', 'Cell 2-2'], ['Cell 3-1', 'Cell 3-2'], ] ); }

table robotique
---------- ----------
 En-tête 1 En-tête 2
---------- ----------
 Cellule 1-1 Cellule 1-2
 Cellule 2-1 Cellule 2-2
 Cellule 3-1 Cellule 3-2
---------- ----------

Plutôt cool, hein ?

Grands assistants

Une autre raison d'aimer Robo est qu'il prend en charge de nombreuses tâches courantes, ce qui facilite l'écriture de code compréhensible, même si vous y revenez 3 mois plus tard. Voyons comment Robo aide à écrire du code très propre pour certaines tâches assez standard :

 # Create a directory, and switch to it: $this->taskExecStack() ->stopOnFail() ->exec('mkdir site') ->exec('cd site') ->run(); # Search and replace inside a text file: $this->taskReplaceInFile('VERSION') ->from('0.2.0') ->to('0.3.0') ->run(); # Run composer update: $this->taskComposerUpdate()->run(); # SSH into a server, go to a specific directory, list the contents of the directory, and set permissions on the logs subdirectory $this->taskSshExec('remote.example.com', 'user') ->remoteDir('/var/www/html') ->exec('ls -la') ->exec('chmod g+x logs') ->run();

Tout ce qui précède est possible en utilisant PHP normal et la fonction exec() , mais cela devient souvent un exercice sans espoir consistant à essayer de coller des chaînes de commande ensemble et à échapper correctement aux arguments sans trop gâcher les choses.

Outre les exemples ci-dessus, il existe également une prise en charge similaire pour Git, Subversion, Rsync, Bower, Gulp, Docker, NPM et d'autres outils souvent utilisés dans les environnements de développement.

Avantages de Robo

Pris ensemble, Robo rend la création de scripts de ligne de commande beaucoup plus facile et le résultat final est généralement beaucoup plus attrayant sur le plan sémantique que PHP ordinaire.

Je trouve que les scripts pour Robo finissent par être plus faciles à lire et à comprendre par rapport aux scripts PHP purs, car une grande partie de la ligne de commande passe-partout est cachée à l'intérieur de Robo lui-même. Personnellement, je peux regarder mon propre code après quelques mois et me demander honnêtement qui l'a écrit, donc tout ce qui m'aide à écrire un code clair et lisible est un ajout bienvenu dans ma ceinture à outils.

Maintenir WordPress avec Robo

Le reste de cet article suppose que vous êtes quelque peu familiarisé avec WP-CLI, en utilisant Composer et en utilisant la ligne de commande.

Les fichiers importants

Il y a quatre fichiers importants dans cette configuration. Je vais couvrir chacun d'eux tout au long de ce post:

1. wp-cli.yml – Le fichier de configuration WP-CLI standard. Je l'utilise pour tirer parti de plusieurs des fonctionnalités intégrées de WP-CLI lorsqu'il s'agit de gérer plusieurs environnements.
2. RoboFile.php - Il s'agit du fichier de base pour l'implémentation des commandes robo.
3. robo.yml - Un fichier YAML personnalisé pour certains paramètres de configuration supplémentaires pour nos commandes Robo.
4. composer.json – Le fichier de configuration standard de Composer.

Mon environnement

Juste pour préparer le terrain pour le reste de cet article, je vais décrire rapidement comment mon environnement de développement local est configuré. Ceci est une version simplifiée de la façon dont j'ai organisé les choses sur le disque :

~/src
├── devenv/
│ ├── RoboFile.php
│ ├── composer.json
│ ├── wp-cli.yml
│ ├── robo.yml
│ ├── wordpress-dev/
│ └── wordpress-test/    
├── plugin1/
│ ├── actifs/
│ └── inclure/
└── plugin2
    └── ...

Le dossier src est l'endroit où tout ce qui concerne le développement est stocké et le dossier devenv contient des fichiers spécifiques à l'environnement d'exécution réel. Comme j'ai généralement plus d'un environnement WordPress en cours d'exécution en même temps, chaque installation WordPress a son propre sous-dossier, nommé wordpress-dev et wordpress-test dans cet exemple.

Chacun des plugins sur lesquels je travaille se trouve dans un dossier séparé par plugin.

Dans le monde réel, j'ai plusieurs dossiers devenv afin que je puisse séparer mon travail pour Delicious Brains de divers projets parallèles, mais cela n'est pas pertinent pour cet article.

Utilisateur de la base de données

Pour que tout fonctionne, j'ai également créé des bases de données locales pour chacune des installations WordPress dans mon installation MySQL locale et il y a un utilisateur de base de données, bien nommé wordpress , avec l'accès correct à ces bases de données. Les détails exacts des bases de données ainsi que les informations d'identification de l'utilisateur sont stockés dans le fichier wp-cli.yml .

Serveur Web

J'utilise nginx comme serveur Web local, mais vous constaterez qu'Apache2 fonctionne tout aussi bien. Ma configuration nginx est configurée de sorte que http://www.wordpress-dev.local et http://www.wordpress-test.local pointent vers les deux dossiers WordPress mentionnés ci-dessus.

Prendre soin des dépendances

Pour rendre mes scripts Robo plus flexibles, j'utilise certaines fonctionnalités supplémentaires installées via Composer, en particulier l'analyseur Symfony Yaml. Puisque RoboFile.php est vraiment juste un fichier PHP normal, je suis libre d'inclure toutes les bibliothèques que je veux et j'utilise naturellement Composer pour le faire. Le fichier composer.json pour ce projet ressemble à ceci :

 { "require": { "symfony/yaml": "^5.2" } }

Si vous copiez cela, n'oubliez pas d'installer la bibliothèque en utilisant composer update .

Tirer parti de wp-cli.yml

Lorsque vous travaillez avec WP-CLI, vous pouvez vous simplifier la vie en utilisant un fichier de configuration tel que wp-cli.yml . J'utilise le fichier de configuration WP-CLI pour deux raisons principales : les alias et la configuration des valeurs par défaut pour diverses sous-commandes.

Qu'est-ce qu'un alias dans WP-CLI ?

À la base, un alias WP-CLI est juste une étiquette dans le fichier de configuration qui vous permet de remplacer certaines des valeurs par défaut.

L'utilisation la plus courante des alias consiste probablement à remplacer le path par défaut afin que chaque alias pointe vers une installation WordPress distincte. Étant donné que chaque installation WordPress conserve son propre fichier de configuration avec les informations d'identification de la base de données, l'alias utilisé de cette manière représente également une base de données distincte. Un alias dans le fichier de configuration WP-CLI peut remplacer les paramètres url , path , user , ssh et http , mais il ne peut pas remplacer les valeurs par défaut des sous-commandes.

La création d'un environnement WordPress supplémentaire nommé @test me permet d'exécuter des commandes WP-CLI comme ceci :

# Listez tous les plugins dans l'installation dev WordPress
liste des plugins wp

# Listez tous les plugins dans l'installation test de WordPress
wp @test liste des plugins

Valeurs par défaut des commandes

Si vous n'avez jamais essayé cela auparavant, la configuration des paramètres par défaut pour les sous-commandes est très pratique. Par exemple, lorsque vous créez un nouveau fichier de configuration WordPress à l'aide de la commande config create , vous devez spécifier au moins trois paramètres à chaque fois :

$ wp config create --dbname=somedb --dbuser=myuser --dbpass=secret

Si jamais vous en avez assez de taper ceci, vous pouvez coller les paramètres dans un fichier wp-cli.yml :

 config create: dbuser: myuser dbpass: secret dbname: somedb

Une fois que vous avez fait cela, vous pouvez simplement utiliser wp config create et il récupérera les bons paramètres à partir de votre fichier wp-cli.yml .

Malheureusement, il n'est pas possible de configurer différentes commandes par défaut pour différents alias. C'était en fait l'une des raisons pour lesquelles j'ai commencé à regarder Robo pour plus d'automatisation.

Mon fichier de configuration WP-CLI ressemble à ceci :

 # Global parameter defaults path: wordpress-dev url: http://www.wordpress-dev.local user: admin @test: path: wordpress-test url: www.wordpress-test.local # Subcommand defaults config create: dbuser: wordpress dbpass: ***** dbname: wordpress extra-php: | define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true); define( 'SCRIPT_DEBUG', true ); core install: admin_user: admin admin_password: admin admin_email: [email protected] title: WordPress Dev core multisite-install: admin_user: admin admin_password: admin admin_email: [email protected]

Avec juste ce fichier de configuration en place, je peux exécuter des commandes courantes sans avoir à spécifier les paramètres individuels à chaque fois :

# Réinitialiser la base de données sur l'environnement de test
wp @test db reset --oui

# Téléchargez la dernière version et créez le fichier wp-config.php
wp @test télécharger le noyau
wp @test config créer

# Installer WordPress
wp @test core install --title="Test WordPress"

Comme WP-CLI récupère la plupart des paramètres du fichier de configuration, je n'ai pas à taper tous les paramètres de ligne de commande comme --dbuser et --admin_email que je devrais normalement.

Notez que dans le dernier exemple ci-dessus, j'ai fourni le paramètre de title séparément. C'est parce que je veux que le titre du site soit différent dans l'environnement de test, mais il n'est pas possible de remplacer ce paramètre à l'aide d'un alias.

Création de commandes Robo personnalisées

Configurer une nouvelle installation WordPress n'est presque jamais suffisant. Généralement, il y a un ou plusieurs plugins qui doivent être installés et activés et bien souvent quelques paramètres à régler ici et là.

Même avec un fichier de configuration WP-CLI soigneusement écrit, je me retrouverais toujours avec une longue chaîne de commandes si je voulais réinitialiser mon environnement WordPress et tout préparer. J'ai souvent fait des séquences comme celle-ci encore et encore:

# Réinitialiser mon environnement de développement
wp db reset --oui
rm -rf chemin/vers/wordpress
wp téléchargement de base
créer une configuration wp
installation wp core
ln -s chemin/vers/mon/plugin1 chemin/vers/wordpress/wp-content/plugins/
plugin wp activer plugin1

Même en tirant pleinement parti du fichier de configuration WP-CLI, cela représente beaucoup de frappe. Pour éviter de taper ceci encore et encore et de me tromper de temps en temps, j'ai créé deux commandes spécialisées en utilisant Robo pour le faire pour moi :

• reset – Réinitialise un environnement WordPress à un état connu.
• profile – Exécute un ensemble de commandes sur un environnement existant.

Étant donné que les paramètres par défaut de la sous-commande WP-CLI ne s'étendent pas à différents environnements de ligne de commande, nous pouvons utiliser Robo pour tuer cet oiseau avec la même pierre. Voyons comment.

Configuration de la commande

Notre premier arrêt consiste à jeter un œil au fichier de configuration Robo que j'ai créé pour cela. Il est écrit en YAML, ce qui devrait le rendre assez simple à comprendre et à étendre. Je vais passer en revue chaque section au fur et à mesure que nous arrivons à la commande qui l'utilise :

 wordpress-dev: cli-prefix: "" path: "wordpress" core-multisite-install: title: WordPress Multisite post-install: - ln -s $cwd/../plugins1 $path/wp-content/plugins/ - ln -s $cwd/../plugins2 $path/wp-content/plugins/ wordpress-test: cli-prefix: "@test" path: "wordpress-test" config-create: dbname: wordpress-test core-install: title: WordPress Test core-multisite-install: title: WordPress Test Multisite post-install: - ln -s $cwd/../plugins1 $path/wp-content/plugins/ profiles: woocommerce: - $wp plugin install --activate woocommerce - $wp wc payment_gateway update cheque --enabled=true --user=admin - $wp option update woocommerce_calc_taxes yes - $wp wc tax create --name=VAT --rate=10 --user=admin - $wp wc shipping_zone_method create 0 --method_id=flat_rate --user=admin - $wp option update --format=json woocommerce_flat_rate_1_settings '{"title":"Flat rate","tax_status":"taxable","cost":"15"}' imageimport: - $wp media import $cwd/../media/lots-of-images/* issue2530: - $wp plugin install --activate some_plugin - $wp config set FOOBAR true --raw

Chaque environnement WordPress est identifié à l'aide d'une clé wordpress-$env . Chaque clé peut contenir plusieurs valeurs de configuration.

La commande de reset

La première commande est reset . Il est utilisé depuis la ligne de commande comme ceci :

# Réinitialiser l'environnement de développement (par défaut)
robot réinitialiser

# Ou étant plus explicite
robo reset –env=dev

# Réinitialiser l'environnement de test
robo reset –env=test

# Réinitialisez l'environnement de développement et installez un multisite WordPress
robot réinitialiser --multi

# Réinitialisez l'environnement de développement sur une version spécifique de WordPress
robot réinitialisé --ver=5.6.1

La première chose que cette commande fait est de supprimer tous les fichiers et dossiers existants dans le répertoire d'installation WordPress cible et de réinitialiser la base de données WordPress configurée.

Ensuite, la commande de reset utilise les commandes WP-CLI core download , config create et une parmi core install ou core multisite-install selon l'option --multi .

Dans la mesure du possible, cela utilise les paramètres par défaut de la commande situés dans le fichier wp-cli.yml . La raison en est que ces valeurs par défaut sont également utiles lors de l'exécution directe de WP-CLI sans le wrapper Robo. Mais comme indiqué ci-dessus, dans certains cas, ce n'est tout simplement pas possible.

Par conséquent, le fichier de configuration robo.yml offre la possibilité de spécifier des remplacements pour les valeurs par défaut dans wp-cli.yml. Par exemple, lors de l'installation de l'environnement @test, nous souhaitons remplacer les paramètres du paramètre d' core install --title . Nous pouvons le faire en ajoutant ce qui suit dans robo.yml :

 wordpress-test: ... ... core-install: title: WordPress Test ... ...

La syntaxe ici est assez simple : le nom de la commande CLI (espaces remplacés par des tirets) comme clé et une sous-clé pour chaque paramètre nommé. L'exemple ci-dessus générerait le paramètre supplémentaire suivant pour la commande core install cli :

wp @test core install --title="Test WordPress"

Étapes post-installation

Chaque clé d'environnement dans le fichier de configuration peut éventuellement spécifier un tableau avec des étapes de post-installation. Il s'agit simplement d'une liste de commandes bash exécutées lorsque l'installation de WordPress est terminée. Pour plus de flexibilité, quelques remplacements de chaîne sont effectués avant l'exécution de la commande :

Ainsi, une étape post-installation de ln -s $cwd/../plugin1 $path/wp-content/plugins/ créerait un lien symbolique depuis l'un de mes dossiers de plugins vers le sous-dossier des plugins dans l'installation WordPress cible.

La commande de profile

La commande de profile est assez similaire aux étapes de post-installation, mais son utilisation prévue est d'exécuter un ensemble de commandes sur une installation WordPress existante. Disons que vous avez un environnement de développement très simple dans lequel vous effectuez la plupart de votre travail. Cependant, vous devez parfois installer le plugin WooCommerce et effectuer une configuration de base pour celui-ci. C'est à cela que sert la commande de profile . Il peut être utilisé comme ceci :

# Réinitialiser l'environnement de développement
robot réinitialiser

# Installez WooCommerce et apportez quelques modifications à la configuration
profil robo woocommerce

L'exemple de fichier robo.yml ci-dessus a un profil WooCommerce. L'application de ce profil :

• Installez et activez WooCommerce à l'aide de WP-CLI.
• Utilisez la sous-commande wc pour configurer une passerelle de paiement, une zone fiscale et des paramètres d'expédition.
• Utilisez la sous-commande option pour modifier certains paramètres directement dans le tableau des options de WordPress.

L'utilisation de différents profils est très utile. Je passe la plupart de mes journées à travailler sur le plugin WP Offload Media et j'ai souvent besoin d'importer beaucoup d'images dans la médiathèque WordPress. WP-CLI a une commande très pratique pour cela :

wp import media /some/long/path/I/often/forget/*

Comme j'oublie souvent beaucoup de choses en général et les longs noms de chemin en particulier, je trouve plus facile de me souvenir :

importation d'image de profil robo

Voici un autre exemple. J'ai travaillé sur un problème GitHub particulier où nous essayons de résoudre un problème de compatibilité entre notre plugin et un autre plugin WordPress populaire. Lorsque je travaille sur ce problème, je dois installer ce plugin et définir une valeur de configuration dans wp-config.php. J'ai donc créé un profil pour lui :

 .... issue2530: - $wp plugin install --activate some_plugin - $wp config set FOOBAR value

Maintenant, je peux préparer mon environnement en une seule étape, juste robo profile issue2530 .

Tout comme les étapes de post-install dans la commande de réinitialisation, chaque ligne de la définition des profils n'est en réalité qu'une commande bash distincte. Vous pouvez l'utiliser pour lancer des scripts séparés, supprimer des fichiers ou tout ce que vous voulez. Il est également tout à fait possible de se tirer une balle dans le pied, alors soyez prudent.

La source

Si l'un des éléments ci-dessus semble intéressant à essayer, voici le RoboFile que j'utilise pour tout ce qui précède, n'hésitez pas à l'utiliser pour commencer à gérer WordPress à l'aide de Robo.

 <?php use Robo\Symfony\ConsoleIO; use Robo\Tasks; use Symfony\Component\Yaml\Yaml; require_once 'vendor/autoload.php'; /** * Class RoboFile */ class RoboFile extends Tasks { /** * Reset the WordPress environment to a known state. Reads environments * and configuration from robo.yml * * @option env Environment (dev, test etc) * @option multi Make a multi site install * @option ver WordPress version * * @return bool */ public function reset( $opts = [ 'env' => 'dev', 'multi' => false, 'ver' => 'latest' ] ) { $env = $opts['env']; $version = $opts['ver']; $multi = $opts['multi']; $all_config = $this->read_yaml(); $key = "wordpress-$env"; if ( ! $this->ensure_basic_config( $all_config, $env ) ) { return false; } if ( ! isset( $all_config[ $key ]['path'] ) ) { $this->say( "No path set for environment $env." ); } $config = $all_config[ $key ]; $prefix = $config['cli-prefix']; $wp = trim( "wp $prefix" ); $path = $config['path']; $path = substr( $path, 0, 1 ) !== '/' ? __DIR__ . '/' . $path : $path; $version = $version === 'latest' ? '' : "--version=$version"; $config_create = $this->additional_parameters( 'config create', $config ); $install_cmd = $multi ? 'core multisite-install' : 'core install'; $install_params = $this->additional_parameters( $install_cmd, $config ); echo "$wp $install_cmd $install_params\n"; $this->taskExec( "$wp db reset --yes" )->run(); $this->taskExecStack() ->exec( "rm -rf $path/*" ) ->exec( "$wp core download $version" ) ->exec( "$wp config create $config_create" ) ->exec( "$wp config delete WP_DEBUG" ) ->exec( "$wp $install_cmd $install_params" ) ->run(); foreach ( $config['post-install'] as $cmd ) { $cmd = str_replace( '$wp', $wp, $cmd ); $cmd = str_replace( '$path', $path, $cmd ); $cmd = str_replace( '$cwd', __DIR__, $cmd ); $cmd = str_replace( '~', getenv( "HOME" ), $cmd ); echo $cmd . "\n"; $this->taskExec( $cmd )->run(); } } /** * Run a set of wp-cli commands on an existing WordPress environment * * @param string $profileName Name of the profile in robo.yml * * @option env Environment (dev, test etc) */ public function profile( $profileName, $opts = ['env' => 'dev']) { $env = $opts['env']; $all_config = $this->read_yaml(); $key = "wordpress-$env"; if ( ! $this->ensure_basic_config( $all_config, $env ) ) { return false; } $config = $all_config[ $key ]; $prefix = $config['cli-prefix']; $wp = trim( "wp $prefix" ); $path = $config['path']; $path = substr( $path, 0, 1 ) !== '/' ? __DIR__ . '/' . $path : $path; if ( ! isset( $all_config['profiles'][ $profileName ] ) ) { $this->say( "Profile $profileName not found" ); return false; } $profile = $all_config['profiles'][ $profileName ]; foreach ( $profile as $cmd ) { $cmd = str_replace( '$wp', $wp, $cmd ); $cmd = str_replace( '$path', $path, $cmd ); $cmd = str_replace( '$cwd', __DIR__, $cmd ); $cmd = str_replace( '~', getenv( "HOME" ), $cmd ); // Quick and dirty. If the cmd exactly matches another profile, run it! if ( isset( $all_config['profiles'][ $cmd ] ) ) { $this->profile( $cmd, $env ); continue; } echo $cmd . "\n"; $this->taskExec( $cmd )->run(); } } /** * @return array */ private function read_yaml() { return Yaml::parseFile( __DIR__ . '/robo.yml' ); } /** * @param $config * @param $env * * @return bool */ private function ensure_basic_config( $config, $env ) { $key = "wordpress-$env"; if ( ! isset( $config[ $key ] ) ) { $this->say( "No path set for environment $env." ); return false; } if ( ! isset( $config[ $key ]['cli-prefix'] ) ) { $this->say( "No wp-cli prefix set for environment $env." ); return false; } return true; } /** * @param string $name * @param array<string, string> $config * * @return string */ private function additional_parameters( $name, $config ) { $name = str_replace( ' ', '-', $name ); if ( ! isset( $config[ $name ] ) ) { return ''; } return implode( ' ', array_map( function ( $v, $k ) { return sprintf( "--%s='%s'", $k, $v ); }, $config[ $name ], array_keys( $config[ $name ] ) ) ); } }

Emballer

Dans le développement, les tâches répétitives ont tendance à aller avec le territoire. Je ne vois pas comment les éliminer complètement, mais en automatiser autant que possible vous aide vraiment à accomplir autant de travail réel avec le temps disponible.

L'automatisation de certaines de ces tâches avec la combinaison de WP-CLI et de Robo que j'ai décrite ici m'a fait gagner du temps chaque jour en tant que développeur de plugins. Je ne pourrais plus jamais recommencer à faire ces choses manuellement.

Quels outils utilisez-vous pour automatiser les parties les plus fastidieuses de votre workflow de développement ? Faites-moi savoir dans les commentaires.