El lanzamiento de WordPress 7.1 está previsto para el 19 de agosto y promete ser una actualización muy interesante para desarrolladores, profesionales, agencias y blogueros de todo el ecosistema.
Esta segunda gran actualización del año trae un montón de funcionalidades que abarcan casi todos los aspectos del CMS. De entre todas las nuevas funcionalidades, la que más nos entusiasma es el procesamiento de archivos multimedia del lado del cliente. La razón es que en Kinsta nos apasiona el rendimiento web y la velocidad de los sitios, y esta nueva arquitectura multimedia supone un gran paso adelante: ofrece mejoras notables en la eficiencia del servidor y tiempos de carga de página más rápidos.
Además de las mejoras en la gestión de archivos multimedia, WordPress 7.1 trae novedades importantes para la colaboración en equipo, como nuevas funcionalidades de Notas, así como varias mejoras en la interfaz de usuario del panel de administración —por ejemplo, una barra de administración permanente y la nueva pantalla Identidad en el Editor del Sitio—. Esta versión incluye bloques nuevos y mejorados, herramientas de diseño ampliadas y un amplio abanico de actualizaciones para desarrolladores.
¿Quieres descubrir qué nos depara el futuro? Vamos a profundizar en WordPress 7.1.
Procesamiento de archivos multimedia del lado del cliente
Hasta WordPress 7.0, la generación de las dimensiones de las imágenes y las miniaturas para mostrarlas en la interfaz de usuario, la conversión de formatos y la gestión de la rotación de las imágenes se gestionaban totalmente en el servidor mediante PHP.
Ahora, WordPress 7.1 presenta una nueva arquitectura de procesamiento de archivos multimedia: el cambio de tamaño de las imágenes, la conversión de formatos, la rotación de datos EXIF y la generación de miniaturas ahora se realizan del lado del cliente, directamente en el navegador del usuario.
Este cambio debería mejorar significativamente el rendimiento del sitio y reducir el consumo de recursos del servidor.
Echemos un vistazo más de cerca a los cambios en el procesamiento de imágenes:
1. ¿Qué es el procesamiento de archivos multimedia del lado del cliente?
Mientras que antes las imágenes se procesaban en el servidor mediante PHP utilizando las bibliotecas GD o Imagick, ahora la generación de imágenes en distintos tamaños, la conversión de formatos y la rotación EXIF se realizan directamente en el navegador del usuario, siempre que este admita el encabezado Document-Isolation-Policy (DIP) para permitir el acceso a SharedArrayBuffer.
Como el procesamiento se realiza en el navegador, WordPress ya no recibe solo una imagen, sino todos los archivos de imagen resultantes del pipeline de procesamiento. Esto tiene dos consecuencias principales: un menor uso de la CPU y la RAM del servidor, y más solicitudes HTTP para subir las miniaturas individuales.
En el momento de escribir esto, solo Chrome 137+ y Microsoft Edge 137+ (versión de escritorio) son totalmente soportados por Document-Isolation-Policy. Safari y Firefox no admiten la pipeline WASM, aunque Safari sí permite la decodificación nativa de los formatos HEIC/HEIF a JPG.
2. ¿Cuáles son las funcionalidades técnicas del procesamiento de medios del lado del cliente?
Desde el punto de vista de la arquitectura, el procesamiento de medios del lado del cliente se gestiona a través de tres paquetes principales:
- El nuevo paquete
@wordpress/vipsgestiona el procesamiento del lado del cliente utilizando la bibliotecalibvipscompilada en WebAssembly (wasm-vips). Considerada por muchos como una de las bibliotecas de procesamiento de imágenes más rápidas y eficientes que hay, se ejecuta en paralelo dentro de un Web Worker, lo que evita que la interfaz de usuario se cuelgue y ofrece un rendimiento mucho mejor que el JavaScript puro. - El paquete
@wordpress/upload-mediacoordina el proceso de subida, lo que incluye la gestión de colas de subida, la concurrencia en las subidas (hasta 5 subidas simultáneas y 2 operaciones de procesamiento de imágenes), los reintentos automáticos, la reanudación de subidas interrumpidas y la compatibilidad sin conexión. - El paquete
@wordpress/media-utilsse encarga del transporte HTTP y de las solicitudes a la API REST.
Además del procesamiento de imágenes, esta nueva funcionalidad permite convertir automáticamente GIF animados en vídeos MP4/WebM. La conversión la lleva a cabo el nuevo paquete @wordpress/video-conversion, que integra la biblioteca mediabunny en un Web Worker para convertir GIF opacos (sin fondos transparentes) en archivos de vídeo ligeros.
El procesamiento de archivos multimedia del lado del cliente también introduce nuevos endpoints de la API REST (sideload, finalize y replace_file), junto con dos nuevos parámetros: generate_sub_sizes y convert_format.
3. ¿Qué ventajas tiene esto para los usuarios de WordPress?
El procesamiento de archivos multimedia en el lado del cliente traslada el procesamiento de imágenes del servidor al cliente. Esto libera al servidor de la pesada carga de trabajo que supone generar miniaturas en distintos tamaños, rotar imágenes y convertir formatos, trasladando esa tarea directamente al navegador del usuario.
Estas son algunas de las ventajas para los usuarios de trasladar el procesamiento de archivos multimedia al cliente:
- Menos errores de falta de memoria en PHP: El procesamiento de archivos multimedia del lado del cliente elimina los errores por agotamiento de memoria (
Se ha superado el límite de memoria de PHP) que antes se producían al procesar archivos de imagen de gran tamaño. - Menor consumo de CPU y RAM: Otra gran ventaja para el servidor es la reducción sustancial del uso de la CPU y la RAM del servidor, lo que libera recursos para otras tareas.
- Mejor rendimiento del sitio: La biblioteca
libvipsutiliza algoritmos de compresión avanzados que generan imágenes que, de media, son un 15 % más pequeñas que las generadas por GD o Imagick. Esto se traduce en imágenes más ligeras y tiempos de carga de página más rápidos. - Mayor fiabilidad en la subida de archivos: Cada subida de imagen requiere una solicitud HTTP independiente. Esto genera un mayor volumen de solicitudes HTTP, pero garantiza que cada imagen se procese de forma independiente. Las solicitudes fallidas se pausan automáticamente y se vuelven a intentar.
Además, los GIF animados se pueden convertir automáticamente en vídeos de reproducción automática más eficientes; las fotos HEIC subidas desde un iPhone pueden ser convertidas a JPG por el navegador antes de subirlas (evitando posibles problemas de compatibilidad con el servidor); y la compatibilidad con AVIF ahora funciona incluso sin que el servidor soporte este formato (se omite la comprobación del tipo MIME para las subidas decodificadas por el cliente).
4. ¿Qué cambia para los desarrolladores?
Los desarrolladores pueden desactivar el procesamiento de archivos multimedia del lado del cliente usando el nuevo filtro wp_client_side_media_processing_enabled. Aquí tienes un ejemplo:
add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );Aparte de esto, no hay cambios importantes para los desarrolladores de plugins. Los hooks relacionados con el procesamiento de archivos multimedia siguen activándose igual que si las imágenes se procesaran en el servidor.
Los filtros existentes leen la configuración del servidor y siguen funcionando como se espera. Por ejemplo, el filtro wp_generate_attachment_metadata se ejecuta dos veces: primero durante la subida inicial (create) y una segunda vez después de que se llame al endpoint de finalización (update). Los plugins que usen este filtro seguirán funcionando como se espera.
Para los desarrolladores de temas, los tamaños de imagen registrados mediante add_image_size() ahora se generan del lado del cliente. Si un tema define un tamaño de imagen con dimensiones idénticas a las de un tamaño predeterminado de WordPress, las imágenes se «deduplican» en un único archivo de imagen registrado con ambos nombres de tamaño.
5. ¿Qué ventajas tiene para la seguridad?
Aunque el procesamiento de medios del lado del cliente está diseñado principalmente para mejorar el rendimiento y la eficiencia, más que para la seguridad, ofrece varias ventajas que refuerzan la seguridad de los sitios de WordPress.
En primer lugar, reduce la superficie de ataque. Como ya se ha mencionado, antes de WordPress 7.1, el procesamiento de imágenes se basaba en bibliotecas del lado del servidor, como GD e Imagick. Con el tiempo, estas bibliotecas se han visto afectadas por diversas vulnerabilidades de seguridad relacionadas con la decodificación de imágenes.
Con el procesamiento de imágenes del lado del cliente, el servidor ya no necesita GD ni Imagick, ya que recibe imágenes preprocesadas. Esto reduce significativamente la cantidad de código sensible que se ejecuta en el servidor.
Otra ventaja de seguridad es que el procesamiento de imágenes se lleva a cabo dentro de un entorno aislado del navegador, utilizando WebAssembly en un Web Worker.
El procesamiento del lado del cliente también reduce el riesgo de ataques de denegación de servicio (DoS), ya que la carga computacional recae en el cliente.
Para procesar imágenes en el cliente, WordPress utiliza SharedArrayBuffer, un objeto de JavaScript que permite que el hilo principal y los Workers compartan el mismo espacio de memoria.
Para permitir el acceso a SharedArrayBuffer, WordPress habilita el encabezado Document-Isolation-Policy: isolate-and-credentialless. Esto proporciona un contexto de ejecución aislado para el editor de bloques en los navegadores con Chromium 137 o superior (Chrome 137 o superior y Edge 137 o superior).
En resumen, aunque el objetivo principal del procesamiento de archivos multimedia del lado del cliente es mejorar el rendimiento y la eficiencia en la gestión de archivos multimedia, esta nueva funcionalidad también aporta importantes mejoras en materia de seguridad.
6. Recursos oficiales
El procesamiento de medios del lado del cliente se ha documentado ampliamente tanto para usuarios como para desarrolladores. Echa un vistazo a los siguientes recursos para conocer los detalles:
- Procesamiento de medios del lado del cliente en WordPress 7.1 (nota de desarrollo)
- Arquitectura del procesamiento de archivos multimedia del lado del cliente (Manual del Editor de Bloques)
- Procesamiento de archivos multimedia del lado del cliente (Guías Prácticas)
- Filtros y parámetros de procesamiento de medios del lado del cliente (Referencia de Hooks)
Mejoras en las Notas
Las Notas, que se introdujeron por primera vez en WordPress 6.9, han recibido numerosas novedades y mejoras que las convierten en una herramienta de colaboración más completa.
Para empezar, WordPress 7.1 añade compatibilidad con texto enriquecido en las notas, lo que las hace «más expresivas, más fáciles de leer y más acordes con lo que los usuarios esperan de herramientas como Google Docs, Figma, GitHub y otros editores colaborativos».
Esto incluye el formato básico en el texto, como negrita (Ctrl/⌘ + B), cursiva (Ctrl/⌘ + I), enlaces (Ctrl/⌘ + K) y emojis.
Ahora puedes añadir notas inline seleccionando fragmentos de texto en lugar de solo un bloque completo (comentarios inline en bloques). También puedes añadir varias notas al mismo bloque o a la misma selección de texto.
WordPress 7.1 también introduce las @menciones para etiquetar a tus colaboradores en las notas, lo que hace que la funcionalidad de las notas se parezca más a la de las herramientas de colaboración más populares. Cuando escribes el carácter @, aparece un panel con una lista de los usuarios de tu sitio para que puedas seleccionarlos fácilmente. El destinatario de la mención recibirá una notificación por correo electrónico con un enlace a la entrada.
Otra novedad tiene que ver con la parte visible de las notas. Ahora, las notas largas se ocultan por defecto para que no ocupen demasiado espacio en la pantalla. Un botón de Mostrar más/Mostrar menos te permite mostrar u ocultar el texto completo.
Puedes ver la lista completa de las nuevas funcionalidades para Notas que vienen con WordPress 7.1 en la versión de Notas para WordPress 7.1.
Mejoras en la interfaz de usuario de administración
La interfaz de usuario de administración recibe varias actualizaciones que mejoran la coherencia de la interfaz y simplifican la navegación entre pantallas.
Barra de administración persistente en el editor de entradas y en el Editor del Sitio
Antes de WordPress 7.1, la barra de administración no aparecía en el editor de entradas ni en el Editor del Sitio. Este comportamiento era un poco raro, ya que la barra de herramientas de administración es el elemento más usado de la interfaz de administración, y no mostrarla en los editores no se consideraba lo mejor. A partir de WordPress 7.1, esto cambia, y ahora la barra de herramientas de administración está visible en el editor de entradas y en el Editor del Sitio.
El esquema de colores del usuario se ha ampliado al Editor del Sitio
Otra mejora destinada a dar un aspecto uniforme a todas las áreas de administración consiste en aplicar la misma combinación de colores que el usuario haya elegido en su página de configuración también al Editor del Sitio. Antes de la versión 7.1, la barra lateral del Editor del sitio tenía un color fijo: negro.
La barra lateral del editor también se ha actualizado con WordPress 7.1. Se ha eliminado el icono del sitio de la barra de herramientas del editor y ahora aparece en la barra de herramientas de WordPress.
En versiones anteriores, para volver al panel de administración de WordPress, tenías que hacer clic en el icono del sitio, que técnicamente no era un botón para volver atrás.
Por eso, el icono del sitio ahora solo aparece en la barra de herramientas de administración, mientras que en la barra de herramientas del editor aparece un botón más claro para volver atrás.
Categorías de comandos y interfaz de usuario mejorada de la paleta de comandos
La paleta de comandos ha recibido varias novedades y modificaciones para mejorar su facilidad de uso. Para empezar, los comandos disponibles se han dividido en secciones (recientes, sugerencias y resultados) para que sea más fácil encontrarlos.
Se ha ajustado el tamaño de la ventana modal (512 píxeles) y ahora los comandos se leen mejor.
Pantalla Identidad en el Editor del Sitio
Ahora aparece una nueva opción llamada Identidad en el menú Diseño del Editor del sitio. La pantalla correspondiente te permite configurar el título, el eslogan, el logotipo y el icono de tu sitio. Así podrás editar la configuración de identidad de tu sitio sin salir del Editor del sitio.
Desplazamiento infinito para la vista cuadrícula de la Biblioteca Multimedia
Hasta WordPress 7.0, se podía activar el desplazamiento infinito en la vista cuadrícula de la Biblioteca Multimedia mediante el filtro media_library_infinite_scrolling, que venía configurado en false por defecto. Los desarrolladores podían cambiar la configuración predeterminada añadiendo la siguiente línea a sus plugins:
add_filter( 'media_library_infinite_scrolling', '__return_true' );A partir de WordPress 7.1, el filtro media_library_infinite_scrolling está configurado en true, lo que significa que el desplazamiento infinito en la vista de cuadrícula de la biblioteca multimedia está activado por defecto para todos los usuarios.
Además, hay una nueva opción en la página de perfil de usuario del panel de administración de WordPress que te permite configurar tus preferencias de desplazamiento infinito.
WordPress guarda la elección del usuario en las opciones de usuario mediante la clave meta infinite_scrolling. Puedes recuperar la preferencia del usuario de esta forma:
$infinite_scrolling = get_user_option( 'infinite_scrolling', $user_id );Bloques principales y mejoras en los bloques
WordPress 7.1 introduce dos nuevos bloques y varias mejoras en los ya existentes.
Nuevos bloques de Listas de Reproducción y Pestañas
Un nuevo bloque de Lista de reproducción te permite insertar una lista de reproducción sencilla en tu contenido.
Puedes personalizar varios aspectos del aspecto del bloque, como la tipografía, el fondo, las dimensiones, el borde y los elementos. Entre los controles de estilo específicos de este bloque están Forma de onda y botón de reproducción y Fondo de la forma de onda. El control Forma te permite cambiar la visualización de audio con forma de onda.
El bloque Lista de Reproducción admite todos los archivos de audio compatibles con tu instalación de WordPress. Si añades compatibilidad con un nuevo tipo MIME, el bloque lo hereda automáticamente.
El nuevo bloque Pestañas está pensado para organizar el contenido en pestañas. Cada pestaña puede contener cualquier bloque, lo que lo hace especialmente útil para mostrar contenido clasificado por temas, preguntas frecuentes o comparativas de productos o servicios.
Bloques editables dentro del bloque HTML Personalizado
El bloque de HTML personalizado ha recibido una nueva mejora. Ahora puedes añadir bloques editables directamente dentro del código HTML. Esto te permite combinar HTML estático y bloques editables dentro del mismo fragmento de código.
Aunque se pueden editar, los bloques editables no se pueden mover ni eliminar, ni tampoco se pueden añadir bloques adicionales a través del editor visual. Sin embargo, el código subyacente sigue siendo totalmente editable en el editor de código.
Antes de WordPress 7.1, tu contenido tenía que ser o bien HTML totalmente estático, o bien estar compuesto íntegramente por bloques. Ahora puedes mezclar libremente HTML y bloques, lo cual resulta especialmente útil a la hora de generar contenido con modelos de IA.
Este cambio viene acompañado de la posibilidad de añadir código HTML estático a las variaciones de bloques. Gracias a la nueva compatibilidad con innerContent, puedes registrar una variación del bloque de código HTML tal y como se muestra en el siguiente ejemplo:
wp.blocks.registerBlockVariation( 'core/html', {
name: 'custom-image-card',
title: 'Custom image card',
description: 'A custom HTML block with static header/footer and an editable image.',
innerContent: [
'<h2>Static heading</h2>\n',
null,
'\n<footer>Static footer</footer>'
],
innerBlocks: [
[
'core/image',
{
id: 419,
sizeSlug: 'medium',
linkDestination: 'none',
url: 'https://example.com/wp-content/uploads/...',
alt: ''
}
]
],
} );El valor null en innerContent actúa como marcador de posición para el bloque Imagen.
Ten en cuenta que innerContent solo está disponible para el bloque HTML Personalizado. Si lo aplicas a variaciones de otros bloques, no tendrá ningún efecto.
Mejoras en el sistema de iconos SVG
WordPress 7.0 introdujo un nuevo bloque de iconos y una biblioteca de iconos. Con WordPress 7.1, el sistema de gestión de iconos cuenta ahora con una API pública, lo que permite registrar, mostrar y eliminar iconos mediante programación, así como recuperarlos a través de la API REST.
Registrar y anular el registro de iconos
Para registrar un icono o un conjunto de iconos, primero tienes que registrar una colección de iconos vinculando la nueva función wp_register_icon_collection() a la acción init:
function custom_icons_register_icon_collection() {
wp_register_icon_collection(
'my-icon-set',
array(
'label' => __( 'My awesome icons', 'my-plugin' ),
'description' => __( 'My personal set of icons.', 'my-plugin' ),
)
);
}
add_action( 'init', 'custom_icons_register_icon_collection' );Cada colección tiene un nombre único, que la distingue de los iconos predeterminados y de otros conjuntos de iconos registrados por plugins de terceros. El nombre de la colección debe empezar y terminar con una letra minúscula y puede contener letras minúsculas, números, guiones y guiones bajos.
El segundo argumento de la función es un array que contiene la etiqueta de la colección que se muestra en la biblioteca de iconos y una descripción opcional.
Para eliminar una colección, usa la función wp_unregister_icon_collection(). Al eliminar una colección, se borran automáticamente todos los iconos asociados a ella.
Para registrar un icono individual, usa la función wp_register_icon(), tal y como se muestra en el siguiente ejemplo:
wp_register_icon(
'my-icon-set/motorbike',
array(
'label' => __( 'Motorbike', 'my-plugin' ),
'content' => '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">...</svg>',
)
);En el ejemplo anterior, hemos registrado un icono utilizando una cadena SVG. También puedes registrar un icono directamente desde un archivo .svg:
wp_register_icon(
'my-icon-set/motorbike',
array(
'label' => __( 'Motorbike', 'my-plugin' ),
'file_path' => plugin_dir_path( __FILE__ ) . 'icons/motorbike.svg',
)
);Es importante tener en cuenta que el SVG se depura con wp_kses, y que, por ahora, solo se permiten los elementos <svg>, <path> y <polygon>. El resto de elementos se filtran, aunque es posible que la lista de elementos permitidos se amplíe en el futuro para incluir elementos y atributos adicionales.
Para eliminar un icono, puedes usar la función wp_unregister_icon().
Actualizaciones de la biblioteca de iconos y los bloques
La biblioteca de iconos se ha actualizado en consecuencia y ahora cuenta con una barra lateral que muestra la lista de colecciones de iconos registradas en la web.
El bloque Icono también se ha actualizado. Por defecto, ahora el bloque muestra el icono de información en lugar de un marcador de posición vacío, como en las versiones anteriores. Además, hay dos nuevos controles en la barra de herramientas del bloque que te permiten girar el icono tanto vertical como horizontalmente.
Nuevos endpoints de la API REST para iconos
También se han añadido nuevos endpoints de la API REST de solo lectura para acceder a colecciones de iconos o a iconos concretos.
Para las colecciones de iconos, usarás los siguientes endpoints:
GET /wp/v2/icon-collections
GET /wp/v2/icon-collections/<collection>Para leer los iconos, tendrás que usar estos endpoints:
GET /wp/v2/icons - Introduced with WordPress 7.0.
GET /wp/v2/icons/<collection>
GET /wp/v2/icons/<collection>/<name>Un usuario con la capacidad edit_posts debe autenticar las solicitudes.
Para una descripción más detallada del sistema de iconos en WordPress 7.1, echa un vistazo a la nota para desarrolladores.
Nuevas herramientas de diseño
Los creadores y editores ahora tienen nuevas herramientas de diseño mejoradas que les permiten dar estilo a los bloques de contenido sin tener que recurrir a CSS personalizado.
Compatibilidad con el degradado de fondo
WordPress 7.1 introduce background.gradient compatibilidad, así como un nuevo control en la interfaz de administración para los degradados de fondo.
En la barra lateral de configuración del bloque, hay un nuevo panel Fondo con controles independientes para Imagen, Color y Degradado que te permite probar diferentes combinaciones de imágenes de fondo, colores y degradados sin que se produzcan conflictos.
En WordPress 7.1, la compatibilidad con background.gradient está activada por defecto para los bloques Grupo, Acordeón, Cita destacada, Contenido de la entrada y Cita. Los desarrolladores de temas pueden añadir compatibilidad con background.gradient en el archivo block.json añadiendo una propiedad gradient dentro de styles.background o de forma individual para cada bloque, tal y como se muestra en el siguiente código:
{
"styles": {
"background": {
"gradient": "linear-gradient( 135deg, #1e3c72 0%, #2a5298 100% )"
},
"blocks": {
"core/group": {
"background": {
"gradient": "linear-gradient( 135deg, #f5f7fa 0%, #c3cf8d 100% )"
}
}
}
}
}Compatibilidad con el ancho mínimo
Otra novedad que llega con WordPress 7.1 y que les va a encantar a los diseñadores y desarrolladores de temas es la compatibilidad con la dimensión minWidth. Esto se suma a la compatibilidad ya existente con height, minHeight y width, completando así el conjunto de herramientas de diseño para las dimensiones.
Los desarrolladores de temas pueden añadir compatibilidad con el ancho mínimo a través de theme.json, ya sea activando las Herramientas de Apariencia o añadiendo el campo dimensions.minWidth en la sección de configuración:
{
"settings": {
"dimensions": {
"minWidth": true
}
}
}
También puedes añadir la opción de ancho mínimo de forma global o para cada bloque:
{
"styles": {
"dimensions": {
"minWidth": "400px"
},
"blocks": {
"core/group": {
"dimensions": {
"minWidth": "400px"
}
}
}
}
}Los desarrolladores de bloques también pueden añadir compatibilidad con minWidth al archivo block.json:
{
"supports": {
"dimensions": {
"minWidth": true
}
}
}El control está oculto por defecto en la barra lateral, pero puedes cambiar la configuración predeterminada usando __experimentalDefaultControls. En Estilos Globales, el control está visible por defecto.
Compatibilidad con sombras de texto en Estilos Globales
WordPress 7.1 introduce la compatibilidad con text-shadow en los estilos globales. Antes, habrías necesitado un plugin o habrías tenido que recurrir a CSS personalizado.
Ten en cuenta que se trata de una implementación inicial. Todavía quedan por decidir algunas cuestiones clave, como qué control de la interfaz de usuario usar para personalizar las sombras de texto en el editor, y si text-shadow debería estar disponible como preajuste. Por ahora, solo puedes definir text-shadow en tu theme.json de una de estas formas:
{
"$schema": "https://schemas.wp.org/wp/6.7/theme.json",
"version": 3,
"settings": {},
"styles": {
"typography": {
"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
},
"blocks": {
"core/paragraph": {
"typography": {
"textShadow": "1px 1px 2px red, 0 0 1em red, 0 0 0.2em red"
}
}
},
"elements": {
"h2": {
"typography": {
"fontSize": "var:preset|font-size|x-large",
"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
}
}
}
}
}La siguiente imagen muestra el resultado de las definiciones anteriores.
Novedades para desarrolladores
Las novedades que llegan para los desarrolladores de temas y plugins con WordPress 7.1 son impresionantes. Las numerosas incorporaciones y mejoras en la API Abilities y en la personalización del sistema de diseño nos parecen las más destacadas.
Personalización del sistema de diseño
WordPress 7.1 presenta un nuevo sistema de diseño que los desarrolladores de plugins pueden usar para personalizar el estilo de los elementos de la interfaz de administración. El nuevo sistema consta de dos partes: tokens de diseño y un nuevo componente de React llamado ThemeProvider.
Tokens de diseño
Los tokens de diseño de WordPress son propiedades CSS personalizadas que siguen un patrón establecido. Aquí tienes, por ejemplo, el patrón de la familia de tokens de color:
--wpds-color-<property>-<target>-<tone>[-<emphasis>][-<state>]Según el patrón anterior, la siguiente variable establece el color de fondo para las superficies con énfasis normal:
--wpds-color-background-surface-neutral-strongA partir de WordPress 7.1, cualquier plugin que genere elementos de la interfaz de administración puede utilizar tokens de diseño gracias a una nueva hoja de estilos wp-theme que incluye un conjunto completo de tokens de diseño semánticos y está disponible como dependencia del plugin. Puedes añadir a la cola una hoja de estilos personalizada que utilice wp-theme tal y como se muestra a continuación:
function myplugin_enqueue_admin_assets( $hook_suffix ) {
wp_enqueue_style(
'myplugin-admin-style',
plugin_dir_url( __FILE__ ) . 'assets/css/admin.css',
array( 'wp-theme' ),
'1.0.0'
);
}
add_action( 'admin_enqueue_scripts', 'myplugin_enqueue_admin_assets' );La ventaja de los tokens de diseño es que pueden sustituir los valores de propiedades CSS codificados de forma fija. Echa un vistazo al siguiente ejemplo de la nota para desarrolladores:
.card {
background-color: var(--wpds-color-background-surface-neutral-strong);
color: var(--wpds-color-foreground-content-neutral);
border: var(--wpds-border-width-xs) solid var(--wpds-color-stroke-surface-neutral-weak);
border-radius: var(--wpds-border-radius-lg);
padding: var(--wpds-dimension-padding-2xl);
}Los tokens de diseño se pueden usar junto con el componente ThemeProvider para personalizar el aspecto de áreas específicas de la página de administración.
ThemeProvider
Puedes anular los valores predeterminados de los tokens de diseño que proporciona la hoja de estilos wp-theme envolviendo el contenido del área de administración dentro del nuevo componente React ThemeProvider, tal y como se muestra en el siguiente ejemplo de la nota de desarrollo:
import { ThemeProvider } from '@wordpress/theme';
import { Card } from '@wordpress/ui';
function Application() {
return (
<ThemeProvider
color={
{
primary: '#3858e9',
background: '#11004d'
}
}
cornerRadius="pronounced"
>
<Card.Root>
<Card.Content>
Card content
</Card.Content>
</Card.Root>
</ThemeProvider>
);
}A partir de un color principal y uno de fondo, el componente genera automáticamente una escala de colores armoniosa y coherente que ofrece un contraste accesible entre los elementos de la interfaz de usuario.
El ThemeProvider permite a los desarrolladores de plugins expresar la identidad de su marca en las áreas de la interfaz sin perder la coherencia con el estilo general de la interfaz de administración de WordPress.
Si quieres un análisis más detallado, échale un vistazo a la nota de desarrollo y a la documentación oficial sobre tokens de diseño y ThemeProvider.
Mejoras en la API Abilities
Con el lanzamiento de WordPress 7.1, la API de Abilities incorpora varias novedades que amplían su funcionalidad.
Nuevo ciclo de vida de ejecución para la API Abilities
En primer lugar, el ciclo de ejecución se ha mejorado con 4 nuevos filtros que se ejecutan antes, durante y después de la ejecución de una habilidad.
El filtro wp_pre_execute_ability se ejecuta al principio de WP_Ability::execute() y sirve para interceptar e interrumpir la ejecución de una acción incluso antes de que WordPress empiece a procesarla. Si el filtro devuelve un valor distinto del valor predeterminado $pre (un error, datos o un valor booleano), WordPress se detiene de inmediato, se salta las comprobaciones y devuelve ese valor.
Este filtro se presta a casos de uso interesantes, como desactivar una función durante el mantenimiento del sitio, limitar la frecuencia de las solicitudes procedentes de la misma IP o simular la respuesta de una función (pruebas unitarias).
El filtro wp_ability_normalize_input se ejecuta justo después de que se apliquen los valores por defecto y antes de la validación formal del esquema y las comprobaciones de permisos. Se usa para preparar o transformar los datos que llegan antes de que la ability los valide y procese — por ejemplo, para añadir metadatos contextuales, normalizar los datos antes de la validación, enriquecer una indicación de IA o detener la ejecución de la ability en caso de error.
El filtro wp_ability_permission_result te permite modificar el resultado de las comprobaciones de permisos realizadas antes de ejecutar una ability. Puedes usarlo para añadir reglas de autorización más detalladas, crear un sistema de permisos personalizado o saltarte los permisos en casos concretos.
Ten en cuenta que debes usar este filtro con precaución:
Los plugins deben tener especial cuidado con este filtro, ya que devolver un valor
truepuede anular una denegación delpermission_callbackoriginal de la ability.
El filtro wp_ability_execute_result se ejecuta después del callback de ejecución de la ability y antes de la validación de la salida, lo que te permite modificar el resultado final devuelto por una ability. Te permite transformar la respuesta generada por el procesamiento de la ability antes de devolverla a la función que la invocó.
Filtrado y manipulación de abilities
Antes de WordPress 7.1, para filtrar las abilities registradas había que recorrer manualmente el registro usando array_filter(). A partir de WordPress 7.1, wp_get_abilities() acepta un array opcional de argumentos para filtrar las abilities registradas por category, namespace, meta o una combinación de estos.
El siguiente ejemplo muestra cómo recuperar abilities que pertenecen a una categoría concreta:
$abilities = wp_get_abilities(
array(
'category' => 'content-generation',
)
);También puedes combinar varios parámetros:
$abilities = wp_get_abilities(
array(
'category' => 'content-generation',
'meta' => array(
'public' => true,
),
)
);Para un filtrado más avanzado, la API ofrece los parámetros item_include_callback y result_callback, dos callbacks que se usan para incluir o excluir abilities del array y para ordenar o manipular el conjunto de resultados antes de que se devuelva.
Junto con las actualizaciones de wp_get_abilities(), WordPress 7.1 introduce dos nuevos filtros globales:
wp_get_abilities_item_include: Se ejecuta para cada abilitie que supere los filtros declarativos yitem_include_callback. Puedes usar este filtro para incluir o excluir abilities específicas en todo el sitio.wp_get_abilities_result: Se ejecuta después deresult_callback. Puedes usarlo para manipular todo el conjunto de resultados de abilities en todo el sitio.
Echa un vistazo a la nota de desarrollo para ver una descripción más detallada de las actualizaciones de wp_get_abilities() y sus filtros asociados.
Nuevo flag de exposición pública
WordPress 7.1 también introduce un nuevo flag de metadatos para indicar que una función está disponible para que puedan acceder a ella clientes externos, como la API REST, los adaptadores MCP y los agentes de IA.
Al registrar una ability, ahora puedes usar meta.public para que tu capacidad pueda ser detectada y activada a través de los endpoints REST de abilities. Antes, tenías que especificar la exposición por separado para cada canal; por ejemplo, configurando «show_in_rest» => true para que una ability fuera visible a través de REST.
Otras mejoras en la API Abilities
Además de las actualizaciones mencionadas anteriormente, WordPress 7.1 introduce nuevas mejoras que abarcan diversos aspectos de la API.
Dos nuevos filtros, wp_ability_validate_input y wp_ability_validate_output, permiten a los plugins validar los datos de entrada y salida utilizando reglas más complejas que las que se pueden expresar mediante el esquema JSON de WordPress. El primer filtro se ejecuta después de que se haya preparado la entrada y se haya superado la validación inicial del esquema. El segundo filtro se ejecuta después de que se haya ejecutado la ability y antes de que se devuelva el resultado final.
La acción wp_ability_invoked se ejecuta al inicio de WP_Ability::execute() y se puede usar para rastrear y registrar cada intento de invocar una función. Puedes conectarte a esta acción para registrar los intentos de acceso a una función específica, medir la carga del servidor, configurar contadores de uso diarios o mensuales y detectar intentos de llamadas por fuerza bruta.
Pero ten cuidado:
La acción recibe datos sin procesar y sin normalizar. Por eso, los plugins deberían evitar registrar los datos de forma indiscriminada, ya que pueden contener credenciales, información personal u otros datos confidenciales.
Más novedades para desarrolladores
Las novedades para desarrolladores no terminan aquí. WordPress 7.1 trae un número impresionante de mejoras y novedades, ofreciendo herramientas de desarrollo nuevas y más fiables. Con esta nueva versión, también encontrarás:
- Cuatro nuevos filtros para configurar las pantallas del Editor del Sitio
- El editor de entradas siempre se muestra en un iframe
- Actualizaciones en los componentes del editor
- jQuery UI actualizado a la versión 1.14.2
- Preparación del esquema JSON para la compatibilidad con los clientes.
- Ahora puedes aplicar estilos a los pseudoestados.
- Estilos de bloques adaptables y ventanas de visualización configurables
- Nuevas funciones para mostrar información sobre herramientas y ayuda informativa
Alojamiento de última generación para un WordPress de última generación
WordPress 7.1 supone un gran paso adelante para el CMS en varios frentes.
El procesamiento de archivos multimedia del lado del cliente marca un punto de inflexión en la gestión de imágenes. Ahora el procesamiento se realiza del lado del cliente, lo que se traduce en una mayor eficiencia de los recursos del servidor y un rendimiento más rápido de las páginas.
En cuanto a las capacidades de IA, tras las innovadoras actualizaciones de las versiones 6.9 y 7.0, WordPress 7.1 supone un momento de consolidación. La API Abilities incorpora nuevas funciones que permiten a los desarrolladores crear integraciones y capacidades de IA más fiables y seguras.
Otra novedad muy útil que los desarrolladores y las agencias van a valorar es el Theme Provider, que permite a los plugins mostrar su identidad de marca en el área de administración sin perder la coherencia con la interfaz del panel de control de WordPress.
También hay mejoras en Notas, nuevos bloques, un sistema de iconos SVG más potente y mucho más. En resumen, WordPress no da señales de ralentizarse y está más orientado al futuro que nunca.
Para un CMS cada vez más avanzado, es fundamental elegir un proveedor de alojamiento que vaya al día con las tecnologías modernas. Kinsta ofrece el entorno ideal para sitios de WordPress de última generación: infraestructura en la nube en contenedores, un rendimiento espectacular, seguridad sólida y un servicio de soporte rápido y de primera categoría.
Si aún no has probado nuestro alojamiento, aprovecha la prueba gratuita en determinados planes o ponte en contacto con nosotros para saber más.
