WP-CLI Config Komutu ve İşlemleri

Komut Satırı Aracılığı İle WordPress Yönetimi

WP-ClI ile ilgili değinmek istediğim son birkaç ana konu kaldı. wp config bunlardan biri ve aslında doğrudan çok kullanılmasa da ihtiyaçlarımıza göre önceden yapılandırıldığında WP-CLI kullanım sürecini oldukça pratikleştirmekte.
AA

Bu yazıda da tam olarak değineceğim konu wp config yapılandırma süreci ve belli başlı bazı komutlar olacak ve özellikle YAML içeriğine odaklanacağım.

WP-CLI Konfigürasyon Dosyaları

WP-CLI ile uzak bir sunucuda ya da sunuculardaki WordPress web site(leri)mize hızlı ve güvenli bir şekilde nasıl erişim sağlayabileceğimizden daha önce bahsetmiştim. İlgili işlem aslında sunucu içeriğindeki erişimleri de kapsamakta. Örneğin, DigitalOcean bünyesinde aynı droplet içerisinde birden fazla WordPress kurulumu kullanmaktayım. Doğru bir yapılandırma ile tanımladığım kısa adlarla hızlı bir şekilde tüm işlemlerimi hem sunucu içinde hem de diğer sunuculardaki kurulumlar üzerinden gerçekleştirebilmekteyim. Nasıl mı? Hemen bakalım.

WP-CLI YAML Dosyaları

WP-CLI birkaç konfigürasyon dosyası (tanımlılar ise) üzerinden hızlı bir şekilde kontrol tanımlanan kurallar dahilinde özelleştirilebilmekte. Bu özelleştirmeler çeşitli sınırlandırmalar, kısa yollar, bağlantılar ve daha pek çok içerik ile sağlanabilmekte. Öncelikle bu dosyalara ve bulunabilecekleri konumlara bir bakalım.

  • wp-cli.local.yml WP-CLI project config. Aktif olarak bulunulan klasör veya bir üst dizinde yer alabilir. local burada bir değişken tanımı alsında. Farklı kurulumlar için farklı tanımlar kullanılabilir; örneğin wp-cli.production.yml
  • wp-cli.yml WP-CLI project config. Aktif olarak bulunulan klasör veya bir üst dizinde yer alabilir.
  • ~/.wp-cli/config.yml WP-CLI global config. İlgili diğer YAML dosyalarından farklı olarak ~/.wp-cli içeriğinde yer alır. Ancak bu yol WP_CLI_CONFIG_PATH ile yeniden tanımlanabilir.

Yukarıda açıklamasıyla birlikte yer alan wp-cli.yml dosyasını daha önce uzak sunucudaki WordPress sitelerimize kısa adlar tanımlarken kullanmıştık ve içeriğini şu şekilde hazırlamıştık:

@all

@per:
  ssh: kullanici-adi@ip-veya-alanadi/public_html/directory/

@dev:
  ssh: kullanici-adi@ip-veya-alanadi2

@both:
  - @per
  - @dev

Bu içerik sayesinde tanımladığımız @per ve @dev kısa adları üzerinden işaret ettiğimiz adreslere hızlı bir şekilde SSH bağlantısı sağlayabilmekteydik.

wp @dev [komut]

Elbette bu dosyalar içeriğinde daha pek çok tanımlama yapılabilmekte1. Ben bu yazıda örneklerde çeşitlilik olması adına ~/.wp-cli/config.yml dosyasını oluşturup işlemlerimi bu dosya aracılığıyla gerçekleştireceğim. İlk olarak wp cli info komutu ile WP-CLI global config içeriğine bir bakalım.

wp cli info

Komut uygulandığında aşağıdakine benzer bir içerik dönecektir.

OS: Linux 3.10.0-714.10.2.lve1.5.19.3.el7.x86_64 #1 SMP Tue Aug 7 21:33:29 EDT 2018 x86_64
Shell: /bin/bash
PHP binary: /opt/alt/php71/usr/bin/php
PHP version: 7.1.25
php.ini used: /opt/alt/php71/etc/php.ini
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /home/\[kullanici-adi\]/.wp-cli
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.1.0

Eğer WP-CLI global config yukarıdaki örnekteki gibi boş dönmüş ise bash env olarak WP_CLI_CONFIG_PATH tanımlaması yapmamız gerekir.

Eğer Oh My Zsh kullanıyorsanız .bashrc ifadelerini .zshrc şeklinde güncellemelisiniz.

echo "WP_CLI_CONFIG_PATH='/home/[kullanici-adi]/.wp-cli/config.yml'" >> ~/.bashrc && source ~/.bashrc && wp cli info

config.yml oluşturalım ve sunucuda yer alan WordPress kurulumları için kısa adları ekleyelim. Komutun uygulanmasının ardından WP-CLI global config içeriğinin /home/[kulanici-adi]/.wp-cli/config.yml şeklinde değer aldığını görebilirsiniz. Şimdi ilgili dosyamızı oluşturalım.

nano ~/.wp-cli/config.yml

İçeriğimiz de şu şekilde olsun:

path: /www/wp0/
url: https://ornekwebsitesi.com

@all

@wp1:
     path: /www/wp1/

@wp2:
      path: /www/wp2/
        inherit: wp1.yml

@wp3:
      ssh: kullanici-adi@ip-veya-alanadi1

@wp4:
      ssh: kullanici-adi@ip-veya-alanadi2
      path: /www/wp4/

@wp5:
      ssh: kullanici-adi@ip-veya-alanadi3
      path: /www/wp5/
        inherit: yc.yml

@clients:
  - @wp2
  - @wp5

Önceki örnekle karşılaştırdığımızda benzer tanımlamaların yanı sıra farklılıklarda var, değil mi? İlk farklılık herhangi bir adres barındırmayan global tanımlar. İlk satırlarda yer alan path ve url herhangi bir adres işaret etmediğim durumda hangi WordPress kurulumu üzerinde işlem yapılacağını göstermekte. Kimi zaman --path hatası alabilirsiniz.

Error: This does not seem to be a WordPress installation.
Pass --path=`path/to/wordpress` or run `wp core download`.

Bu hatanın bulunulan wp komutunun uygulandığı dizinde bir WordPress kurulumunun yer almıyor oluşudur. Normalde bu hatayı aldığımız zaman aşağıdaki örnekteki gibi wp komutumuza ayrıca --path ile ilgili kurulumun bulunduğu dizin bilgisini ekleriz.

wp plugin list --path=/www/wp0/

Elbette config.yml sayesinde her defasında bu tanımlamayı yapmak zorunda kalmayız. Bir diğer farklılık @wp1 ve @wp2 gibi path içerikleri barındıran tanımlamalar. Yazının giriş bölümünde de belirttiğim gibi, YAML içeriğinde sadece farklı sunucu erişimleri tanımlamak zorunda değiliz. Yukarıdaki örnekte de görebileceğiniz üzere aktif barındırma alanı da dahil pek çok alana erişimler tanımlayabilmekteyiz. @wp4 SSH bağlantısının yanı sıra ilgili sunucuda birden fazla WordPress var ise hangisine erişilmesi gerektiğini de göstermekte. Bu tanımlama elbette SSH bağlantısı sonuna dizin bilgisi eklenerek de yapılabilirdi. Son farklılık ise @wp2, @wp4, @wp5 gibi kendi konfigürasyon tanımlamalarına sahip kısa adlar. Evet, bazı erişimler için özelleştirilmiş alt konfigürasyonlar kullanabilmekteyiz. Unutmadan, ilgili konfigürasyon dosyalarına yeni ad tanımlamaları yaptığımızda ilgili tanımlamayı rewrite flush ile işlemeliyiz. Örneğin @yeni-site şeklinde yeni bir kısa ad tanımladık, o halde şu komutu uygulamalıyız.

wp @yeni-site rewrite flush

İlgili komutu uyguladıktan sonra eğer kısa ad içeriğinde bir sorun yoksa (kısa adın yanlış yazımı, ilgili WordPress dizininin doğruluğu vb.) bir doğrulama mesajı alırız.

Success: Rewrite rules flushed.

Bu doğrulama mesajı yerine eğer yukarıda da bahsi geçen --path hatasını almışsak WordPress yolunu kontrol etmemiz gerekir. Fakat aşağıdaki gibi bir alias hatası alırsak bu durumda da YAML içeriğine eklediğimiz kısa adın doğruluğuna bakarız. İlgili tanımlama konfigürasyon dosyasına işlenmemiş ya da bir yazım hatası olabilir.

Error: Alias '@yeni-site' not found.

Şimdiye kadar her şey yolunda! O halde ilgili konfigürasyon dosyamızın içeriğini biraz daha genişletelim ve sınırlamalar ekleyelim. Örneğin, global olarak bazı komutların kullanımını engelleyelim.

disabled_commands:
        - db drop
        - plugin install
        - plugin list
        - user create

Bu satırları config.yml dosyasında, global tanımlamalar yaptığımız alana eklediğimizde ilgili konfigürasyon dosyasında tanımlı kısa adlar üzerinden tanımlanan kısıtlamalar işleme alınacaktır. Son durumda dosyamız aşağı yukarı şöyle olacaktır:

path: /www/wp0/
url: https://ornekwebsitesi.com
disabled_commands:
        - db drop
        - plugin install
        - plugin list
        - user create

@all

@wp1:
     path: /www/wp1/

@wp2:
      path: /www/wp2/
        inherit: wp1.yml

@wp3:
      ssh: kullanici-adi@ip-veya-alanadi1

@wp4:
      ssh: kullanici-adi@ip-veya-alanadi2
      path: /www/wp4/

@wp5:
      ssh: kullanici-adi@ip-veya-alanadi3
      path: /www/wp5/
        inherit: yc.yml

@clients:
  - @wp2
  - @wp5

İlgili komut sınırlandırmalarını test etmek amacıyla @wp2 için eklentileri listeleme komutunu girelim.

wp @wp2 plugin list

Komutu uyguladığımızda şu dönüşü almamız gerekir:

Error: The 'plugin list' command has been disabled from the config file.

Global tanımlamaların yanı sıra bu gibi sınırlandırmaları inherit ile ilgili WordPress kurulumları için özelleştirebiliriz. Bu aşamaya kadar her şey yolundadır diye tahmin ediyorum. Bu arada, tanımlanabilecek yığınla parametre bulunmakta. Örnek olarak Feature: Run a WP-CLI command dosyasını inceleyebilirsiniz2. Ancak, WP-CLI > Config sayfası3 daha ileri seviye ihtiyaçlar doğrultusunda4 şekillendikleri için bu yazı bağlamında değinmeyeceğim. wp config komutu öncesinde, son olarak değineceğim konfigürasyon parametresi config create. Hemen bir örnek oluşturalım.

user: admin
config create:
    dbuser: root
    dbpass:
    extra-php: |
        define( 'WP_DEBUG', true );
        define( 'WP_POST_REVISIONS', 3 );

Bu tanımlamayı config.yml dosyamıza eklediğimizde, her uygulanan wp config işleminde burada tanımlanan tanımlar işleme alınır. Son durumda config.yml dosyamızın içeriği şöyle oldu:

path: /www/wp0/
url: https://ornekwebsitesi.com
user: admin
disabled_commands:
        - db drop
        - plugin install
        - plugin list
        - user create
config create:
        dbuser: root
        dbpass:
        extra-php: |
                define( 'WP_DEBUG', true );
                define( 'WP_POST_REVISIONS', 3 );

@all

@wp1:
     path: /www/wp1/

@wp2:
      path: /www/wp2/
        inherit: wp1.yml

@wp3:
      ssh: kullanici-adi@ip-veya-alanadi1

@wp4:
      ssh: kullanici-adi@ip-veya-alanadi2
      path: /www/wp4/

@wp5:
      ssh: kullanici-adi@ip-veya-alanadi3
      path: /www/wp5/
        inherit: yc.yml

@clients:
  - @wp2
  - @wp5

Evet, ayar dosyalarıyla ilgili temel olarak bahsedebileceklerim şimdilik bu kadar. İlerleyen zaman içerisinde çeşitli ihtiyaçlar doğrultusunda eklemeler yapmaya devam edeceğim. Gelelim wp config komutuna.

WP Config Komutu

wp config komutu temel olarak wp-config.php dosyasından sorumludur ve bu dosyayı oluşturabilir ve okuyabilir. Yukarıda konfigürasyon tanımlamaları esnasında config create ile bu komut ile ilişkili tanımlamlalar yapmıştık. Komutun kendisini bu tanımlamalarla birlikte config dosyasını oluşturulması, düzenlenmesi, silinmesi, içeriğinin okunması, tanımlamalar eklenmesi gibi amaçlarla kullanabilmekteyiz5. Örneğin, wp core download sonrasında wp core install ile kullanıcı detaylarını gireriz.

wp core install --url=[alan-adi]  --title="[web-sitesi-basligi]" --admin_user=[kullanici-adi] --admin_password=[kullanici-sifresi] --admin_email="[kullanici-e-posta-adresi]"

wp config ise bu adıların öncesinde veritabanı başta olmak üzere web sitesinin ayarlarını yapma imkanı sunar. Eğer administrator oluşturulmadan wp config komutunu uygularsak hata olarak install işleminin tamamlanması gerektiği mesajını alırız. install işlemi ardından ise kullanım bilgilendirmesi dönecektir.

usage: wp config create --dbname=<dbname> --dbuser=<dbuser> [--dbpass=<dbpass>] [--dbhost=<dbhost>] [--dbprefix=<dbprefix>] [--dbcharset=<dbcharset>] [--dbcollate=<dbcollate>] [--locale=<locale>] [--extra-php] [--skip-salts] [--skip-check] [--force]
   or: wp config delete <name> [--type=<type>]
   or: wp config edit
   or: wp config get <name> [--type=<type>] [--format=<format>]
   or: wp config has <name> [--type=<type>]
   or: wp config list [<filter>...] [--fields=<fields>] [--format=<format>] [--strict]
   or: wp config path
   or: wp config set <name> <value> [--add] [--raw] [--anchor=<anchor>] [--placement=<placement>] [--separator=<separator>] [--type=<type>]
   or: wp config shuffle-salts

Örneğin wp-config.php içeriğini görüntüleyelim.

wp config edit

Komutu uygulamamızın ardından ön tanımlı metin editörü (çoğu durumda nano veya vim) ile wp-config.php dosyasının içeriği karşımıza çıkacaktır. Editörü kendiniz belirlemek isterseniz ilgili komut satırını EDITOR=nano ile başlatabilirsiniz.

EDITOR=nano wp config edit

Veri tabanı tanımlamaları için ise --dbname, --dbuser ve --dbpass kullanırız.

wp config create --dbname=[veri-tabani-adi] --dbuser=[veri-tabani-kullanici-adi] --dbpass=[veri-tabani-kullanici-sifresi]

wp-config.php içerisinden bilgi almak için ise get kullanırız. Örneğin, table_prefix tanımına bakalım.

wp config get table_prefix

Eğer get sonrasında herhangi bir tanım yapmazsak wp-config.php içeriğindeki tüm değerler tablo olarak getirilecektir. Benzer bir işlemi wp config list ile de gerçekleştirmek mümkün. Ancak, list ile ayrıca bilgilerin sunulacağı format, gösterilecek alanlar, filtreler gibi tanımlamalar da yapılabilmekte.

WP Config

list kullanarak sadece DB_USER ve DB_PASSWORD bilgilerini alalım.

wp config list DB_USER DB_PASSWORD --strict

Son olarak wp config set ile nasıl wp-config.php içeriğine ekleme yapabileceğimize bakalım. list ile WP_DEBUG içeriğini kontrol edelim.

wp config list WP_DEBUG

Eğer tanımlı değilse Error: No matching entries found in 'wp-config.php'. mesajı dönecektir. Ancak, list içeriğinde WP_DEBUG listelenmişti. Dolayısıyla tanımlı olduğunu biliyoruz. Fakat herhangi bir value tanımlı olmadığı için ilgili alan boş listelenecektir. Şimdi bu alanı true olarak değiştirelim.

wp config set WP_DEBUG true --raw

Komutu uygulamamızın ardından şu dönüşü alırız; Success: Updated the constant 'WP_DEBUG' in the 'wp-config.php' file with the raw value 'true'. Oldukça pratik, değil mi? wp config ile ilgili işlemler yukarıdakilerle sınırlı değil elbette. Daha detaylı bilgi için WP-CLI Commands > wp config6 ve WP-CLI Configuration3 sayfalarını inceleyebilirsiniz.

  1. viewone/wp-cli-environment. GitHub ↩
  2. bemanningsstyrkan. Feature: Run a WP-CLI command ↩
  3. WP-CLI Config ↩ ↩
  4. Different wp-cli.yml values for different environments. GitHub Issues ↩
  5. wp-cli/config-command. GitHub ↩
  6. wp config \<command>. WP-CLI Commands ↩
Yorum alanını göster
Beğendim
Beğenmedim