¿Llegará la edición completa del sitio a WordPress 5.8? Se avecina una decisión

Ayer, Josepha Haden Chomphosy anunció la hoja de ruta para decidir si Full Site Editing (FSE) aterrizará en WordPress 5.8. Después del lanzamiento de Gutenberg 10.4 el 14 de abril, un pequeño grupo de líderes principales participará en una demostración de go/no go.

Las siguientes personas estarán en la llamada:

• Matias Ventura – Gutenberg Project Lead que será el anfitrión de la demostración.
• Matt Mullenweg – Líder de proyecto de WordPress.
• Helen Hou-Sandi: desarrolladora principal.
• Josepha Haden Chomphosy – Directora Ejecutiva.

La agenda de la reunión es simple. Ventura será el anfitrión de la demostración, y el grupo discutirá y cubrirá las preguntas de implementación.

Si no hay bloqueadores, compartirán un plan para fusionar FSE con WordPress. El resultado más probable es que encuentren al menos algunos elementos que deben abordarse. En ese caso, los compartirán públicamente con un plan para abordarlos antes de una segunda fecha de ida/no salida del 27 de abril.

La primera versión beta de WordPress 5.8 está programada para el 8 de junio, con un lanzamiento público general para el 20 de julio. El equipo debe decidir sobre la inclusión temprano en el ciclo de lanzamiento para que los desarrolladores de temas y complementos tengan tiempo de prepararse.

Si bien muchos están alerta esperando una decisión final, todos deben tener un poco de paciencia en este momento. Todo debe ser sopesado cuidadosamente por los líderes del proyecto. Existe una buena posibilidad de que no sepamos el resultado hasta ese segundo plazo, el 27 de abril.

La mayor parte de la transición de FSE sería una ejecución beta para un subconjunto de usuarios. Incluir estas funciones en el núcleo no significa que WordPress active inmediatamente el interruptor y habilite todo para el 40% de la web. Para la experiencia general de FSE, los usuarios deben elegir explícitamente instalar y activar un tema basado en bloques.

Con eso en mente, la experiencia de incorporación debe ser acogedora que invite a los usuarios a editar el sitio y les informe sobre los posibles problemas. Si se trata de una versión beta integrada, realmente necesitan comprender que se avecinan mejoras.

Una ejecución beta en el núcleo como esta también es bienvenida, dado el lanzamiento del editor de bloques del proyecto hace un par de años. Independientemente de si la gente amaba u odiaba el editor de bloques, la implementación no fue fácil para todos. WordPress colocó a los usuarios finales en un sistema revisado, lo que fue un cambio impactante para muchos. El proyecto tiene la oportunidad de hacerlo mejor esta vez mediante la introducción incremental de funciones a los usuarios y permitiendo que otros se sumerjan en la nueva experiencia de su propia elección.

“El contexto más importante para compartir es que no se envía como la experiencia predeterminada completa para los usuarios ”, escribió Chomphosy en la publicación, señalando que el equipo está creciendo más allá de los errores del pasado. “Uno de los comentarios más claros del proceso de fusión de la Fase Uno fue que no hubo tiempo suficiente para que nuestros extensores (agencias, autores de temas, desarrolladores de complementos, creadores de sitios, etc.) se prepararan para los próximos cambios”.

Los responsables de la toma de decisiones también pueden decidir enviar algunas piezas pero no otras. FSE es un proyecto compuesto por varios componentes.

“Todo el proyecto de edición del sitio completo es una especie de término general para una colección de herramientas y proyectos, por lo que sería posible enviar algunas piezas mientras que otras no”, dijo Haden Chomphosy. "Probablemente haya algunas excepciones a eso, como mencionaste, pero muchos de estos pueden enviarse cuando estén listos".

Las excepciones a las que se refería son componentes que tienen más sentido juntos. Por ejemplo, los temas basados ​​en bloques a través de un archivo de configuración theme.json y la mayoría de los bloques de edición de sitios no son tan útiles cuando están separados.

Por supuesto, hay casos en los que algo como el bloque Consulta podría usarse fuera del editor del sitio. Los usuarios pueden crear consultas personalizadas dentro de una página sin el beneficio del editor del sitio, por ejemplo.

Mi principal preocupación no son las funciones relacionadas con el editor del sitio, sino los widgets basados ​​en bloques. Es una herramienta de transición para usuarios sobre temas tradicionales. Junto con la nueva pantalla de menús de navegación, no forma parte de la experiencia de temas basados ​​en bloques. El objetivo es permitir que los usuarios comiencen a usar bloques en más lugares. Sin embargo, esto resultará en una UX rota en muchos casos.

La experiencia de los widgets todavía está parcialmente rota, tratando cada bloque como un widget separado. Los usuarios deben aprender a colocar un Encabezado (título del widget) y otro bloque (contenido del widget) en un Grupo (envoltura del widget) para las clases correctas relacionadas con el widget en la parte frontal del sitio. Para algunos temas, si los usuarios hacen esto no será un problema. Para otros, se verá feo en el mejor de los casos y romperá el diseño en el peor. Poner esta responsabilidad sobre los hombros de los usuarios finales se consideró una solución aceptable.

Quería centrarme en este problema porque es una de esas cosas que simplemente se pueden activar para todos los usuarios. Todavía tengo miedo de que la transición de un sistema en funcionamiento a uno potencialmente roto sea un viaje lleno de baches.

El equipo de lanzamiento de WordPress 5.6 decidió no enviar widgets basados ​​en bloques. Hou-Sandi, como líder tecnológico central para 5.6, brindó un relato histórico de la decisión y por qué no estaba lista para su inclusión:

Mi pregunta sobre las características que afectan el front-end es "¿puedo probar esta cosa nueva sin la penalización de estropear mi sitio?" — es decir, la confianza del usuario. En este momento, dado que las áreas de widgets no se muestran en nada parecido a lo que ve en su sitio sin que los temas realmente se esfuercen y que tiene que guardar sus cambios en vivo sin revisiones para obtener una vista contextual real, los bloques de área de widgets no permitirle probar esta nueva característica sin penalizarlo por experimentar.

Si bien se puede decir que los widgets han mejorado, sigo viendo que la respuesta es la misma que en octubre pasado. No he visto suficiente aceptación por parte de la comunidad de desarrollo de temas para admitir el editor de bloques en sí, y mucho menos las nuevas características relacionadas con los bloques. Sin embargo, en algún momento, el proyecto simplemente necesita seguir adelante. Los temáticos solo tendrán que mantenerse al día.