WordPress Trac'te Özelleştirici Çekimini Devre Dışı Bırakmak için Filtre

WordPress 4.3, menü öğelerini eklemek, silmek ve sipariş etmek için ön uçta canlı önizlemeler sağlayarak, özelleştirici aracılığıyla menü yönetimini tanıtacaktır. Kullanıcılar hala yönetici arayüzünü kullanarak menüleri yönetme seçeneğine sahip olsa da, bu özelliğe meraklı olmayan geliştiriciler, özelleştiriciyi devre dışı bırakmanın ve WordPress'teki bağlantılarını kaldırmanın kolay bir yolunu arıyorlar.

İstemci çalışmasını içeren belirli senaryolarda, özelleştirici, değerinden daha fazla sorun yaratabilir ve özel olarak tasarlanmış bir WordPress yöneticisine faydalı bir ek olmayabilir.

@pollyplummer çok ilginç. Yeni güncellemelere karşı değilim ama özelleştirici ajans dünyasında cehennem gibi.

- Edward McIntyre (@twittem) 24 Haziran 2015

Risdall'da uygulama geliştiricisi ve UI mühendisi olan Gabe Shackle, geçen hafta WordPress trac'de özelleştiriciyi devre dışı bırakmak için bir filtre talep eden bir bilet oluşturdu. Onun yaması, geliştiricilere gövde etiketi içinde 'özelleştirici desteği olmayan' sınıfını etkinleştirmenin kolay bir yolunu sunuyor.

'Özelleştirici-destek' sınıfının sayfa oluşturmada JavaScript aracılığıyla eklenmesi nedeniyle, şu anda herhangi bir çekirdek filtre veya eylem kullanılarak değiştirilemez.

Filtre değeri false olarak ayarlandığında, Özelleştirici esasen yöneticiden gizlenir ve şu anda Özelleştiriciye işaret eden bağlantılar (widget'lar, temalar vb.) önceki pano hedeflerine döndürülür.

Şu anda, özelleştiriciyi devre dışı bırakmak isteyen geliştiriciler, özelleştiricinin yöneticiye sunduğu her şeyi etkili bir şekilde kaldırmak için farklı yöntemlerin bir kombinasyonunu kullanmak zorundadır.

Shackle, "Bu filtre, bu işlemi basit bir boole filtresine dönüştürüyor, böylece Özelleştirici'yi istemeyen veya buna ihtiyaç duymayan geliştiriciler onu kolayca kaldırabiliyor" dedi.

WordPress baş geliştiricisi Dion Hulse, bilete yanıt vererek, kişiselleştiriciyi pek kullanmasa da, WordPress kullanıcılarının onu kapatmanın kolay bir yolundan faydalanacağını düşünmediğini söyledi.

Kişisel olarak, kişiselleştiriciyi çoğu zaman kullanmasam da, onu devre dışı bırakmak için bir filtre önermenin muhtemelen WordPress kullanıcılarının yararına olmadığını düşünüyorum.

Özelleştirici, bazıları hoşlanmasa da, WordPress UX'in geleceğinin önemli bir bileşenidir – bunun iyi mi yoksa kötü bir şey mi olduğu, bazıları tarafından görülecektir – ancak beğenin veya nefret edin, burada.

Hulse, alternatif olarak, onu devre dışı bırakmanın daha iyi bir yolunun, rollerden customize yeteneğini kaldırmak olduğunu önerdi.

Shackle ayrıca, benzer bir UX bileşeni türü olduğunu düşündüğü yönetici çubuğunun örneğini takip etmeye çalıştığını açıkladı.

"Yönetici Çubuğu yalnızca bir filtreyle değil, genel bir değişken, temel işlev ve kullanıcı profili ayarıyla da devre dışı bırakılabilir" dedi. "Özelleştirici bu seçeneklerin hiçbirine sahip değil."

4.3 ile birleştirilen Menü Özelleştirici eklentisinin geliştiricisi Nick Halsey, Shackle'ın neden özelliği devre dışı bırakmak için bir filtre talep edebileceğine ilişkin varsayımlara dayanarak yanıt verdi:

Böyle bir şey için henüz geçerli bir sebep göremiyorum. Çoğu durumda, kullanıcıların Özelleştiriciye erişmesini istememe konusundaki endişeler, onlara uygun yetenekleri vermemenizden kaynaklanır. Ve özelleştirme yeteneği, gerçekten gerekiyorsa, Özelleştiriciyi kapatmak için kullanılabilir.

Özelleştirme meta yeteneğini kaldırabilseniz de (veya yeniden eşleseniz veya her neyse), bunu yalnızca kullanıcıları eğitmek istemediğiniz veya Özelleştiriciyi kullanmak istemediğiniz için yapmak, kendinize ve kullanıcılarınıza çok büyük bir kötülük yapmaktır. dd32'de belirtildiği gibi, Özelleştirici yalnızca WordPress içinde önem kazanmaya devam edecektir. Ek olarak, kullanıcı testleri, Özelleştirici deneyiminin kullanıcılar için genel olarak yöneticiden daha kolay kavrandığını göstermiştir; bu, büyük ölçüde canlı önizlemenin mevcut olmasının değerinden kaynaklanmaktadır. Her sürümde, onu geliştirmeye devam etmek için Özelleştiriciye önemli miktarda zaman ayırıyoruz ve kullanılabilirliği optimize etmek için yol boyunca sık sık kullanıcı testleri yapıyoruz.

Halsey bu değiş tokuşun ardından bileti derhal kapattı. customize yeteneğini kaldırmak için önerilen alternatifin neden onun amaçları için yetersiz olduğunu öğrenmek için Shackle ile görüştüm.

Shackle, "Çoğunlukla Özelleştiricinin, onu devre dışı bırakmak için 3'ten fazla yöntemi olan yönetici çubuğu gibi ele alınabileceğini umuyordum" dedi. "Açık bir şekilde etiketlenmiş bir filtreye sahip olmak, bence, kullanıcı yeteneklerini değiştirmekten daha okunaklı. Neredeyse hiç WordPress bilgisi olmayan bir PHP geliştiricisi, 'map_meta_cap' yerine 'enable_customizer_support' adlı bir filtreyle neler olduğunu çok daha hızlı anlayabilir.”

Açıkçası, tüm biletler ve yamalar, WordPress çekirdek bileşenlerinin koruyucuları tarafından geçerli kabul edilmeyecektir, ancak Shackle, tartışmaya verilen savunma yanıtı nedeniyle hayal kırıklığına uğradı.

"Dürüst olmak gerekirse, yanıt basitçe 'Aynı etkiyi elde etmek için customize özelliğini kullanmalısınız' gibi bir şey olsaydı, gerçekten herhangi bir sorun yaşamazdım" dedi.

“Ne yazık ki, 'Her şey için özelleştirici!' dışında herhangi bir yaklaşım var gibi görünüyor. Bu, müşterilerime ne kadar kötü bir hizmet yaptığımın ve müşterilerime sitelerinin görünümünü nasıl yöneteceklerini yeniden eğitmekle kalmayıp ne kadar tembel bir geliştirici olduğumun defalarca söylendiği anlamına geliyor.

Shackle, "Customizer ekibinin kendilerinin projeye ya hep ya hiç yaklaşımına sahip olduklarını ve bunu sorgulayan herkesin, akıl yürütmelerinden bağımsız olarak yanlış olduğunu hissediyor" dedi.

Bu değişim, temel katkıda bulunanların özelleştiriciyi WordPress'in geleceğinin önemli bir parçası olarak gördüklerinden, bu, onu daha modüler hale getirme çabalarını destekleme konusunda çok az istekliliğin olacağı bir özellik olduğunu gösteriyor. Özelleştirici desteğinin devre dışı bırakılması, Customizer Remove All Parts eklentisinin yaratıcılarının kullandığı yöntemin aynısı olan 'map_meta_cap' kullanımını gerektirmeye devam edecektir.