Gestión de entornos de desarrollo de WordPress con WP-CLI y Robo

Publicado: 2022-09-13

La automatización de tareas repetitivas es una de las mejores formas de ahorrar tiempo en su flujo de trabajo de desarrollo. En mi trabajo diario como desarrollador de complementos, a menudo tengo que restablecer la base de datos, reinstalar una versión específica de WordPress, instalar uno o más complementos y actualizar la configuración. Esto rápidamente se vuelve aburrido, por lo que es una opción natural para la automatización. En este artículo, le mostraré cómo uso WP-CLI en combinación con Robo para automatizar las tareas necesarias para administrar mi entorno de desarrollo de WordPress.

La herramienta de línea de comandos de WordPress, WP-CLI, es un gran comienzo para acelerar su flujo de trabajo. Si no está familiarizado con él, le recomiendo leer una de nuestras muchas publicaciones de blog. Nuestra guía de instalación es un excelente punto de partida, ya que explica cómo instalarlo en su sistema operativo, configurar la finalización de pestañas y crear un archivo de configuración.

Tabla de contenido

  1. ¿Qué es Robo?
    1. Robo simplifica PHP de línea de comandos
    2. Instalando Robo
    3. Tu primer comando
    4. Entrada y salida
    5. Grandes ayudantes
    6. Beneficios de Robo
  2. Mantenimiento de WordPress con Robo
    1. Los archivos importantes
    2. mi entorno
    3. Usuario de base de datos
    4. Servidor web
    5. Cuidando las Dependencias
  3. Aprovechar wp-cli.yml
    1. ¿Qué es un alias en WP-CLI?
    2. Valores predeterminados de comandos
  4. Creación de comandos Robo personalizados
    1. Configuración de comandos
    2. El comando de reset
    3. Pasos posteriores a la instalación
    4. El comando de profile
  5. Terminando

¿Qué es Robo?

Robo es un ejecutor de tareas moderno de código abierto utilizado por varios proyectos, incluidos Drush y Codeception.

Robo es similar a Gulp y Grunt, pero usa PHP en lugar de JavaScript.

La idea es que puedas crear pequeños e ingeniosos comandos como este:

# Restablecer mi entorno de desarrollo de WP y hacerlo multisitio
reinicio de robo --multi

# Instale y configure el complemento WP Offload Media
perfil de robo ome-dev

El ejecutor de tareas de Robo facilita la documentación de los comandos que crea agregando comentarios de DocBlock a sus comandos, para que pueda proporcionar ayuda para futuras versiones de usted mismo:

# Robo sin ningún argumento mostrará los comandos disponibles.
robo

Comandos disponibles:
  ayuda Muestra ayuda para un comando
  list Enumera los comandos
  perfil Ejecute un conjunto de comandos wp-cli en un entorno de WordPress existente
  restablecer Restablecer el entorno de WordPress a un estado conocido

Solicitar más información sobre un comando específico:

reinicio de ayuda robótica

Descripción:
  Restablezca el entorno de WordPress a un estado conocido. Lee entornos y configuración 
  de robo.yml

Uso:
  restablecer [opciones]

Opciones:
      --env[=ENV] Entorno (dev, prueba, etc.) [predeterminado: "dev"]
      --multi Realiza una instalación multisitio
      --ver[=VER] Versión de WordPress [predeterminado: "más reciente"]

Creé algunos comandos poderosos con Robo que uso todos los días para administrar mi entorno de desarrollo de WordPress. En este artículo, voy a compartir estos comandos con usted y proporcionaré una introducción a los comandos de Robo en el camino.

Robo simplifica PHP de línea de comandos

Miremos un poco el espejo retrovisor. Escribir comandos PHP de línea de comandos ciertamente no es nuevo. Siempre ha sido posible simplemente ejecutar un script PHP desde la línea de comandos de esta manera:

php miscript.php

Y PHP ha estado disponible como un entorno de línea de comandos en la mayoría de los entornos *NIX desde que tengo memoria. Agregar el shebang de PHP funcionará en la mayoría de los entornos que tienen instalado el intérprete de PHP.

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

Lo que hace posible ejecutar el script desde la línea de comando sin especificar que PHP debe analizarlo (o incluir la extensión de archivo .php):

miscript

La desventaja de ejecutar scripts PHP sin formato desde la línea de comandos es que hay una gran cantidad de gastos generales para la entrada y la salida de cada script. El proceso de aceptar argumentos desde la línea de comandos y luego enviar los mensajes a la línea de comandos es un poco engorroso y no se siente muy flexible.

Robo se propone facilitar la escritura de la línea de comandos PHP al ocuparse de gran parte de la "plomería" estándar que necesitan la mayoría de los scripts. Esto le permite concentrarse en la funcionalidad central de sus scripts.

Instalando Robo

Deberá instalar Robo antes de que podamos comenzar. Mantengo Robo instalado globalmente en mi máquina, así que lo instalé así:

compositor global requiere consolidación/robo

Pero al igual que con cualquier cosa instalada a través de Composer, puede mantenerlo como una dependencia del proyecto si se siente más cómodo con eso. Alternativamente, GitHub tiene instrucciones sobre cómo instalarlo descargando robo.phar .

Tu primer comando

Primero, necesitamos inicializar Robo en la carpeta del proyecto:

cd /ruta/a/miproyecto
inicialización robótica

Esto realmente solo crea un nuevo RoboFile.php en su carpeta con el siguiente contenido:

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

Para agregar nuestro primer comando, solo agregamos un método público:

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

Como probablemente pueda adivinar, el método anterior crea el comando hello y simplemente muestra un mensaje en la pantalla.

Análisis de argumentos

Simplemente agregar ese método como lo hicimos anteriormente es una excelente manera de mostrar una de las razones más importantes por las que me gusta Robo, a saber, analizar los argumentos de la línea de comando.

Para mostrarle lo que quiero decir, intentemos ejecutar este comando:

robo hola

No hay suficientes argumentos (falta: "mundo").

hola [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [ -n|--no
-interacción] [--simular] [--progreso-retraso PROGRESO-RETRASO] [-D|--define DEFINE] [--]

¡Ajá! Robo me da un mensaje de error porque el comando hello en realidad espera un parámetro $world y luego procede a escribir la sintaxis de uso completa para el comando.

Cambiemos un poco el método y hagamos que el parámetro sea opcional:

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

…y ahora vamos a ejecutarlo de nuevo:

# Sin argumentos
robo hola
Hola de Robo

# Con un argumento simple
robo hola!
¡Hola!

# Con un argumento que contiene espacios
hola robo "Vivo en la línea de comando"
Hola, vivo en la línea de comando.

¡Eso es mejor! Al hacer que el parámetro sea opcional, Robo ahora felizmente ejecuta nuestro método incluso sin pasar un argumento. También hemos visto que podemos pasar un argumento simple y un argumento entre comillas y simplemente funciona.

Si alguna vez pasó algún tiempo escribiendo la lógica de verificación de argumentos para un script de línea de comandos, probablemente se dé cuenta de por qué esta es una buena característica. Simplemente quita mucho dolor.

El comando hello de ejemplo utiliza un solo argumento posicional. Robo también admite el uso de banderas y argumentos con nombre mediante la creación de un argumento de matriz con algunos valores predeterminados.

Modifiquemos aún más la función para imprimir opcionalmente algunos caracteres adicionales:

 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( '***************' ); }

Esto le dirá a Robo que opcionalmente podemos pasar argumentos con nombre usando guiones dobles:

# Con solo incluir un argumento con nombre, obtendrá el valor 'verdadero'
robo hola --estrellas
 ***************
 Hola de Robo
 ***************

Entrada y salida

También hemos visto un ejemplo usando IO. La función say() del objeto de tarea de Robo simplemente devuelve una cadena al usuario. También hay una función ask() que le permite pedirle al usuario una entrada:

 public function hello() { $word = $this->ask("Tell me what to say:"); $this->say( $word ); }
robo hola
? Dime qué decir: foobar
Foobar

Robo usa Symfony Console para crear interacciones de usuario. Esto significa que además de las dos funciones simples say() y ask() , tenemos acceso a cualquier función de la Consola Symfony, como 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'], ] ); }
mesa robótica
---------- ----------
 Encabezado 1 Encabezado 2
---------- ----------
 Celda 1-1 Celda 1-2
 Celda 2-1 Celda 2-2
 Celda 3-1 Celda 3-2
---------- ----------

Bastante genial, ¿eh?

Grandes ayudantes

Otra razón por la que le gusta Robo es que tiene soporte integrado para muchas tareas comunes que facilita la escritura de código comprensible, incluso si vuelve a hacerlo 3 meses después. Echemos un vistazo a cómo Robo ayuda a escribir un código muy limpio para algunas tareas bastante estándar:

 # 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();

Todo lo anterior es posible usando PHP normal y la función exec() , pero eso a menudo se convierte en un ejercicio inútil de tratar de unir las cadenas de comandos y escapar correctamente de los argumentos sin estropear demasiado las cosas.

Además de los ejemplos anteriores, también hay soporte similar para Git, Subversion, Rsync, Bower, Gulp, Docker, NPM y otras herramientas que se usan a menudo en entornos de desarrollo.

Beneficios de Robo

En conjunto, Robo hace que la creación de scripts de línea de comandos sea mucho más fácil y el resultado final suele ser mucho más atractivo desde el punto de vista semántico que PHP simple.

Encuentro que las secuencias de comandos para Robo terminan siendo más fáciles de leer y comprender en comparación con las secuencias de comandos PHP puras, porque gran parte de la línea de comandos está oculta dentro de Robo. Personalmente, puedo mirar mi propio código después de unos meses y honestamente me pregunto quién lo escribió, por lo que cualquier cosa que me ayude a escribir un código claro y legible es una adición bienvenida a mi cinturón de herramientas.

Mantenimiento de WordPress con Robo

El resto de este artículo asume que está algo familiarizado con WP-CLI, usando Composer y trabajando con la línea de comandos.

Los archivos importantes

Hay cuatro archivos importantes en esta configuración. Cubriré cada uno de ellos a lo largo de esta publicación:

  1. wp-cli.yml : el archivo de configuración estándar de WP-CLI. Estoy usando esto para aprovechar varias de las excelentes funciones integradas de WP-CLI cuando se trata de administrar múltiples entornos.
  2. RoboFile.php : este es el archivo base para implementar comandos de robo.
  3. robo.yml : un archivo YAML personalizado para algunos parámetros de configuración adicionales para nuestros comandos Robo.
  4. composer.json : el archivo de configuración estándar de Composer.

mi entorno

Solo para preparar el escenario para el resto de este artículo, describiré rápidamente cómo se configura mi entorno de desarrollo local. Esta es una versión simplificada de cómo he organizado las cosas en el disco:

~/origen
├── desarrollo/
│ ├── RoboFile.php
│ ├── compositor.json
│ ├── wp-cli.yml
│ ├── robo.yml
│ ├── wordpress-dev/
│ └── prueba de wordpress/    
├── plugin1/
│ ├── activos/
│ └── incluir/
└── plugin2
    └──...

La carpeta src es donde se almacena todo lo relacionado con el desarrollo y la carpeta devenv contiene archivos específicos del entorno de tiempo de ejecución real. Dado que normalmente tengo más de un entorno de WordPress ejecutándose al mismo tiempo, cada instalación de WordPress tiene su propia subcarpeta, denominada wordpress-dev y wordpress-test en este ejemplo.

Cada uno de los complementos en los que trabajo se encuentra en una carpeta separada por complemento.

En el mundo real, tengo varias carpetas devenv para poder mantener mi trabajo para Delicious Brains separado de varios proyectos paralelos, pero eso no es relevante para este artículo.

Usuario de base de datos

Para que todo funcione, también he creado bases de datos locales para cada una de las instalaciones de WordPress en mi instalación local de MySQL y hay un usuario de la base de datos, acertadamente llamado wordpress , con el acceso correcto a esas bases de datos. Los detalles exactos de las bases de datos, así como las credenciales del usuario, se almacenan en el archivo wp-cli.yml .

Servidor web

Estoy usando nginx como mi servidor web local, pero encontrarás que Apache2 funciona igual de bien. Mi configuración de nginx está configurada para que http://www.wordpress-dev.local y http://www.wordpress-test.local apunten a las dos carpetas de WordPress mencionadas anteriormente.

Cuidando las Dependencias

Para hacer que mis scripts de Robo sean más flexibles, estoy usando algunas funciones adicionales instaladas a través de Composer, específicamente el analizador Symfony Yaml. Dado que RoboFile.php es realmente un archivo PHP normal, soy libre de incluir las bibliotecas que desee y, naturalmente, uso Composer para hacerlo. El archivo composer.json para este proyecto se ve así:

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

Si copia eso, no olvide instalar la biblioteca usando la composer update .

Aprovechar wp-cli.yml

Cuando trabaje con WP-CLI, puede hacer la vida mucho más simple utilizando un archivo de configuración como wp-cli.yml . Uso el archivo de configuración de WP-CLI por dos razones principales: alias y configuración predeterminada para varios subcomandos.

¿Qué es un alias en WP-CLI?

En esencia, un alias de WP-CLI es solo una etiqueta en el archivo de configuración que le permite anular algunos de los valores predeterminados.

El uso más común de los alias es probablemente anular la path predeterminada para que cada alias apunte a una instalación de WordPress separada. Dado que cada instalación de WordPress mantiene su propio archivo de configuración con las credenciales de la base de datos, el alias utilizado de esta manera también representa una base de datos separada. Un alias en el archivo de configuración de WP-CLI puede anular la configuración de url , path , user , ssh y http , pero no puede anular los valores predeterminados para los subcomandos.

La creación de un entorno de WordPress adicional llamado @test me permite ejecutar comandos WP-CLI como este:

# Listar todos los complementos en la instalación de desarrollo de WordPress
lista de complementos wp

# Listar todos los complementos en la instalación de prueba de WordPress
wp @test lista de complementos

Valores predeterminados de comando

Si no ha probado esto antes, la configuración de parámetros predeterminados para los subcomandos es muy útil. Por ejemplo, cuando crea un nuevo archivo de configuración de WordPress usando el comando config create , necesita especificar al menos tres parámetros cada vez:

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

Si alguna vez te cansas de escribir esto, puedes pegar los parámetros en un archivo wp-cli.yml :

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

Una vez que haya hecho eso, puede usar wp config create y recogerá los parámetros correctos de su archivo wp-cli.yml .

Desafortunadamente, no es posible configurar diferentes valores predeterminados de comando para diferentes alias. En realidad, esta fue una de las razones por las que comencé a buscar en Robo una mayor automatización.

Mi archivo de configuración de WP-CLI se ve así:

 # 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]

Con solo este archivo de configuración en su lugar, puedo ejecutar comandos comunes sin tener que especificar los parámetros individuales cada vez:

# Restablecer la base de datos en el entorno de prueba
wp @test db restablecer --sí

# Descargue la última versión y cree el archivo wp-config.php
wp @prueba de descarga básica
wp @test configuración crear

# Instalar WordPress
wp @test core install --title="Prueba de WordPress"

Como WP-CLI recoge la mayoría de los parámetros del archivo de configuración, no tengo que escribir todos los parámetros de la línea de comandos como --dbuser y --admin_email que normalmente tendría que hacer.

Tenga en cuenta que en el último ejemplo anterior proporcioné el parámetro de title por separado. Esto se debe a que quiero que el título del sitio sea diferente en el entorno de prueba, pero no es posible anular este parámetro con un alias.

Creación de comandos Robo personalizados

Configurar una nueva instalación de WordPress casi nunca es suficiente. Por lo general, hay uno o más complementos que deben instalarse y activarse y, con bastante frecuencia, algunas configuraciones para corregir aquí y allá.

Incluso con un archivo de configuración WP-CLI cuidadosamente escrito, todavía terminaría con una larga cadena de comandos si quiero restablecer mi entorno de WordPress y tener todo listo. A menudo hacía secuencias como esta una y otra vez:

# Restablecer mi entorno de desarrollo
wp db restablecer --sí
rm -rf ruta/hacia/wordpress
descarga del núcleo de wp
creación de configuración de wp
instalación del núcleo de wp
ln -s ruta/a/mi/plugin1 ruta/a/wordpress/wp-content/plugins/
plugin wp activar plugin1

Incluso cuando se aprovecha al máximo el archivo de configuración de WP-CLI, se trata de escribir mucho. Para evitar escribir esto una y otra vez y también equivocarme de vez en cuando, creé dos comandos especializados usando Robo para hacerlo por mí:

  • restablecer : restablece un entorno de WordPress a un estado conocido.
  • perfil : ejecuta un conjunto de comandos en un entorno existente.

Dado que los parámetros predeterminados del subcomando WP-CLI no se extienden a diferentes entornos de línea de comandos, podemos usar Robo para matar ese pájaro con la misma piedra. Veamos cómo.

Configuración de comandos

Nuestra primera parada es echar un vistazo al archivo de configuración de Robo que he creado para esto. Está escrito en YAML, lo que debería hacerlo bastante sencillo de entender y extender. Repasaré cada sección a medida que lleguemos al comando que lo usa:

 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

Cada entorno de WordPress se identifica mediante una clave wordpress-$env . Cada tecla puede contener varios valores de configuración.

El comando de reset

El primer comando se reset . Se usa desde la línea de comando así:

# Restablecer el entorno dev (predeterminado)
restablecer robo

# O siendo más explícito
reinicio de robo –env=dev

# Restablecer el entorno de prueba
reinicio de robo –env=prueba

# Reinicie el entorno de desarrollo e instale un multisitio de WordPress
reinicio de robo --multi

# Restablecer el entorno de desarrollo a una versión específica de WordPress
reinicio de robo --ver=5.6.1

Lo primero que hace este comando es eliminar todos los archivos y carpetas existentes en el directorio de instalación de WordPress de destino y restablecer la base de datos de WordPress configurada.

Luego, el comando de reset usa los comandos WP-CLI core download , config create y uno de core install o core multisite-install dependiendo de la opción --multi .

En la mayor medida posible, esto utiliza los valores predeterminados de parámetros de comando ubicados en el archivo wp-cli.yml . La razón de esto es que esos valores predeterminados también son útiles cuando se ejecuta WP-CLI directamente sin el envoltorio Robo. Pero como se discutió anteriormente, en algunos casos simplemente no es posible.

Por lo tanto, el archivo de configuración robo.yml ofrece la posibilidad de especificar anulaciones para los valores predeterminados en wp-cli.yml. Por ejemplo, al instalar el entorno @test queremos anular los parámetros del parámetro de core install --title . Podemos hacerlo agregando lo siguiente en robo.yml :

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

La sintaxis aquí es bastante sencilla: el nombre del comando CLI (espacios reemplazados con guiones) como clave y una subclave para cada parámetro nombrado. El ejemplo anterior generaría el siguiente parámetro adicional para el comando core install cli:

wp @test core install --title="Prueba de WordPress"

Pasos posteriores a la instalación

Cada clave de entorno en el archivo de configuración puede especificar opcionalmente una matriz con pasos posteriores a la instalación. Esta es simplemente una lista de comandos bash que se ejecutan cuando finaliza la instalación de WordPress. Para mayor flexibilidad, se realizan algunos reemplazos de cadenas antes de ejecutar el comando:

Cuerda Reemplazadas con
$cwd El directorio de trabajo actual
$ruta La ruta de la instalación de WordPress de destino
$wp El comando wp-cli, incluido el prefijo de alias, es decir, wp @test
~ (símbolo de tilde) El directorio HOME del usuario actual

Entonces, un paso posterior a la instalación de ln -s $cwd/../plugin1 $path/wp-content/plugins/ crearía un enlace simbólico desde una de mis carpetas de complementos a la subcarpeta de complementos en la instalación de destino de WordPress.

El comando de profile

El comando de profile es bastante similar a los pasos posteriores a la instalación, pero su uso previsto es ejecutar un conjunto de comandos en una instalación de WordPress existente. Digamos que tiene un entorno de desarrollo muy simple en el que realiza la mayor parte de su trabajo. Sin embargo, a veces necesita instalar el complemento WooCommerce y realizar una configuración básica. Para esto es el comando de profile . Se puede usar así:

# Restablecer el entorno de desarrollo
restablecer robo

# Instale WooCommerce y realice algunos cambios de configuración
perfil robo woocommerce

El archivo robo.yml de muestra anterior tiene un perfil de WooCommerce. Aplicar ese perfil:

  • Instale y active WooCommerce usando WP-CLI.
  • Utilice el subcomando wc para configurar una pasarela de pago, una zona fiscal y una configuración de envío.
  • Use el subcomando de option para modificar algunas configuraciones directamente en la tabla de opciones de WordPress.

Usar diferentes perfiles es bastante útil. Paso la mayor parte de mis días trabajando en el complemento WP Offload Media y, a menudo, necesito importar muchas imágenes a la biblioteca de medios de WordPress. WP-CLI tiene un comando muy conveniente para esto:

wp import media /some/long/path/I/a menudo/olvidar/*

Dado que a menudo olvido muchas cosas en general y nombres de rutas largos en particular, me resulta más fácil recordar:

importación de imagen de perfil de robo

Aquí hay otro ejemplo. Estuve trabajando en un problema particular de GitHub en el que intentamos solucionar un problema de compatibilidad entre nuestro complemento y otro complemento popular de WordPress. Cuando trabajo en ese problema, necesito instalar ese complemento y establecer un valor de configuración en wp-config.php. Así que creé un perfil para ello:

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

Ahora puedo tener mi entorno listo para funcionar en un solo paso, solo robo profile issue2530 .

Al igual que los pasos post-install en el comando de reinicio, cada fila en la definición de perfiles es en realidad solo un comando bash separado. Puede usarlo para iniciar secuencias de comandos separadas, eliminar archivos o lo que desee. También es muy posible que te dispares en el pie, así que ten cuidado.

La fuente

Si alguno de los anteriores suena interesante para probar, aquí está el RoboFile que estoy usando para todas las cosas anteriores, siéntase libre de usarlo para comenzar a administrar WordPress usando 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 ] ) ) ); } }

Terminando

En desarrollo, las tareas repetitivas tienden a ir con el territorio. No puedo ver una forma de eliminarlos por completo, pero automatizar tantos como sea posible realmente te ayuda a realizar la mayor cantidad de trabajo real con el tiempo disponible.

Automatizar algunas de esas tareas con la combinación de WP-CLI y Robo que describí aquí me ha ahorrado tiempo todos los días como desarrollador de complementos. Nunca podría volver a hacer estas cosas manualmente de nuevo.

¿Qué herramientas utiliza para automatizar las partes más tediosas de su flujo de trabajo de desarrollo? Házmelo saber en los comentarios.