WP-CLI Uzak Sunucu - WordPress Erişimi

Şimdiye kadar WordPress web sayfamızın yönetimini admin panel (wp-admin) dışında, sunucuda kurulu wp-cli üzerinden nasıl gerçekleştirebileceğimizden bahsetmiştik.

AA

WP-CLI local server işlemleri yazısı ile ise sunucu erişimi gerektirmeksizin (uzak mysql erişimi sağlamadığımızı varsayıyorum) WordPress kurulumunu nasıl test edebileceğimizi görmüştük. Şimdi edindiğimiz bu bilgiler ile bir sonraki aşamaya geçelim ve farklı sunucularda ya da aynı sunucuda birden fazla alt alanda kurulu olan WordPress web sitelerimizi bilgisayarımızdan hızlı ve güveli bir şekilde nasıl tek seferde ya da ayrı ayrı yönetebileceğimize bakalım1. Evet, yanlış yazmadım. Örneğin 20 farklı sunucuda yer alan WordPress kurulumunuz olsun, tüm bu kurulumları aynı anda güncelleyebilir, hepsine aynı anda eklentiler kurabilir ya da var olan eklentileri pasif duruma getirebilirsiniz. Şahane, değil mi?

WP-CLI Uzak Sunucu Erişimi

Bilgisayarımızda kurulu wp-cli ile uzak bir sunucuya bağlanmak istediğimizde --ssh opsiyonundan faydalanabilmekteyiz. Örnek erişim tanımlamaları için aşağıdaki satırlara göz atabilirsiniz.

wp --ssh=ornekwebsitesi.com
wp --ssh=kullanici-adi@ornekwebsitesi.com
wp --ssh=ornekwebsitesi.com:2222
wp --ssh=ornekwebsitesi.com~/public_html/sub-directory/

Ancak, yazının giriş paragrafında da belirttiğim üzere aynı anda erişimler sağlamak istediğimizde ya da sürekli aynı bilgileri yazmak istemediğimizde daha pratik bir yönteme ihtiyaç duymaktayız. İşte bu aşamada da takma isim (alias) ile ilerleyebilmekteyiz. Aşağıdaki örneğe bir bakalım:

wp --ssh=dev

Bu satırda dev ifadesini görmektesiniz. Aslında dev tanımladığımız erişim yolunun takma adı. Bu sayede aynı bilgileri tekrar tekrar yazmadan erişim sağlayabilmekteyiz. Hatta, belirlediğimiz bir takma ad ile aynı anda pek çok alana da erişim sağlayabiliriz. Peki, takma ad (alias) oluşturma işlemi nasıl gerçekleştirilebilmekte?

WP-CLI SSH Alias

Alias ifadesini belirli bir duruma ya da işleme işaret eden bir tanımlama olarak özetleyebiliriz sanırım. Daha öncesinde alias kullanımına ayrı bir yazı altında (bkz. Alias Nedir?) detaylıca değinmiştim. Wp-cli kullanımında, yine aynı mantıkla hareket ederek SSH bağlantıları için kısa adlar oluşturabilmekteyiz. Örneğin, yukarıda yer alan bağlantı ifadelerini kapsayan şu tanımlamaları yapalım:

@all

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

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

@both:
  - @per
  - @dev

Bu dosyayı wp-cli konfigürasyon dosyalarının olduğu dizin (WP_CLI phar path) içerisine wp-cli.yml ya da config.yml ismiyle kayıt etmeniz yeterli. Bu bilgiyi wp cli info komutuyla edinebilirsiniz. Ayrıca, tanımlı kısa adları wp cli alias ile listeleyebilirsiniz.

WP-CLI Kullanımı

Ad tanımlamalarımız @per, @dev ve her ikisini işleme alan @both yerine elbette kendi ifadelerinizi yazabilirsiniz. @per, kullanici-adi@ip-veya-alanadi/public_html/directory/ için bir kısa yol görevi görmekte. @dev tanımı da yine @per ile benzer bir içeriğe sahip. @both ise tanımlı ifadeleri kapsayan bir kısa yol. @all ise tanımlı tüm alanları kapsar. Yani, ayrı ayrı tanımladığım ve her biri farklı WordPress kurulumlarıyla ilişkili olan ad tanımlamalarını tek bir ad altında yada gruplandırarak da kontrol edebiliyoruz. Şöyle bir komut oluşturalım:

wp @both core check-update

Bu komut uygulandığında @both altında tanımlı olan tüm alt tanımlar için WordPress güncellemesi olup olmadığının kontrol edilmesini sağlayacaktır. Yazının başında belirttiğim bir diğer örneğe, yani tüm kurulumlardaki bir eklentinin pasif hale getirilmesine bakalım.

wp @both plugin deactivate hello

Unutmadan, SSH işlemlerinde key tanımlamak gerekiyor. SSH üzerine yayınladığım yazılardan gerekli tüm detayları edinebilirsiniz.

Konumuza devam edelim. Varsayalım ki bu konfigürasyon dosyasına eklemeler ya da var olan alanlarda değişiklikler gerçekleştirdik. Bu durumda kullanmamız gereken bir komutumuz var. Mesela @dev ad tanımının içeriğini değiştirmiş olalım:

wp @dev rewrite flush

İşlemlerimiz şimdilik bu kadar. Şimdiye kadar wp-cli işlemlerimizi sıklıkla DigitalOcean ve local alanda gerçekleştirmiştik. Paylaşımlı barındırma alanlarında (shared hosting) süreç biraz daha farklı ilerliyor. Bir sonraki yazıda da bu farklılıklara ve nasıl çözümlenebileceklerine değineceğim. Yeni eklenen yazılardan ve video eğitimlerden haberdar olmak için aşağıda yer alan bülten formuna e-posta adresiniz ile kayıt olabilirsiniz. Soru ve önerilerinizi yorum olarak paylaşmayı unutmayın.