Gerenciando ambientes de desenvolvimento do WordPress com WP-CLI e Robo

Publicados: 2022-09-13

Automatizar tarefas repetitivas é uma das melhores maneiras de economizar tempo em seu fluxo de trabalho de desenvolvimento. No meu dia a dia como desenvolvedor de plugins, muitas vezes tenho que redefinir o banco de dados, reinstalar uma versão específica do WordPress, instalar um ou mais plugins e atualizar as configurações. Isso rapidamente se torna cansativo, por isso é um ajuste natural para a automação. Neste artigo, mostrarei como uso o WP-CLI em combinação com o Robo para automatizar as tarefas necessárias para gerenciar meu ambiente de desenvolvimento WordPress.

A ferramenta de linha de comando do WordPress, WP-CLI, é um ótimo começo para acelerar seu fluxo de trabalho. Se você não estiver familiarizado com ele, eu recomendo a leitura de um dos nossos muitos posts. Nosso guia de instalação é um ótimo ponto de partida, explicando como instalá-lo em seu sistema operacional, configurar o preenchimento de guias e criar um arquivo de configuração.

Índice

  1. O que é Robô?
    1. Robo simplifica o PHP de linha de comando
    2. Instalando o Robo
    3. Seu primeiro comando
    4. Entrada e saída
    5. Grandes ajudantes
    6. Benefícios do Robô
  2. Mantendo o WordPress com Robo
    1. Os arquivos importantes
    2. Meu ambiente
    3. Usuário do banco de dados
    4. Servidor web
    5. Cuidando das Dependências
  3. Aproveitando o wp-cli.yml
    1. O que é um Alias ​​no WP-CLI?
    2. Padrões de Comando
  4. Criando Comandos Robo Personalizados
    1. Configuração do Comando
    2. O comando reset
    3. Etapas pós-instalação
    4. O comando do profile
  5. Empacotando

O que é Robô?

Robo é um executor de tarefas moderno de código aberto usado por vários projetos, incluindo Drush e Codeception.

Robo é semelhante ao Gulp e Grunt, mas usando PHP em vez de JavaScript.

A ideia é que você possa criar pequenos comandos bacanas como este:

# Redefinir meu ambiente de desenvolvimento WP e torná-lo multisite
robo reset --multi

# Instale e configure o plugin WP Offload Media
robo perfil ome-dev

O executor de tarefas Robo facilita a documentação dos comandos que você cria adicionando comentários DocBlock aos seus comandos, para que você possa fornecer ajuda para futuras versões de si mesmo:

# Robo sem nenhum argumento mostrará os comandos disponíveis.
robô

Comandos disponíveis:
  help Mostra a ajuda de um comando
  list Comandos de listas
  profile Execute um conjunto de comandos wp-cli em um ambiente WordPress existente
  reset Redefina o ambiente do WordPress para um estado conhecido

Pedindo mais informações sobre um comando específico:

robo ajuda redefinir

Descrição:
  Redefina o ambiente do WordPress para um estado conhecido. Lê ambientes e configuração 
  de robo.yml

Uso:
  redefinir [opções]

Opções:
      --env[=ENV] Ambiente (dev, teste etc) [padrão: "dev"]
      --multi Faz uma instalação em vários sites
      --ver[=VER] Versão do WordPress [padrão: "mais recente"]

Criei alguns comandos poderosos com o Robo que uso todos os dias para gerenciar meu ambiente de desenvolvimento WordPress. Neste artigo, compartilharei esses comandos com você e fornecerei uma introdução aos comandos do Robo ao longo do caminho.

Robo simplifica o PHP de linha de comando

Vamos verificar o espelho retrovisor um pouco. Escrever comandos PHP de linha de comando certamente não é novo. Sempre foi possível executar um script PHP a partir da linha de comando assim:

php meuscript.php

E o PHP está disponível como um ambiente de linha de comando na maioria dos ambientes *NIX desde que me lembro. Adicionar o PHP shebang funcionará na maioria dos ambientes que possuem o interpretador PHP instalado.

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

O que torna possível executar o script a partir da linha de comando sem especificar que ele deve ser analisado pelo PHP (ou incluindo a extensão de arquivo .php):

meuscript

A desvantagem de executar scripts PHP brutos a partir da linha de comando é que há muita sobrecarga de entrada e saída para cuidar de cada script. O processo de aceitar argumentos da linha de comando e, em seguida, enviar as mensagens para a linha de comando é um pouco complicado e não parece muito flexível.

O Robo se propõe a tornar mais fácil escrever PHP de linha de comando, cuidando muito do “encanamento” padrão que a maioria dos scripts precisa. Isso permite que você se concentre na funcionalidade principal de seus scripts.

Instalando o Robo

Você precisará instalar o Robo antes que possamos começar. Eu mantenho o Robo instalado globalmente na minha máquina, então instalei assim:

compositor global requer consolidação/robo

Mas como acontece com qualquer coisa instalada via Composer, você pode mantê-lo como uma dependência do projeto se estiver mais confortável com isso. Alternativamente, o GitHub tem instruções sobre como instalá-lo baixando robo.phar .

Seu primeiro comando

Primeiro, precisamos inicializar o Robo na pasta do projeto:

cd /caminho/para/meuprojeto
inicialização do robô

Isso realmente apenas cria um novo RoboFile.php em sua pasta com o seguinte conteúdo:

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

Para adicionar nosso primeiro comando, basta adicionar um método público:

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

Como você provavelmente pode adivinhar, o método acima cria o comando hello e simplesmente exibe uma mensagem na tela.

Analisando argumentos

Apenas adicionar esse método como fizemos acima é uma ótima maneira de mostrar uma das razões mais importantes pelas quais eu gosto do Robo, ou seja, analisar argumentos de linha de comando.

Para mostrar o que quero dizer, vamos tentar executar este comando:

robô olá

Não há argumentos suficientes (faltando: "mundo").

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

Ah! Robo me dá uma mensagem de erro porque o comando hello realmente espera um parâmetro $world e então continua a escrever a sintaxe de uso completa para o comando.

Vamos mudar um pouco o método e tornar o parâmetro opcional:

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

… e agora vamos executá-lo novamente:

# Sem argumentos
robô olá
Olá, do Robô

# Com um argumento simples
Robô Olá!
Olá!

# Com um argumento contendo espaços
robo hello “Eu moro na linha de comando”
Olá, eu vivo na linha de comando

Isso é melhor! Ao tornar o parâmetro opcional, Robo agora executa nosso método com satisfação, mesmo sem passar um argumento. Também vimos que podemos passar um argumento simples e um argumento entre aspas e simplesmente funciona.

Se você já passou algum tempo escrevendo lógica de verificação de argumentos para um script de linha de comando, provavelmente percebeu por que esse é um bom recurso. Só tira muita dor.

O comando hello de exemplo usa um único argumento posicional. O Robo também suporta o uso de sinalizadores e argumentos nomeados criando um argumento de matriz com alguns valores padrão.

Vamos modificar ainda mais a função para, opcionalmente, imprimir alguns caracteres adicionais:

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

Isso dirá ao Robo que podemos opcionalmente passar argumentos nomeados usando traços duplos:

# Apenas incluindo um argumento nomeado, ele obterá o valor 'true'
Robo Olá --estrelas
 ***************
 Olá, do Robô
 ***************

Entrada e saída

Também já vimos um exemplo usando IO. A função say() do objeto de tarefa Robo simplesmente retorna uma string para o usuário. Há também uma função ask() que permite solicitar a entrada do usuário:

 public function hello() { $word = $this->ask("Tell me what to say:"); $this->say( $word ); }
robô olá
? Diga-me o que dizer: foobar
foobar

O Robo usa o Symfony Console para criar interações do usuário. Isso significa que além das duas funções simples say() e ask() , temos acesso a qualquer função do Symfony Console, 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ô
---------- ----------
 Cabeçalho 1 Cabeçalho 2
---------- ----------
 Célula 1-1 Célula 1-2
 Célula 2-1 Célula 2-2
 Célula 3-1 Célula 3-2
---------- ----------

Bem legal, hein?

Grandes ajudantes

Outra razão para gostar do Robo é que ele tem suporte embutido para muitas tarefas comuns que facilitam a escrita de código compreensível, mesmo se você voltar a ele 3 meses depois. Vamos dar uma olhada em como o Robo ajuda a escrever um código muito limpo para algumas tarefas bastante padrão:

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

Todos os itens acima são possíveis usando PHP normal e a função exec() , mas isso muitas vezes se torna um exercício inútil de tentar colar strings de comando e escapar argumentos corretamente sem estragar muito as coisas.

Além dos exemplos acima, também há suporte semelhante para Git, Subversion, Rsync, Bower, Gulp, Docker, NPM e outras ferramentas frequentemente usadas em ambientes de desenvolvimento.

Benefícios do Robô

Juntos, o Robo torna a criação de scripts de linha de comando muito mais fácil e o resultado final geralmente é muito mais atraente semanticamente do que o PHP simples.

Acho que os scripts para o Robo acabam sendo mais fáceis de ler e entender em comparação com os scripts PHP puros, porque muito do material clichê da linha de comando está oculto dentro do próprio Robo. Pessoalmente, posso olhar para meu próprio código depois de alguns meses e honestamente me perguntar quem o escreveu, então qualquer coisa que me ajude a escrever um código claro e legível é uma adição bem-vinda no meu cinto de ferramentas.

Mantendo o WordPress com Robo

O restante deste artigo pressupõe que você esteja um pouco familiarizado com o WP-CLI, usando o Composer e trabalhando com a linha de comando.

Os arquivos importantes

Existem quatro arquivos importantes nesta configuração. Vou abordar cada um deles ao longo deste post:

  1. wp-cli.yml – O arquivo de configuração WP-CLI padrão. Estou usando isso para aproveitar vários dos excelentes recursos integrados do WP-CLI quando se trata de gerenciar vários ambientes.
  2. RoboFile.php – Este é o arquivo base para implementação de comandos robo.
  3. robo.yml – Um arquivo YAML personalizado para alguns parâmetros de configuração adicionais para nossos comandos Robo.
  4. composer.json – O arquivo de configuração padrão do Composer.

Meu ambiente

Apenas para preparar o cenário para o restante deste artigo, descreverei rapidamente como meu ambiente de desenvolvimento local está configurado. Esta é uma versão simplificada de como organizei as coisas no disco:

~/src
├── desenvolvimento/
│ ├── RoboFile.php
│ ├── composer.json
│ ├── wp-cli.yml
│ ├── robo.yml
│ ├── wordpress-dev/
│ └── wordpress-test/    
├── plugin1/
│ ├── ativos/
│ └── incluir/
└── plug-in2
    └──...

A pasta src é onde tudo relacionado ao desenvolvimento é armazenado e a pasta devenv contém arquivos específicos para o ambiente de tempo de execução real. Como geralmente tenho mais de um ambiente WordPress rodando ao mesmo tempo, cada instalação do WordPress tem sua própria subpasta, denominada wordpress-dev e wordpress-test neste exemplo.

Cada um dos plugins em que trabalho fica em uma pasta separada por plugin.

No mundo real, tenho várias pastas devenv para que possa manter meu trabalho para o Delicious Brains separado de vários projetos paralelos, mas isso não é relevante para este artigo.

Usuário do banco de dados

Para fazer tudo funcionar, também criei bancos de dados locais para cada uma das instalações do WordPress em minha instalação local do MySQL e há um usuário de banco de dados, apropriadamente chamado wordpress , com o acesso correto a esses bancos de dados. Os detalhes exatos dos bancos de dados, bem como as credenciais do usuário, são armazenados no arquivo wp-cli.yml .

Servidor web

Estou usando o nginx como meu servidor web local, mas você verá que o Apache2 funciona tão bem. Minha configuração do nginx está configurada para que http://www.wordpress-dev.local e http://www.wordpress-test.local apontem para as duas pastas do WordPress mencionadas acima.

Cuidando das Dependências

Para tornar meus scripts Robo mais flexíveis, estou usando algumas funcionalidades adicionais instaladas via Composer, especificamente o analisador Symfony Yaml. Já que RoboFile.php é realmente apenas um arquivo PHP normal, eu sou livre para incluir quaisquer bibliotecas que eu quiser e eu naturalmente uso o Composer para fazer isso. O arquivo composer.json para este projeto tem esta aparência:

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

Se você copiar isso, não se esqueça de instalar a biblioteca usando composer update .

Aproveitando o wp-cli.yml

Ao trabalhar com WP-CLI, você pode tornar a vida muito mais simples usando um arquivo de configuração como wp-cli.yml . Eu uso o arquivo de configuração WP-CLI por dois motivos principais: aliases e configuração de padrões para vários subcomandos.

O que é um Alias ​​no WP-CLI?

Em sua essência, um alias WP-CLI é apenas um rótulo no arquivo de configuração que permite substituir alguns dos padrões.

O uso mais comum de aliases é provavelmente substituir o path padrão para que cada alias aponte para uma instalação separada do WordPress. Como cada instalação do WordPress mantém seu próprio arquivo de configuração com credenciais de banco de dados, o alias usado dessa forma também representa um banco de dados separado. Um alias no arquivo de configuração WP-CLI pode substituir as configurações url , path , user , ssh e http , mas não pode substituir os valores padrão para subcomandos.

Criar um ambiente WordPress adicional chamado @test me permite executar comandos WP-CLI como este:

# Lista todos os plugins na instalação dev WordPress
lista de plugins wp

# Liste todos os plugins na instalação de teste do WordPress
wp @test lista de plugins

Padrões de Comando

Se você não tentou isso antes, configurar parâmetros padrão para subcomandos é super útil. Por exemplo, ao criar um novo arquivo de configuração do WordPress usando o comando config create , você precisa especificar pelo menos três parâmetros sempre:

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

Se você se cansar de digitar isso, você pode colocar os parâmetros em um arquivo wp-cli.yml :

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

Depois de fazer isso, você pode simplesmente usar wp config create e ele pegará os parâmetros corretos do seu arquivo wp-cli.yml .

Infelizmente, não é possível configurar padrões de comando diferentes para aliases diferentes. Na verdade, essa foi uma das razões pelas quais comecei a olhar para o Robo em busca de mais automação.

Meu arquivo de configuração WP-CLI se parece com isso:

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

Com apenas este arquivo de configuração, posso executar comandos comuns sem precisar especificar os parâmetros individuais todas as vezes:

# Redefinir o banco de dados no ambiente de teste
wp @test db reset --sim

# Baixe a versão mais recente e crie o arquivo wp-config.php
wp @test download do núcleo
wp @test configuração criar

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

Como o WP-CLI pega a maioria dos parâmetros do arquivo de configuração, não preciso digitar todos os parâmetros de linha de comando como --dbuser e --admin_email que normalmente teria que fazer.

Observe que no último exemplo acima forneci o parâmetro title separadamente. Isso ocorre porque quero que o título do site seja diferente no ambiente de teste, mas não é possível substituir esse parâmetro usando um alias.

Criando Comandos Robo Personalizados

Configurar uma nova instalação do WordPress quase nunca é suficiente. Normalmente, há um ou mais plugins que precisam ser instalados e ativados e, muitas vezes, algumas configurações para corrigir aqui e ali.

Mesmo com um arquivo de configuração WP-CLI cuidadosamente escrito, eu ainda acabaria com uma longa sequência de comandos se quisesse redefinir meu ambiente WordPress e deixar tudo pronto. Muitas vezes eu fazia sequências como esta repetidamente:

# Redefinir meu ambiente de desenvolvimento
wp db reset --sim
rm -rf caminho/para/wordpress
download do núcleo wp
wp configuração criar
wp core instalar
ln -s path/to/my/plugin1 path/to/wordpress/wp-content/plugins/
wp plugin ativar plugin1

Mesmo aproveitando ao máximo o arquivo de configuração WP-CLI, isso é muita digitação. Para evitar digitar isso repetidamente e também errar de vez em quando, criei dois comandos especializados usando o Robo para fazer isso por mim:

  • reset – redefine um ambiente WordPress para um estado conhecido.
  • profile – Executa um conjunto de comandos em um ambiente existente.

Como os parâmetros padrão do subcomando WP-CLI não se estendem a diferentes ambientes de linha de comando, podemos usar o Robo para matar aquele pássaro com a mesma pedra. Vamos ver como.

Configuração do Comando

Nossa primeira parada é dar uma olhada no arquivo de configuração do Robo que criei para isso. Ele está escrito em YAML, o que deve torná-lo bastante simples de entender e estender. Analisarei cada seção à medida que chegarmos ao comando que a 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 ambiente WordPress é identificado usando uma chave wordpress-$env . Cada chave pode conter vários valores de configuração.

O comando reset

O primeiro comando é reset . É usado a partir da linha de comando assim:

# Redefinir o ambiente dev (padrão)
robo reset

# Ou sendo mais explícito
robo reset –env=dev

# Redefinir o ambiente de teste
robo reset –env=teste

# Redefina o ambiente de desenvolvimento e instale um multisite WordPress
robo reset --multi

# Redefina o ambiente de desenvolvimento para uma versão específica do WordPress
robo reset --ver=5.6.1

A primeira coisa que este comando faz é excluir todos os arquivos e pastas existentes no diretório de instalação do WordPress de destino e redefinir o banco de dados WordPress configurado.

Em seguida, o comando reset usa os comandos do WP-CLI core download , config create e um de core install ou core multisite-install dependendo da opção --multi .

Na maior extensão possível, isso usa os padrões de parâmetro de comando localizados no arquivo wp-cli.yml . A razão para isso é que esses padrões também são úteis ao executar o WP-CLI diretamente sem o wrapper Robo. Mas, como discutido acima, em alguns casos, simplesmente não é possível.

Portanto, o arquivo de configuração robo.yml oferece a possibilidade de especificar substituições para os padrões em wp-cli.yml. Por exemplo, ao instalar o ambiente @test, queremos substituir os parâmetros do parâmetro de core install --title . Podemos fazer isso adicionando o seguinte em robo.yml :

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

A sintaxe aqui é bastante fácil: o nome do comando CLI (espaços substituídos por traços) como chave e uma subchave para cada parâmetro nomeado. O exemplo acima geraria o seguinte parâmetro extra para o comando core install cli:

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

Etapas pós-instalação

Cada chave de ambiente no arquivo de configuração pode especificar opcionalmente uma matriz com etapas de pós-instalação. Esta é simplesmente uma lista de comandos bash que são executados quando a instalação do WordPress é concluída. Para maior flexibilidade, algumas substituições de strings são feitas antes que o comando seja executado:

Corda Substituído por
$cwd O diretório de trabalho atual
$caminho O caminho da instalação de destino do WordPress
$wp O comando wp-cli, incluindo o prefixo do alias, ou seja, wp @test
~ (símbolo de til) O diretório HOME do usuário atual

Portanto, uma etapa pós-instalação de ln -s $cwd/../plugin1 $path/wp-content/plugins/ criaria um link simbólico de uma das minhas pastas de plugins para a subpasta de plugins na instalação de destino do WordPress.

O comando do profile

O comando profile é bastante semelhante às etapas de pós-instalação, mas seu uso pretendido é executar um conjunto de comandos em uma instalação existente do WordPress. Digamos que você tenha um ambiente de desenvolvimento muito simples no qual você faz a maior parte do seu trabalho. No entanto, às vezes você precisa instalar o plugin WooCommerce e fazer algumas configurações básicas para ele. É para isso que serve o comando profile . Pode ser usado assim:

# Redefinir o ambiente dev
robo reset

# Instale o WooCommerce e faça algumas alterações na configuração
robo perfil woocommerce

O arquivo robo.yml de amostra acima tem um perfil WooCommerce. A aplicação desse perfil irá:

  • Instale e ative o WooCommerce usando WP-CLI.
  • Use o comando wc sub para configurar um gateway de pagamento, zona fiscal e configurações de envio.
  • Use o comando option sub para modificar algumas configurações diretamente na tabela de opções do WordPress.

Usar perfis diferentes é bastante útil. Passo a maior parte dos meus dias trabalhando no plugin WP Offload Media e muitas vezes preciso importar muitas imagens para a biblioteca de mídia do WordPress. O WP-CLI tem um comando muito conveniente para isso:

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

Como muitas vezes esqueço muitas coisas em geral e nomes de caminhos longos em particular, acho mais fácil lembrar:

importação de imagem de perfil do robo

Aqui está outro exemplo. Estou trabalhando em um problema específico do GitHub em que estamos tentando corrigir um problema de compatibilidade entre nosso plugin e outro plugin WordPress popular. Quando trabalho nesse problema, preciso instalar esse plugin e definir um valor de configuração em wp-config.php. Então criei um perfil para isso:

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

Agora posso preparar meu ambiente em uma única etapa, apenas robo profile issue2530 .

Assim como as etapas post-install no comando reset, cada linha na definição de perfis é realmente apenas um comando bash separado. Você pode usá-lo para iniciar scripts separados, excluir arquivos ou o que quiser. Também é bem possível dar um tiro no pé, então pise com cuidado.

A fonte

Se algum dos itens acima parece interessante para experimentar, aqui está o RoboFile que estou usando para todas as coisas acima, sinta-se à vontade para usá-lo para começar a gerenciar o WordPress usando o 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 ] ) ) ); } }

Empacotando

No desenvolvimento, as tarefas repetitivas tendem a acompanhar o território. Não consigo ver uma maneira de eliminá-los completamente, mas automatizar o máximo possível realmente ajuda você a realizar o máximo de trabalho real com o tempo disponível.

Automatizar algumas dessas tarefas com a combinação de WP-CLI e Robo que descrevi aqui economizou tempo para mim todos os dias como desenvolvedor de plugins. Eu nunca poderia voltar a fazer essas coisas manualmente novamente.

Quais ferramentas você usa para automatizar as partes mais tediosas do seu fluxo de trabalho de desenvolvimento? Deixe-me saber nos comentários.