WordPress eklentilerini tek tek geri almak için WP-CLI komutları

WordPress yöneticileri için en can sıkıcı senaryolardan biri, 20 eklentiyi toplu olarak güncellemek ve ardından yalnızca birinin siteyi bozması durumunda ne yapılacağıdır. Büyük çoğunlukla kullanılan WordPress bakım araçları, tüm eklentileri eski haline getirerek sorunu kökten çözme yolunu tercih eder. Bu yaklaşım mantıklı görünse de, aslında yalnızca bozulan eklenti geri alınırsa diğer 19 eklenti güncellemeleri korunmuş olur. Peki bu hassas geri alma işlemi WP-CLI ile nasıl uygulanır?

Tek bir eklentiyi eski sürüme döndürmek için gereken komut: wp plugin install

WP-CLI, WordPress eklentilerini yönetmek için sunduğu güçlü komutlarla tanınır. Belirli bir sürümü zorla kurma olanağı da bunlardan biri. Aşağıdaki komut, istediğiniz bir eklentiyi belirttiğiniz eski sürüme geri yüklemenizi sağlar:

wp plugin install <eklenti-kısaltması> --version=1.2.3 --force --skip-plugins --skip-themes

Komutun içindeki parametreler neler anlam ifade ediyor?

• `--version=1.2.3`: Eklentinin WordPress deposundan indirilecek eski sürümünü belirtir. İster WordPress.org’dan yayınlanan herhangi bir versiyonu seçebilirsiniz.

• `--force`: Eğer eklenti zaten yüklüyse, mevcut dosyaların üzerine yazılmasını sağlar. Böylece bozulan eklentinin PHP dosyaları temiz bir şekilde eski haline döner.

• `--skip-plugins --skip-themes`: WP-CLI’nin başlatılması sırasında diğer eklentileri ve temaları yüklemesini engeller. Bu sayede, bozulan bir eklenti nedeniyle WP-CLI’nin kendisinin çökmesi önlenir ve kurtarma işlemleri kesintisiz devam edebilir.

Bu basit komut sayesinde, tek bir eklentiyi anında eski ve güvenilir bir sürüme geri döndürebilirsiniz. Asıl önemli soru ise şu: Bu komutu ne zaman ve hangi koşullarda kullanmalısınız?

HTTP durum kontrolleriyle adım adım güncelleme stratejisi

En güvenilir yaklaşım, her eklentiyi tek tek güncelleyip ardından siteyi test etmektir. Süreci adım adım özetleyelim:

1. Başlangıç durumu: GET / isteğiyle sitenin çalışıp çalışmadığını kontrol edin. Dönüş kodu 200 (başarılı) olmalıdır.

1. Eklenti güncellemesi: Hedef eklentiyi güncelleyin:

   wp plugin update <eklenti-kısaltması> --skip-plugins --skip-themes

1. Güncelleme sonrası test: Tekrar GET / isteği gönderin. Eğer yanıt 500 (sunucu hatası) dönerse, eklenti bozulmuş demektir.

1. Hemen geri alma: Bozulan eklentiyi eski sürüme döndürün:

   wp plugin install <eklenti-kısaltması> --version=<eski-sürüm> --force --skip-plugins --skip-themes

1. Kurtarma testi: GET / isteğini tekrarlayın. Yanıt 200 ise kurtarma başarılı olmuş ve diğer eklentilerden devam edilebilir.

Bu yöntemle, hata oluşturan eklentiyi anında tespit eder ve yalnızca onu geri alırken diğer eklentilerin güncellemeleri korunmuş olur.

Hangi eklentinin geri alınması gerektiğini nasıl belirleriz?

Toplu güncelleme sırasında hata meydana geldiğinde, hangi eklentinin soruna yol açtığını anlamak zordur. Ancak tek tek güncelleme yapıldığında durum değişir: Hata oluştuğunda, hemen önce güncellenen eklenti otomatik olarak sorumluluğu üstlenir.

Bu sayede, yanlışlıkla alakasız bir eklentiyi geri alma riski ortadan kalkar. Geri alma işlemi için gereken eski sürüm bilgisi de önceden kaydedilmiş bir anlık görüntüden alınabilir:

# Güncelleme öncesi tüm eklentilerin durumunu kaydet
wp plugin list --format=json --skip-plugins --skip-themes > /tmp/eklentiler_oncesi.json

# Bozulan eklentinin eski versiyonunu bul
prev_version=$(jq -r '.[] | select(.name=="<eklenti-kısaltması>") | .version' /tmp/eklentiler_oncesi.json)

Bu komut, wp plugin install --version= komutuna gerekli eski sürüm bilgisini sağlar. Ardından geri alma işlemi tamamlanır ve diğer eklentilere geçilir.

Geri alma işleminden sonra her zaman HTTP durumunu yeniden kontrol edin

Eklentiyi geri yükledikten sonra mutlaka siteyi tekrar test edin:

• Başarılı (200): Eklenti güncellemesi atlandı, diğer eklentilere geçilebilir.

• Hala başarısız (500): Bu durumda sorun yalnızca eklentinin PHP dosyalarında değil, veritabanı şemasında veya diğer dosyalarda da olabilir. Bu gibi durumlarda daha kapsamlı kurtarma yöntemlerine başvurmak gerekir (tam veri tabanı geri alma, önbellek temizleme, tema değiştirme vb.).

Buradan çıkarılacak ders: Eklenti geri yüklemenin siteyi her zaman kurtaracağını varsaymayın. --force parametresi yalnızca dosyaları değiştirir; veritabanı düzeyindeki tutarsızlıklar için ek kontroller şarttır.

"Tümünü geri al" mı, "yalnızca bozulanı geri al" mı?

Endüstride yaygın olarak kullanılan "tüm eklentileri geri al" yaklaşımı, basitliği nedeniyle tercih edilir ve varsayılan olarak uygulanır. Ancak "yalnızca bozulanı geri alma" stratejisinin operasyonel avantajları da oldukça önemlidir:

• Hangi eklentinin bozulduğu loglarda net bir şekilde kaydedilir.

• Diğer eklentilerin başarılı güncellemeleri korunmuş olur.

• Sonraki bakım işlemlerinde yalnızca geri alınan eklenti tekrar denenir.

Bu avantajların karşısında, uygulamanın karmaşıklığı artar. Ancak kazançları, özellikle yüksek trafikli sitelerde ve paylaşımlı barındırma ortamlarında operasyonel şeffaflık ve süreklilik sağlar.

WP-CLI’nin --version=X --force kombinasyonu, bu hassas geri alma işlemini mümkün kılan temel araçtır. SSH erişimi olan paylaşımlı barındırma ortamlarında otomatik bakım sistemleri kurmayı düşünenler için bu komut setini hafızaya kazımak oldukça değerlidir.

WordPress bakım endüstrisinde neden tek tek eklenti geri alma stratejilerinin yaygınlaşmadığını merak edenler, WordPress bakım endüstrisinin henüz çözülememiş üç önemli boşluğu başlıklı yazıyı inceleyebilirler.

Unutmayın: Tek bir komutla karmaşık bir problemi çözmek mümkün. Önemli olan, doğru aracı doğru zamanda kullanmaktır.