¿Los widgets basados ​​en bloques están listos para aterrizar en WordPress 5.6?

Hace dos semanas, el equipo de Gutenberg realizó una convocatoria abierta para recibir comentarios sobre los widgets basados ​​en bloques. Ya había escrito una extensa revisión del nuevo sistema a principios de septiembre, pero un miembro del equipo me pidió que compartiera mis pensamientos sobre la iteración más reciente. Con la próxima congelación de WordPress 5.6 Beta 1 a solo una semana de distancia, pensé que no estaría de más hacer otra inmersión profunda.

Como referencia, mi última prueba es con la versión 9.2.0-alpha-172f589 del complemento de Gutenberg, que fue una compilación de hoy. El desarrollo de Gutenberg avanza rápido, pero todo debería ser preciso hasta ese punto.

En última instancia, muchos de los problemas que señalé hace más de un mes aún existen. Sin embargo, el equipo ha solucionado la mayoría de los problemas menores, como apuntar las flechas de abrir/cerrar para las barras laterales (áreas de bloque) en la dirección correcta y hacerlo más consistente con la pantalla de edición posterior. La interfaz de usuario está mucho más pulida.

Antes de sumergirme en todos los problemas, quiero responder la pregunta que propongo. Sí, el sistema de widgets basado en bloques estará listo para el horario de máxima audiencia cuando llegue WordPress 5.6. Todavía no está allí, pero está en un punto en el que hay una línea de meta clara que se puede alcanzar en los próximos dos meses.

Ignoraré la falla de los widgets basados ​​en bloques en el personalizador, que aterrizó en Gutenberg 8.9 y se eliminó en 9.1. También miraré más allá de la propuesta reciente de reconstruir la pantalla de widgets para usar la API Personalizar, al menos por ahora. Hay un montón de problemas que presentan los widgets basados ​​en bloques para el personalizador, y esos problemas son insuperables para WordPress 5.6. A largo plazo, WordPress necesita tener un solo lugar para editar áreas de widgets/bloques. Es probable que los usuarios tengan que vivir con algunas inconsistencias por un tiempo.

Suponiendo que el equipo no intente lanzar un Ave María de última hora e implementar la edición completa de bloques en el personalizador en esta ronda, es seguro decir que los widgets basados ​​en bloques están bien encaminados hacia un debut exitoso de WordPress 5.6.

La experiencia del usuario

Como usuario, realmente disfruto usando la nueva pantalla de administración de Widgets. Las áreas de bloques de forma libre y abiertas crean posibilidades incalculables para diseñar mis sitios de WordPress. Los widgets tradicionales tenían un alcance limitado. Los usuarios estaban atados a un puñado de widgets principales, posiblemente algunos widgets de complemento, y lo que sea que ofreciera el autor de su tema. Sin embargo, con los bloques, el grupo de opciones se expande al menos para triplicar las opciones listas para usar (no estoy contando los bloques de tipo incrustado individualmente). Además, los bloques ofrecen un conjunto mucho más amplio de opciones de diseño que un widget tradicional.

En comparación, los widgets tradicionales están desactualizados. Los bloques son superiores en casi todos los sentidos. Sin embargo, todavía hay problemas con este nuevo sistema.

El mayor problema en este momento es que los usuarios finales pueden salir de la pantalla Widgets sin guardar los cambios. No hay ninguna advertencia para hacerles saber que todo su trabajo está a punto de perderse en el éter. Este es uno de esos elementos de nivel OMGBBQ que deben suceder antes de que se lance WordPress 5.6.

Una característica agradable de tener pero no necesaria sería la capacidad de arrastrar bloques de un área de bloques a otra. En el antiguo sistema de widgets, los usuarios podían mover los widgets de una barra lateral a otra. La alternativa actual es copiar un widget, pegarlo en una nueva área de bloque y eliminar el original.

Tampoco soy partidario de no tener una opción para la barra de herramientas superior, que está disponible en la pantalla de edición posterior. Una de las razones para usar esta barra de herramientas es que no me gusta la barra de herramientas emergente predeterminada en bloques individuales. Me distrae y a menudo se interpone en mi trabajo.

Los widgets heredados parecen ser todavía un trabajo en progreso. A veces, el bloque Legacy Widget no me funcionaba en absoluto. Entonces, mágicamente comenzó a funcionar. Sin embargo, Gutenberg ahora agrega automáticamente widgets de terceros registrados al insertador de bloques como si fueran bloques.

Esto presentó sus propios problemas. La única forma en que logré hacer que los widgets de complementos de terceros funcionaran fue insertar el widget, guardar y actualizar la pantalla de widgets. En ese momento, aparecieron los widgets y se volvieron editables.

La experiencia del autor del tema

Una de mis mayores preocupaciones para los autores de temas en este momento es que no parece haber ninguna documentación en el manual del editor de bloques. Hay mucho tiempo para que eso suceda, pero hay cosas que los autores de temas deben tener en cuenta. Tener una ubicación centralizada, incluso mientras la función está en desarrollo, les ayudaría a prepararse para la versión 5.6.

Algunas de estas preguntas, que pueden responderse en varias publicaciones del blog Make, deberían existir en una página de documentación dedicada:

• ¿Cómo puede un tema optar por no usar widgets basados ​​en bloques?
• ¿Cuáles son los ganchos para agregar estilos personalizados para la pantalla Widgets?
• ¿Pueden los temas apuntar a estilos de barra lateral específicos en la pantalla Widgets?
• ¿Es posible diseñar secciones de manera consistente como widgets tradicionales en la interfaz?
• ¿Pueden los temas optar por una alineación amplia y completa dentro de las áreas de bloque, que esencialmente podrían usarse de manera similar al área de contenido de la publicación?

Estas son algunas de las preguntas que me gustaría que me respondieran como ex autor de temas. Ya no estoy en el meollo del juego de diseño de temas y supongo que aquellos que lo están tendrán una lista más grande de preguntas.

Una parte menos obvia de la documentación debe centrarse en cómo manejar las funciones de respaldo o los widgets predeterminados. Tradicionalmente, los temas que necesitaban mostrar un conjunto predeterminado de widgets verificaban si la barra lateral tiene widgets y recurrían al uso de the_widget() para generar uno o más valores predeterminados. Si bien los autores de temas todavía pueden hacer eso, deberíamos comenzar a hacer la transición de manera general al sistema de bloques.

¿Deberían los autores de temas copiar/pegar el bloque HTML como alternativa? ¿Sería mejor el sistema de contenido de inicio para esto, y el contenido del widget de inicio puede manejar bloques? ¿Cuál es el método recomendado para la recuperación de widgets en WordPress 5.6?

Todavía existe el problema actual de cómo los autores de temas deben manejar el widget tradicional y el contenedor HTML del título del widget en el nuevo paradigma de bloques. Un parche agregado desde el lanzamiento de Gutenberg 9.1 envuelve cada bloque de nivel superior con el contenedor de widgets. Si esto llega a la versión 9.2, es probable que empeore el problema.

En el sistema tradicional, tanto el título como el contenido del widget se envuelven juntos dentro de un contenedor. Sin embargo, si un usuario agrega un bloque de encabezado (título del widget) y otro bloque (contenido del widget), cada bloque se envuelve por separado con los envoltorios del widget del tema. La única forma de rectificar la situación tal como está es que los usuarios finales agreguen un bloque de grupo para cada "widget" que deseen, lo que requeriría una gran cantidad de reeducación para los usuarios de WordPress. No es un escenario ideal.

En lugar de intentar "arreglar" directamente este problema, WordPress no debería hacer nada con la salida. Los bloques y los widgets tradicionales son fundamentalmente diferentes.

Deje que los autores de temas tomen las riendas de este y exploren las posibilidades. Sin embargo, bríndeles las herramientas para hacerlo, como patrones de bloques compatibles.