Se acerca WordPress 6.1 y hoy hacemos un largo repaso a todas las funcionalidades nuevas que trae… bueno, quizá nos hayamos dejado algunas.
Patrocinador
Hosting WordPress en SiteGround
Enlaces comentados
Joan ha presentado los cursos de estas semanas:
Javier ha comentado cómo le va con sus proyectos:
- Mucha preparación para WordPress 6.1, lo que significa muchas horas dedicadas esta semana al WordPress Podcast y al WordPress Radio.
- Viaje a Madrid al WordPress Day de la Mobile Week de Alcalá de Henares. MUY buen evento organizado por Vidania.
- Agenda de eventos de Javier Casares
Actualidad
Openverse
- Incluir en el núcleo de WordPress (probablemente 6.2) 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.
WordPress 6.0.3 Security Release
- 16 correcciones de seguridad: actualizad LO ANTES POSIBLE.
- Se han aplicado de WordPress 3.7 a WordPress 6.0 (y a WordPress 6.1, para cuando salga).
WordPress 6.1 Versión Candidata 1
- RC2 martes 18
- RC3 martes 25
WordPress 6.1 para desarrolladores
Hoy vamos a explicar CASI todo lo que lleva WordPress 6.1… y no, no estamos en noticias, sino en tema del día porque vamos a estar un rato largo… porque WordPress 6.1 podría ser la versión más importante lanzada desde WordPress 5.0, cuando apareció el Editor de Bloques.
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.
Comenzamos con WordPress Multisite, que ha hecho cambios en el sistema de almacenamiento de metainformación. Ahora la información quedará mucho mejor separada entre lo que es la red y el sitio, con las mejoras correspondientes en llamadas a la base de datos. A esto se le une el almacenamiento del identificador de la red en las opciones de la red, lo que hará que los sitios con WordPress Network también incrementen su rendimiento.
Y hablando de WordPress MultiSite, en este caso WordPress MU, su precursor, hay que tener en cuenta que se han eliminado los Global Terms.
Este sistema venía desde WordPress 3.0, pero dejó de funcionar en WordPress 3.5. Cuando llegó WordPress 4.2 se introdujo el sistema nuevo de términos y que acabó quedando completamente obsoleto con WordPress 4.4 cuando todo el sistema ya tenía sustituto. Ahora, con WordPress 6.1 toda esta tecnología se va a eliminar del núcleo.
Otro de los elementos con mejoras es la REST-API, usada principalmente por sistemas no-code y aplicaciones externas, también ha incluido mejoras de optimización para las respuestas con código de enlaces, o aquellos elementos que se repiten, como podría ser los datos de un mismo autor y que se encuentran en caché.
En cuanto a funcionalidades, vamos a poder buscar contenidos sin saber su ID, incluir o excluir contenidos de un listado, o buscar aquellos contenidos que incluyan un bloque determinado.
Para acabar, se puede activar el modo “bonito” del JSON, para que en vez de devolverse minimizado y en una línea, venga con un formato legible para humanos.
Y si hablamos de mejoras de rendimiento, las cachés se van a convertir en un elemento básico de cualquier instalación de WordPress.
Las principales mejoras se encuentran en la Caché de Objetos con nuevas funciones que afectan principalmente a los temas, además de nuevas funciones como wp_cache_flush_group() que permite limpiar todo un grupo de cachés, o wp_cache_supports() para saber si u plugin o tema soporta determinadas funcionalidades de caché.
Pero no sólo de caché se vive, teniendo mejoras en el Media, con los atributos de imagen decoding=»async», o la carga de lista del Media que podrá estar cacheado.
A nivel de cabeceras HTML, se implementa de forma nativa el uso del rel=’preload’.
Y un cambio importante en el funcionamiento de carga de las páginas lo tenemos en las cabeceras HTTP. Esto va a permitir mejoras en el comportamiento de la caché, poder inyectar cabeceras de precarga o mejoras en redirecciones y la gestión de códigos 300 o 400.
Actualmente las cabeceras se envían justo antes de leer los datos de la URL y la consulta principal de la página. A partir de ahora se hará después de ejecutar la consulta principal, lo que permitiría que dependiendo del resultado de esa consulta se pueda hacer una redirección o solicitar una página de error y actuar en consecuencia.
En referencia al Editor, muchas más novedades. Para la accesibilidad, se va a poder inyectar código ARIA a los bloques que contengan HTML que lo necesite.
Aunque si hemos de ver accesibilidad, los temas 2022 y 2023 ya tienen la etiqueta “accesibility ready”, además de haber incluido 15 mejoras en el panel de administración, mejorado toda la pantalla de login y más de 40 mejoras en el Editor.
Y algo que ha evolucionado desde WordPress 6.0 es la posibilidad de que, al comentar un tipo de contenido nuevo, por defecto en vez de aparecer la página en blanco, se pueda incluir un patrón por defecto. Por ejemplo, si tienes un contenido de tipo coche, al crear un nuevo Coche, no comenzar con el lienzo en blanco sino poder ver un patrón que incluya una cabecera, una foto y Loren Ipsum y un pie de contenido, de forma que el redactor sólo tenga que modificar esa plantilla base.
El bloque de Destacado ya permite el funcionamiento del Duotono en la imagen de fondo y los Enlaces Sociales permiten enlazar a direcciones de correo
También vamos a tener un nuevo tipo de diseño: el diseño restringido. Hasta ahora cuando añadíamos un bloque, este se adaptaba al ancho completo de la ventana, o al ancho de su bloque superior, su contenedor. Ahora tenemos un diseño restringido al que podemos darle un ancho concreto que deberá cumplir por defecto.
Aunque si no te gusta ningún sistema de los que viene, siempre podrás un “disable-layout-styles” y desactivar por completo la funcionalidad en el tema.
Como curiosidad, y que también es una mejora, a partir de ahora tus preferencias en el editor se van a guardar en la base de datos lo que hará que sean consistentes. Esto va a permitir que, al entrar en cualquier dispositivo o navegador, si habías configurado que el Editor se viera con todos los menús activos, vas a seguir teniendo esa configuración en todos y no sólo en el navegador donde se configuró.
Los creadores de formularios están de enhorabuena. Sí, pude parecer raro, pero se han añadido funciones y hooks específicos para aquellos campos en formularios que son obligatorios y que normalmente se marcan con un asterisco.
Y es que los lectores de pantalla no son capaces de leer si un campo es obligatorio o no tal y como funcionaban hasta ahora, así que como una gran mejora de accesibilidad se ha incluido este soporte de forma nativa en el núcleo de WordPress.
En cuanto a los Bloques en general, se han hecho mejoras en el block.json.
Los bloques se van a poder renderizar mediante PHP, indicando la ruta del fichero que ejecutará las acciones cuando se guarde.
Por otro lado, se han separado los scripts en 3 niveles: editar, visualizar y el normal. De esta forma, se ejecutará script distinto según el momento y se podrá reducir el que se necesita para el usuario.
Además, para los desarrolladores que usan boques del núcleo, ya es posible llamarlos por separado y no tener que descargar el uso de todos.
Para los creadores de bloques también vienen novedades con algo que se preguntaba bastante: la creación de estilos. Para esto se ha incluido el Style Engine, el agente responsable de centralizar la generación y render consistente de los estilos de bloques tanto en el servidor como en el cliente.
Reducción de código, nuevas funciones para llamar y procesar los estilos, funciones JavaScript para compilar o acceder a los CSS, y como siempre, retrocompatibilidad. Eso sí, este nuevo sistema por ahora sólo da soporte a bordes, colores, espaciado y tipografía.
Recordemos que se han normalizado las herramientas de estilos en todos los bloques posibles, de forma que prácticamente todos los bloques van a permitir las mismas herramientas de colores, tipografías, espaciados o duotono.
Pero la cosa no queda aquí, ya que también se incluye una estandarización de algunos contenidos del theme.json. En WordPress 6.1 se pueden dar estilos a botones, leyendas, citas y cabeceras.
A esto hay que sumarle los estados interactivos, como el active, focus o hover, que también afectaría a los elementos que hay anidados en los bloques.
Y si hablamos del theme.json una novedad interesante para aquellos que se han preguntado cómo se podrían modificar desde el exterior mediante funciones. Pues ya es posible gracias a varios hooks que permiten el acceso a los datos por defecto, bloques, tema y usuario.
Este sistema, por ejemplo, permitiría desde un plugin o tema añadir una nueva paleta de colores creando una función y añadiendo el filtro correspondiente.
También se han incorporado las referencias al theme.json. Por ejemplo, si quieres que el color de un botón sea el color por defecto, puedes referenciarlo al estilo existente. De esa forma cuando se cambie un color en un sitio, automáticamente se cambiará en el resto.
Y en un nivel bastante avanzado, tenemos algunos cambios en componente internos de WordPress, algunos de ellos ya con fecha de caducidad.
El primero el Popover que prácticamente se ha reescrito; el sistema CustomSelectControl que permite la selección de elementos, y que por defecto usará el 100% del ancho de los elementos padre, y que será ya el estándar en WordPress 6.4.
Para acabar, algunos elementos con márgenes que quedarán obsoletos, y que hacen referencia principalmente a selectores.
Para acabar la ronda de novedades, tenemos los cambios del bloque Query Loop que ya admite variaciones.
Con esto podríamos crear una variación específica para un Custom Post Type de libros en el que se muestren 10, ordenados por novedad descendiente con sólo unas pocas líneas de código, ofreciendo al usuario una plantilla de resultados de contenido con un clic.
A nivel general, algunos cambios que merecen mención:
Las nuevas funciones is_term_publicly_viewable(), para saber si una taxonomía se puede mostrar, o la función did_filter() que devuelve cuántas veces se aplican filtros.
El cambio en la función add_settings_section() que permite pasarle las secciones, antes, durante y después.
Varios nuevos filtros como wp_read_audio_metadata, pre_option, ajax_term_search_results, get_header_image, wp_list_table_class_name, lost_password_html_link, wp_send_new_user_notification_to_admin y wp_send_new_user_notification_to_user.
A los listados de usuarios como wp_list_authors() o wp_list_users() se les va a poder pasar algunos filtros, de forma que no se traiga toda la información sino que puedas pedir los datos que necesitas.
También hay más granularidad en feed_links() y the_posts_pagination().
Además, se ha incluido un nuevo proveedor oEmbed: Pocket Casts.
Y, así a modo general, algunas otras cosas que se han cambiado:
- Los SuperAdministradores pueden crear un Application Password en cualquiera de los sitios.
- La nueva categoría de Pies de Página en los patrones.
- Actualización de librerías externas como PHPMailer, jQuery, Moment o Sodium.
- Permiso para usar en los CSS las funciones min, max, minmax y clamp.
- O el uso de la rotación del EXIF de imágenes.
Todo esto es sólo una parte de lo que viene con WordPress 6.1, y lo que todavía queda por llegar.
Despedida
Nos podéis dejar ideas, posibles temas de los que queréis que hablemos en el pódcast.
Podéis encontrar a Joan Boluda, donde tenéis sus cursos de WordPress, y a Javier Casares, con todos sus proyectos.
Estáis más que invitados a participar a través de la sección de contacto de la web, a través de la que podéis enviar preguntas, dudas, y sugerencias para nuevos episodios.
Puedes suscribirte y escucharnos cada semana en Pocket Casts, Apple Podcasts, Spotify, Google Podcasts e iVoox.
¡Nos vemos el programa que viene con más WordPress!