Members vs. Kakapo Roles: kalıcı olan yetkileri yönetmek
Bir yetki eklentisi tek bir soruyla ölçülür: yetki, kimse yönetim panelinde tıklamadığında da geçerli kalıyor mu? “Gizlemek” denen şeylerin çoğu yalnızca görünümü değiştirir — veriler bir REST API çağrısı uzaklıkta açıkta durmaya devam eder. Bu karşılaştırma Members ve Kakapo Roles'u buna göre ele alıyor.
Kısa yanıt
Members, köklü ve ücretsiz bir yetki eklentisidir: rol oluşturma ve düzenleme, yetki atama, içerikleri role göre koruma. Hafiftir, yaygındır ve basit durumların çoğu için yeterlidir.
Kakapo Roles bir kat daha derinden başlar. Yalnızca rolleri ve yetkileri değil, bir kullanıcının yönetim panelinde neyi görebildiğini de yönetir — yönetim menüsü, ortam kütüphanesi, widget'lar, kısa kodlar — ve görünürlük kurallarını açıkça REST API'de de uygular. Buna bir değişiklik günlüğü, silinen roller için bir çöp kutusu ve içe/dışa aktarma eklenir.
Kısacası: rol oluşturmak ve içerikleri korumak isteyen Members ile epey yol alır ve hiçbir şey ödemez. Bir müşteriye toparlanmış bir yönetim paneli vermek, yetkileri izlenebilir biçimde belgelemek ya da bir kuralın yalnızca arayüzü etkilemesini önlemek isteyen için Kakapo Roles daha doğru seçimdir.
İkisinin de yapabildikleri
- Kendi rollerini oluşturma, yeniden adlandırma ve silme
- Rol başına yetki belirleme, özel içerik türlerininkiler de dahil
- Tek tek kullanıcılara ek yetki verme veya yetki geri alma
- İçerikleri belirli rollerle sınırlama
- Kullanıcı başına birden çok rol
Buraya kadar seçim bir zevk meselesidir. Bunun ötesinde işler ilginçleşir.
İkisi nerede ayrışıyor
| Soru | Members | Kakapo Roles |
|---|---|---|
| Fiyat | ücretsiz | ücretli eklenti, dokuz eklenti için tek lisans |
| REST API üzerinden de yazı yetkileri | kontrol edilmeli | evet, açıkça uygulanır |
| Yönetim menüsünü role göre gizleme | uzantılar üzerinden | yerleşik |
| Ortam kütüphanesini kişinin kendi dosyalarıyla sınırlama | uzantılar üzerinden | yerleşik |
| Role göre widget'lar ve gezinme menüleri | — | yerleşik |
| Role göre kısa kodlara izin verme | — | yerleşik |
| Role göre girişten sonra yönlendirme | — | yerleşik |
| Silinen roller için çöp kutusu | — | evet, geri yüklemeyle |
| Değişiklik günlüğü | — | evet, kimin ne zaman hangi yetkiyi değiştirdiği |
| Yetkilerin içe ve dışa aktarılması | — | evet, dosya olarak |
| Yetki yükseltmeye karşı koruma | kontrol edilmeli | get_editable_roles dikkate alınır, ağda da |
| Birden fazla site | site başına ayrı ayrı | uzak durum ve hepsi için tek lisans |
Önemli olan fark: gizlemek, kilitlemek değildir
Bir yazı “yalnızca belirli roller için” görünür olacaksa bunu uygulamanın iki yolu vardır. Biri onu listelerde ve ön yüzde gizler. Diğeri erişimi reddeder — her yerde, kimsenin tıklamadığı yerlerde de.
Bu fark bir incelik değildir. WordPress'in REST API'si varsayılan olarak erişilebilirdir; /wp-json/wp/v2/posts çağrısı, oturum açmadan yazıları JSON olarak döndürür. Yalnızca görünümü değiştiren bir kural orada etkisizdir — “yalnızca üyeler için” düşünülmüş içerik yanıtta düz metin olarak yer alır.
Bu yüzden Kakapo Roles görünürlük kuralını REST API'de de uygular. Bir yetki eklentisinin kontrol edilebilir olmasının nedeni bu tek satırdır: korunan adresini bir kez oturum kapalıyken JSON olarak çağır. İçerik oradaysa kural hiçbir şeyi korumuyor demektir.
Bu testi her eklentiyle yapabilirsin, şu anda kullandığınla da: yazıyı koru, oturumu kapat, /wp-json/wp/v2/posts?search=… adresini çağır. Bir dakika sürer ve herhangi bir özellik listesinden daha fazlasını yanıtlar.İkinci tuzak: yetkiyi kim verebilir?
Arayüze erişimi olan herkesin kendine daha fazla yetki vermesine izin veren bir yetki eklentisi kendi kendini geçersiz kılar. WordPress'in bunun için bir kancası vardır: get_editable_roles(), birinin hangi rolleri düzenleyebileceğini belirler. Onu atlayan bir eklenti, kapatması gereken yolu tam da açar.
Ağ kurulumlarında ikinci bir soru eklenir: roller orada kısmen ağ genelinde durur. Onları bir alt siteden üzerine yazan, tüm siteler için değiştirir. Kakapo Roles ikisini de dikkate alır — kancayı ve site ile ağ arasındaki sınırı.
Members ne zaman daha iyi seçimdir
- Rollere ve yetkilere ihtiyacın var, başka hiçbir şeye değil
- Bütçe sıfır
- Tek bir siteyle ve az sayıda kullanıcıyla çalışıyorsun
- Tam olarak tek bir iş yapan bir eklenti istiyorsun
Kakapo Roles ne zaman daha iyi seçimdir
- Bir müşteriye yönetim paneli veriyorsun ve onu toparlamak istiyorsun — menü, ortam kütüphanesi, widget'lar
- Korunan içerikler REST API üzerinden de korunmalı
- Kimin ne zaman hangi yetkiyi aldığını kanıtlayabilmen gerekiyor
- Bir yetki yapısını bir kez kurup başka sitelere aktarmak istiyorsun
- Zaten başka Kakapo eklentileri de kullanıyorsun ve beş fatura yerine tek fatura istiyorsun
Geçiş: yapılması gerekenler
- Hangi özel rollerin olduğunu ve bunlara hangi yetkilerin bağlı olduğunu not et — matrisin bir ekran görüntüsü yeterli.
- Bir yedek al. Yetkiler veritabanında durur ve bir hata tüm kullanıcıları aynı anda etkiler.
- Kakapo Roles'u kur ve lisans anahtarını gir.
- Rolleri yeniden oluştur ve matrisi satır satır notunla karşılaştır.
- Rol başına bir test kullanıcısıyla oturum aç ve gerçekte neyi gördüğüne bak.
- Korunan bir içerik için REST testini yap.
- Eski eklentiyi ancak ondan sonra kapat — silme, iki haftalığına.
Aynı anda iki yetki eklentisi kötü bir durumdur: ikisi de aynı rollere yazar ve en son kaydeden kazanır. Geçiş süresini kısa tut ve bu süre içinde yalnızca birinde değişiklik yap.
Sık sorulan sorular
Kakapo Roles mevcut rollerimi devralır mı?
Eklentiyi silersem rollerime ne olur?
Silinmiş bir rolü geri getirebilir miyim?
Bir kısıtlama ön yüzde de etkili olur mu?
Geçerli bir lisans olmadan ne olur?
Kakapo Roles — bir kez ödeyin, sonsuza dek kullanın.
Dokuz eklentinin tamamı ayda 13 € yerine tek seferde 149 €. Stripe ile güvenli ödeme. İlk 14 günde: sorun çözülür ya da paranız iade edilir.
Lifetime’ı al Tüm özellikler