Filtro para deshabilitar el personalizador derribado en WordPress Trac

WordPress 4.3 introducirá la gestión de menús a través del personalizador, proporcionando vistas previas en vivo en la interfaz para agregar, eliminar y ordenar elementos del menú. Aunque los usuarios aún tienen la opción de administrar los menús usando la interfaz de administración, los desarrolladores que no están interesados ​​​​en la función están buscando una manera fácil de deshabilitar el personalizador y eliminar sus enlaces en WordPress.

En ciertos escenarios que involucran el trabajo del cliente, el personalizador puede ser más problemático de lo que vale y puede no ser una adición beneficiosa para un administrador de WordPress personalizado.

@pollyplummer muy interesante. No estoy en contra de las nuevas actualizaciones, pero el personalizador es un infierno en el mundo de las agencias.

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

Gabe Shackle, desarrollador de aplicaciones e ingeniero de interfaz de usuario en Risdall, creó un ticket en el trac de WordPress la semana pasada, solicitando un filtro para desactivar el personalizador. Su parche ofrece a los desarrolladores una manera fácil de habilitar la clase 'no-customizer-support' dentro de la etiqueta del cuerpo.

Debido al hecho de que la clase 'customizer-support' se agrega a través de JavaScript en el procesamiento de la página, actualmente no se puede manipular con ningún filtro o acción principal.

Al establecer el valor del filtro en falso, el personalizador se oculta esencialmente para el administrador y los enlaces que apuntaban actualmente al personalizador (widgets, temas, etc.) se revierten a sus destinos de panel anteriores.

Actualmente, los desarrolladores que desean deshabilitar el personalizador deben emplear una combinación de diferentes métodos para eliminar de manera efectiva todo lo que el personalizador introduce en el administrador.

“Este filtro convierte este proceso en un filtro booleano simple para que los desarrolladores que no quieren o no necesitan el Personalizador puedan eliminarlo fácilmente”, dijo Shackle.

El desarrollador principal de WordPress, Dion Hulse, respondió al ticket para decir que, aunque él mismo no usa mucho el personalizador, no cree que los usuarios de WordPress se beneficien de una manera fácil de desactivarlo.

Personalmente, aunque no uso el personalizador mucho tiempo, creo que ofrecer un filtro para deshabilitarlo probablemente no sea lo mejor para los usuarios de WordPress.

El personalizador, por mucho que a algunos no les guste, es un componente importante del futuro de WordPress UX; si eso es algo bueno o malo, aún está por verse para algunos, pero les guste o no, está aquí.

Hulse sugirió, como alternativa, que una mejor manera de desactivarlo sería eliminar la capacidad de customize de los roles.

Shackle explicó además que estaba intentando seguir el precedente de la barra de administración, que considera un tipo similar de componente UX.

“La barra de administración se puede deshabilitar no solo mediante un filtro, sino también mediante una variable global, una función central y una configuración de perfil de usuario”, dijo. “El Personalizador no tiene ninguna de estas opciones”.

Nick Halsey, el desarrollador del complemento Menu Customizer que se está fusionando en 4.3, respondió basándose en suposiciones sobre por qué Shackle podría solicitar un filtro para deshabilitar la función:

Todavía tengo que ver una razón válida para algo como esto. En la mayoría de los casos, las preocupaciones acerca de no querer que los usuarios tengan acceso al Personalizador surgen del hecho de que no les está dando las capacidades adecuadas. Y la capacidad de personalización se puede utilizar para desactivar el Personalizador si realmente es necesario.

Si bien puede eliminar la metacapacidad de personalización (o reasignarla o lo que sea), hacerlo simplemente porque no desea capacitar a los usuarios o no desea utilizar el Personalizador le está perjudicando a usted y a sus usuarios. Como mencionó dd32, el Personalizador seguirá creciendo en importancia dentro de WordPress. Además, las pruebas de los usuarios han demostrado que la experiencia del Personalizador es generalmente más fácil de entender para los usuarios que para el administrador, lo que se deriva en gran medida del valor de tener disponible la vista previa en vivo. Estamos invirtiendo una cantidad significativa de tiempo en el Personalizador en cada versión para continuar mejorándolo, realizando frecuentes pruebas de usuario en el camino para optimizar la usabilidad.

Halsey cerró rápidamente el boleto luego de este intercambio. Seguí con Shackle para averiguar por qué la alternativa propuesta para eliminar la capacidad de customize es inadecuada para sus propósitos.

“Sobre todo esperaba que el Personalizador pudiera tratarse más como la barra de administración, que tiene más de 3 métodos para desactivarlo”, dijo Shackle. “Tener un filtro claramente etiquetado es, en mi opinión, más legible que modificar las capacidades del usuario. Un desarrollador de PHP sin prácticamente ningún conocimiento de WordPress probablemente podría entender mucho más rápido lo que sucede con un filtro llamado 'enable_customizer_support' en lugar de 'map_meta_cap'".

Obviamente, no todos los tickets y parches serán considerados válidos por los mantenedores de los componentes principales de WordPress, pero Shackle se sintió decepcionado por la respuesta defensiva a la discusión.

“Honestamente, si la respuesta hubiera sido simplemente algo como 'Deberías usar la capacidad de customize para lograr el mismo efecto', realmente no habría tenido ningún problema”, dijo.

“Desafortunadamente, parece cualquier enfoque que no sea '¡Personalizador para todas las cosas!' significa que me dicen varias veces cuánto daño estoy haciendo a mis clientes y qué desarrollador perezoso soy por no solo volver a capacitar a mis clientes sobre cómo administrar la apariencia de sus sitios.

“Parece que el propio equipo de Customizer tiene un enfoque de todo o nada para el proyecto y que cualquiera que cuestione esto está equivocado, independientemente de su razonamiento”, dijo Shackle.

Este intercambio demuestra que, dado que los colaboradores principales ven el personalizador como una parte importante del futuro de WordPress, esta es una característica en la que habrá poca voluntad de apoyar los esfuerzos para que sea más modular. Deshabilitar la compatibilidad con el personalizador seguirá requiriendo el uso de 'map_meta_cap', el mismo método que han empleado los creadores del complemento Remover todas las partes del personalizador.