WP-CLI ile WordPress Kullanıcı Yetki ve Kapasite Yönetimi
WordPress site yönetiminde kullanıcı yetkilendirmesi, hem güvenlik hem de operasyonel verimlilik açısından kritik bir konu. Özellikle çok kullanıcılı sitelerde, e-ticaret platformlarında veya müşteri sitelerini toplu yöneten ajans ortamlarında hangi kullanıcının ne yapabileceğini hassas biçimde kontrol etmek zorundasın. İşte tam bu noktada wp cap komutu devreye giriyor.
wp cap Nedir ve Neden Kullanmalısın?
WP-CLI’nin wp cap komutu, WordPress’in yerleşik capability (kapasite/yetki) sistemini komut satırından yönetmenizi sağlar. WordPress, kullanıcı rollerine bağlı onlarca farklı capability tanımlar. edit_posts, manage_options, delete_users gibi her biri belirli bir işlemi temsil eden bu yetkiler, normalde ya kod yazarak ya da eklentiler üzerinden yönetilir. WP-CLI ile bunu tek satır komutla halledebilirsin.
Bu komut özellikle şu senaryolarda hayat kurtarır:
- Müşteriye özel kısıtlı yönetici rolleri oluşturmak
- Ajans bünyesindeki editörlere ek yetkiler vermek
- WooCommerce mağazalarında shop manager rolünü özelleştirmek
- Toplu sunucu yönetiminde onlarca siteye aynı yetki yapılandırmasını uygulamak
- Güvenlik olaylarından sonra hızlıca yetki kısıtlamak
Temel Sözdizimi
wp cap üç alt komuttan oluşur:
wp cap add: Bir role yeni capability ekler wp cap remove: Bir rolden capability kaldırır wp cap list: Bir rolün sahip olduğu tüm capability’leri listeler
Genel kullanım şekli şöyle:
wp cap <komut> <rol> [capability] [--allow-root] [--path=/site/yolu]
--allow-root parametresini root kullanıcıyla çalışırken eklemeyi unutma, aksi takdirde WP-CLI uyarı verir.
Mevcut Capability’leri Listeleme
Bir role hangi yetkilerin atanmış olduğunu görmek için list alt komutunu kullanırsın. Örneğin editör rolünün yetkilerini inceleyelim:
wp cap list editor --allow-root
Bu komut çıktısında delete_others_pages, delete_others_posts, edit_others_pages gibi onlarca satır görürsün. Eğer bu çıktıyı bir dosyaya aktarmak ve daha sonra başka bir sitede uygulamak istersen:
wp cap list editor --allow-root > editor_caps.txt
cat editor_caps.txt
Subscriber, contributor, author, editor, administrator gibi WordPress’in varsayılan rollerini teker teker inceleyebilirsin. Özellikle özel roller oluştururken hangi capability’nin nerede olduğunu anlamak için bu çıktılar çok değerli.
Capability Ekleme
Diyelim ki bir içerik editörünün eklenti güncellemelerini de yönetmesini istiyorsun ama tam yönetici yapmak istemiyorsun. update_plugins capability’sini editör rolüne ekleyebilirsin:
wp cap add editor update_plugins --allow-root
Birden fazla capability’yi aynı anda eklemek de mümkün:
wp cap add editor update_plugins install_plugins delete_plugins --allow-root
Bu komutla editörler artık Eklentiler menüsünü görebilir ve güncellemeleri yapabilir. Ancak Ayarlar menüsüne erişemezler çünkü manage_options capability’si hala editör rolünde yok.
Gerçek dünya senaryosunu düşün: Bir haber sitesi yönetiyorsun. Baş editör kendi ekibini yönetmek istiyor, kullanıcı profillerini düzenlemek ve yeni yazarlar oluşturmak istiyor. Bunun için editör rolüne birkaç kullanıcı yönetimi capability’si ekliyorsun:
wp cap add editor create_users edit_users list_users promote_users --allow-root
Bu işlem sonrasında baş editör, yönetici panelinde Kullanıcılar menüsünü görebilir ve yeni yazar hesapları oluşturabilir. Ama site ayarlarına, veritabanına veya dosya yönetimine erişimi yok. Bu tam olarak istediğin minimal yetki prensibi.
Capability Kaldırma
Bir güvenlik olayı yaşandığında veya iş akışı değiştiğinde yetkileri hızlıca kaldırmak gerekebilir. remove komutu burada devreye girer:
wp cap remove editor update_plugins install_plugins delete_plugins --allow-root
Daha dramatik bir senaryo: Site saldırıya uğradı ve saldırgan bir editör hesabını ele geçirdi. Editör rolündeki tüm hassas capability’leri hızlıca kısıtlamak istiyorsun. Önce mevcut yetkiler listesini alırsın, sonra tehlikeli olanları çıkarırsın:
wp cap remove editor publish_posts delete_published_posts --allow-root
Artık o hesapla giriş yapan kişi içerik görebilir ama yayınlayamaz veya silemez. Güvenlik olayını araştırırken bu geçici kısıtlama çok işe yarar.
WooCommerce Senaryoları
WooCommerce kurulu sitelerde shop_manager rolü özel ilgi ister. Genellikle müşteriler mağazayı kendileri yönetmek ister ama sitenin genel WordPress ayarlarına dokunmalarını istemezsin. Bu dengeyi wp cap ile çok ince ayarlayabilirsin.
Önce shop_manager rolünün mevcut capability’lerini incele:
wp cap list shop_manager --allow-root
WooCommerce’in varsayılan shop_manager rolü manage_woocommerce, view_woocommerce_reports, edit_products gibi ticaret odaklı yetkiler içerir. Ancak bazı sitelerde mağaza yöneticisinin indirimi ve kuponu yönetmesi ama ürün silememesi gerekebilir. Bu durumda:
wp cap remove shop_manager delete_products delete_published_products --allow-root
Öte yandan mağaza yöneticisinin raporları dışa aktarabilmesi için ek bir yetki gerekebilir:
wp cap add shop_manager export --allow-root
export capability’si WordPress’in yerleşik XML dışa aktarma aracına erişim verir. WooCommerce bazı eklentilerle birlikte CSV raporları için bu capability’yi kontrol eder.
Çok mağazalı bir yapıda her mağazanın kendi yöneticisi varsa ve birbirlerinin ürünlerine karışmaması gerekiyorsa, capability yönetimini özel eklenti kodlarıyla birleştirmen gerekir. Ama temel yetki yapısını WP-CLI üzerinden hızlıca düzenleyebilirsin.
Toplu Site Yönetimi: Ajans Senaryosu
Onlarca WordPress sitesini yöneten bir ajansın sistem yöneticisisin. Her müşteri sitesinde aynı özel editör yapılandırmasını uygulamak istiyorsun. Bash döngüsüyle bunu saniyeler içinde yapabilirsin:
#!/bin/bash
SITES=(
"/var/www/musteri1.com"
"/var/www/musteri2.com"
"/var/www/musteri3.com"
"/var/www/musteri4.com"
)
CAPS_TO_ADD="update_plugins manage_categories"
CAPS_TO_REMOVE="delete_others_posts"
for site in "${SITES[@]}"; do
echo "Islem yapiliyor: $site"
wp cap add editor $CAPS_TO_ADD --path="$site" --allow-root
wp cap remove editor $CAPS_TO_REMOVE --path="$site" --allow-root
echo "$site tamamlandi"
done
echo "Tum siteler guncellendi."
Bu scripti cron job’a ekleyebilir veya yeni müşteri eklendiğinde otomatik çalıştırabilirsin. Böylece her sitede tutarlı bir yetki politikası uygulanmış olur.
Multisite Ortamında wp cap Kullanımı
WordPress Multisite kurulumlarında durum biraz farklılaşır. Her alt site kendi kullanıcı rollerini yönetir ama süper admin yetkisi ağ genelinde geçerlidir. --url parametresiyle hangi alt sitede işlem yapacağını belirtmen gerekir:
wp cap add editor update_plugins --url=altsitem.anasite.com --allow-root
Dikkat etmen gereken önemli bir nokta: Multisite’da bir rolü bir alt sitede değiştirdiğinde, bu değişiklik yalnızca o alt siteyi etkiler. Başka bir alt sitedeki aynı rol etkilenmez. Bu davranış aslında çok kullanışlı, farklı alt sitelerde farklı yetki yapıları kurabilirsin.
Ağ genelindeki tüm alt sitelerde aynı değişikliği yapmak istersen site listesini alıp döngüye sokabilirsin:
wp site list --field=url --allow-root | while read url; do
wp cap add editor manage_categories --url="$url" --allow-root
echo "$url guncellendi"
done
Özel Roller ile Birlikte Kullanım
wp role komutuyla özel rol oluşturup ardından wp cap ile yetkileri ayarlamak çok yaygın bir iş akışıdır. Örneğin “İçerik Moderatörü” adında özel bir rol oluşturalım:
wp role create icerik_moderator "Icerik Moderatoru" --allow-root
Bu rol başlangıçta hiçbir capability içermez. Şimdi ihtiyaç duyduğu yetkileri ekleyelim:
wp cap add icerik_moderator read edit_posts edit_others_posts moderate_comments manage_categories --allow-root
Sonucu doğrulamak için:
wp cap list icerik_moderator --allow-root
Bu kişi artık siteyi okuyabilir, kendi ve başkalarının yazılarını düzenleyebilir, yorumları moderasyon edebilir ve kategorileri yönetebilir. Ama yayınlama, silme veya kullanıcı yönetimi yetkisi yok. Mükemmel bir minimal yetki uygulaması.
Capability Doğrulama ve Raporlama
Büyük sitelerde hangi rolün hangi capability’ye sahip olduğunu takip etmek zorlaşabilir. Tüm rollerin yetkilerini tek seferde raporlamak için şu scripti kullanabilirsin:
#!/bin/bash
SITE_PATH="/var/www/sitem.com"
OUTPUT_FILE="/tmp/cap_rapor_$(date +%Y%m%d).txt"
ROLES=("subscriber" "contributor" "author" "editor" "administrator")
echo "WordPress Capability Raporu - $(date)" > $OUTPUT_FILE
echo "Site: $SITE_PATH" >> $OUTPUT_FILE
echo "========================================" >> $OUTPUT_FILE
for rol in "${ROLES[@]}"; do
echo "" >> $OUTPUT_FILE
echo "### ROL: $rol ###" >> $OUTPUT_FILE
wp cap list $rol --path="$SITE_PATH" --allow-root >> $OUTPUT_FILE
done
echo "Rapor olusturuldu: $OUTPUT_FILE"
cat $OUTPUT_FILE
Bu raporu haftalık cron job olarak çalıştırıp bir önceki haftalık raporla karşılaştırabilirsin. Yetkisiz değişiklikler hemen dikkat çeker.
Sık Yapılan Hatalar ve Çözümleri
Yanlış rol adı kullanmak: WordPress rol adları genellikle küçük harfle yazılır ve boşluk içermez. shop_manager yerine Shop Manager yazmak komutu başarısız kılar. Her zaman wp role list --allow-root ile doğru adı teyit et.
Kalıcı olmayan değişiklikler: Bazı güvenlik eklentileri (özellikle role management eklentileri) yetki değişikliklerini sıfırlayabilir. Eğer yaptığın değişiklikler kayboluyorsa, hangi eklentinin rol yönetimini override ettiğini kontrol et.
Administrator rolüne dokunmak: Administrator rolünü değiştirmek ciddi sorunlara yol açabilir. Özellikle manage_options capability’sini kaldırırsan yönetici paneline erişemez hale gelebilirsin. Bu rolde işlem yapmadan önce muhakkak yedek al.
Multisite’da süper admin ile karışıklık: Multisite’da süper admin yetkisi capability tabanlı değildir, doğrudan veritabanında tutulur. wp cap add administrator something --url=... komutu süper admin yetkisini etkilemez.
Güvenlik İçin En İyi Pratikler
Capability yönetiminde minimal yetki prensibi esastır. Kullanıcıya yalnızca işini yapması için gereken minimum yetkileri ver. Bu prensibi uygularken şu kontrol listesini kullanabilirsin:
- Kullanıcı hangi menülere erişmeli?
- Başkalarının içeriklerini görüp düzenlemesi gerekiyor mu?
- Yayınlama veya silme yetkisi gerekli mi?
- Eklenti veya tema yönetimine ihtiyacı var mı?
- Kullanıcı veya site ayarlarına dokunması gerekiyor mu?
Bu soruların cevaplarına göre capability listeni oluştur ve wp cap add ile uygula. Daha az yetki her zaman daha güvenlidir.
Ayrıca değişiklik loglaması için şu yaklaşımı benimseyebilirsin: Her wp cap add veya wp cap remove komutunu çalıştırmadan önce mevcut durumu kaydet:
wp cap list editor --allow-root > /var/log/wordpress/editor_caps_before_$(date +%Y%m%d%H%M).txt
wp cap add editor update_plugins --allow-root
wp cap list editor --allow-root > /var/log/wordpress/editor_caps_after_$(date +%Y%m%d%H%M).txt
diff /var/log/wordpress/editor_caps_before_*.txt /var/log/wordpress/editor_caps_after_*.txt
Bu sayede hangi değişikliklerin ne zaman yapıldığını takip edebilirsin. Özellikle ekip olarak çalışıyorsan bu log dosyaları olası sorunları hızlıca teşhis etmenizi sağlar.
Sonuç
wp cap komutu, WordPress site güvenliğini ve operasyonel verimliliği artırmanın en pratik yollarından biri. Eklenti bağımlılığı olmadan, doğrudan komut satırından kullanıcı yetkilerini hassas biçimde kontrol edebiliyorsun. Ajans ortamlarında toplu uygulama, WooCommerce sitelerinde role tabanlı erişim kontrolü ve güvenlik olaylarında hızlı yetki kısıtlama gibi gerçek senaryolarda bu komut ciddi zaman kazandırıyor.
Özellikle bash scriptleriyle birleştirdiğinde, onlarca siteye tutarlı yetki politikaları uygulamak dakikalar içinde tamamlanabilen bir iş haline geliyor. Capability raporlamayı düzenli yaparsan, yetkisiz değişiklikleri proaktif olarak tespit edebilir ve site güvenliğini uzun vadede koruyabilirsin.
Bir sonraki adım olarak wp role komutunu da keşfetmeni öneririm. Özel roller oluşturup bunlara wp cap ile özelleştirilmiş yetki setleri atamak, kullanıcı yönetiminde sana tam kontrol imkanı sunar.
