161. Rediseño del Admin, v4

Tras muchos años, se plantea el rediseño por completo del panel de Administración de WordPress, que se convertiría en la cuarta versión.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify, Google Podcasts, Apple Podcasts e iVoox o suscribirte al feed directamente.

Transcripción del programa

Hola, soy Javier Casares y estás escuchando WordPress Pódcast, en el resumen de noticias de la Comunidad WordPress.

En este programa encontrarás la información del 10 al 16 de julio de 2023.

Cuando WordPress comenzó a ser WordPress venía con una interfaz heredada de b2, por lo que no se pensó mucho en el diseño del panel de administración hasta que ya era un proyecto consolidado.

Entre las versiones 2.5 y 2.7 se preparó y lanzó el proyecto Crazyhorse, un diseño evolucionado y con tintes del ya existente, pero con una estructura más parecida a la actual. El panel de administración pasó de un sistema de tan sólo una columna, a la actual de tres con una barra principal de navegación, una zona central de contenidos y una tercera parte de opciones.

El proyecto Crazyhorse se convertía en la segunda gran versión visual de WordPress.

Y la tercera comenzó con la discusión de unos iconos. Sí, cambiar unos iconos en el panel llevó a cambiar todo el panel. Pero en esta ocasión los que se quisieron implicar lo hicieron de una manera distinta.

Después de lo aprendido en la gestión previa, esta vez los cambios se hicieron a través de un plugin llamado MP6, que acabó siendo el nombre del proyecto, y que desde WordPress 3.5 hasta 3.8 tuvo sus idas y venidas, llegando a desarrollarse por primera vez dos versiones de WordPress en paralelo, la 3.7 y la 3.8, en la que finalmente se incluiría el diseño que conocemos en la actualidad.

Y aunque desde hace ya un año que se sabía que la fase 3 incluiría la posibilidad de rediseñar WordPress, e incluso proyectos como WooCommerce ya disponen de una opción para aplicar este diseño, es ahora, con la llegada de la fase 3, que tenemos la propuesta del Admin Design.

El objetivo del nuevo funcionamiento, que básicamente es el que ya tenemos en el Editor del Sitio, es el de extender la navegación a los plugins, pudiendo crear toda una navegación en el menú de forma personalizada para cada plugin sin sobrecargar el menú principal.

Un elemento básico es que el sistema funcione con APIs, de forma que todos los desarrolladores trabajen con una misma tecnología y sea muy sencillo el poder normalizar el diseño de los menús, la navegación y, sobre todo, la experiencia de los usuarios.

Esto, además, mejoraría el pasar de la edición de un elemento a otro sin fisuras, ya sea con elementos nativos o personalizados, ya sea como un usuario o un administrador.

Estamos en los primeros comentarios sobre el nuevo diseño, muy abierto por primera vez y con ganas de que todos los que se quieran implicar lo hagan. Ahora queda esperar a las próximas versiones de Gutenberg donde se comience a incluir esta versión experimental y que los desarrolladores puedan adaptar sus paneles a la nueva interfaz.

Aunque no es lo único que añadirá la fase 3, ya que la Biblioteca de Bloques, algo que se lleva escuchando desde su creación, también puede convertirse en una realidad.

Al igual que gestionamos Temas y Plugins, los Bloques se han convertido en un elemento esencial de un sitio que, se puede gestionar, pero no es nada simple en este momento.

Aunque no sólo el poder activarlos o desactivarlos, ampliar el funcionamiento de los bloques por ejemplo a los tipos de contenido, que cuando selecciones uno de tipo Imagen el bloque por defecto sea una imagen y no un párrafo podría ayudar a recuperar esta funcionalidad que se usa poco y que se podría mejorar.

Aunque quizá hay dos elementos mucho más profundos y útiles. El primero es la posible creación de ficheros theme.json para tipos de contenido, de forma que haya un tema general pero que las especificaciones de las distintas plantillas o listados, como la ficha de autor, las fichas de fecha o los resultados de búsqueda, tengan su propio fichero JSON de configuración.

Y, no nos quedemos ahí. Algo que comenzó a hablarse en la WordCamp Europe fue la posibilidad de enlazar los Custom Fields con los bloques. De esta manera un bloque podría enlazarse con un campo externo y poder modificarse de forma dinámica todo o parte del contenido de este. Incluso, hay opciones más avanzadas de la creación de parte del contenido generado de forma dinámica desde el servidor.

Y, a raíz de la serie de entradas sobre la fase 3, ya se están comenzando a abrir ciertas líneas de trabajo, la primera de ellas sobre la propia colaboración en tiempo real, respondiendo a algunas preguntas como qué tecnología se usará, qué pasa si un usuario está trabajando y se queda sin conexión a Internet. Para todo esto tendremos el Sync Engine, un motor de sincronización que, de forma transparente, se encargará de resolver todos estos conflictos de trabajo del tiempo real.

Y mientras llegan todas estas funcionalidades maravillosas, lo que sí que tenemos en el mundo real es Gutenberg 16.2, que parece ser la última versión que se incluirá en WordPress 6.3.

Esta versión cierra la consolidación de los Patrones y de todos los cambios de estas ultimas versiones, con la inclusión de “Mis Patrones” o de la sincronización de patrones, es decir, los bloques reutilizables.

También veremos las notas al pie de página y el texto con orientación vertical de forma nativa.

Aunque sin duda la noticia más importante de esta versión, y del futuro del Editor, es el inicio del camino para que el Editor Clásico deje de estar disponible. Este camino que iba a comenzarse hace bastantes versiones comienza ahora con la búsqueda de retrocompatibilidad, que podría quedarse simplemente en el Bloque Clásico o con la mejora de la conversión de partes de código HTML a bloques, siempre que sea posible.

Y ya con WordPress 6.3 beta 4 lanzado y a punto de tener disponible la primera versión candidata, a la que se anima a comprobar a todos los desarrolladores de temas y plugins sus componentes, comenzamos a saber algunas cosas de la nueva versión.

Para empezar, el Rollback, que lleva bastante tiempo en pruebas y que se ha aplicado en esta versión. Este sistema, en caso de que una actualización de un plugin o tema falle, automáticamente dejará los ficheros previos a la instalación para mantener el sistema, algo que antes podría llegar a dar error eliminando la extensión.

Esto forma parte de la fase 1 y 2 del sistema, dejando la tercera fase para WordPress 6.4, que incluirá la comprobación de errores además de la propia sustitución de los ficheros.

Otra de las mejoras es sobre la Metadata API que va a incluir un sistema de carga lenta.

Como contexto, la carga lenta de metadatos en WordPress es una técnica en la que los metadatos asociados a varios elementos se cargan sólo cuando son necesarios. En lugar de obtener y cargar todos los metadatos por adelantado, se aplazan a una cola hasta que se solicita el tipo específico de metadatos, lo que reduce las consultas innecesarias a la base de datos o las búsquedas en la caché y mejora el rendimiento general.

Las imágenes van a ver mejoras de rendimiento, que se pueden resumir en dos grandes conceptos:

Ahora se añadirá automáticamente el atributo fetchpriority con un valor «high» a la imagen que determina que es más probable que sea la «imagen LCP», es decir, la imagen que es el elemento de contenido más grande en la ventana gráfica. El atributo indica al navegador que dé prioridad a esta imagen, incluso antes de haber calculado el diseño, lo que suele mejorar el LCP entre un 5 y un 10%.

Por otro lado, se han implementado más ajustes y correcciones para mejorar la gestión automática del loading=”lazy” para ser más fiable cuándo se omite el atributo.

Otros elementos importantes en esta versión son los cambios en el Editor.

Para empezar, tenemos la creación y gestión de los Patrones, que se pueden crear desde el Editor, todo ello en la sección de Patrones que incluye los patrones de los temas, los del Directorio de Patrones y tus patrones, entre los que estarán los sincronizados, o sea, los bloques reutilizables, y los no-sincronizados.

Además, se le suman más de 15 patrones nativos, revisados y mantenidos por la Comunidad WordPress.

Las imágenes también tendrán una pequeña mejora: poder mantener la ratio de aspecto de las mismas, por lo que, si una imagen es cuadrada, podrá seguir siéndolo.

Para aquellos que inyectan scripts a WordPress para su funcionamiento en el frontal, un ticket que llevaba más de 10 años en cola tiene solución: la incorporación de forma nativa del async o defer en los scripts.

Ahora se podrá indicar la carga diferida o asíncrona de los scripts para que ya no bloqueen la carga y por tanto mejoren el rendimiento del funcionamiento de interactividad para los usuarios.

Algunas mejoras también en los sistemas de internacionalización con la incorporación de funciones para pruebas de carga y caché de traducciones, o la carga de traducciones en tiempo real, reduciendo las peticiones.

Donde vamos a ver mucha mejora es en la carga de información de los usuarios. Desde WordPress 6.1 se han ido haciendo mejoras en la caché de otros elementos como los comentarios, información del sitio, o de las taxonomías, y ahora les llega el turno a los usuarios.

Se ha creado un sistema de caché específico sobre la información e los usuarios, que en aquellos sitios que tengan un gran listado, que podrían situarse en más de 1.000, notarán una mejora significativa.

Y otra de las mejoras relacionadas con la caché es la función get_pages() que comienza a usar el sistema nativo de llamadas a la base de datos y que, por tanto, aprovecha toda la potencia de esta función a la hora de preparar y cachear los resultados, con una mejora significativa y que cierra un ticket de hace 13 años.

Y, para facilitar el desarrollo sobre WordPress, se ha lanzado para sitios que no estén en producción la posibilidad de activar un nuevo elemento: el modo desarrollo.

Esta funcionalidad permite indicar si se está desarrollando sobre core, plugin o theme, e incluso all, o sea, todo, y que determinadas funcionalidades se activen o desactiven, como por ejemplo las cachés.

Este sistema es complementario del debug, que muestra más o menos información de errores, o del entorno, que indica el momento en el que se encuentra el sitio.

El equipo de Comunidad ha anunciado los primeros alumnos del Programa de Mentorías que se llevará a cabo durante 4 semanas y que se divide en 2 semanas de formación general, 2 semanas de formación específica en un equipo, y la posibilidad de extender 3 meses con un plan de contribución específico.

El programa parte de 4 perfiles: los alumnos, los mentores, que hacen el seguimiento 1 a 1 del alumno asignado, los representantes de los distintos equipos que forman parte del piloto, y una lista amplia de facilitadores que dan soporte a los alumnos en todo lo que necesiten además de crear conversación.

Además, se ha incorporado en el Handbook de las WordCamp, documentación sobre distintas opciones en la elección de los ponentes de las WordCamp.

Sin duda es algo que queda en manos de la organización, dependiendo de sus objetivos, pero en caso de plantear una WordCamp general, las elecciones en base a personas reconocidas o de manera ciega no siempre dan los mejores resultados, por lo que se han planteado mecanismos de elección variados para una selección más amplia y diversa.

Y en este sentido, desde WordPress como proyecto, tras la WordCamp Europe se ha planteado la creación de un nuevo equipo, tal y como ya pasó con el de Sostenibilidad, en este caso llamado Make Diversity, Equity, Inclusion, and Belonging (“DEIB”), es decir, el equipo de Diversidad, Igualdad, Inclusión y Pertenencia.

El equipo del DEIB tendría entre sus objetivos:

• Una mayor representación de los grupos infrarrepresentados en la comunidad de WordPress, especialmente en puestos de liderazgo.
• Una mayor inclusión, según indiquen las encuestas a la comunidad u otros comentarios.
• Un mayor acceso a oportunidades dentro de la comunidad de WordPress, como oportunidades de formación y educación.
• Y una colaboración efectiva con otros equipos dentro de la comunidad WordPress, como iniciativas o recursos compartidos.

Y, para acabar, ya sabes que tienes todos los enlaces para ampliar la información, en WordPress Pódcast .es.

Un abrazo, y hasta el próximo programa.