WP-CLI ve Robo ile WordPress Geliştirme Ortamlarını Yönetme

Yayınlanan: 2022-09-13

Tekrarlayan görevleri otomatikleştirmek, geliştirme iş akışınızda zaman kazanmanın en iyi yollarından biridir. Eklenti geliştiricisi olarak günlük işlerimde, genellikle veritabanını sıfırlamam, belirli bir WordPress sürümünü yeniden yüklemem, bir veya daha fazla eklenti yüklemem ve ayarları güncellemem gerekir. Bu çabucak yorucu hale gelir, bu nedenle otomasyon için doğal bir seçimdir. Bu makalede, WordPress geliştirme ortamımı yönetmek için gereken görevleri otomatikleştirmek için WP-CLI'yi Robo ile birlikte nasıl kullandığımı göstereceğim.

WordPress komut satırı aracı WP-CLI, iş akışınızı hızlandırmak için harika bir başlangıçtır. Buna aşina değilseniz, birçok blog yazımızdan birini okumanızı şiddetle tavsiye ederim. Kurulum kılavuzumuz, onu işletim sisteminize nasıl kuracağınızı, sekme tamamlamayı nasıl ayarlayacağınızı ve bir yapılandırma dosyası oluşturacağınızı anlatan harika bir başlangıç ​​noktasıdır.

İçindekiler

  1. Robo nedir?
    1. Robo, PHP Komut Satırını Basitleştiriyor
    2. Robo'yu Yükleme
    3. İlk Komutunuz
    4. Giriş ve çıkış
    5. Büyük Yardımcılar
    6. Robo'nun Faydaları
  2. WordPress'i Robo ile Korumak
    1. Önemli Dosyalar
    2. Çevrem
    3. Veritabanı Kullanıcısı
    4. Web sunucusu
    5. Bağımlılıkların Bakımı
  3. wp-cli.yml'den yararlanma
    1. WP-CLI'de Takma Ad Nedir?
    2. Komut Varsayılanları
  4. Özel Robo Komutları Oluşturma
    1. Komut Yapılandırması
    2. reset Komutu
    3. Kurulum Sonrası Adımlar
    4. profile Komutu
  5. Toplama

Robo nedir?

Robo, Drush ve Codeception dahil olmak üzere bir dizi proje tarafından kullanılan açık kaynaklı modern bir görev çalıştırıcıdır.

Robo, Gulp ve Grunt'a benzer, ancak JavaScript yerine PHP kullanıyor.

Buradaki fikir, bunun gibi şık küçük komutlar oluşturabilmenizdir:

# WP dev ortamımı sıfırla ve çoklu site yap
robo sıfırlama --çoklu

# WP Offload Media eklentisini kurun ve kurun
robo profil ome-dev

Robo görev çalıştırıcı, komutlarınıza DocBlock yorumları ekleyerek oluşturduğunuz komutları belgelemenizi kolaylaştırır, böylece gelecekteki sürümleriniz için yardım sağlayabilirsiniz:

# Robo herhangi bir argüman olmadan mevcut komutları gösterecektir.
robot

Kullanılabilir komutlar:
  help Bir komut için yardım görüntüler
  Listeler komutları
  profile Mevcut bir WordPress ortamında bir dizi wp-cli komutu çalıştırın
  sıfırla WordPress ortamını bilinen bir duruma sıfırlayın

Belirli bir komut hakkında daha fazla bilgi istemek:

robo yardım sıfırlama

Tanım:
  WordPress ortamını bilinen bir duruma sıfırlayın. Ortamları ve yapılandırmayı okur 
  robo.yml'den

Kullanım:
  ayarları sıfırla]

Seçenekler:
      --env[=ENV] Ortam (geliştirme, test vb.) [varsayılan: "dev"]
      --multi Çoklu site kurulumu yap
      --ver[=VER] WordPress sürümü [varsayılan: "en son"]

WordPress geliştirme ortamımı yönetmek için her gün kullandığım Robo ile bazı güçlü komutlar oluşturdum. Bu yazıda, bu komutları sizinle paylaşacağım ve yol boyunca Robo komutlarına bir giriş yapacağım.

Robo, PHP Komut Satırını Basitleştiriyor

Dikiz aynasını biraz kontrol edelim. Komut satırı PHP komutları yazmak kesinlikle yeni değil. Komut satırından şöyle bir PHP betiği çalıştırmak her zaman mümkün olmuştur:

php myscript.php

Ve PHP, hatırlayabildiğim kadarıyla çoğu *NIX ortamında bir komut satırı ortamı olarak mevcuttu. PHP Shebang'ı eklemek, PHP yorumlayıcısının kurulu olduğu çoğu ortamda çalışacaktır.

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

Bu, PHP tarafından (veya .php dosya uzantısı dahil) ayrıştırılması gerektiğini belirtmeden komut satırından komut dosyasını çalıştırmayı mümkün kılar:

Myscript

Ham PHP betiklerini komut satırından çalıştırmanın dezavantajı, her betikte giriş ve çıkış için oldukça fazla ek yükün olmasıdır. Komut satırından argümanları kabul etme ve ardından mesajları komut satırına gönderme süreci biraz zahmetlidir ve çok esnek hissettirmez.

Robo, çoğu betiğin ihtiyaç duyduğu birçok standart “tesisat” ile ilgilenerek PHP komut satırı yazmayı kolaylaştırmayı amaçlıyor. Bu, komut dosyalarınızın temel işlevlerine odaklanmanızı sağlar.

Robo'yu Yükleme

Başlamadan önce Robo'yu yüklemeniz gerekecek. Robo'yu makinemde global olarak yüklü tutuyorum, bu yüzden şöyle kurdum:

besteci global konsolidasyon/robo gerektirir

Ancak Composer aracılığıyla yüklenen herhangi bir şeyde olduğu gibi, bu konuda daha rahatsanız, onu proje bağımlılığı olarak tutabilirsiniz. Alternatif olarak, robo.phar dosyasını indirerek yükleme talimatları vardır.

İlk Komutunuz

İlk olarak, proje klasöründe Robo'yu başlatmamız gerekiyor:

cd /yol/to/projem
robot başlangıç

Bu, klasörünüzde aşağıdaki içeriğe sahip yeni bir RoboFile.php oluşturur:

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

İlk komutumuzu eklemek için sadece bir genel yöntem ekliyoruz:

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

Tahmin edebileceğiniz gibi, yukarıdaki yöntem hello komutunu oluşturur ve ekranda bir mesaj verir.

Bağımsız Değişkenleri Ayrıştırma

Sadece yukarıda yaptığımız gibi bu yöntemi eklemek, Robo'yu sevmemin daha önemli nedenlerinden birini, yani komut satırı argümanlarını ayrıştırmayı göstermenin harika bir yoludur.

Size ne demek istediğimi göstermek için şu komutu çalıştırmayı deneyelim:

robot merhaba

Yeterli argüman yok (eksik: "dünya").

merhaba [-h|--help] [-q|--sessiz] [-v|vv|vvv|--ayrıntılı] [-V|--versiyon] [--ansi] [--no-ansi] [ -n|--hayır
-etkileşim] [--simülasyon] [--ilerleme-gecikmesi İLERLEME-GECİKMESİ] [-D|--tanımla DEFINE] [--]

Aha! hello komutu aslında bir $world parametresi beklediği ve ardından komut için tam kullanım sözdizimini yazmaya devam ettiği için Robo bana bir hata mesajı veriyor.

Metodu biraz değiştirelim ve parametreyi isteğe bağlı yapalım:

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

…ve şimdi tekrar çalıştıralım:

# Argümanlar olmadan
robot merhaba
Merhaba, Robo'dan

# Basit bir argümanla
robo merhaba orda!
Merhaba oradaki!

# Boşluk içeren bir arg ile
robo merhaba "Komut satırında yaşıyorum"
Merhaba, komut satırında yaşıyorum

Bu daha iyi! Parametreyi isteğe bağlı yaparak, Robo artık bir argüman iletmeden bile yöntemimizi mutlu bir şekilde yürütür. Ayrıca basit bir argümanı ve bir argümanı tırnak içine alabileceğimizi gördük ve işe yarıyor.

Bir komut satırı komut dosyası için argüman kontrol mantığı yazmak için herhangi bir zaman harcadıysanız, muhtemelen bunun neden güzel bir özellik olduğunu anlamışsınızdır. Sadece çok fazla acıyı alır.

Örnek hello komutu, tek bir konumsal argüman kullanır. Robo ayrıca bazı varsayılan değerlerle bir dizi argümanı oluşturarak bayrakların ve adlandırılmış argümanların kullanılmasını destekler.

İsteğe bağlı olarak bazı ek karakterleri yazdırmak için işlevi daha fazla değiştirelim:

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

Bu, Robo'ya isteğe bağlı olarak çift tire kullanarak adlandırılmış argümanları iletebileceğimizi söyleyecektir:

# Sadece adlandırılmış bir argüman ekleyerek 'true' değerini alacak
robo merhaba --yıldızlar
 ***************
 Merhaba, Robo'dan
 ***************

Giriş ve çıkış

Ayrıca IO kullanan bir örnek gördük. Robo görev nesnesinin say() işlevi, kullanıcıya yalnızca bir dize çıktısı verir. Kullanıcıdan girdi istemenizi sağlayan bir ask() işlevi de vardır:

 public function hello() { $word = $this->ask("Tell me what to say:"); $this->say( $word ); }
robot merhaba
? Bana ne diyeceğimi söyle: foobar
bilgi çubuğu

Robo, kullanıcı etkileşimleri oluşturmak için Symfony Konsolunu kullanır. Bu, iki basit say() ve ask() işlevinin yanı sıra, Symfony Console'dan table() gibi herhangi bir işleve erişimimiz olduğu anlamına gelir:

 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'], ] ); }
robot masası
---------- ----------
 Başlık 1 Başlık 2
---------- ----------
 Hücre 1-1 Hücre 1-2
 Hücre 2-1 Hücre 2-2
 Hücre 3-1 Hücre 3-2
---------- ----------

Oldukça havalı, ha?

Büyük Yardımcılar

Robo'yu sevmenin bir başka nedeni de, 3 ay sonra geri dönseniz bile, anlaşılır kod yazmayı kolaylaştıran birçok yaygın görev için yerleşik desteğe sahip olmasıdır. Robo'nun bazı oldukça standart görevler için çok temiz kod yazmaya nasıl yardımcı olduğuna bir göz atalım:

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

Yukarıdakilerin tümü normal PHP ve exec() işlevi kullanılarak mümkündür, ancak bu genellikle komut dizelerini birbirine yapıştırmaya çalışmak ve olayları çok fazla karıştırmadan argümanlardan doğru bir şekilde kaçmak için umutsuz bir alıştırma haline gelir.

Yukarıdaki örneklerin yanı sıra Git, Subversion, Rsync, Bower, Gulp, Docker, NPM ve geliştirme ortamlarında sıklıkla kullanılan diğer araçlar için de benzer destek vardır.

Robo'nun Faydaları

Birlikte ele alındığında, Robo komut satırı komut dosyaları oluşturmayı çok daha kolay hale getirir ve sonuç genellikle düz PHP'den çok daha semantik olarak çekicidir.

Robo betiklerinin saf PHP betiklerine kıyasla okunması ve anlaşılması daha kolay olduğunu görüyorum, çünkü komut satırı ortak plakası öğelerinin çoğu Robo'nun içinde gizli. Şahsen, birkaç ay sonra kendi koduma bakabilirim ve dürüstçe onu kimin yazdığını merak edebilirim, bu nedenle açık, okunabilir kod yazmama yardımcı olan her şey alet kemerimde hoş bir ektir.

WordPress'i Robo ile Korumak

Bu makalenin geri kalanında WP-CLI, Composer kullanımı ve komut satırı ile çalışma hakkında biraz bilgi sahibi olduğunuz varsayılmaktadır.

Önemli Dosyalar

Bu kurulumda dört önemli dosya vardır. Bu yazı boyunca her birini ele alacağım:

  1. wp-cli.yml – Standart WP-CLI yapılandırma dosyası. Konu birden çok ortamı yönetmeye geldiğinde, WP-CLI'nin birçok harika yerleşik özelliğinden yararlanmak için bunu kullanıyorum.
  2. RoboFile.php – Bu, robo komutlarını uygulamak için temel dosyadır.
  3. robo.yml – Robo komutlarımız için bazı ek yapılandırma parametreleri için özel bir YAML dosyası.
  4. besteci.json – Standart Besteci yapılandırma dosyası.

Çevrem

Bu makalenin geri kalanına zemin hazırlamak için, yerel geliştirme ortamımın nasıl kurulduğunu hızlıca anlatacağım. Bu, diskteki şeyleri nasıl düzenlediğimin basitleştirilmiş bir versiyonudur:

~/src
├── dev/
│ ├── RoboFile.php
│ ├── besteci.json
│ ├── wp-cli.yml
│ ├── robo.yml
│ ├── wordpress-dev/
│ └── wordpress testi/    
├── eklenti1/
│ ├── varlıklar/
│ └── dahil/
└── eklenti2
    └── ...

src klasörü, geliştirmeyle ilgili her şeyin depolandığı yerdir ve devenv klasörü, gerçek çalışma zamanı ortamına özgü dosyaları tutar. Genelde aynı anda çalışan birden fazla WordPress ortamım olduğundan, her WordPress kurulumunun bu örnekte wordpress-dev ve wordpress-test adlı kendi alt klasörü vardır.

Üzerinde çalıştığım eklentilerin her biri, eklenti başına ayrı bir klasörde oturuyor.

Gerçek dünyada, Delicious Brains çalışmamı çeşitli yan projelerden ayrı tutabilmem için birden fazla devenv klasörüm var, ancak bu bu makaleyle alakalı değil.

Veritabanı Kullanıcısı

Her şeyin çalışması için yerel MySQL kurulumumdaki WordPress kurulumlarının her biri için yerel veritabanları da oluşturdum ve bu veritabanlarına doğru erişimi olan uygun şekilde wordpress adlı bir veritabanı kullanıcısı var. Veritabanlarının tam ayrıntıları ve kullanıcı kimlik bilgileri wp-cli.yml dosyasında saklanır.

Web sunucusu

Yerel web sunucum olarak nginx kullanıyorum, ancak Apache2'nin de aynı şekilde çalıştığını göreceksiniz. Nginx yapılandırmam, http://www.wordpress-dev.local ve http://www.wordpress-test.local yukarıda bahsedilen iki WordPress klasörünü gösterecek şekilde ayarlandı.

Bağımlılıkların Bakımı

Robo komut dosyalarımı daha esnek hale getirmek için Composer aracılığıyla yüklenen bazı ek işlevler, özellikle de Symfony Yaml ayrıştırıcısı kullanıyorum. RoboFile.php gerçekten normal bir PHP dosyası olduğundan, istediğim kitaplıkları eklemekte özgürüm ve bunu yapmak için doğal olarak Composer kullanıyorum. Bu proje için composer.json dosyası şöyle görünür:

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

Bunu kopyalarsanız, kitaplığı gerçekten composer update kullanarak kurmayı unutmayın.

wp-cli.yml'den yararlanma

WP-CLI ile çalışırken wp-cli.yml gibi bir yapılandırma dosyası kullanarak hayatı çok daha basit hale getirebilirsiniz. WP-CLI yapılandırma dosyasını iki ana nedenden dolayı kullanıyorum: takma adlar ve çeşitli alt komutlar için varsayılanları ayarlama.

WP-CLI'de Takma Ad Nedir?

Özünde, bir WP-CLI takma adı, yapılandırma dosyasındaki bazı varsayılanları geçersiz kılmanıza izin veren bir etikettir.

Takma adların en yaygın kullanımı, muhtemelen her bir takma adın ayrı bir WordPress kurulumuna işaret etmesi için varsayılan path geçersiz kılmaktır. Her WordPress kurulumu, veritabanı kimlik bilgileriyle kendi yapılandırma dosyasını sakladığından, bu şekilde kullanılan takma ad ayrıca ayrı bir veritabanını temsil eder. WP-CLI yapılandırma dosyasındaki bir diğer ad, url , path , user , ssh ve http ayarlarını geçersiz kılabilir, ancak alt komutlar için varsayılan değerleri geçersiz kılamaz.

@test adlı ek bir WordPress ortamı oluşturmak, bunun gibi WP-CLI komutlarını çalıştırmama izin veriyor:

# Dev WordPress kurulumundaki tüm eklentileri listeleyin
wp eklenti listesi

# Test WordPress kurulumundaki tüm eklentileri listeleyin
wp @test eklenti listesi

Komut Varsayılanları

Bunu daha önce denemediyseniz, alt komutlar için varsayılan parametreleri ayarlamak çok kullanışlıdır. Örneğin, config create komutunu kullanarak yeni bir WordPress yapılandırma dosyası oluşturduğunuzda, her seferinde en az üç parametre belirtmeniz gerekir:

$ wp yapılandırma oluştur --dbname=somedb --dbuser=myuser --dbpass=secret

Bunu yazmaktan yorulursanız, parametreleri bir wp-cli.yml dosyasına yapıştırabilirsiniz:

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

Bunu yaptıktan sonra, wp config create komutunu kullanabilirsiniz ve wp-cli.yml dosyanızdan doğru parametreleri alacaktır.

Ne yazık ki, farklı takma adlar için farklı komut varsayılanları ayarlamak mümkün değildir. Bu aslında daha fazla otomasyon için Robo'ya bakmaya başlamamın nedenlerinden biriydi.

WP-CLI yapılandırma dosyam şöyle görünüyor:

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

Yalnızca bu yapılandırma dosyası yerindeyken, her seferinde tek tek parametreleri belirtmek zorunda kalmadan ortak komutları çalıştırabiliyorum:

# Test ortamında veritabanını sıfırlayın
wp @test db sıfırlama -- evet

# En son sürümü indirin ve wp-config.php dosyasını oluşturun
wp @test çekirdeği indir
wp @test yapılandırma oluşturma

# WordPress'i yükleyin
wp @test çekirdek kurulumu --title="WordPress Testi"

WP-CLI, yapılandırma dosyasındaki parametrelerin çoğunu aldığından, normalde yapmam gereken --dbuser ve --admin_email gibi tüm komut satırı parametrelerini yazmam gerekmiyor.

Yukarıdaki son örnekte title parametresini ayrı olarak sağladığımı unutmayın. Bunun nedeni, site başlığının test ortamında farklı olmasını istiyorum, ancak bir takma ad kullanarak bu parametreyi geçersiz kılmak mümkün değil.

Özel Robo Komutları Oluşturma

Yeni bir WordPress kurulumu kurmak neredeyse hiçbir zaman yeterli değildir. Genellikle yüklenmesi ve etkinleştirilmesi gereken bir veya daha fazla eklenti vardır ve çoğu zaman burada ve orada düzeltmek için birkaç ayar vardır.

Özenle yazılmış bir WP-CLI yapılandırma dosyasıyla bile, WordPress ortamımı sıfırlamak ve her şeyi hazır hale getirmek istersem yine de uzun bir komut dizisiyle karşılaşırdım. Sık sık bunun gibi dizileri tekrar tekrar yaptım:

# Geliştirme ortamımı sıfırla
wp db sıfırlama -- evet
rm -rf yolu/to/wordpress
wp çekirdek indir
wp yapılandırma oluşturma
wp çekirdek kurulumu
ln -s path/to/my/plugin1 path/to/wordpress/wp-content/plugins/
wp eklentisi eklentiyi etkinleştir1

WP-CLI yapılandırma dosyasından tam olarak yararlanırken bile, bu çok fazla yazmadır. Bunu tekrar tekrar yazmaktan ve ara sıra yanlış yapmaktan kaçınmak için, bunu benim için yapması için Robo'yu kullanarak iki özel komut oluşturdum:

  • reset – Bir WordPress ortamını bilinen bir duruma sıfırlar.
  • profile – Mevcut bir ortamda bir dizi komut çalıştırır.

WP-CLI alt komut varsayılan parametreleri farklı komut satırı ortamlarını kapsamadığından, o kuşu aynı taşla öldürmek için Robo'yu kullanabiliriz. Nasıl olduğunu görelim.

Komut Yapılandırması

İlk durağımız bunun için oluşturduğum Robo konfigürasyon dosyasına bir göz atmak. YAML'de yazılmıştır, bu da anlaşılmasını ve genişletilmesini oldukça basit hale getirmesi gerekir. Onu kullanan komuta ulaştığımızda her bölümün üzerinden geçeceğim:

 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

Her WordPress ortamı, bir wordpress-$env anahtarı kullanılarak tanımlanır. Her anahtar birkaç yapılandırma değerini tutabilir.

reset Komutu

İlk komut reset . Komut satırından şu şekilde kullanılır:

# Geliştirme (varsayılan) ortamını sıfırlayın
robot sıfırlama

# Veya daha açık olmak
robo sıfırlama –env=dev

# Test ortamını sıfırlayın
robo sıfırlama –env=test

# Geliştirme ortamını sıfırlayın ve bir WordPress multisite kurun
robo sıfırlama --çoklu

# Geliştirme ortamını belirli bir WordPress sürümüne sıfırlayın
robo sıfırlama --ver=5.6.1

Bu komutun yaptığı ilk şey, hedef WordPress kurulum dizinindeki tüm mevcut dosya ve klasörleri silmek ve yapılandırılmış WordPress veritabanını sıfırlamaktır.

Ardından reset komutu, --multi seçeneğine bağlı olarak core download , config create ve core install veya core multisite-install komutlarından biri olan WP-CLI komutlarını kullanır.

Bu, mümkün olan en geniş ölçüde, wp-cli.yml dosyasında bulunan komut parametresi varsayılanlarını kullanır. Bunun nedeni, bu varsayılanların, WP-CLI'yi doğrudan Robo sarmalayıcı olmadan çalıştırırken de yararlı olmasıdır. Ancak yukarıda tartışıldığı gibi, bazı durumlarda bu mümkün değildir.

Bu nedenle robo.yml yapılandırma dosyası, wp-cli.yml. Örneğin, @test ortamını kurarken, core install parametresi --title için parametreleri geçersiz kılmak istiyoruz. Bunu robo.yml aşağıdakileri ekleyerek yapabiliriz:

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

Buradaki sözdizimi oldukça kolaydır: anahtar olarak CLI komut adı (boşluklar tire ile değiştirilir) ve adlandırılmış her parametre için bir alt anahtar. Yukarıdaki örnek, core install cli komutuna aşağıdaki ekstra parametreyi oluşturacaktır:

wp @test çekirdek kurulumu --title="WordPress Testi"

Kurulum Sonrası Adımlar

Yapılandırma dosyasındaki her ortam anahtarı, isteğe bağlı olarak yükleme sonrası adımlarla bir dizi belirtebilir. Bu, WordPress kurulumu tamamlandığında yürütülen bash komutlarının bir listesidir. Daha fazla esneklik için komut yürütülmeden önce birkaç dize değişikliği yapılır:

Sicim ile değiştirildi
$cwd Geçerli çalışma dizini
$yol Hedef WordPress kurulumunun yolu
$wp Takma ad öneki dahil wp-cli komutu, yani wp @test
~ (tilde sembolü) Geçerli kullanıcının HOME dizini

Bu nedenle, ln -s $cwd/../plugin1 $path/wp-content/plugins/ kurulum sonrası adımı, eklenti klasörlerimden birinden hedef WordPress kurulumundaki eklentiler alt klasörüne bir sembolik bağlantı oluşturur.

profile Komutu

profile komutu, kurulum sonrası adımlara oldukça benzer, ancak kullanım amacı, mevcut bir WordPress kurulumunda bir dizi komut çalıştırmaktır. Diyelim ki işinizin çoğunu yaptığınız çok sade bir geliştirme ortamınız var. Ancak bazen WooCommerce eklentisini kurmanız ve bunun için bazı temel kurulumlar yapmanız gerekir. profile komutu bunun içindir. Şu şekilde kullanılabilir:

# Geliştirme ortamını sıfırlayın
robot sıfırlama

# WooCommerce'i kurun ve bazı kurulum değişiklikleri yapın
robo profil woocommerce

Yukarıdaki örnek robo.yml dosyası bir WooCommerce profiline sahiptir. Bu profili uygulamak:

  • WP-CLI kullanarak WooCommerce'i kurun ve etkinleştirin.
  • Bir ödeme ağ geçidi, vergi bölgesi ve gönderim ayarları ayarlamak için wc alt komutunu kullanın.
  • Bazı ayarları doğrudan WordPress seçenekler tablosunda değiştirmek için option alt komutunu kullanın.

Farklı profiller kullanmak oldukça faydalıdır. Günlerimin çoğunu WP Boşaltma Medyası eklentisi üzerinde çalışarak geçiriyorum ve sık sık WordPress medya kitaplığına çok sayıda resim aktarmam gerekiyor. WP-CLI bunun için gerçekten uygun bir komuta sahiptir:

wp medya içe aktarma /bazı/uzun/yol/I/sık sık/unutmak/*

Genelde çoğu şeyi ve özellikle uzun yol adlarını unuttuğum için hatırlamayı daha kolay buluyorum:

robo profil resmi içe aktarma

İşte başka bir örnek. Eklentimiz ile başka bir popüler WordPress eklentisi arasındaki uyumluluk sorununu düzeltmeye çalıştığımız belirli bir GitHub sorunu üzerinde çalışıyorum. Bu sorun üzerinde çalıştığımda, o eklentiyi kurmam ve wp-config.php. Bunun için bir profil oluşturdum:

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

Artık ortamımı tek adımda kullanıma hazır hale getirebilirim, sadece robo profile issue2530 .

Sıfırlama komutundaki post-install adımlar gibi, profil tanımındaki her satır gerçekten ayrı bir bash komutudur. Ayrı komut dosyaları başlatmak, dosyaları silmek veya ne istersen onu kullanabilirsin. Kendinizi ayağınızdan vurmanız da oldukça olasıdır, bu nedenle dikkatli bir şekilde adım atın.

Kaynak

Yukarıdakilerden herhangi birini denemek ilginç geliyorsa, işte yukarıdakilerin tümü için kullandığım RoboFile, Robo kullanarak WordPress'i yönetmeye başlamak için kullanmaktan çekinmeyin.

 <?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 ] ) ) ); } }

Toplama

Geliştirmede, tekrarlayan görevler bölge ile gitme eğilimindedir. Bunları tamamen ortadan kaldırmanın bir yolunu göremiyorum, ancak mümkün olduğunca çoğunu otomatikleştirmek, mevcut zamanla çok fazla gerçek iş yapmanıza gerçekten yardımcı oluyor.

Bu görevlerin bazılarını burada özetlediğim WP-CLI ve Robo kombinasyonu ile otomatikleştirmek, bir eklenti geliştiricisi olarak her gün benim için zaman kazandırdı. Bu şeyleri tekrar manuel olarak yapmaya asla geri dönemezdim.

Geliştirme iş akışınızın en sıkıcı kısımlarını otomatikleştirmek için hangi araçları kullanıyorsunuz? Yorumlarda bana bildirin.