Filtrer pour désactiver le Customizer Shot Down sur WordPress Trac

WordPress 4.3 introduira la gestion des menus via le personnalisateur, fournissant des aperçus en direct sur le frontend pour ajouter, supprimer et commander des éléments de menu. Bien que les utilisateurs aient toujours la possibilité de gérer les menus à l'aide de l'interface d'administration, les développeurs qui ne sont pas intéressés par cette fonctionnalité recherchent un moyen simple de désactiver le personnalisateur et de supprimer ses liens dans WordPress.

Dans certains scénarios impliquant le travail du client, le personnalisateur peut poser plus de problèmes qu'il n'en vaut la peine et peut ne pas constituer un ajout avantageux à un administrateur WordPress personnalisé.

@pollyplummer très intéressant. Je ne suis pas contre les nouvelles mises à jour mais le customiseur c'est l'enfer dans le monde des agences.

— Edward McIntyre (@twittem) 24 juin 2015

Gabe Shackle, développeur d'applications et ingénieur UI chez Risdall, a créé un ticket sur WordPress trac la semaine dernière, demandant un filtre pour désactiver le personnalisateur. Son correctif offre aux développeurs un moyen simple d'activer la classe "no-customizer-support" dans la balise body.

En raison du fait que la classe 'customizer-support' est ajoutée via JavaScript sur le rendu de la page, elle ne peut actuellement pas être manipulée à l'aide de filtres ou d'actions de base.

En définissant la valeur du filtre sur false, le Customizer est essentiellement caché à l'administrateur et les liens qui pointaient actuellement vers le Customizer (widgets, thèmes, etc.) sont renvoyés vers leurs destinations de tableau de bord précédentes.

Actuellement, les développeurs qui souhaitent désactiver le personnalisateur doivent utiliser une combinaison de différentes méthodes afin de supprimer efficacement tout ce que le personnalisateur introduit dans l'administrateur.

"Ce filtre transforme ce processus en un simple filtre booléen afin que les développeurs qui ne veulent pas ou n'aient pas besoin du Customizer puissent facilement le supprimer", a déclaré Shackle.

Le développeur principal de WordPress, Dion Hulse, a répondu au ticket pour dire que bien qu'il n'utilise pas beaucoup le personnalisateur lui-même, il ne pense pas que les utilisateurs de WordPress bénéficieraient d'un moyen simple de le désactiver.

Personnellement, même si je n'utilise pas souvent le personnalisateur, je pense que proposer un filtre pour le désactiver n'est probablement pas dans l'intérêt des utilisateurs de WordPress.

Le personnalisateur, même si certains ne l'aiment pas, est un élément majeur de l'avenir de WordPress UX – que ce soit une bonne ou une mauvaise chose reste à voir par certains – mais qu'on l'aime ou qu'on le déteste, il est là.

Hulse a suggéré, comme alternative, qu'une meilleure façon de le désactiver serait de supprimer la capacité de customize des rôles.

Shackle a en outre expliqué qu'il tentait de suivre le précédent de la barre d'administration, qu'il considère comme un type similaire de composant UX.

"La barre d'administration peut être désactivée non seulement par un filtre, mais aussi par une variable globale, une fonction principale et un paramètre de profil utilisateur", a-t-il déclaré. "Le Customizer n'a aucune de ces options."

Nick Halsey, le développeur du plugin Menu Customizer qui est fusionné avec la version 4.3, a répondu en se basant sur des hypothèses sur la raison pour laquelle Shackle pourrait demander un filtre pour désactiver la fonctionnalité :

Je n'ai pas encore vu de raison valable pour quelque chose comme ça. Dans la plupart des cas, les inquiétudes concernant le fait de ne pas vouloir que les utilisateurs aient accès au Customizer proviennent du fait que vous ne leur donnez pas les capacités appropriées. Et la capacité de personnalisation peut être utilisée pour désactiver le Customizer si vous le devez vraiment.

Bien que vous puissiez supprimer la méta-capacité de personnalisation (ou la remapper ou autre), le faire simplement parce que vous ne voulez pas former les utilisateurs ou ne voulez pas utiliser le Customizer vous rend un énorme mauvais service à vous-même et à vos utilisateurs. Comme dd32 l'a mentionné, le Customizer ne fera que gagner en importance au sein de WordPress. De plus, les tests utilisateurs ont montré que l'expérience Customizer est généralement plus facile à saisir pour les utilisateurs que pour l'administrateur, ce qui découle en grande partie de l'intérêt de disposer d'un aperçu en direct. Nous consacrons beaucoup de temps à chaque version de Customizer pour continuer à l'améliorer, en effectuant des tests utilisateurs fréquents en cours de route pour optimiser la convivialité.

Halsey a rapidement fermé le ticket suite à cet échange. J'ai suivi avec Shackle pour savoir pourquoi l'alternative proposée pour supprimer la capacité de customize est inadéquate pour ses besoins.

"La plupart du temps, j'espérais que le Customizer pourrait être traité davantage comme la barre d'administration, qui a plus de 3 méthodes pour le désactiver", a déclaré Shackle. "Avoir un filtre clairement étiqueté est, à mon avis, plus lisible que de modifier les capacités de l'utilisateur. Un développeur PHP n'ayant pratiquement aucune connaissance de WordPress pourrait très probablement comprendre beaucoup plus rapidement ce qui se passe avec un filtre nommé 'enable_customizer_support' plutôt que 'map_meta_cap'.

De toute évidence, tous les tickets et correctifs ne seront pas considérés comme valides par les responsables des composants de base de WordPress, mais Shackle a été déçu par la réponse défensive à la discussion.

"Honnêtement, si la réponse avait simplement été quelque chose du genre" Vous devriez simplement utiliser la capacité de customize pour obtenir le même effet ", je n'aurais vraiment eu aucun problème", a-t-il déclaré.

"Malheureusement, il semble que toute approche autre que 'Customizer pour toutes choses !' signifie qu'on me dit plusieurs fois à quel point je rends service à mes clients et quel développeur paresseux je suis pour ne pas simplement former mes clients à la gestion de l'apparence de leurs sites.

"On dirait que l'équipe Customizer elle-même a une approche tout ou rien du projet et que quiconque remet en question cela a tort, quel que soit son raisonnement", a déclaré Shackle.

Cet échange démontre que puisque les principaux contributeurs considèrent le personnalisateur comme une partie importante de l'avenir de WordPress, c'est une fonctionnalité où il y aura peu de volonté de soutenir les efforts pour le rendre plus modulaire. La désactivation de la prise en charge du personnalisateur nécessitera toujours l'utilisation de 'map_meta_cap', la même méthode que les créateurs du plugin Customizer Remove All Parts ont utilisée.