116. Cosas que aún no sabíamos de WordPress 6.1

Se acerca el momento de la primera versión candidata de WordPress 6.1 y comienzan a salir a la luz aquellas cosas menos visibles, lo que no es de Gutenberg o del Editor y que tiene mucho que ver con mejorar el rendimiento.

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 Podcast, el resumen de noticias de la Comunidad WordPress. En este programa encontrarás la información del 3 al 9 de octubre de 2022.

Comenzamos un programa más con una sesión de “cosas que aún no sabíamos de WordPress 6.1 y que te van a interesar”.

Comenzamos con el comportamiento del Bloque de Navegación, que va a tener comportamientos retroactivos para según que casos. Si un bloque de navegación está construido con las nuevas tecnologías de bloques, es decir, incluye bloques internos, el sistema hará su trabajo normal. Pero si un bloque de navegación está vacío, o viene heredado de uno clásico, el sistema lo entenderá y se comportará como tal. Si i siquiera existe ningún menú de navegación, el sistema creará de forma automática un listado de las páginas de navegación, como ya ocurría previamente. ¿Qué pasa si hay varios menús? El sistema tomará el último menú creado.

Y siguiendo con la retrocompatibilidad, los temas clásicos van a poder usar las template parts, o partes de plantilla. Esto va a permitir que en 3 pasos un desarrollador de temas clásicos permita el uso de bloques en su diseño.

Lo primero será activar la funcionalidad, después crear las partes de plantilla, por ejemplo, un pie de página, sustituyendo el código habitual del tema, por una parte hecha con bloques. Para acabar, en donde tenga que mostrarse, se cargará con la función correspondiente.

A parir de ese momento, el usuario podrá entrar en la zona del Editor y cambiar todo el pie de página a su gusto.

Otra de las novedades es la mejora del Salud del Sitio con información de la caché de objetos y de página.

Por un lado, la información sobre Caché de Objetos te informará si existe y está disponible, y si es recomendable usarla o no según las necesidades de WordPress.

El sistema de Caché de Página también te muestra si el sitio la está utilizando, si es óptima o si debería usarla.

Y aunque los plugins ya le dieron soporte, ahora llega el turno a permitir la cabecera de Update URI en los themes, en la que se puede indicar la URL oficial del tema.

De esta manera, si existen dos temas que se llaman igual, una en el repositorio y otra en cualquier otro lugar de Internet que permita su descarga, al ser lugares distintos, aunque tengan un mismo nombre, se considerarán temas distintos y no se sustituirá el tema externo con un tema que se llame igual y se encuentre en el repositorio de WordPress.

Una de las grandes mejoras, que podría reducir hasta un 50% el consumo de recursos del servidor de base de datos, son las nuevas mejoras en la caché de la función WP_Query, que básicamente es la función principal de llamada a la base de datos.

Por defecto las consultas se cachearán, aunque se han añadido métodos para que esto no ocurra si el desarrollador así lo requiere.

Si sois desarrolladores de bloques y los incluís usando el sistema de registro, se ha trabajado en una serie de mejoras para que la carga funcione mucho más rápida, lo que beneficiará a todos los que tengan plugins o temas que incluyan sus propios bloques.

Hasta ahora el sistema escaneaba una serie de carpetas, cargaba todos los elementos, y PHP los procesaba.

Con el nuevo sistema se puede registrar directamente los ficheros para saber donde está la información, se ha mejorado el sistema de lectura de los JSON y se ha añadido el registro del bloquea a la caché de WordPress, lo que significa que la carga será mucho menor.

En WordPress 6.1 se incorpora el funcionamiento completo de los espaciados y esto hace que los usuarios puedan establecer los valores que quieran, y eso es algo que puede provocar desastres.

Así que se han creado las escalas de espaciado. Este sistema, en vez de mostrar la típica barra de 0 a 100, mostrará una serie de pequeños pasos para que existan una serie de datos ya prefabricados. En vez de que el usuario elija 27, se podrán crear unos de 2, 5, 10, 25, 50, 75 y 100, por ejemplo, dándole la oportunidad al usuario de elegir unos valores que tengan cierto sentido desde el punto de vista del diseñador del tema.

En la parte de seguridad, se han hecho unos cambios en la función prepare() de la base de datos. Esta función es a la que hay que llamar antes de ejecutar una consulta y permite la sustitución de placeholders por variables para que el sistema se encargue de corregir posibles inyecciones SQL.

Ahora se ha creado el %i (porcentaje i) creado específicamente para el nombre de campos y tablas, reduciendo las expresiones regulares y mejorando el rendimiento de todas las consultas.

Y, una semana más, tenemos ya WordPress 6.1 beta 3, con la expectativa de que el ciclo de versiones candidatas comience este 11 de octubre. Esto significa que empieza el periodo de pruebas final con una versión disponible ya para probar en entonos de prueba y finalizar las traducciones de las cadenas pendientes.

Si todo sigue su curso, el próximo martes 1 de noviembre tendremos la versión general de WordPress 6.1 y comenzará el ciclo de desarrollo de las versiones menores y de WordPress 6.2, que podría llegar alrededor de finales de febrero.

El equipo de Documentación ha acabado la segunda revisión en el proyecto de Reclasificación de la Documentación para Usuarios finales.

Finalmente, la documentación se organizará en distintos grupos:

• Sobre WordPress
• Guías técnicas
• Guías de soporte
• Personalización

La documentación más técnica se moverá al Advanced Administration Handbook.

Los próximos pasos de Openverse están bastante claros: mejorar la documentación, eliminar el iframe, que es un proyecto que ya está muy avanzado, y preparar la integración del proyecto dentro del núcleo de WordPress a través de una serie de bloques de Gutenberg.

Esto último ya tiene un ticket por parte del equipo de Gutenberg, con algunos cambios importantes. Actualmente el “inserter” tiene una pestaña para Bloques, otra de Patrones y una de Bloques Reutilizables. Esto podría cambiar por Bloques, Patrones y Media.

En el caso de la nueva pestaña de Media nos encontraríamos con 4 opciones: Imágenes, Audio, Vídeo y Openverse, en la que encontraríamos integrado un pequeño buscador que nos mostraría una previsualización de los contenidos directamente en el Editor, integrando todo este nuevo proyecto dentro de la fase 2 de personalización de Gutenberg.

El equipo de Comunidad está planteando la instalación y uso de Freescout, como plataforma de ticketing y control del correo para las WordCamp. Habitualmente se hacía una redirección a una cuenta de Google en la que todo el mundo entraba, y por temas de seguridad era más complejo. Este sistema podría facilitar la comunicación entre los organizadores de WordCamp, asistentes, patrocinadores y, en el fondo, cualquiera que quiera ponerse en contacto.

Está muy claro: BuddyPress necesita un nuevo theme, y eso es lo que se va a acabar haciendo. Gracias a los pasos previos como el de BP Rewrites esto será posible, y ya hay quien se ha ofrecido a preparar el nuevo diseño.

Y es que el próximo 19 de octubre está previsto el lanzamiento de la primera versión beta de BuddyPress 11.0 en la que se integrará BP Attachments, como una librería Media gestionada desde el frontal, y el Activity block, que permitirá a los usuarios ver toda su actividad en la red de forma centralizada.

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

Un abrazo, y hasta el próximo programa.