Matt Mullenweg, creador de WordPress y líder de Automattic, sugirió dejar de introducir funciones nuevas en WordPress y en su lugar enfocarse en una estrategia centrada en los plugins.
Este reciente enfoque para el futuro de WordPress ha dado lugar a una nueva característica diseñada para que la próxima versión de WordPress se renueve por completo.
Se afirma que los complementos canónicos proporcionan una forma de mejorar continuamente WordPress de manera más eficiente.
Sin embargo, algunos miembros del equipo principal de WordPress señalaron que la experiencia de edición del usuario podría verse afectada.
Texto reformulado: Extensiones estándar
Inicialmente debatido en 2009, los plugins canónicos son una forma de crear nuevas funcionalidades a través de plugins.
El propósito de esta estrategia es conservar la agilidad y eficiencia del núcleo de WordPress, al mismo tiempo que se impulsa la creación de nuevas funciones a través de plugins experimentales.
La descripción original de 2009 la presenta de esta manera:
Los plugins canónicos son aquellos creados por la comunidad, es decir, por varios desarrolladores en lugar de una sola persona, y que satisfacen las demandas de funcionalidad más comunes con un rendimiento excepcional.
El núcleo de WordPress mantenía una estrecha conexión con los plugins, garantizando que estos cumplieran con altos estándares de seguridad y codificación, y que las nuevas versiones de WordPress se probaran con dichos plugins para asegurar su compatibilidad antes de su lanzamiento.
Este método de destacar las características y opciones se denomina también como Plugin First, con el objetivo de resaltar que las características inicialmente se presentarán en forma de plugins.
Estos complementos son denominados “canónicos” ya que son elaborados por el equipo principal de desarrollo de WordPress, a diferencia de los no canónicos, que son creados por terceros y podrían restringir algunas funciones para impulsar la adquisición de una versión de pago.
Una vez que los plugins han demostrado ser populares y esenciales para la mayoría de los usuarios, se contemplaría la posibilidad de incorporarlos directamente en el núcleo de WordPress.
La ventaja de adoptar esta nueva perspectiva en WordPress sería evitar la inclusión de funciones adicionales que podrían resultar innecesarias para la mayoría de los usuarios.
Plugin-first se alinea con la filosofía de WordPress conocida como Decisiones, No Opciones, la cual tiene como objetivo simplificar la experiencia de los usuarios al evitar abrumarlos con configuraciones técnicas.
Al instalar plugins con diversas características y funcionalidades, un usuario podrá evitar tener que lidiar con opciones activas o desactivadas que no son necesarias o comprensibles para él.
La filosofía de diseño de WordPress establece los principios rectores que guían el desarrollo del software.
Debemos como desarrolladores tomar decisiones de diseño conscientes y no cargar a nuestros usuarios finales con las decisiones técnicas.
¿Los enchufes convencionales son el porvenir?
Matt Mullenweg compartió una publicación llamada “Canonical Plugins Revisited”, en la que argumentó que esta es la dirección en la que WordPress debería evolucionar en términos de desarrollo.
Él redactó un mensaje.
Estamos llegando a un punto en el que el núcleo de WordPress debe ser más selectivo y rechazar características adicionales que no son esenciales. La idea es que los equipos vean esto como una oportunidad para influir en el futuro de WordPress a través de un enfoque centrado en los plugins, lo que permitirá ciclos de desarrollo y lanzamiento más rápidos, menos revisión burocrática y una vía más clara para integrar un plugin exitoso en el núcleo del sistema.
La primera consecuencia de esta nueva estrategia es la decisión de no incluir la conversión de imágenes WebP en la siguiente versión de WordPress, la cual se esperaba para noviembre de 2022.
Plugin-First genera controversia.
Hubo discusión en la sección de comentarios sobre la transición a un enfoque de desarrollo del complemento.
Algunos desarrolladores, incluido el principal contribuyente Jon Brown, mostraron dudas sobre la idea de pasar a utilizar plugins canónicos para el desarrollo.
Expresaron su opinión:
El inconveniente persiste debido a la presencia de demasiados complementos complejos en pie, cuando podrían ser una característica opcional sencilla.
Los plugins no son una solución sencilla para la configuración central. Los usuarios primerizos deben encontrar un plugin, luego enfrentan otra pantalla para configurarlo, además de encargarse de las actualizaciones y mantenimiento del mismo.
El comentarista mencionó cómo una función de comentarios ofrecida por múltiples plugins inflados puede resultar en una experiencia de usuario poco satisfactoria.
Expresaron que es mejor contar con un plugin canónico para abordar un problema en lugar de depender de plugins de terceros sobrecargados que contienen las opciones deseadas.
Sin embargo, también expresaron que contar con una configuración integrada en el núcleo, sin depender de un complemento adicional, podría ofrecer una experiencia de usuario más satisfactoria.
Persistieron.
En mi opinión, los plugins básicos son una opción más favorable que los plugins complejos con más de 6 funciones, como los que se encuentran actualmente aquí. Sin embargo, sería beneficioso incluir una casilla de verificación en la configuración principal para esto, lo que ayudaría a abordar los problemas de experiencia de usuario y descubrimiento asociados con los plugins.
En resumen, el comentarista sugirió que la propuesta de utilizar plugins canónicos podría ser una forma de evitar las discusiones sobre las características a considerar, impidiendo así que la conversación tenga lugar.
El uso de “los plugins canónicos” parece ser una estrategia diseñada para desviar las conversaciones, de forma similar a cómo “decisiones no opciones” ha sido utilizada a lo largo de los años.
La declaración final menciona las frustraciones que experimentan ciertos colaboradores clave al no poder incluir opciones para características debido a la filosofía de “decisiones, no opciones”.
Algunos también estuvieron en desacuerdo con la aproximación inicial basada en plugins.
El plugin canónico puede parecer útil, pero incrementará la carga de trabajo de mantenimiento para los usuarios.
En mi punto de vista, no se trata de ir.
Sería preferible incorporar ciertas características fundamentales directamente en el núcleo en lugar de simplemente afirmar que es un buen lugar para el complemento.
Otra persona destacó una posible desventaja del plugin al mencionar que puede resultar complicado recopilar comentarios de los usuarios. De ser así, podría no existir una forma efectiva de mejorar los plugins para satisfacer las necesidades de los usuarios si estas no son conocidas.
Redactaron.
“¿De qué manera podemos mejorar nuestra recepción de las opiniones de los usuarios?”
A menos que los dueños de los sitios estén lo suficientemente informados para mencionar problemas en GitHub o Trac (siendo realistas, nadie reporta problemas de plugins en Trac), es difícil recopilar feedback de los usuarios para mejorar los plugins recomendados u oficiales.
Plugins estándar
El progreso en el desarrollo de WordPress está avanzando para implementar mejoras de manera más ágil. Los comentarios iniciales de los colaboradores apuntan a que existen incertidumbres sobre la eficacia que tendrá este sistema para los usuarios.
Un signo anticipado se verá en lo que sucede con la función WebP que fue cancelada para su integración en el núcleo, y ahora será transformada en un complemento.
Imagen principal proporcionada por Shutterstock/Studio Romantic
