Zarządzanie środowiskami deweloperskimi WordPress za pomocą WP-CLI i Robo

Automatyzacja powtarzających się zadań to jeden z najlepszych sposobów na zaoszczędzenie czasu w przepływie pracy deweloperskiej. W mojej codziennej pracy jako programista wtyczek często muszę resetować bazę danych, ponownie instalować określoną wersję WordPressa, instalować jedną lub więcej wtyczek i aktualizować ustawienia. To szybko staje się męczące, więc jest to naturalne dopasowanie do automatyzacji. W tym artykule pokażę, jak używam WP-CLI w połączeniu z Robo do automatyzacji zadań potrzebnych do zarządzania moim środowiskiem programistycznym WordPress.

Narzędzie wiersza poleceń WordPress, WP-CLI, to świetny początek przyspieszenia przepływu pracy. Jeśli go nie znasz, gorąco polecam przeczytanie jednego z wielu naszych postów na blogu. Nasz przewodnik instalacji to świetny punkt wyjścia, przedstawiający sposób instalacji w systemie operacyjnym, konfiguracji uzupełniania zakładek i tworzenia pliku konfiguracyjnego.

Spis treści

1. Co to jest Robo?
   1. Robo upraszcza wiersz poleceń PHP
   2. Instalowanie Robo
   3. Twoje pierwsze dowództwo
   4. Wejście i wyjście
   5. Wielcy Pomocnicy
   6. Korzyści z Robo
2. Utrzymanie WordPressa za pomocą Robo
   1. Ważne pliki
   2. Moje środowisko
   3. Użytkownik bazy danych
   4. Serwer internetowy
   5. Dbanie o zależności
3. Wykorzystanie wp-cli.yml
   1. Co to jest alias w WP-CLI?
   2. Domyślne polecenia
4. Tworzenie niestandardowych poleceń Robo
   1. Konfiguracja poleceń
   2. Polecenie reset
   3. Kroki po instalacji
   4. Polecenie profile
5. Zawijanie

Co to jest Robo?

Robo to nowoczesny program do uruchamiania zadań typu open source, używany w wielu projektach, w tym w Drush i Codeception.

Robo jest podobny do Gulp i Grunt, ale używa PHP zamiast JavaScript.

Pomysł polega na tym, że możesz tworzyć sprytne małe polecenia, takie jak:

# Zresetuj moje środowisko programistyczne WP i spraw, aby było wielostanowiskowe
resetowanie robo -- multi

# Zainstaluj i skonfiguruj wtyczkę WP Offload Media
robo profil ome-dev

Program uruchamiający zadania Robo ułatwia dokumentowanie tworzonych poleceń, dodając komentarze DocBlock do poleceń, dzięki czemu możesz zapewnić pomoc dla przyszłych wersji siebie:

# Robo bez żadnych argumentów pokaże dostępne polecenia.
robota

Dostępne polecenia:
  pomoc Wyświetla pomoc do polecenia
  lista Lista poleceń
  profil Uruchom zestaw poleceń wp-cli w istniejącym środowisku WordPress
  reset Zresetuj środowisko WordPress do znanego stanu

Pytanie o więcej informacji o konkretnym poleceniu:

reset pomocy robo

Opis:
  Zresetuj środowisko WordPress do znanego stanu. Odczytuje środowiska i konfigurację 
  z robo.yml

Stosowanie:
  zresetuj [opcje]

Opcje:
      --env[=ENV] Środowisko (dev, test itp.) [domyślnie: "dev"]
      --multi Wykonaj instalację w wielu witrynach
      --ver[=VER] Wersja WordPressa [domyślnie: "najnowsza"]

W Robo stworzyłem kilka potężnych poleceń, których używam na co dzień do zarządzania moim środowiskiem programistycznym WordPress. W tym artykule podzielę się z wami tymi poleceniami i po drodze przedstawię wprowadzenie do poleceń Robo.

Robo upraszcza wiersz poleceń PHP

Sprawdźmy trochę lusterko wsteczne. Pisanie poleceń PHP w wierszu poleceń z pewnością nie jest niczym nowym. Zawsze można było po prostu uruchomić skrypt PHP z wiersza poleceń w ten sposób:

php mój skrypt.php

Odkąd tylko pamiętam, PHP było dostępne jako środowisko wiersza poleceń w większości środowisk *NIX. Dodanie PHP shebang zadziała w większości środowisk, w których zainstalowany jest interpreter PHP.

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

Dzięki temu możliwe jest wykonanie skryptu z wiersza poleceń bez określania, że ​​ma on być parsowany przez PHP (lub dołączania rozszerzenia pliku .php):

mój skrypt

Wadą uruchamiania surowych skryptów PHP z wiersza poleceń jest to, że w każdym skrypcie trzeba się zatroszczyć o wejście i wyjście. Proces akceptowania argumentów z wiersza poleceń, a następnie wyprowadzania komunikatów do wiersza poleceń jest nieco kłopotliwy i nie wydaje się zbyt elastyczny.

Robo stara się ułatwić pisanie PHP w wierszu poleceń, dbając o wiele standardowych „hydrauliki”, których potrzebuje większość skryptów. Pozwala to skupić się na podstawowej funkcjonalności skryptów.

Instalowanie Robo

Musisz zainstalować Robo, zanim zaczniemy. Trzymam Robo zainstalowanego globalnie na moim komputerze, więc zainstalowałem go w ten sposób:

kompozytor globalny wymaga konsolidacji/robo

Ale tak jak w przypadku wszystkiego, co jest instalowane przez Composer, możesz zachować to jako zależność projektu, jeśli Ci to wygodniej. Alternatywnie GitHub ma instrukcje dotyczące instalacji, pobierając robo.phar .

Twoje pierwsze dowództwo

Najpierw musimy zainicjować Robo w folderze projektu:

cd /ścieżka/do/mójprojekt
robo init

To naprawdę po prostu tworzy nowy RoboFile.php w twoim folderze z następującą zawartością:

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

Aby dodać nasze pierwsze polecenie, po prostu dodajemy metodę publiczną:

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

Jak zapewne się domyślasz, powyższa metoda tworzy polecenie hello i po prostu wyświetla komunikat na ekranie.

Parsowanie argumentów

Samo dodanie tej metody, tak jak to zrobiliśmy powyżej, jest świetnym sposobem na pokazanie jednego z ważniejszych powodów, dla których lubię Robo, a mianowicie parsowania argumentów wiersza poleceń.

Aby pokazać, o co mi chodzi, spróbujmy uruchomić to polecenie:

Robo cześć

Za mało argumentów (brak: „świat”).

cześć [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--wersja] [--ansi] [--no-ansi] [ -n|--nie
-interaction] [--simulate] [--progress-delay PROGRESS-DELAY] [-D|--define DEFINE] [--]

Aha! Robo wyświetla komunikat o błędzie, ponieważ polecenie hello faktycznie oczekuje parametru $world , a następnie przystępuje do wypisania pełnej składni polecenia.

Zmieńmy nieco metodę i ustawmy parametr jako opcjonalny:

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

…a teraz uruchommy go ponownie:

# Bez argumentów
Robo cześć
Witam, od Robo

# Prostym argumentem
robo witam!
Witam!

# Z argumentem zawierającym spacje
robo witam „Mieszkam w wierszu poleceń”
Witam mieszkam na linii poleceń

Tak jest lepiej! Dzięki uczynieniu parametru opcjonalnym, Robo szczęśliwie wykonuje teraz naszą metodę nawet bez przekazywania argumentu. Widzieliśmy również, że możemy przekazać prosty argument i argument w cudzysłowie i to po prostu działa.

Jeśli kiedykolwiek spędziłeś czas na pisaniu logiki sprawdzania argumentów dla skryptu wiersza poleceń, prawdopodobnie zdajesz sobie sprawę, dlaczego jest to przyjemna funkcja. To po prostu zabiera dużo bólu.

Przykładowe polecenie hello używa jednego pojedynczego argumentu pozycyjnego. Robo obsługuje również używanie flag i nazwanych argumentów, tworząc argument tablicowy z pewnymi wartościami domyślnymi.

Zmodyfikujmy dalej funkcję, aby opcjonalnie wydrukować kilka dodatkowych znaków:

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

To powie Robo, że możemy opcjonalnie przekazać nazwane argumenty za pomocą podwójnych myślników:

# Po prostu dołączając nazwany argument, otrzyma wartość 'true'
robo witam -- gwiazdki
 ***************
 Witam, od Robo
 ***************

Wejście i wyjście

Widzieliśmy już również przykład z wykorzystaniem IO. Funkcja say() obiektu zadania Robo po prostu wyprowadza ciąg znaków z powrotem do użytkownika. Istnieje również funkcja ask() , która pozwala poprosić użytkownika o wprowadzenie danych:

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

Robo cześć
? Powiedz mi, co powiedzieć: foobar
foobar

Robo używa konsoli Symfony do tworzenia interakcji z użytkownikiem. Oznacza to, że oprócz dwóch prostych funkcji say() i ask() , mamy dostęp do dowolnej funkcji z konsoli Symfony, takiej jak 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'], ] ); }

stół robo
---------- ----------
 Nagłówek 1 Nagłówek 2
---------- ----------
 Ogniwo 1-1 Ogniwo 1-2
 Ogniwo 2-1 Ogniwo 2-2
 Ogniwo 3-1 Ogniwo 3-2
---------- ----------

Całkiem fajnie, co?

Wielcy Pomocnicy

Innym powodem, dla którego warto polubić Robo, jest to, że ma wbudowaną obsługę wielu typowych zadań, co ułatwia pisanie zrozumiałego kodu, nawet jeśli wrócisz do niego 3 miesiące później. Przyjrzyjmy się, jak Robo pomaga w pisaniu bardzo czystego kodu dla kilku dość standardowych zadań:

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

Wszystko to jest możliwe przy użyciu normalnego PHP i funkcji exec() , ale to dość często staje się beznadziejnym ćwiczeniem polegającym na sklejaniu ze sobą ciągów poleceń i poprawnym unikaniu argumentów bez zbytniego zepsucia sprawy.

Oprócz powyższych przykładów istnieje również podobne wsparcie dla Git, Subversion, Rsync, Bower, Gulp, Docker, NPM i innych narzędzi często używanych w środowiskach programistycznych.

Korzyści z Robo

Podsumowując, Robo znacznie ułatwia tworzenie skryptów wiersza poleceń, a wynik końcowy jest zwykle znacznie bardziej atrakcyjny semantycznie niż zwykły PHP.

Uważam, że skrypty dla Robo są łatwiejsze do odczytania i zrozumienia w porównaniu z czystymi skryptami PHP, ponieważ tak wiele elementów standardowych linii poleceń jest ukrytych w samym Robo. Osobiście mogę po kilku miesiącach spojrzeć na swój własny kod i szczerze się zastanawiać, kto go napisał, więc wszystko, co pomaga mi pisać przejrzysty, czytelny kod, jest mile widzianym dodatkiem w moim pasku narzędzi.

Utrzymanie WordPressa za pomocą Robo

W dalszej części tego artykułu zakładamy, że znasz nieco WP-CLI, używasz Composera i pracujesz z wierszem poleceń.

Ważne pliki

W tej konfiguracji są cztery ważne pliki. W tym poście omówię każdy z nich:

1. wp-cli.yml – Standardowy plik konfiguracyjny WP-CLI. Używam tego, aby wykorzystać kilka wspaniałych wbudowanych funkcji WP-CLI, jeśli chodzi o zarządzanie wieloma środowiskami.
2. RoboFile.php – jest to podstawowy plik do implementacji poleceń robo.
3. robo.yml — niestandardowy plik YAML zawierający dodatkowe parametry konfiguracyjne dla naszych poleceń Robo.
4. composer.json – standardowy plik konfiguracyjny Composera.

Moje środowisko

Aby przygotować grunt pod resztę tego artykułu, opiszę szybko, jak skonfigurowane jest moje lokalne środowisko programistyczne. To jest uproszczona wersja tego, jak zorganizowałem rzeczy na dysku:

~/src
devenv/
RoboFile.php
kompozytor.json
│ ├── wp-cli.yml
robo.yml
│ ├── wordpress-dev/
│ └── wordpress-test/    
├── plugin1/
│ ├── aktywa/
│ └── zawiera/
└── plugin2
    ...

Folder src to miejsce, w którym przechowywane są wszystko, co jest związane z programowaniem, a folder devenv zawiera pliki specyficzne dla rzeczywistego środowiska wykonawczego. Ponieważ zwykle mam więcej niż jedno środowisko WordPress działające w tym samym czasie, każda instalacja WordPressa ma swój własny podfolder o nazwach wordpress-dev i wordpress-test w tym przykładzie.

Każda z wtyczek, nad którymi pracuję, znajduje się w osobnym folderze dla każdej wtyczki.

W prawdziwym świecie mam wiele folderów devenv, dzięki czemu mogę oddzielić moją pracę dla Delicious Brains od różnych projektów pobocznych, ale nie jest to istotne w tym artykule.

Użytkownik bazy danych

Aby wszystko działało, stworzyłem również lokalne bazy danych dla każdej instalacji WordPressa w mojej lokalnej instalacji MySQL i jest tam użytkownik bazy danych, trafnie nazwany wordpress , z poprawnym dostępem do tych baz. Dokładne szczegóły baz danych oraz poświadczenia użytkownika są przechowywane w pliku wp-cli.yml .

Serwer internetowy

Używam nginx jako mojego lokalnego serwera WWW, ale przekonasz się, że Apache2 działa równie dobrze. Moja konfiguracja nginx jest skonfigurowana tak, aby http://www.wordpress-dev.local i http://www.wordpress-test.local wskazywały na dwa wspomniane wyżej foldery WordPress.

Dbanie o zależności

Aby moje skrypty Robo były bardziej elastyczne, używam dodatkowej funkcjonalności instalowanej przez Composer, w szczególności parsera Symfony Yaml. Ponieważ RoboFile.php jest tak naprawdę zwykłym plikiem PHP, mogę dołączyć dowolne biblioteki i oczywiście używam do tego Composera. Plik composer.json dla tego projektu wygląda tak:

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

Jeśli to skopiujesz, nie zapomnij zainstalować biblioteki za pomocą composer update .

Wykorzystanie wp-cli.yml

Podczas pracy z WP-CLI możesz znacznie uprościć życie, używając pliku konfiguracyjnego, takiego jak wp-cli.yml . Używam pliku konfiguracyjnego WP-CLI z dwóch głównych powodów: aliasów i ustawień domyślnych dla różnych podkomend.

Co to jest alias w WP-CLI?

U podstaw aliasu WP-CLI jest po prostu etykieta w pliku konfiguracyjnym, która pozwala zastąpić niektóre ustawienia domyślne.

Najczęstszym zastosowaniem aliasów jest prawdopodobnie zastąpienie domyślnej path , tak aby każdy alias wskazywał osobną instalację WordPress. Ponieważ każda instalacja WordPressa przechowuje własny plik konfiguracyjny z poświadczeniami bazy danych, używany w ten sposób alias reprezentuje również oddzielną bazę danych. Alias ​​w pliku konfiguracyjnym WP-CLI może zastąpić ustawienia url , path , user , ssh i http , ale nie może zastąpić domyślnych wartości podkomend.

Stworzenie dodatkowego środowiska WordPress o nazwie @test pozwala mi uruchamiać takie polecenia WP-CLI:

# Lista wszystkich wtyczek w instalacji deweloperskiej WordPress
lista wtyczek wp

# Lista wszystkich wtyczek w testowej instalacji WordPress
wp @lista wtyczek testowych

Domyślne polecenia

Jeśli nie próbowałeś tego wcześniej, ustawienie domyślnych parametrów podkomend jest bardzo przydatne. Na przykład, gdy tworzysz nowy plik konfiguracyjny WordPress za pomocą polecenia config create , musisz za każdym razem określić co najmniej trzy parametry:

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

Jeśli kiedykolwiek znudzi Ci się wpisywanie tego, możesz wkleić parametry do pliku wp-cli.yml :

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

Gdy to zrobisz, możesz po prostu użyć wp config create i pobierze odpowiednie parametry z twojego pliku wp-cli.yml .

Niestety nie jest możliwe ustawienie różnych wartości domyślnych poleceń dla różnych aliasów. To był właściwie jeden z powodów, dla których zacząłem szukać w Robo większej automatyzacji.

Mój plik konfiguracyjny WP-CLI wygląda tak:

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

Mając tylko ten plik konfiguracyjny, jestem w stanie uruchamiać typowe polecenia bez konieczności określania za każdym razem poszczególnych parametrów:

# Zresetuj bazę danych w środowisku testowym
wp @test db reset --tak

# Pobierz najnowszą wersję i utwórz plik wp-config.php
wp @pobierz rdzeń testowy
wp @utwórz konfigurację testową

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

Ponieważ WP-CLI pobiera większość parametrów z pliku konfiguracyjnego, nie muszę wpisywać wszystkich parametrów wiersza poleceń, takich jak --dbuser i --admin_email , co normalnie musiałbym zrobić.

Zauważ, że w ostatnim przykładzie powyżej podałem parametr title oddzielnie. Dzieje się tak, ponieważ chcę, aby tytuł witryny był inny w środowisku testowym, ale nie można zastąpić tego parametru za pomocą aliasu.

Tworzenie niestandardowych poleceń Robo

Konfiguracja nowej instalacji WordPressa prawie nigdy nie wystarcza. Zwykle istnieje jedna lub więcej wtyczek, które należy zainstalować i aktywować, a często kilka ustawień do poprawienia tu i tam.

Nawet ze starannie napisanym plikiem konfiguracyjnym WP-CLI nadal będę miał długi ciąg poleceń, jeśli chcę zresetować środowisko WordPress i wszystko przygotować. Często powtarzałem takie sekwencje w kółko:

# Zresetuj moje środowisko programistyczne
wp db reset -- tak
rm -rf ścieżka/do/wordpress
pobierz rdzeń wp
tworzenie konfiguracji wp
instalacja rdzenia wp
ln -s ścieżka/do/moja/plugin1 ścieżka/do/wordpress/wp-content/plugins/
wp plugin aktywuj plugin1

Nawet przy pełnym wykorzystaniu pliku konfiguracyjnego WP-CLI jest to dużo pisania. Aby uniknąć ciągłego wpisywania tego i od czasu do czasu popełniania błędów, stworzyłem dwa wyspecjalizowane polecenia za pomocą Robo, aby zrobić to za mnie:

• reset — resetuje środowisko WordPress do znanego stanu.
• profil — uruchamia zestaw poleceń w istniejącym środowisku.

Ponieważ domyślne parametry podkomendy WP-CLI nie rozciągają się na różne środowiska wiersza poleceń, możemy użyć Robo do zabicia tego ptaka tym samym kamieniem. Zobaczmy jak.

Konfiguracja poleceń

Naszym pierwszym przystankiem jest przyjrzenie się plikowi konfiguracyjnemu Robo, który w tym celu utworzyłem. Jest napisany w YAML, co powinno ułatwić zrozumienie i rozszerzenie. Przejdę do każdej sekcji, gdy dojdziemy do polecenia, które go używa:

 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

Każde środowisko WordPress jest identyfikowane za pomocą klucza wordpress-$env . Każdy klucz może zawierać kilka wartości konfiguracyjnych.

Polecenie reset

Pierwsze polecenie jest reset . Jest używany z wiersza poleceń w następujący sposób:

# Zresetuj środowisko programistyczne (domyślne)
resetowanie robota

# Lub bycie bardziej jednoznacznym
reset robo – env=dev

# Zresetuj środowisko testowe
reset robo – env=test

# Zresetuj środowisko deweloperskie i zainstaluj WordPress multisite
resetowanie robo -- multi

# Zresetuj środowisko deweloperskie do określonej wersji WordPress
reset robo -- wersja = 5.6.1

Pierwszą rzeczą, jaką robi to polecenie, jest usunięcie wszystkich istniejących plików i folderów w docelowym katalogu instalacyjnym WordPress i zresetowanie skonfigurowanej bazy danych WordPress.

Następnie polecenie reset używa poleceń WP-CLI core download , config create i jednego z core install lub core multisite-install w zależności od opcji --multi .

W największym możliwym stopniu wykorzystuje to domyślne parametry polecenia znajdujące się w pliku wp-cli.yml . Powodem tego jest to, że te wartości domyślne są również pomocne podczas bezpośredniego uruchamiania WP-CLI bez opakowania Robo. Ale jak omówiono powyżej, w niektórych przypadkach jest to po prostu niemożliwe.

Dlatego plik konfiguracyjny robo.yml oferuje możliwość określenia nadpisań dla wartości domyślnych w wp-cli.yml. Na przykład podczas instalowania środowiska @test chcemy nadpisać parametry dla core install --title . Możemy to zrobić, dodając w robo.yml :

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

Składnia tutaj jest dość prosta: nazwa polecenia CLI (spacje zastąpione myślnikami) jako klucz i jeden podklucz dla każdego nazwanego parametru. Powyższy przykład wygeneruje następujący dodatkowy parametr do polecenia core install cli:

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

Kroki po instalacji

Każdy klucz środowiskowy w pliku konfiguracyjnym może opcjonalnie określać tablicę z krokami poinstalacyjnymi. Jest to po prostu lista poleceń bash, które są wykonywane po zakończeniu instalacji WordPress. Aby zwiększyć elastyczność, przed wykonaniem polecenia wykonywanych jest kilka zamian ciągów:

Tak więc krok po instalacji ln -s $cwd/../plugin1 $path/wp-content/plugins/ utworzy dowiązanie symboliczne z jednego z moich folderów wtyczek do podfolderu wtyczek w docelowej instalacji WordPressa.

Polecenie profile

Polecenie profile jest dość podobne do kroków po instalacji, ale jego przeznaczeniem jest uruchomienie zestawu poleceń w istniejącej instalacji WordPress. Załóżmy, że masz bardzo proste środowisko programistyczne, w którym wykonujesz większość swojej pracy. Czasami jednak musisz zainstalować wtyczkę WooCommerce i wykonać dla niej podstawową konfigurację. Do tego służy polecenie profile . Może być używany w ten sposób:

# Zresetuj środowisko deweloperskie
resetowanie robota

# Zainstaluj WooCommerce i wprowadź zmiany w konfiguracji
robo profil woocommerce

Przykładowy plik robo.yml powyżej ma profil WooCommerce. Zastosowanie tego profilu spowoduje:

• Zainstaluj i aktywuj WooCommerce za pomocą WP-CLI.
• Użyj polecenia podrzędnego wc , aby skonfigurować bramkę płatności, strefę podatkową i ustawienia wysyłki.
• Użyj polecenia option , aby zmodyfikować niektóre ustawienia bezpośrednio w tabeli opcji WordPress.

Korzystanie z różnych profili jest całkiem przydatne. Spędzam większość dni pracując nad wtyczką WP Offload Media i często muszę importować wiele obrazów do biblioteki multimediów WordPress. WP-CLI ma do tego naprawdę wygodne polecenie:

wp importuj media /jakaś/długa/ścieżka/I/często/zapomnij/*

Ponieważ często zapominam o wielu rzeczach w ogóle, a w szczególności o długich nazwach ścieżek, łatwiej mi je zapamiętać:

Import obrazu profilu robo

Oto kolejny przykład. Pracowałem nad konkretnym problemem GitHub, w którym próbujemy naprawić problem ze zgodnością między naszą wtyczką a inną popularną wtyczką WordPress. Kiedy pracuję nad tym problemem, muszę zainstalować tę wtyczkę i ustawić wartość konfiguracyjną w wp-config.php. Stworzyłem więc dla niego profil:

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

Teraz mogę przygotować moje środowisko w jednym kroku, wystarczy robo profile issue2530 .

Podobnie jak kroki post-install w poleceniu resetowania, każdy wiersz w definicji profili jest tak naprawdę osobnym poleceniem bash. Możesz go użyć do uruchomienia oddzielnych skryptów, usunięcia plików lub cokolwiek chcesz. Całkiem możliwe jest również strzelenie sobie w stopę, więc stąpaj ostrożnie.

Źródło

Jeśli którykolwiek z powyższych brzmi interesująco do wypróbowania, oto RoboFile, którego używam do wszystkich powyższych rzeczy, możesz go użyć, aby rozpocząć zarządzanie WordPress za pomocą 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 ] ) ) ); } }

Zawijanie

W rozwoju, powtarzalne zadania zwykle idą w parze z terytorium. Nie widzę sposobu na całkowite ich wyeliminowanie, ale zautomatyzowanie ich tak wielu, jak to możliwe, naprawdę pomaga wykonać jak najwięcej prawdziwej pracy w dostępnym czasie.

Automatyzacja niektórych z tych zadań za pomocą połączenia WP-CLI i Robo, które tu opisałem, zaoszczędziło mi czasu każdego dnia jako programisty wtyczek. Nigdy więcej nie mogłem wrócić do robienia tych rzeczy ręcznie.

Jakich narzędzi używasz do automatyzacji najbardziej żmudnych części pracy programistycznej? Daj znać w komentarzach.