Filtro per disabilitare il Customizer abbattuto su WordPress Trac

WordPress 4.3 introdurrà la gestione dei menu tramite il personalizzatore, fornendo anteprime dal vivo sul frontend per aggiungere, eliminare e ordinare voci di menu. Sebbene gli utenti abbiano ancora la possibilità di gestire i menu utilizzando l'interfaccia di amministrazione, gli sviluppatori che non sono entusiasti della funzionalità stanno cercando un modo semplice per disabilitare il personalizzatore e rimuovere i suoi collegamenti in WordPress.

In alcuni scenari che coinvolgono il lavoro del cliente, il personalizzatore può essere più problematico di quanto valga la pena e potrebbe non essere un'aggiunta vantaggiosa a un amministratore WordPress personalizzato.

@pollyplummer molto interessante. Non sono contrario ai nuovi aggiornamenti, ma il personalizzatore è l'inferno nel mondo delle agenzie.

— Edward McIntyre (@twittem) 24 giugno 2015

Gabe Shackle, sviluppatore di applicazioni e ingegnere dell'interfaccia utente di Risdall, ha creato un ticket su WordPress trac la scorsa settimana, richiedendo un filtro per disabilitare il personalizzatore. La sua patch offre agli sviluppatori un modo semplice per abilitare la classe "no-customizer-support" all'interno del tag body.

A causa del fatto che la classe "customizer-support" viene aggiunta tramite JavaScript durante il rendering della pagina, non può essere manipolata utilizzando attualmente alcun filtro o azione principale.

Impostando il valore del filtro su false, il Customizer viene essenzialmente nascosto all'amministratore e i collegamenti che puntavano attualmente al Customizer (widget, temi, ecc...) vengono ripristinati alle destinazioni del dashboard precedenti.

Attualmente, gli sviluppatori che vogliono disabilitare il personalizzatore devono utilizzare una combinazione di metodi diversi per rimuovere efficacemente tutto ciò che il personalizzatore introduce nell'amministratore.

"Questo filtro trasforma questo processo in un semplice filtro booleano in modo che gli sviluppatori che non desiderano o non necessitano del Customizer possano rimuoverlo facilmente", ha affermato Shackle.

Dion Hulse, sviluppatore principale di WordPress, ha risposto al ticket affermando che, sebbene non utilizzi molto il personalizzatore, non pensa che gli utenti di WordPress trarrebbero vantaggio da un modo semplice per disattivarlo.

Personalmente, per quanto non utilizzi spesso il personalizzatore, penso che offrire un filtro per disabilitarlo probabilmente non sia nel migliore interesse degli utenti di WordPress.

Il personalizzatore, per quanto ad alcuni non piaccia, è una componente importante del futuro di WordPress UX – che sia una cosa buona o cattiva resta da vedere da alcuni – ma piace o lo odia, è qui.

Hulse ha suggerito, in alternativa, che un modo migliore per disabilitarlo sarebbe rimuovere la capacità di customize dai ruoli.

Shackle ha inoltre spiegato che stava tentando di seguire il precedente della barra di amministrazione, che considera un tipo simile di componente UX.

"La barra di amministrazione può essere disabilitata non solo da un filtro, ma da una variabile globale, una funzione principale e un'impostazione del profilo utente", ha affermato. "Il Customizer non ha nessuna di queste opzioni."

Nick Halsey, lo sviluppatore del plug-in Menu Customizer che viene unito alla versione 4.3, ha risposto basandosi su supposizioni sul motivo per cui Shackle potrebbe richiedere un filtro per disabilitare la funzione:

Devo ancora vedere una ragione valida per qualcosa del genere. Nella maggior parte dei casi, le preoccupazioni sul non volere che gli utenti abbiano accesso al Customizer derivano dal fatto che non stai fornendo loro le capacità appropriate. E la capacità di personalizzazione può essere utilizzata per disattivare il Customizer se proprio necessario.

Sebbene tu possa rimuovere la meta capacità di personalizzazione (o rimapparla o altro), farlo semplicemente perché non vuoi addestrare gli utenti o non vuoi usare il Customizer sta facendo a te stesso e ai tuoi utenti un enorme disservizio. Come accennato in dd32, il Customizer continuerà a crescere di importanza all'interno di WordPress. Inoltre, i test degli utenti hanno dimostrato che l'esperienza di personalizzazione è generalmente più facile da comprendere per gli utenti rispetto all'amministratore, il che deriva in gran parte dal valore di avere l'anteprima dal vivo disponibile. Dedichiamo una notevole quantità di tempo a Customizer in ogni versione per continuare a migliorarlo, conducendo test utente frequenti lungo il percorso per ottimizzare l'usabilità.

Halsey ha prontamente chiuso il biglietto a seguito di questo scambio. Ho seguito Shackle per scoprire perché l'alternativa proposta per rimuovere la capacità di customize è inadeguata per i suoi scopi.

"Per lo più speravo che il Customizer potesse essere trattato più come la barra di amministrazione, che ha più di 3 metodi per disabilitarlo", ha detto Shackle. “Avere un filtro chiaramente etichettato è, a mio parere, più leggibile che modificare le capacità dell'utente. Uno sviluppatore PHP praticamente senza alcuna conoscenza di WordPress potrebbe molto probabilmente capire molto più velocemente cosa sta succedendo con un filtro chiamato 'enable_customizer_support' piuttosto che 'map_meta_cap'."

Ovviamente non tutti i ticket e le patch saranno considerati validi dai manutentori dei componenti core di WordPress, ma Shackle è rimasto deluso dalla risposta difensiva alla discussione.

"Onestamente, se la risposta fosse stata semplicemente qualcosa sulla falsariga di 'Dovresti semplicemente usare la capacità di customize per ottenere lo stesso effetto', non avrei davvero avuto problemi", ha detto.

“Purtroppo, sembra un approccio diverso da 'Personalizzatore per tutte le cose!' significa che mi viene detto più volte quanto disservizio sto facendo ai miei clienti e che sviluppatore pigro sono per non solo riqualificare i miei clienti come gestire l'aspetto dei loro siti.

"Sembra che il team di Customizer stesso abbia un approccio tutto o niente al progetto e che chiunque metta in dubbio questo sia sbagliato, indipendentemente dal loro ragionamento", ha detto Shackle.

Questo scambio dimostra che, poiché i contributori principali vedono il personalizzatore come una parte importante del futuro di WordPress, questa è una caratteristica in cui ci sarà poca volontà di supportare gli sforzi per renderlo più modulare. La disabilitazione del supporto per la personalizzazione continuerà a richiedere l'uso di "map_meta_cap", lo stesso metodo utilizzato dai creatori del plug-in Customizer Remove All Parts.