Filter untuk Menonaktifkan Penyesuai yang Ditembak di WordPress Trac

WordPress 4.3 akan memperkenalkan manajemen menu melalui penyesuai, menyediakan pratinjau langsung di frontend untuk menambahkan, menghapus, dan memesan item menu. Meskipun pengguna masih memiliki opsi untuk mengelola menu menggunakan antarmuka admin, pengembang yang tidak tertarik dengan fitur ini mencari cara mudah untuk menonaktifkan penyesuai dan menghapus tautannya di seluruh WordPress.

Dalam skenario tertentu yang melibatkan pekerjaan klien, penyesuai dapat menjadi lebih banyak masalah daripada nilainya dan mungkin bukan tambahan yang bermanfaat bagi admin WordPress yang dirancang khusus.

@pollyplummer sangat menarik. Saya tidak menentang pembaruan baru tetapi penyesuai adalah neraka di dunia agensi.

— Edward McIntyre (@twittem) 24 Juni 2015

Gabe Shackle, pengembang aplikasi dan insinyur UI di Risdall, membuat tiket di WordPress trac minggu lalu, meminta filter untuk menonaktifkan penyesuai. Patch-nya menawarkan pengembang cara mudah untuk mengaktifkan kelas 'no-customizer-support' di dalam tag body.

Karena fakta bahwa kelas 'dukungan penyesuai' ditambahkan melalui JavaScript pada render halaman, kelas tersebut tidak dapat dimanipulasi menggunakan filter atau tindakan inti apa pun saat ini.

Dengan menyetel nilai filter ke false, Penyesuai pada dasarnya disembunyikan dari admin dan tautan yang saat ini mengarah ke Penyesuai (widget, tema, dll…) dikembalikan ke tujuan dasbor sebelumnya.

Saat ini, pengembang yang ingin menonaktifkan penyesuai harus menggunakan kombinasi berbagai metode agar dapat menghapus semua yang diperkenalkan penyesuai ke admin secara efektif.

“Filter ini membuat proses ini menjadi filter boolean sederhana sehingga pengembang yang tidak menginginkan atau membutuhkan Customizer dapat dengan mudah menghapusnya,” kata Shackle.

Pengembang utama WordPress, Dion Hulse, menjawab tiket untuk mengatakan bahwa meskipun dia sendiri tidak banyak menggunakan penyesuai, dia tidak berpikir bahwa pengguna WordPress akan mendapat manfaat dari cara mudah untuk mematikannya.

Secara pribadi, meskipun saya tidak sering menggunakan penyesuai, saya pikir menawarkan filter untuk menonaktifkannya mungkin bukan demi kepentingan terbaik pengguna WordPress.

Penyesuai, meskipun beberapa tidak menyukainya, adalah komponen utama masa depan WordPress UX – apakah itu hal yang baik atau buruk masih harus dilihat oleh sebagian orang – tetapi suka atau tidak suka, ada di sini.

Hulse menyarankan, sebagai alternatif, bahwa cara yang lebih baik untuk menonaktifkannya adalah dengan menghapus kemampuan customize dari peran.

Shackle lebih lanjut menjelaskan bahwa dia mencoba mengikuti preseden bilah admin, yang dia anggap sebagai jenis komponen UX yang serupa.

“Admin Bar dapat dinonaktifkan tidak hanya oleh filter tetapi oleh variabel global, fungsi inti, dan pengaturan profil pengguna,” katanya. "The Customizer tidak memiliki opsi ini."

Nick Halsey, pengembang plugin Menu Customizer yang sedang digabungkan ke 4.3, menjawab berdasarkan asumsi tentang mengapa Shackle mungkin meminta filter untuk menonaktifkan fitur:

Saya belum melihat alasan yang sah untuk hal seperti ini. Dalam kebanyakan kasus, kekhawatiran tentang tidak ingin pengguna memiliki akses ke Penyesuai berasal dari fakta bahwa Anda tidak memberi mereka kemampuan yang sesuai. Dan kemampuan menyesuaikan dapat digunakan untuk mematikan Customizer jika Anda benar-benar harus.

Meskipun Anda dapat menghapus kemampuan meta kustomisasi (atau memetakannya kembali atau apa pun), melakukannya hanya karena Anda tidak ingin melatih pengguna atau tidak ingin menggunakan Penyesuai akan merugikan diri sendiri dan pengguna Anda. Seperti yang disebutkan dd32, Customizer hanya akan terus tumbuh semakin penting dalam WordPress. Selain itu, pengujian pengguna telah menunjukkan bahwa pengalaman Penyesuai umumnya lebih mudah dipahami pengguna daripada admin, yang sebagian besar berasal dari nilai ketersediaan pratinjau langsung. Kami menempatkan banyak waktu ke dalam Customizer setiap rilis untuk terus meningkatkannya, melakukan pengujian pengguna yang sering di sepanjang jalan untuk mengoptimalkan kegunaan.

Halsey segera menutup tiket setelah pertukaran ini. Saya menindaklanjuti dengan Shackle untuk mencari tahu mengapa alternatif yang diusulkan untuk menghapus kemampuan customize tidak memadai untuk tujuannya.

“Sebagian besar saya berharap Customizer dapat diperlakukan lebih seperti bilah admin, yang memiliki 3+ metode untuk menonaktifkannya,” kata Shackle. “Memiliki filter berlabel jelas, menurut saya, lebih mudah dibaca daripada memodifikasi kemampuan pengguna. Pengembang PHP yang hampir tidak memiliki pengetahuan WordPress kemungkinan besar dapat memahami lebih cepat apa yang terjadi dengan filter bernama 'enable_customizer_support' daripada 'map_meta_cap'.”

Jelas, tidak semua tiket dan patch akan dianggap valid oleh pengelola komponen inti WordPress, tetapi Shackle kecewa dengan respons defensif terhadap diskusi tersebut.

“Sejujurnya, jika jawabannya adalah sesuatu seperti 'Anda hanya harus menggunakan kemampuan customize untuk mencapai efek yang sama', saya benar-benar tidak akan memiliki masalah apa pun,” katanya.

“Sayangnya, sepertinya ada pendekatan selain 'Customizer untuk semua hal!' berarti saya diberi tahu berkali-kali berapa banyak kerugian yang saya lakukan kepada klien saya dan betapa malasnya saya sebagai pengembang karena tidak hanya melatih kembali klien saya cara mengelola tampilan situs mereka.

“Rasanya seperti tim Customizer sendiri memiliki pendekatan semua-atau-tidak sama sekali terhadap proyek dan bahwa siapa pun yang mempertanyakan ini salah, terlepas dari alasan mereka,” kata Shackle.

Pertukaran ini menunjukkan bahwa karena kontributor inti melihat penyesuai sebagai bagian utama dari masa depan WordPress, ini adalah salah satu fitur di mana akan ada sedikit keinginan untuk mendukung upaya untuk membuatnya lebih modular. Menonaktifkan dukungan untuk penyesuai akan terus memerlukan penggunaan 'map_meta_cap', metode yang sama yang digunakan pembuat plugin Hapus Semua Bagian Penyesuai.