Gestire gli ambienti di sviluppo di WordPress con WP-CLI e Robo

Pubblicato: 2022-09-13

L'automazione delle attività ripetitive è uno dei modi migliori per risparmiare tempo nel flusso di lavoro di sviluppo. Nel mio lavoro quotidiano come sviluppatore di plugin, devo spesso ripristinare il database, reinstallare una versione specifica di WordPress, installare uno o più plugin e aggiornare le impostazioni. Questo diventa rapidamente noioso, quindi è una scelta naturale per l'automazione. In questo articolo, ti mostrerò come utilizzo WP-CLI in combinazione con Robo per automatizzare le attività necessarie per gestire il mio ambiente di sviluppo WordPress.

Lo strumento da riga di comando di WordPress, WP-CLI, è un ottimo inizio per accelerare il flusso di lavoro. Se non lo conosci, ti consiglio vivamente di leggere uno dei nostri numerosi post sul blog. La nostra guida all'installazione è un ottimo punto di partenza, spiega come installarlo sul tuo sistema operativo, impostare il completamento delle schede e creare un file di configurazione.

Sommario

  1. Cos'è Robo?
    1. Robo semplifica la riga di comando PHP
    2. Installazione di Robo
    3. Il tuo primo comando
    4. Ingresso e uscita
    5. Grandi aiutanti
    6. Vantaggi di Robo
  2. Mantenere WordPress con Robo
    1. I file importanti
    2. Il mio ambiente
    3. Utente del database
    4. Server web
    5. Prendersi cura delle dipendenze
  3. Sfruttando wp-cli.yml
    1. Che cos'è un alias in WP-CLI?
    2. Comandi predefiniti
  4. Creazione di comandi robotici personalizzati
    1. Configurazione dei comandi
    2. Il comando di reset
    3. Passaggi successivi all'installazione
    4. Il comando profile
  5. Avvolgendo

Cos'è Robo?

Robo è un moderno task runner open source utilizzato da numerosi progetti tra cui Drush e Codeception.

Robo è simile a Gulp e Grunt, ma utilizza PHP anziché JavaScript.

L'idea è che puoi creare piccoli comandi eleganti come questo:

# Ripristina il mio ambiente di sviluppo WP e rendilo multisito
robo reset --multi

# Installa e configura il plug-in WP Offload Media
robo profilo ome-dev

Il Robo task runner semplifica la documentazione dei comandi che crei aggiungendo commenti DocBlock ai tuoi comandi, così puoi fornire aiuto per le versioni future di te stesso:

# Robo senza argomenti mostrerà i comandi disponibili.
robo

Comandi disponibili:
  help Visualizza la guida per un comando
  list Elenca i comandi
  profilo Esegui una serie di comandi wp-cli su un ambiente WordPress esistente
  reset Ripristina l'ambiente WordPress su uno stato noto

Chiedere maggiori informazioni su un comando specifico:

robo aiuta a ripristinare

Descrizione:
  Reimposta l'ambiente WordPress su uno stato noto. Legge ambienti e configurazione 
  da robo.yml

Utilizzo:
  ripristinare [opzioni]

Opzioni:
      --env[=ENV] Ambiente (sviluppo, test ecc.) [predefinito: "dev"]
      --multi Effettua un'installazione multisito
      --ver[=VER] Versione di WordPress [predefinito: "più recente"]

Ho creato alcuni potenti comandi con Robo che uso ogni giorno per gestire il mio ambiente di sviluppo WordPress. In questo articolo, condividerò questi comandi con te e fornirò un'introduzione ai comandi Robo lungo il percorso.

Robo semplifica la riga di comando PHP

Controlliamo un po' lo specchietto retrovisore. Scrivere comandi PHP da riga di comando non è certamente una novità. È sempre stato possibile eseguire semplicemente uno script PHP dalla riga di comando in questo modo:

php mioscript.php

E PHP è disponibile come ambiente a riga di comando nella maggior parte degli ambienti *NIX da quando ho memoria. L'aggiunta di PHP shebang funzionerà nella maggior parte degli ambienti in cui è installato l'interprete PHP.

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

Il che rende possibile eseguire lo script dalla riga di comando senza specificare che dovrebbe essere analizzato da PHP (o includendo l'estensione del file .php):

mio copione

Lo svantaggio dell'esecuzione di script PHP grezzi dalla riga di comando è che c'è un bel po' di sovraccarico per l'input e l'output di cui occuparsi in ogni script. Il processo di accettazione degli argomenti dalla riga di comando e quindi l'output dei messaggi sulla riga di comando è un po' macchinoso e non sembra molto flessibile.

Robo si propone di semplificare la scrittura di PHP da riga di comando occupandosi di gran parte delle "idrauliche" standard di cui la maggior parte degli script ha bisogno. Ciò ti consente di concentrarti sulle funzionalità principali dei tuoi script.

Installazione di Robo

Dovrai installare Robo prima di poter iniziare. Mantengo Robo installato a livello globale sulla mia macchina, quindi l'ho installato in questo modo:

compositore globale richiedono consolidamento/robo

Ma come con qualsiasi cosa installata tramite Composer, puoi mantenerla come una dipendenza dal progetto se ti senti più a tuo agio con quello. In alternativa, GitHub ha istruzioni per installarlo scaricando robo.phar .

Il tuo primo comando

Innanzitutto, dobbiamo inizializzare Robo nella cartella del progetto:

cd /percorso/del/mioprogetto
robo init

Questo crea davvero un nuovo RoboFile.php nella tua cartella con il seguente contenuto:

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

Per aggiungere il nostro primo comando, aggiungiamo semplicemente un metodo pubblico:

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

Come probabilmente puoi immaginare, il metodo sopra crea il comando hello e genera semplicemente un messaggio sullo schermo.

Argomenti di analisi

Il solo fatto di aggiungere quel metodo come abbiamo fatto sopra è un ottimo modo per mostrare uno dei motivi più importanti per cui mi piace Robo, ovvero l'analisi degli argomenti della riga di comando.

Per mostrarti cosa intendo, proviamo a eseguire questo comando:

ciao ciao

Argomenti insufficienti (manca: "mondo").

ciao [-h|--aiuto] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--versione] [--ansi] [--no-ansi] [ -n|--n
-interaction] [--simulate] [--progress-delay PROGRESS-DELAY] [-D|--define DEFINE] [--]

Ah! Robo mi dà un messaggio di errore perché il comando hello si aspetta effettivamente un parametro $world e quindi procede a scrivere la sintassi di utilizzo completa per il comando.

Cambiamo un po' il metodo e rendiamo il parametro opzionale:

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

...e ora eseguiamolo di nuovo:

# Senza argomenti
ciao ciao
Ciao, da Robo

# Con un semplice argomento
robo ciao!
Ciao!

# Con un arg contenente spazi
robo ciao "Vivo sulla riga di comando"
Ciao, vivo sulla riga di comando

Va meglio! Rendendo il parametro opzionale, Robo ora esegue felicemente il nostro metodo anche senza passare un argomento. Abbiamo anche visto che possiamo passare un argomento semplice e un argomento tra virgolette e funziona.

Se hai mai passato del tempo a scrivere argomenti controllando la logica per uno script della riga di comando, probabilmente ti rendi conto del motivo per cui questa è una bella caratteristica. Toglie solo molto dolore.

Il comando hello esempio utilizza un singolo argomento posizionale. Robo supporta anche l'uso di flag e argomenti denominati creando un argomento array con alcuni valori predefiniti.

Modifichiamo ulteriormente la funzione per stampare facoltativamente alcuni caratteri aggiuntivi:

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

Questo dirà a Robo che possiamo opzionalmente passare argomenti con nome usando doppi trattini:

# Semplicemente includendo un argomento denominato, otterrà il valore 'true'
robo ciao --stelle
 ***************
 Ciao, da Robo
 ***************

Ingresso e uscita

Abbiamo anche già visto un esempio usando IO. La funzione say() dell'oggetto attività Robo restituisce semplicemente una stringa all'utente. C'è anche una funzione ask() che ti consente di chiedere all'utente un input:

 public function hello() { $word = $this->ask("Tell me what to say:"); $this->say( $word ); }
ciao ciao
? Dimmi cosa dire: foobar
foobar

Robo usa Symfony Console per creare interazioni con l'utente. Ciò significa che oltre alle due semplici funzioni say() e ask() , abbiamo accesso a qualsiasi funzione da Symfony Console, come 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'], ] ); }
tavolo robotico
---------- ----------
 Intestazione 1 Intestazione 2
---------- ----------
 Cella 1-1 Cella 1-2
 Cella 2-1 Cella 2-2
 Cella 3-1 Cella 3-2
---------- ----------

Abbastanza bello, eh?

Grandi aiutanti

Un altro motivo per apprezzare Robo è che ha il supporto integrato per molte attività comuni che semplifica la scrittura di codice comprensibile, anche se ci torni 3 mesi dopo. Diamo un'occhiata a come Robo aiuta a scrivere codice molto pulito per alcune attività piuttosto 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();

Tutto quanto sopra è possibile usando il normale PHP e la funzione exec() , ma questo spesso diventa un esercizio senza speranza di provare a incollare insieme le stringhe di comando e sfuggire correttamente agli argomenti senza rovinare troppo le cose.

Oltre agli esempi precedenti, esiste anche un supporto simile per Git, Subversion, Rsync, Bower, Gulp, Docker, NPM e altri strumenti spesso utilizzati negli ambienti di sviluppo.

Vantaggi di Robo

Nel complesso, Robo rende la creazione di script da riga di comando molto più semplice e il risultato finale è solitamente molto più attraente dal punto di vista semantico rispetto al semplice PHP.

Trovo che gli script per Robo finiscano per essere più facili da leggere e capire rispetto agli script PHP puri, perché gran parte delle cose standard della riga di comando sono nascoste all'interno di Robo stesso. Personalmente, posso guardare il mio codice dopo alcuni mesi e sinceramente chiedermi chi l'ha scritto, quindi tutto ciò che mi aiuta a scrivere codice chiaro e leggibile è un'aggiunta gradita alla mia cintura degli strumenti.

Mantenere WordPress con Robo

Il resto di questo articolo presuppone che tu abbia una certa familiarità con WP-CLI, usando Composer e lavorando con la riga di comando.

I file importanti

Ci sono quattro file importanti in questa configurazione. Tratterò ciascuno di essi in questo post:

  1. wp-cli.yml – Il file di configurazione WP-CLI standard. Lo sto usando per sfruttare molte delle fantastiche funzionalità integrate di WP-CLI quando si tratta di gestire più ambienti.
  2. RoboFile.php – Questo è il file di base per l'implementazione dei comandi robo.
  3. robo.yml – Un file YAML personalizzato per alcuni parametri di configurazione aggiuntivi per i nostri comandi Robo.
  4. composer.json – Il file di configurazione standard di Composer.

Il mio ambiente

Giusto per preparare il terreno per il resto di questo articolo, descriverò rapidamente come è impostato il mio ambiente di sviluppo locale. Questa è una versione semplificata di come ho organizzato le cose su disco:

~/sorgente
├── devenv/
│ ├── RoboFile.php
│ ├── composer.json
│ ├── wp-cli.yml
│ ├── robo.yml
│ ├── wordpress-dev/
│ └── test wordpress/    
├── plug-in1/
│ ├── beni/
│ └── includi/
└── plug-in2
    └── ...

La cartella src è dove viene archiviato tutto ciò che riguarda lo sviluppo e la cartella devenv contiene i file specifici dell'ambiente di runtime effettivo. Poiché di solito ho più di un ambiente WordPress in esecuzione contemporaneamente, ogni installazione di WordPress ha la propria sottocartella, denominata wordpress-dev e wordpress-test in questo esempio.

Ciascuno dei plugin su cui lavoro si trova in una cartella separata per plugin.

Nel mondo reale, ho più cartelle devenv in modo da poter mantenere il mio lavoro per Delicious Brains separato dai vari progetti collaterali, ma non è rilevante per questo articolo.

Utente del database

Per far funzionare tutto ho anche creato database locali per ciascuna delle installazioni di WordPress nella mia installazione MySQL locale e c'è un utente del database, giustamente chiamato wordpress , con l'accesso corretto a quei database. I dettagli esatti dei database e le credenziali dell'utente sono memorizzati nel file wp-cli.yml .

Server web

Sto usando nginx come mio server web locale, ma scoprirai che Apache2 funziona altrettanto bene. La mia configurazione di nginx è impostata in modo che http://www.wordpress-dev.local e http://www.wordpress-test.local puntino alle due cartelle di WordPress menzionate sopra.

Prendersi cura delle dipendenze

Per rendere i miei script Robo più flessibili, sto usando alcune funzionalità aggiuntive installate tramite Composer, in particolare il parser Symfony Yaml. Poiché RoboFile.php è in realtà solo un normale file PHP, sono libero di includere tutte le librerie che voglio e naturalmente uso Composer per farlo. Il file composer.json per questo progetto è simile al seguente:

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

Se lo copi, non dimenticare di installare effettivamente la libreria usando il composer update .

Sfruttando wp-cli.yml

Quando si lavora con WP-CLI, è possibile semplificare notevolmente la vita utilizzando un file di configurazione come wp-cli.yml . Uso il file di configurazione WP-CLI per due motivi principali: alias e impostazione dei valori predefiniti per vari sottocomandi.

Che cos'è un alias in WP-CLI?

In sostanza, un alias WP-CLI è solo un'etichetta nel file di configurazione che ti consente di ignorare alcune delle impostazioni predefinite.

L'uso più comune degli alias è probabilmente quello di sovrascrivere il path predefinito in modo che ogni alias punti a un'installazione WordPress separata. Poiché ogni installazione di WordPress conserva il proprio file di configurazione con le credenziali del database, l'alias utilizzato in questo modo rappresenta anche un database separato. Un alias nel file di configurazione WP-CLI può sovrascrivere le impostazioni url , path , user , ssh e http , ma non può sovrascrivere i valori predefiniti per i sottocomandi.

La creazione di un ambiente WordPress aggiuntivo denominato @test mi consente di eseguire comandi WP-CLI come questo:

# Elenca tutti i plugin nell'installazione di dev WordPress
elenco dei plugin wp

# Elenca tutti i plugin nell'installazione di prova di WordPress
wp @test elenco di plugin

Comandi predefiniti

Se non l'hai mai provato prima, l'impostazione dei parametri predefiniti per i sottocomandi è molto utile. Ad esempio, quando crei un nuovo file di configurazione di WordPress utilizzando il comando config create , devi specificare almeno tre parametri ogni volta:

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

Se ti stanchi di digitarlo, puoi inserire i parametri in un file wp-cli.yml :

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

Una volta fatto, puoi semplicemente usare wp config create e raccoglierà i parametri corretti dal tuo file wp-cli.yml .

Sfortunatamente non è possibile impostare impostazioni predefinite di comando diverse per alias diversi. Questo è stato in realtà uno dei motivi per cui ho iniziato a guardare Robo per una maggiore automazione.

Il mio file di configurazione WP-CLI è simile a questo:

 # 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 questo file di configurazione in atto, sono in grado di eseguire comandi comuni senza dover specificare ogni volta i singoli parametri:

# Reimposta il database nell'ambiente di test
wp @test db reset --yes

# Scarica l'ultima versione e crea il file wp-config.php
wp @test core download
wp @test config create

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

Poiché WP-CLI raccoglie la maggior parte dei parametri dal file di configurazione, non devo digitare tutti i parametri della riga di comando come --dbuser e --admin_email che normalmente dovrei.

Nota che nell'ultimo esempio sopra ho fornito il parametro title separatamente. Questo perché voglio che il titolo del sito sia diverso nell'ambiente di test, ma non è possibile sovrascrivere questo parametro usando un alias.

Creazione di comandi robotici personalizzati

Configurare una nuova installazione di WordPress non è quasi mai abbastanza. Di solito ci sono uno o più plugin che devono essere installati e attivati ​​e abbastanza spesso alcune impostazioni da sistemare qua e là.

Anche con un file di configurazione WP-CLI scritto con cura, mi ritroverei comunque con una lunga serie di comandi se voglio ripristinare il mio ambiente WordPress e preparare tutto. Ho fatto spesso sequenze come questa più e più volte:

# Ripristina il mio ambiente di sviluppo
wp db reset --sì
rm -rf percorso/a/wordpress
download di core wp
wp config creare
installazione di base di wp
ln -s percorso/a/mio/plugin1 percorso/a/wordpress/wp-content/plugins/
plugin wp attiva plugin1

Anche quando si sfrutta appieno il file di configurazione WP-CLI, è necessario digitare molto. Per evitare di digitarlo più e più volte e anche di sbagliare ogni tanto, ho creato due comandi specializzati usando Robo per farlo per me:

  • reset – Ripristina un ambiente WordPress a uno stato noto.
  • profilo : esegue una serie di comandi su un ambiente esistente.

Poiché i parametri predefiniti del sottocomando WP-CLI non si estendono a diversi ambienti della riga di comando, possiamo usare Robo per uccidere quell'uccello con la stessa pietra. Vediamo come.

Configurazione dei comandi

La nostra prima tappa è dare un'occhiata al file di configurazione di Robo che ho creato per questo. È scritto in YAML, il che dovrebbe renderlo abbastanza semplice da comprendere ed estendere. Esaminerò ogni sezione mentre arriviamo al comando che 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

Ogni ambiente WordPress viene identificato utilizzando una chiave wordpress-$env . Ogni chiave può contenere diversi valori di configurazione.

Il comando di reset

Il primo comando è reset . Viene utilizzato dalla riga di comando in questo modo:

# Reimposta l'ambiente di sviluppo (predefinito).
ripristino robotico

# O essere più espliciti
robo reset –env=dev

# Reimposta l'ambiente di test
robo reset –env=test

# Ripristina l'ambiente di sviluppo e installa un multisito WordPress
robo reset --multi

# Ripristina l'ambiente di sviluppo su una versione specifica di WordPress
robo reset --ver=5.6.1

La prima cosa che fa questo comando è eliminare tutti i file e le cartelle esistenti nella directory di installazione di WordPress di destinazione e ripristinare il database WordPress configurato.

Quindi, il comando reset usa i comandi WP-CLI core download , config create e uno di core install o core multisite-install a seconda dell'opzione --multi .

Nella misura più ampia possibile, questo utilizza i parametri di comando predefiniti che si trovano nel file wp-cli.yml . La ragione di ciò è che queste impostazioni predefinite sono utili anche quando si esegue WP-CLI direttamente senza il wrapper Robo. Ma come discusso sopra, in alcuni casi semplicemente non è possibile.

Pertanto il file di configurazione robo.yml offre la possibilità di specificare le sostituzioni per i valori predefiniti in wp-cli.yml. Ad esempio, quando si installa l'ambiente @test, si desidera sovrascrivere i parametri per il parametro di core install --title . Possiamo farlo aggiungendo quanto segue in robo.yml :

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

La sintassi qui è abbastanza semplice: il nome del comando CLI (spazi sostituiti con trattini) come chiave e una sottochiave per ogni parametro denominato. L'esempio sopra genererebbe il seguente parametro aggiuntivo per il comando cli di core install :

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

Passaggi successivi all'installazione

Ciascuna chiave di ambiente nel file di configurazione può facoltativamente specificare un array con i passaggi successivi all'installazione. Questo è semplicemente un elenco di comandi bash che vengono eseguiti al termine dell'installazione di WordPress. Per una maggiore flessibilità, prima dell'esecuzione del comando vengono effettuate alcune sostituzioni di stringhe:

Corda Sostituito con
$cwd La directory di lavoro corrente
$percorso Il percorso dell'installazione di WordPress di destinazione
$wp Il comando wp-cli, incluso il prefisso alias, cioè wp @test
~ (simbolo tilde) La directory HOME dell'utente corrente

Quindi un passaggio post-installazione di ln -s $cwd/../plugin1 $path/wp-content/plugins/ creerebbe un collegamento simbolico da una delle mie cartelle dei plug-in alla sottocartella dei plug-in nell'installazione di WordPress di destinazione.

Il comando profile

Il comando del profile è abbastanza simile ai passaggi successivi all'installazione, ma il suo uso previsto è eseguire una serie di comandi su un'installazione WordPress esistente. Diciamo che hai un ambiente di sviluppo molto semplice in cui svolgi la maggior parte del tuo lavoro. Tuttavia, a volte è necessario installare il plug-in WooCommerce ed eseguire alcune impostazioni di base per questo. A questo serve il comando profile . Può essere utilizzato in questo modo:

# Ripristina l'ambiente di sviluppo
ripristino robotico

# Installa WooCommerce e apporta alcune modifiche alla configurazione
profilo robo woocommerce

Il file robo.yml di esempio sopra ha un profilo WooCommerce. L'applicazione di quel profilo:

  • Installa e attiva WooCommerce utilizzando WP-CLI.
  • Utilizzare il comando secondario wc per configurare un gateway di pagamento, una zona fiscale e le impostazioni di spedizione.
  • Usa il sottocomando option per modificare alcune impostazioni direttamente nella tabella delle opzioni di WordPress.

L'uso di profili diversi è abbastanza utile. Passo la maggior parte delle mie giornate a lavorare sul plug-in WP Offload Media e spesso ho bisogno di importare molte immagini nella libreria multimediale di WordPress. WP-CLI ha un comando davvero conveniente per questo:

wp import media /alcuni/lungo/percorso/io/spesso/dimentica/*

Dato che spesso dimentico molte cose in generale e nomi di percorsi lunghi in particolare, trovo più facile ricordare:

Importazione immagine profilo robo

Ecco un altro esempio. Ho lavorato su un particolare problema di GitHub in cui stiamo cercando di risolvere un problema di compatibilità tra il nostro plugin e un altro popolare plugin di WordPress. Quando lavoro su questo problema, devo installare quel plugin e impostare un valore di configurazione in wp-config.php. Quindi ho creato un profilo per questo:

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

Ora posso preparare il mio ambiente per andare in un solo passaggio, solo robo profile issue2530 .

Proprio come i passaggi post-install nel comando di ripristino, ogni riga nella definizione dei profili è in realtà solo un comando bash separato. Puoi usarlo per avviare script separati, eliminare file o qualsiasi cosa tu voglia. È anche del tutto possibile spararsi a un piede, quindi cammina con cautela.

La fonte

Se qualcuno dei precedenti sembra interessante da provare, ecco il RoboFile che sto usando per tutte le cose di cui sopra, sentiti libero di usarlo per iniziare a gestire 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 ] ) ) ); } }

Avvolgendo

Nello sviluppo, i compiti ripetitivi tendono ad andare con il territorio. Non riesco a vedere un modo per eliminarli completamente, ma automatizzarne il maggior numero possibile ti aiuta davvero a svolgere il maggior lavoro reale con il tempo a disposizione.

Automatizzare alcune di queste attività con la combinazione di WP-CLI e Robo che ho descritto qui mi ha fatto risparmiare tempo ogni singolo giorno come sviluppatore di plugin. Non potrei mai più tornare a fare queste cose manualmente.

Quali strumenti utilizzi per automatizzare le parti più noiose del tuo flusso di lavoro di sviluppo? Fatemi sapere nei commenti.