Filtro para desativar o personalizador derrubado no WordPress Trac

O WordPress 4.3 introduzirá o gerenciamento de menus por meio do personalizador, fornecendo visualizações ao vivo no frontend para adicionar, excluir e ordenar itens de menu. Embora os usuários ainda tenham a opção de gerenciar menus usando a interface de administração, os desenvolvedores que não estão interessados ​​no recurso estão procurando uma maneira fácil de desativar o personalizador e remover seus links em todo o WordPress.

Em certos cenários que envolvem o trabalho do cliente, o personalizador pode ser mais problemático do que vale a pena e pode não ser uma adição benéfica a um administrador do WordPress personalizado.

@pollyplummer muito interessante. Não sou contra as novas atualizações, mas o customizador é um inferno no mundo das agências.

— Edward McIntyre (@twittem) 24 de junho de 2015

Gabe Shackle, desenvolvedor de aplicativos e engenheiro de interface do usuário da Risdall, criou um ticket no WordPress trac na semana passada, solicitando um filtro para desabilitar o personalizador. Seu patch oferece aos desenvolvedores uma maneira fácil de habilitar a classe 'no-customizer-support' dentro da tag body.

Devido ao fato de que a classe 'customizer-support' é adicionada via JavaScript na renderização da página, ela não pode ser manipulada usando nenhum filtro ou ação principal atualmente.

Ao definir o valor do filtro como falso, o Personalizador fica essencialmente oculto do administrador e os links que estavam apontando para o Personalizador (widgets, temas, etc.) são revertidos para seus destinos de painel anteriores.

Atualmente, os desenvolvedores que desejam desabilitar o personalizador precisam empregar uma combinação de métodos diferentes para remover efetivamente tudo o que o personalizador introduz no administrador.

“Esse filtro transforma esse processo em um filtro booleano simples para que os desenvolvedores que não querem ou precisam do Customizer possam removê-lo facilmente”, disse Shackle.

O desenvolvedor líder do WordPress, Dion Hulse, respondeu ao ticket para dizer que, embora ele não use muito o personalizador, ele não acha que os usuários do WordPress se beneficiariam de uma maneira fácil de desativá-lo.

Pessoalmente, por mais que eu não use o personalizador muitas vezes, acho que oferecer um filtro para desativá-lo provavelmente não é do melhor interesse dos usuários do WordPress.

O personalizador, por mais que alguns não gostem, é um componente importante do futuro do WordPress UX – se isso é uma coisa boa ou ruim, continua a ser visto por alguns – mas goste ou odeie, está aqui.

Hulse sugeriu, como alternativa, que uma maneira melhor de desativá-lo seria remover o recurso de customize das funções.

Shackle explicou ainda que estava tentando seguir o precedente da barra de administração, que ele considera um tipo semelhante de componente UX.

“A barra de administração pode ser desabilitada não apenas por um filtro, mas por uma variável global, função principal e configuração de perfil do usuário”, disse ele. “O Personalizador não tem nenhuma dessas opções.”

Nick Halsey, o desenvolvedor do plugin Menu Customizer que está sendo mesclado no 4.3, respondeu com base em suposições sobre por que o Shackle pode solicitar um filtro para desabilitar o recurso:

Eu ainda tenho que ver uma razão válida para algo assim. Na maioria dos casos, as preocupações sobre não querer que os usuários tenham acesso ao Personalizador decorrem do fato de você não estar fornecendo a eles os recursos apropriados. E o recurso de personalização pode ser usado para desativar o Personalizador, se você realmente precisar.

Embora você possa remover a meta capacidade de personalização (ou remapear ou qualquer outra coisa), fazê-lo simplesmente porque não deseja treinar usuários ou não deseja usar o Personalizador está fazendo a você e a seus usuários um enorme desserviço. Como o dd32 mencionou, o Customizer só continuará a crescer em importância dentro do WordPress. Além disso, o teste do usuário mostrou que a experiência do Customizer é geralmente mais fácil para os usuários entenderem do que para o administrador, o que se deve em grande parte ao valor de ter a visualização ao vivo disponível. Estamos dedicando uma quantidade significativa de tempo ao Customizador a cada versão para continuar aprimorando-o, realizando testes de usuário frequentes ao longo do caminho para otimizar a usabilidade.

Halsey prontamente fechou o ticket após essa troca. Acompanhei Shackle para descobrir por que a alternativa proposta para remover o recurso de customize é inadequada para seus propósitos.

“Principalmente, eu esperava que o Personalizador pudesse ser tratado mais como a barra de administração, que possui mais de 3 métodos para desativá-lo”, disse Shackle. “Ter um filtro claramente rotulado é, na minha opinião, mais legível do que modificar as capacidades do usuário. Um desenvolvedor PHP com praticamente nenhum conhecimento de WordPress provavelmente poderia entender muito mais rápido o que está acontecendo com um filtro chamado 'enable_customizer_support' em vez de 'map_meta_cap'.”

Obviamente, nem todos os tickets e patches serão considerados válidos pelos mantenedores dos componentes principais do WordPress, mas Shackle ficou desapontado com a resposta defensiva à discussão.

“Honestamente, se a resposta fosse simplesmente algo como 'Você deveria usar o recurso de customize para obter o mesmo efeito', eu realmente não teria nenhum problema”, disse ele.

“Infelizmente, parece que qualquer abordagem que não seja 'Personalizador para todas as coisas!' significa que eu sou informado várias vezes sobre o desserviço que estou fazendo aos meus clientes e como sou um desenvolvedor preguiçoso por não apenas retreinar meus clientes como gerenciar a aparência de seus sites.

“Parece que a própria equipe do Customizador tem uma abordagem de tudo ou nada para o projeto e que qualquer um que questione isso está errado, independentemente de seu raciocínio”, disse Shackle.

Essa troca demonstra que, como os principais contribuidores veem o personalizador como uma parte importante do futuro do WordPress, esse é um recurso em que haverá pouca vontade de apoiar os esforços para torná-lo mais modular. A desativação do suporte para o personalizador continuará a exigir o uso de 'map_meta_cap', o mesmo método que os criadores do plugin Customizer Remove All Parts empregaram.