WP-CLI ile Sunucudan WordPress Yönetimi: Net Rehber

WordPress’i yalnızca panel üzerinden yönetmek zorunda değilsiniz. WP-CLI, sunucudan (SSH) WordPress görevlerini komut satırı üzerinden çalıştırmanızı sağlar. Bu sayede bakım penceresi kısalır, tekrarlı işlemler otomatikleşir ve hata ayıklama süreci hızlanır. Bu rehberde; WP-CLI kurulumundan güncelleme ve eklenti yönetimine, güvenlikten bakım planına kadar “ne yapayım, hangi komut, neden” yaklaşımıyla net bir yol haritası göreceksiniz.

WP-CLI tam olarak neyi çözer?

WP-CLI (WordPress Command Line Interface), WordPress yönetim işlerini CLI üzerinden yürütür. Panelde arama yapmadan, tek komutla şu işler yapılabilir: - WordPress çekirdek (core) güncelleme - Eklenti (plugin) ve tema (theme) listeleme/kurulum/güncelleme - Veritabanı işlemleri, bakım moduna alma - Kullanıcı yönetimi (ör. şifre reset) - Veritabanı arama-değiştirme (dikkatli kullanım) - Site sağlığı (health check) gibi tanısal görevler

Bu yaklaşımın pratik karşılığı şudur: Kurulum, güncelleme ve sorun giderme süreçlerinde “panelde tek tek tıklama” süresi düşer. Özellikle birden fazla siteyi benzer şekilde yönetirken (ajans, çoklu müşteri, staging/production farkı) operasyonel maliyet azalır.

WP-CLI kullanırken kritik şart: Çalıştığı dizin

WP-CLI komutları WordPress’in kurulu olduğu dizini (örn. /var/www/wordpress/public_html) baz alır. Yanlış dizinden çalıştırılan komutlar hata verir veya istenmeyen bir hedefi etkileyebilir.

Hedef dizini doğrulamak için: - Sunucuya SSH ile bağlanın - WordPress’in bulunduğu klasöre geçin - wp komutlarını oradan çalıştırın

WP-CLI kurulumu ve sürüm doğrulama

WP-CLI’yi kurma şekli sunucunuza göre değişir. En yaygın senaryo: WP-CLI’nin doğru konumda çalışması ve wp komutunun PATH’te bulunması.

1) Mevcut WP-CLI var mı kontrol edin

Önce sistemde wp var mı bakın: - wp --info

Eğer komut bulunamazsa kurulum adımına geçin.

2) WordPress projesinde doğru klasöre geçin

Örnek mantık: - cd /var/www/sitename/public_html

Sonra WP-CLI’nin WordPress kökünü görüp görmediğini doğrulayın: - wp core version

Bu komut WordPress sürümünü döndürüyorsa temel bağlantı doğru demektir.

3) WP-CLI’yi kullanıcı yerine “doğru” kullanıcıyla çalıştırın

WP-CLI çoğunlukla web sunucusunun (nginx/apache) çalıştığı kullanıcıdan ayrı bir kullanıcıyla çalıştırılabilir. Ancak dosya izinleri sorunsuz olmalıdır. Şu iki hedefi net belirleyin: - WordPress dosyaları WP’nin sahibi kullanıcıya ait olmalı - Güncelleme sırasında yazma izni (write permission) sorun çıkarmamalı

Güvenli WP-CLI kullanımı: Hız kadar kontrol

WP-CLI hızlıdır ama sınırsız yetkiyle komut çalıştırır. Bu nedenle risk kontrolü yapılmalıdır.

1) --dry-run ile plan yapın

WP-CLI’nin bir dizi işlemi simüle etme imkânı sunar. Uygulanabilecek yerlerde --dry-run kullanın. Bu yaklaşım özellikle eklenti/tema güncellemesinde veya toplu değişikliklerde zamandan tasarruf sağlar.

2) Mantıklı hedefe kilitleyin: staging/production ayrımı

Tek bir sunucuda hem staging hem production varsa hedefi komutla karıştırma riski doğar. Bunun için: - Her komutta doğru dizine geçin - Terminal prompt’unuzdaki dizin bilgisini kontrol edin

3) Değişiklikten önce yedek (backup) alın

“Eklenti güncelleyeyim” gibi basit görünen işler bile bazen veritabanı şeması değişikliği tetikleyebilir. Yedek stratejisi net olmalıdır: - Dosya yedeği (plugins/themes dahil) - Veritabanı yedeği (backup SQL) - Yedeklerin geri yüklenebilirliği (restore) test edilmelidir

WordPress core güncellemesi (ek risklerle)

Core güncellemelerinde en büyük risk, güncelleme sonrası uyumsuzluklar ve bakım modunun gerektiği durumlar. WP-CLI bu süreci kontrol edilebilir kılar.

1) Güncelleme öncesi durum kontrolü

Önce nelerin güncellenebilir olduğunu görün: - wp core check-update

Bu komut mevcut durumu raporlar.

2) Core güncelleme

Güncelleme adımı: - wp core update

3) Güncelleme sonrası doğrulama

En azından şu kontrolleri çalıştırın: - wp core version - wp plugin list - (gerekiyorsa) tema ve eklenti uyumluluk kontrolü

Eklenti ve tema yönetimi: Listele, güncelle, temizle

WP-CLI ile eklenti ve tema yönetiminde en verimli akış genelde “önce listele, sonra güncelle” şeklindedir.

Eklentileri listeleme

• wp plugin list

Güncellenebilir eklentileri bulma

• wp plugin update --dry-run

Bu sayede güncelleme öncesi tahmin edilen değişikliği görürsünüz.

Eklenti güncelleme

• wp plugin update

Eski sürüm kalıntılarını önlemek için iyi pratik: gereksiz eklentiyi kaldırma

Kullanılmayan eklentiler hem saldırı yüzeyini büyütür hem de güncelleme yükünü artırır. Kaldırma örneği: - wp plugin delete <plugin-slug>

Not: Silme işlemi geri dönüşsüz olabilir. Önce yedek alın ve hedefi doğrulayın.

Tema güncelleme ve kontrol

Temalar için de benzer akış: - wp theme list - wp theme update --dry-run - wp theme update

Kullanıcı ve oturum yönetimi: Hızlı müdahale senaryoları

WP-CLI, admin erişimi kaybolduğunda veya hızlı müdahale gerektiğinde pratik olur.

Admin şifre reset (örnek yaklaşım)

Kullanıcının username’ini bilirseniz şifreyi komut satırından güncelleyebilirsiniz.

Mantık: - wp user list - Sonra wp user update ile şifre değişikliği

Şifrelerinizi komut satırında doğrudan açık metin olarak paylaşmaktan kaçının. Mümkünse güçlü parola üretin ve erişim kontrolünü sıkı tutun.

Bakım modu (maintenance mode) ve bakım penceresi planlama

Güncelleme sırasında trafik alındığında hatalar büyüyebilir. WP-CLI ile bakım modunu veya benzeri kontrol akışlarını yönetmek daha planlı sonuç verir.

Bakım modunu hangi durumda düşünmelisiniz?

• Çok sayıda eklenti güncelleyecekseniz
• Core + plugin + theme birlikte güncellenecekse
• Production ortamında ani yükseltme yapıyorsanız

Pratik yaklaşım

1) Güncellemeyi --dry-run ile planla 2) Yedek al 3) Bakım penceresi aç 4) Core + eklentileri güncelle 5) Bakım modunu kapat 6) Siteyi hem kullanıcı hem admin bakış açısından doğrula

Veritabanı ve site sağlığı için tanısal komutlar

WP-CLI sadece güncelleme için değil, teşhis için de kullanılabilir.

Site sağlığı çıktısı

Genelde şu mantık kullanılır: - wp --health-check

Bu rapor; WordPress yapılandırması, kritik uyarılar ve öneriler konusunda ipucu verir.

Veritabanı ile ilgili riskli işlemler

WP-CLI, veritabanı üzerinde doğrudan işlem yapabilen komutlar da içerir. Arama-değiştirme gibi işlemler özellikle dikkat ister.

Bu tip adımlar için net kural koyun: - Önce yedek - Sonra --dry-run (uygulanabiliyorsa) - Sonra küçük örnek alanda test - Son olarak tüm veride uygula

Çok siteli ortamlar: Komut standardizasyonu

Tek bir WordPress ile sınırlı değilseniz (multi-site veya birden fazla domain), iş akışını standardize edin.

Standart kontrol listesi (her güncellemede)

• Hangi site dizininde çalıştığımı teyit et
• Yedek alındı mı?
• --dry-run ile eklenti/tema/core güncellemesini planla
• Bakım penceresi gerekecek mi karar ver
• Güncelleme komutlarını sırayla çalıştır
• Son testleri yap: admin giriş, ana sayfa yükleniyor mu, form çalışıyor mu

Performans etkisi: WP-CLI hız sağlar mı?

WP-CLI’nin kendisi runtime performansı artırmaz; ancak operasyonel zaman ve hatayı azaltarak “hız” hissini dolaylı şekilde verir. Somut olarak şu kazanımlar görülür: - Güncelleme/dağıtım süresi kısalır - Otomasyon ile daha az insan hatası olur - Hızlı geri dönüş için komut tabanlı adımlar hazır olur

Örneğin staging→production geçişinde her site için aynı komut sırası kurulursa, yeni bir site açmada operasyon süresi azalır.

WP-CLI ile WordPress yönetimi: Hangi hosting türü ne zaman gerektirir?

WP-CLI kullanımı için pratik koşul şudur: SSH erişimi ve yeterli sistem izinleri. Bu noktada hosting türünü seçerken şu kriterleri listeleyin.

• Paylaşımlı hosting (shared): SSH sunuyorsa WP-CLI kullanılabilir; fakat izin kısıtları güncellemede sorun çıkarabilir.
• VPS/VDS: WP-CLI için en sorunsuz senaryolardan biridir. Dosya sahipliği ve izinler kontrol edilebilir.
• Dedicated: Büyük ölçek ve operasyonel kontrol için güçlüdür; WP-CLI otomasyonu ile tam uyumludur.
• Kontrol paneli (cPanel/Plesk/Hestia): WP-CLI her panelde değil, ama altyapı SSH erişimi sağlıyorsa kullanılır.

Net karar eşiği (pratik kriter)

Şu koşullarda VPS/VDS yönüne geçmek gerekir: - Aynı komut dizisini ayda birden fazla sitede çalıştırma ihtiyacı - Sık bakım/güncelleme ve staging/production otomasyonu - Dosya izinleri ve bakım penceresi kontrolünün kritik olması

En sık yapılan 6 hata ve net çözümleri

1) Yanlış dizinde komut çalıştırmak → WordPress kök klasörüne geçin, wp core version ile doğrulayın. 2) Yedeği atlamak → Dosya + veritabanı yedeği alın; restore test edin. 3) --dry-run olmadan toplu güncelleme yapmak → Önce simülasyonla görün. 4) Eklenti/tema uyumluluğunu kontrol etmemek → Güncelleme öncesi sürüm uyumluluğunu kontrol edin. 5) Dosya izinleri yüzünden güncellemeyi yarım bırakmak → Güncelleyici kullanıcının yazma izni olduğundan emin olun. 6) Hedefi karıştırmak (staging yerine production) → Terminalde konumu ve domain/servis bilgisini doğrulayın.

Sonuç: WP-CLI’yi “standart iş akışı”na bağlayın

WP-CLI ile WordPress yönetimi, tıklamalı yönetimden komut tabanlı, ölçülebilir bir sürece geçiştir. Başarı için tek kritik nokta komutları “tek seferlik sihir” gibi değil, yedek + dry-run + doğru hedef dizin + sıraya bağlı standart iş akışı gibi uygulamaktır.

Aksiyon önerisi: Bugün bir siteyi staging kabul ederek şu adımı uygulayın: wp core check-update → eklenti/tema --dry-run → yedek → güncelleme → site doğrulama. Bu testten sonra aynı komut sırasını production için kullanın; bir kez doğru kurulduğunda WP-CLI, bakım operasyonlarınızı belirgin şekilde sadeleştirir.