Gestionarea mediilor de dezvoltare WordPress cu WP-CLI și Robo

Publicat: 2022-09-13

Automatizarea sarcinilor repetitive este una dintre cele mai bune modalități de a economisi timp în fluxul de lucru de dezvoltare. În munca mea de zi cu zi ca dezvoltator de pluginuri, de multe ori trebuie să resetez baza de date, să reinstalez o anumită versiune de WordPress, să instalez unul sau mai multe plugin-uri și să actualizez setările. Acest lucru devine rapid obositor, așa că este o potrivire naturală pentru automatizare. În acest articol, vă voi arăta cum folosesc WP-CLI în combinație cu Robo pentru a automatiza sarcinile necesare pentru a gestiona mediul meu de dezvoltare WordPress.

Instrumentul de linie de comandă WordPress, WP-CLI, este un început excelent pentru a vă accelera fluxul de lucru. Dacă nu sunteți familiarizat cu el, vă recomand cu căldură să citiți una dintre numeroasele noastre postări de blog. Ghidul nostru de instalare este un punct de plecare excelent, care prezintă modul de instalare pe sistemul de operare, configurarea completării filei și crearea unui fișier de configurare.

Cuprins

  1. Ce este Robo?
    1. Robo simplifică linia de comandă PHP
    2. Instalarea Robo
    3. Prima ta comanda
    4. Intrare și ieșire
    5. Mari Ajutatori
    6. Beneficiile Robo
  2. Menținerea WordPress cu Robo
    1. Fisierele importante
    2. Mediul Meu
    3. Utilizator baze de date
    4. Server Web
    5. Îngrijirea dependențelor
  3. Utilizarea wp-cli.yml
    1. Ce este un alias în WP-CLI?
    2. Valori implicite ale comenzii
  4. Crearea comenzilor Robo personalizate
    1. Configurarea comenzii
    2. Comanda de reset
    3. Pașii post-instalare
    4. Comanda de profile
  5. Încheierea

Ce este Robo?

Robo este un ruler de sarcini modern, open source, utilizat de o serie de proiecte, inclusiv Drush și Codeception.

Robo este similar cu Gulp și Grunt, dar folosește PHP mai degrabă decât JavaScript.

Ideea este că puteți crea comenzi mici și minunate ca aceasta:

# Resetați mediul meu de dezvoltare WP și faceți-l multisite
robo reset --multi

# Instalați și configurați pluginul WP Offload Media
profil robo ome-dev

Robo task runner facilitează documentarea comenzilor pe care le creați adăugând comentarii DocBlock la comenzile dvs., astfel încât să puteți oferi ajutor pentru versiunile viitoare ale dvs.:

# Robo fără niciun argument va afișa comenzile disponibile.
robo

Comenzi disponibile:
  ajutor Afișează ajutor pentru o comandă
  list Listează comenzi
  profile Rulați un set de comenzi wp-cli într-un mediu WordPress existent
  reset Resetați mediul WordPress la o stare cunoscută

Solicită mai multe informații despre o anumită comandă:

robo ajută la resetare

Descriere:
  Resetați mediul WordPress la o stare cunoscută. Citește mediile și configurația 
  din robo.yml

Utilizare:
  resetare [opțiuni]

Opțiuni:
      --env[=ENV] Mediu (dev, test etc) [implicit: „dev”]
      --multi Efectuați o instalare pe mai multe site-uri
      --ver[=VER] Versiunea WordPress [implicit: „latest”]

Am creat câteva comenzi puternice cu Robo pe care le folosesc în fiecare zi pentru a gestiona mediul meu de dezvoltare WordPress. În acest articol, voi împărtăși aceste comenzi cu dvs. și vă voi oferi o introducere în comenzile Robo pe parcurs.

Robo simplifică linia de comandă PHP

Să verificăm puțin oglinda retrovizoare. Scrierea comenzilor PHP din linia de comandă nu este cu siguranță nouă. A fost întotdeauna posibil să rulați un script PHP din linia de comandă astfel:

php myscript.php

Și PHP a fost disponibil ca mediu de linie de comandă în majoritatea mediilor *NIX de când îmi amintesc. Adăugarea PHP shebang va funcționa în majoritatea mediilor care au interpretul PHP instalat.

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

Ceea ce face posibilă executarea scriptului din linia de comandă fără a specifica faptul că ar trebui să fie analizat de PHP (sau să includă extensia de fișier .php):

myscript

Dezavantajul rulării de scripturi PHP brute din linia de comandă este că există destul de multă suprasarcină pentru intrare și ieșire de care trebuie să se ocupe în fiecare script. Procesul de acceptare a argumentelor din linia de comandă și apoi trimiterea mesajelor către linia de comandă este puțin greoi și nu se simte foarte flexibil.

Robo își propune să faciliteze scrierea în linia de comandă PHP, având grijă de o mulțime de „instalații” standard de care au nevoie majoritatea scripturilor. Acest lucru vă permite să vă concentrați pe funcționalitatea de bază a scripturilor dvs.

Instalarea Robo

Va trebui să instalați Robo înainte de a începe. Țin Robo instalat la nivel global pe mașina mea, așa că l-am instalat astfel:

compozitor global necesită consolidare/robo

Dar, ca și în cazul oricărui lucru instalat prin Composer, îl puteți păstra ca dependență de proiect dacă vă simțiți mai confortabil cu asta. Alternativ, GitHub are instrucțiuni despre instalarea acestuia prin descărcarea robo.phar .

Prima ta comanda

Mai întâi, trebuie să inițializam Robo în folderul de proiect:

cd /calea/la/proiectul meu
robo init

Acest lucru într-adevăr creează un nou RoboFile.php în folderul dvs. cu următorul conținut:

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

Pentru a adăuga prima noastră comandă, adăugăm doar o metodă publică:

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

După cum probabil puteți ghici, metoda de mai sus creează comanda hello și pur și simplu emite un mesaj pe ecran.

Analizarea argumentelor

Doar adăugarea acelei metode, așa cum am făcut mai sus, este o modalitate excelentă de a arăta unul dintre cele mai importante motive pentru care îmi place Robo, și anume analizarea argumentelor liniei de comandă.

Pentru a vă arăta ce vreau să spun, să încercăm să rulăm această comandă:

robo salut

Nu sunt suficiente argumente (lipsește: „lume”).

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

Aha! Robo îmi dă un mesaj de eroare, deoarece comanda hello se așteaptă de fapt la un parametru $world și apoi continuă să scrie sintaxa de utilizare completă pentru comandă.

Să schimbăm puțin metoda și să facem parametrul opțional:

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

... și acum hai să-l rulăm din nou:

# Fără argumente
robo salut
Bună, de la Robo

# Cu un simplu argument
robo salutare!
Salutare!

# Cu un argument care conține spații
robo salut „Trăiesc pe linia de comandă”
Bună, locuiesc pe linia de comandă

Asa e mai bine! Făcând parametrul opțional, Robo acum execută cu plăcere metoda noastră chiar și fără a trece un argument. De asemenea, am văzut că putem trece un argument simplu și un argument între ghilimele și pur și simplu funcționează.

Dacă ați petrecut vreodată timp scriind argumente verificând logica pentru un script de linie de comandă, probabil vă dați seama de ce aceasta este o caracteristică bună. Pur și simplu elimină multă durere.

Exemplul de comandă hello folosește un singur argument pozițional. Robo acceptă, de asemenea, utilizarea steagurilor și a argumentelor denumite prin crearea unui argument de matrice cu unele valori implicite.

Să modificăm funcția în continuare pentru a imprima opțional câteva caractere suplimentare:

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

Acest lucru îi va spune lui Robo că putem trece opțional argumente numite folosind liniuțe duble:

# Doar prin includerea unui argument numit, va obține valoarea „adevărat”
robo salut --stele
 ***************
 Bună, de la Robo
 ***************

Intrare și ieșire

De asemenea, am văzut deja un exemplu folosind IO. Funcția say() a obiectului task Robo pur și simplu scoate un șir înapoi către utilizator. Există, de asemenea, o funcție ask() care vă permite să cereți intrare utilizatorului:

 public function hello() { $word = $this->ask("Tell me what to say:"); $this->say( $word ); }
robo salut
? Spune-mi ce să spun: foobar
foobar

Robo folosește Symfony Console pentru a crea interacțiuni cu utilizatorul. Aceasta înseamnă că, pe lângă cele două funcții simple say() și ask() , avem acces la orice funcție din Consola Symfony, cum ar fi 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'], ] ); }
masa robo
---------- ----------
 Antet 1 Antet 2
---------- ----------
 Celula 1-1 Celula 1-2
 Celula 2-1 Celula 2-2
 Celula 3-1 Celula 3-2
---------- ----------

Destul de misto, nu?

Mari Ajutatori

Un alt motiv pentru care să-ți placă Robo este că are suport încorporat pentru multe sarcini obișnuite, care facilitează scrierea unui cod ușor de înțeles, chiar dacă revii la el 3 luni mai târziu. Să aruncăm o privire la modul în care Robo ajută la scrierea unui cod foarte curat pentru unele sarcini destul de 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();

Toate cele de mai sus sunt posibile folosind PHP obișnuit și funcția exec() , dar asta devine adesea un exercițiu fără speranță de a încerca să lipiți șirurile de comandă împreună și să scape corect de argumente fără a încurca lucrurile prea rău.

Pe lângă exemplele de mai sus, există și suport similar pentru Git, Subversion, Rsync, Bower, Gulp, Docker, NPM și alte instrumente adesea folosite în mediile de dezvoltare.

Beneficiile Robo

Luați împreună, Robo face crearea de scripturi de linie de comandă mult mai ușoară, iar rezultatul final este de obicei mult mai atrăgător din punct de vedere semantic decât PHP simplu.

Găsesc că scripturile pentru Robo ajung să fie mai ușor de citit și de înțeles în comparație cu scripturile PHP pure, deoarece o mare parte din chestiile standard ale liniei de comandă sunt ascunse în interiorul Robo. Personal, pot să mă uit la propriul cod după câteva luni și să mă întreb sincer cine l-a scris, așa că orice mă ajută să scriu un cod clar și lizibil este un plus binevenit în centura mea de instrumente.

Menținerea WordPress cu Robo

Restul acestui articol presupune că sunteți oarecum familiarizat cu WP-CLI, folosind Composer și lucrul cu linia de comandă.

Fisierele importante

Există patru fișiere importante în această configurare. Voi acoperi fiecare dintre ele pe parcursul acestei postări:

  1. wp-cli.yml – Fișierul standard de configurare WP-CLI. Folosesc acest lucru pentru a folosi câteva dintre caracteristicile încorporate ale WP-CLI atunci când vine vorba de gestionarea mai multor medii.
  2. RoboFile.php – Acesta este fișierul de bază pentru implementarea comenzilor robo.
  3. robo.yml – Un fișier YAML personalizat pentru câțiva parametri de configurare suplimentari pentru comenzile noastre Robo.
  4. composer.json – Fișierul de configurare standard al Composer.

Mediul Meu

Doar pentru a pregăti scena pentru restul acestui articol, voi descrie rapid modul în care este configurat mediul meu de dezvoltare locală. Aceasta este o versiune simplificată a modului în care am organizat lucrurile pe disc:

~/src
├── devenv/
│ ├── RoboFile.php
│ ├── compozitor.json
│ ├── wp-cli.yml
│ ├── robo.yml
│ ├── wordpress-dev/
│ └── wordpress-test/    
├── plugin1/
│ ├── active/
│ └── includ/
└── plugin2
    └──...

Folderul src este locul în care este stocat tot ceea ce are legătură cu dezvoltarea, iar folderul devenv conține fișiere specifice mediului de rulare real. Deoarece de obicei am mai mult de un mediu WordPress care rulează în același timp, fiecare instalare WordPress are propriul său subdosar, numit wordpress-dev și wordpress-test în acest exemplu.

Fiecare dintre pluginurile la care lucrez se află într-un folder separat pentru fiecare plugin.

În lumea reală, am mai multe foldere devenv, astfel încât să îmi pot păstra munca pentru Delicious Brains separat de diferite proiecte secundare, dar acest lucru nu este relevant pentru acest articol.

Utilizator baze de date

Pentru ca totul să funcționeze, am creat, de asemenea, baze de date locale pentru fiecare dintre instalările WordPress din instalația mea locală MySQL și există un utilizator al bazei de date, numit corect wordpress , cu acces corect la acele baze de date. Detaliile exacte ale bazelor de date, precum și acreditările utilizatorului sunt stocate în fișierul wp-cli.yml .

Server Web

Folosesc nginx ca server web local, dar veți descoperi că Apache2 funcționează la fel de bine. Configurația mea nginx este configurată astfel încât http://www.wordpress-dev.local și http://www.wordpress-test.local să indice cele două foldere WordPress menționate mai sus.

Îngrijirea dependențelor

Pentru a face scripturile mele Robo mai flexibile, folosesc unele funcționalități suplimentare instalate prin Composer, în special analizatorul Symfony Yaml. Deoarece RoboFile.php este într-adevăr doar un fișier PHP normal, sunt liber să includ orice biblioteci pe care le doresc și, în mod natural, folosesc Composer pentru a face asta. Fișierul composer.json pentru acest proiect arată astfel:

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

Dacă o copiați, nu uitați să instalați efectiv biblioteca folosind composer update .

Utilizarea wp-cli.yml

Când lucrați cu WP-CLI, puteți face viața mult mai simplă utilizând un fișier de configurare precum wp-cli.yml . Folosesc fișierul de configurare WP-CLI din două motive principale: aliasuri și configurarea setărilor implicite pentru diferite subcomenzi.

Ce este un alias în WP-CLI?

În esență, un alias WP-CLI este doar o etichetă în fișierul de configurare care vă permite să înlocuiți unele dintre valorile implicite.

Cea mai obișnuită utilizare a alias-urilor este probabil să suprascrieți path implicită, astfel încât fiecare alias să indice o instalare WordPress separată. Deoarece fiecare instalare WordPress își păstrează propriul fișier de configurare cu acreditările bazei de date, aliasul utilizat în acest fel reprezintă și o bază de date separată. Un alias din fișierul de configurare WP-CLI poate suprascrie setările url , path , user , ssh și http , dar nu poate suprascrie valorile implicite pentru subcomenzi.

Crearea unui mediu WordPress suplimentar numit @test îmi permite să rulez comenzi WP-CLI ca aceasta:

# Listați toate pluginurile din instalarea dev WordPress
lista de pluginuri wp

# Listați toate pluginurile din instalarea de test WordPress
wp @test lista de pluginuri

Valori implicite ale comenzii

Dacă nu ați încercat acest lucru înainte, configurarea parametrilor impliciti pentru subcomenzi este foarte utilă. De exemplu, atunci când creați un nou fișier de configurare WordPress folosind comanda config create , trebuie să specificați cel puțin trei parametri de fiecare dată:

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

Dacă te-ai săturat să tastezi asta, poți să lipiți parametrii într-un fișier wp-cli.yml :

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

Odată ce ați făcut asta, puteți utiliza wp config create și va prelua parametrii potriviți din fișierul dvs. wp-cli.yml .

Din păcate, nu este posibil să setați diferite valori implicite de comandă pentru diferite aliasuri. Acesta a fost de fapt unul dintre motivele pentru care am început să mă uit la Robo pentru mai multă automatizare.

Fișierul meu de configurare WP-CLI arată astfel:

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

Doar cu acest fișier de configurare pe loc, pot rula comenzi comune fără a fi necesar să specific de fiecare dată parametrii individuali:

# Resetați baza de date în mediul de testare
wp @test db reset --da

# Descărcați cea mai recentă versiune și creați fișierul wp-config.php
wp @test core download
wp @test config create

# Instalați WordPress
wp @test core install --title="Test WordPress"

Deoarece WP-CLI preia majoritatea parametrilor din fișierul de configurare, nu trebuie să scriu toți parametrii liniei de comandă, cum ar fi --dbuser și --admin_email , pe care ar trebui să o fac în mod normal.

Rețineți că în ultimul exemplu de mai sus am furnizat separat parametrul title . Acest lucru se datorează faptului că vreau ca titlul site-ului să fie diferit în mediul de testare, dar nu este posibil să suprascrieți acest parametru folosind un alias.

Crearea comenzilor Robo personalizate

Configurarea unei noi instalări WordPress nu este aproape niciodată suficientă. De obicei, există unul sau mai multe plugin-uri care trebuie instalate și activate și destul de des câteva setări de reparat ici și colo.

Chiar și cu un fișier de configurare WP-CLI scris cu atenție, aș ajunge cu un șir lung de comenzi dacă vreau să-mi resetez mediul WordPress și să pregătesc totul. Am făcut adesea secvențe ca aceasta din nou și din nou:

# Resetați mediul meu de dezvoltare
wp db reset --da
rm -rf cale/la/wordpress
descărcare wp core
wp config create
wp core install
ln -s calea/la/my/plugin1 calea/la/wordpress/wp-content/plugins/
wp plugin activați plugin1

Chiar și atunci când profitați din plin de fișierul de configurare WP-CLI, aceasta este multă tastare. Pentru a evita să tastez acest lucru din nou și din nou și, de asemenea, să greșesc din când în când, am creat două comenzi specializate folosind Robo pentru a face acest lucru pentru mine:

  • resetare – Resetează un mediu WordPress la o stare cunoscută.
  • profile – Rulează un set de comenzi într-un mediu existent.

Deoarece parametrii impliciti pentru subcomandă WP-CLI nu se extind la diferite medii de linie de comandă, putem folosi Robo pentru a ucide acea pasăre cu aceeași piatră. Să vedem cum.

Configurarea comenzii

Prima noastră oprire este să aruncăm o privire la fișierul de configurare Robo pe care l-am creat pentru asta. Este scris în YAML, ceea ce ar trebui să fie destul de simplu de înțeles și extins. Voi trece peste fiecare secțiune pe măsură ce ajungem la comanda care o folosește:

 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

Fiecare mediu WordPress este identificat folosind o cheie wordpress-$env . Fiecare cheie poate deține mai multe valori de configurare.

Comanda de reset

Prima comandă este reset . Este folosit din linia de comandă astfel:

# Resetați mediul de dezvoltare (implicit).
resetare robo

# Sau fiind mai explicit
resetare robo –env=dev

# Resetați mediul de testare
robo reset –env=test

# Resetați mediul de dezvoltare și instalați un multisite WordPress
robo reset --multi

# Resetați mediul de dezvoltare la o anumită versiune WordPress
robo reset --ver=5.6.1

Primul lucru pe care îl face această comandă este să ștergeți toate fișierele și folderele existente în directorul de instalare WordPress țintă și să resetați baza de date WordPress configurată.

Apoi, comanda de reset folosește comenzile WP-CLI core download , config create și una dintre core install sau core multisite-install , în funcție de opțiunea --multi .

În cea mai mare măsură posibilă, aceasta utilizează valorile implicite ale parametrului de comandă aflate în fișierul wp-cli.yml . Motivul pentru aceasta este că aceste valori implicite sunt utile și atunci când rulați WP-CLI direct fără învelișul Robo. Dar, după cum am discutat mai sus, în unele cazuri pur și simplu nu este posibil.

Prin urmare, fișierul de configurare robo.yml oferă posibilitatea de a specifica suprascrieri pentru valorile implicite în wp-cli.yml. De exemplu, când instalăm mediul @test, dorim să înlocuim parametrii pentru parametrul de core install --title . Putem face asta adăugând următoarele în robo.yml :

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

Sintaxa aici este destul de ușoară: numele comenzii CLI (spații înlocuite cu liniuțe) ca cheie și o subcheie pentru fiecare parametru numit. Exemplul de mai sus ar genera următorul parametru suplimentar pentru comanda core install cli:

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

Pașii post-instalare

Fiecare cheie de mediu din fișierul de configurare poate specifica opțional o matrice cu pași post-instalare. Aceasta este pur și simplu o listă de comenzi bash care sunt executate când instalarea WordPress este finalizată. Pentru mai multă flexibilitate, se fac câteva înlocuiri de șiruri înainte de executarea comenzii:

Şir Inlocuit cu
$cwd Directorul de lucru curent
$cale Calea instalării WordPress țintă
$wp Comanda wp-cli, inclusiv prefixul alias, adică wp @test
~ (simbol tilde) Directorul HOME al utilizatorului curent

Deci, un pas de post-instalare de ln -s $cwd/../plugin1 $path/wp-content/plugins/ ar crea un link simbolic de la unul dintre folderele mele cu pluginuri la subfolderul cu pluginuri din instalarea WordPress țintă.

Comanda de profile

Comanda de profile este destul de asemănătoare cu pașii de după instalare, dar scopul său este de a rula un set de comenzi pe o instalare WordPress existentă. Să presupunem că aveți un mediu de dezvoltare foarte simplu în care vă desfășurați cea mai mare parte a muncii. Cu toate acestea, uneori trebuie să instalați pluginul WooCommerce și să faceți niște setări de bază pentru el. Pentru asta este comanda profile . Poate fi folosit astfel:

# Resetați mediul de dezvoltare
resetare robo

# Instalați WooCommerce și faceți câteva modificări de configurare
profil robo woocommerce

Exemplul de fișier robo.yml de mai sus are un profil WooCommerce. Aplicarea acelui profil va:

  • Instalați și activați WooCommerce folosind WP-CLI.
  • Utilizați sub-comanda wc pentru a configura o poartă de plată, o zonă fiscală și setări de expediere.
  • Utilizați subcomandă option pentru a modifica unele setări direct în tabelul de opțiuni WordPress.

Utilizarea diferitelor profiluri este destul de utilă. Îmi petrec majoritatea zilelor lucrând la pluginul WP Offload Media și adesea trebuie să import o mulțime de imagini în biblioteca media WordPress. WP-CLI are o comandă foarte convenabilă pentru aceasta:

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

Deoarece uit adesea multe lucruri în general și nume de căi lungi în special, îmi este mai ușor să-mi amintesc:

robo profile imageimport

Iată un alt exemplu. Am lucrat la o anumită problemă GitHub în care încercăm să remediam o problemă de compatibilitate între pluginul nostru și un alt plugin WordPress popular. Când lucrez la această problemă, trebuie să instalez acel plugin și să setez o valoare de configurare în wp-config.php. Așa că am creat un profil pentru el:

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

Acum îmi pot pregăti mediul într-un singur pas, doar robo profile issue2530 .

La fel ca în pașii post-install din comanda de resetare, fiecare rând din definiția profilurilor este de fapt doar o comandă bash separată. Îl puteți folosi pentru a lansa scripturi separate, a șterge fișiere sau orice doriți. Este, de asemenea, foarte posibil să te împuști în picior, așa că mergi cu grijă.

Sursa

Dacă oricare dintre cele de mai sus sună interesant de încercat, iată RoboFile pe care îl folosesc pentru toate lucrurile de mai sus, nu ezitați să îl utilizați pentru a începe să gestionați WordPress folosind 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 ] ) ) ); } }

Încheierea

În dezvoltare, sarcinile repetitive tind să meargă cu teritoriul. Nu văd o modalitate de a le elimina complet, dar automatizarea cât mai multor dintre ele vă ajută cu adevărat să lucrați cât mai mult cu timpul disponibil.

Automatizarea unora dintre aceste sarcini cu combinația de WP-CLI și Robo pe care am subliniat-o aici mi-a economisit timp în fiecare zi ca dezvoltator de pluginuri. Nu m-aș putea întoarce niciodată să fac aceste lucruri manual din nou.

Ce instrumente folosiți pentru automatizarea celor mai obositoare părți ale fluxului dvs. de lucru de dezvoltare? Anunță-mă în comentarii.