WordPress 7.1 se publicó el 19 de agosto de 2026 y, como suele pasar con las versiones que llegan en agosto, va a entrar en muchas webs sin que nadie la lea con detenimiento. Es una pena, porque debajo de la lista de novedades hay dos movimientos que importan bastante a quien mantiene sitios de empresa: el editor ha dado un salto real en diseño responsive sin escribir CSS, y el core sigue construyendo, versión tras versión, la infraestructura para que agentes de IA operen dentro de WordPress de forma gobernada.
En números, la versión trae más de 310 tickets de Trac cerrados, de los cuales más de 100 son mejoras y unos 180 corrección de errores, con más de 800 personas contribuyendo y Anne McCarthy como responsable de la release. El paquete del editor viene de casi 600 mejoras y más de 630 correcciones acumuladas en Gutenberg entre las versiones 22.7 y 23.6. No es una versión menor.
Este artículo es la continuación natural de nuestra guía de actualización a WordPress 7 para empresas: allí explicamos qué cambió con el salto de versión mayor y cómo planificar la migración; aquí repasamos qué añade 7.1 encima, con foco en lo que un CTO o un responsable de IT necesita decidir. Al final incluimos también lo que puede romperse, porque esta versión tiene varios cambios silenciosos que afectan a temas y plugins a medida.
Aviso de honestidad por delante: en el material oficial no hay benchmarks de rendimiento de la versión, ni un cambio anunciado de requisitos mínimos de PHP o MySQL. Cuando aquí damos una cifra, viene de la documentación de desarrollo y la citamos como tal.
1. Estilos responsive nativos: el fin de una era de plugins
Es la novedad que la propia documentación pone en portada, y con razón. Hasta ahora, adaptar un bloque a móvil o a tablet significaba o bien escribir CSS a mano, o bien instalar un plugin que añadía controles de visibilidad y tamaños por dispositivo. WordPress 7.1 incorpora esa capacidad al núcleo.
El mecanismo es sencillo de entender: aparecen dos nuevas claves de estilo, @mobile y @tablet, que se pueden usar tanto en theme.json como en los estilos globales y en los atributos de estilo de cada bloque individual. Por defecto @mobile equivale a una consulta de medios de hasta 480 píxeles y @tablet al rango entre 480 y 782 píxeles. No existe una clave @desktop: el escritorio es el estado base y las otras dos son variaciones.
Lo interesante para quien desarrolla temas es que esos puntos de corte dejan de estar grabados en piedra. Un nuevo ajuste de primer nivel, settings.viewport, permite definir tus propios valores de mobile y tablet en píxeles, em o rem, y todo el sistema —incluida la visibilidad de bloques por dispositivo— se adapta a ellos automáticamente. Si tu tema corporativo ya trabajaba con una rejilla propia, ahora puedes alinear el editor con ella en lugar de pelearte con los valores del core.
Existe además un ajuste del editor, responsiveEditingEnabled, activo por defecto y filtrable mediante block_editor_settings_all, por si en un proyecto concreto prefieres no exponer estos controles al equipo editorial. En sitios donde el diseño está muy pautado, desactivarlo es una decisión razonable.
Esto conecta directamente con lo que contábamos sobre la visibilidad por dispositivo que llegó en WordPress 7: aquello permitía mostrar u ocultar bloques según la pantalla, y ahora se completa con la capacidad de darles estilos distintos. Entre las dos versiones, buena parte de los plugins de responsive que arrastran los proyectos antiguos se han quedado sin motivo para existir.
2. Estados interactivos: hover, focus y active desde el editor
La segunda pieza de la misma familia son los estados de estilo. En theme.json aparecen las claves :hover, :focus, :focus-visible y :active, y en el editor se pueden configurar visualmente para los bloques Botón y Enlace de navegación, que son los dos que las estrenan.
Hay también un mecanismo para estados personalizados, declarados con un prefijo de guion —por ejemplo -current— y mapeados desde un nuevo campo selectors.states en el block.json del bloque. Es la vía para que un bloque a medida exponga sus propios estados al sistema de estilos globales, algo que hasta ahora obligaba a inyectar CSS por separado.
El orden de anidamiento, por si te toca escribirlo a mano, es: primero el viewport, después el estado personalizado y por último el pseudo-estado. Y existe el correspondiente interruptor blockStatesEditingEnabled, también activo por defecto.
Aquí conviene una advertencia práctica. Si el tema del cliente ya tiene CSS escrito a mano para los :hover de botones y menús, y ahora alguien del equipo editorial toca esos controles desde el editor, vas a tener dos fuentes de verdad compitiendo por el mismo estilo. Merece la pena decidir cuál manda antes de actualizar, no después de la primera incidencia.
3. Procesado de medios en el navegador: la novedad más técnica
WordPress 7.1 incorpora el procesado de imágenes del lado del cliente. En lugar de subir el archivo original al servidor y que PHP genere las miniaturas con GD o Imagick, el navegador comprime, redimensiona, convierte de formato, rota y genera los tamaños intermedios usando wasm-vips, una compilación a WebAssembly de la librería libvips.
Los beneficios para quien administra el hosting son evidentes. Se acaban los fallos de subida por límite de memoria de PHP en imágenes grandes. Se libera CPU del servidor en cada carga de medios. El resultado es consistente independientemente de qué librería gráfica tenga instalada el hosting del cliente, que es una fuente clásica de diferencias entre entornos. Y se gana soporte nativo para HEIC, para AVIF de salida aunque el servidor no lo soporte, para mapas de ganancia HDR y para convertir GIF animados en vídeo. La documentación cifra en torno a un 15% la reducción de peso de los JPEG con una codificación de tipo MozJPEG.
3.1 La letra pequeña que no aparece en la nota de prensa
Esta funcionalidad depende del aislamiento de origen cruzado en el navegador, y eso significa que hoy solo funciona en Chromium 137 o superior. En Firefox y en Safari el proceso cae automáticamente al camino tradicional de servidor. No es un problema de corrección, pero sí implica que el comportamiento no será uniforme entre los miembros del equipo editorial de tu cliente.
Hay tres detalles más que importan si mantienes código a medida. El primero: como no se usa el editor de imágenes del servidor, los hooks wp_image_editors, image_memory_limit e image_make_intermediate_size simplemente dejan de dispararse. Si tienes un plugin propio o del cliente que engancha ahí para marcas de agua, recompresión o rutas de almacenamiento, deja de funcionar en silencio.
El segundo: wp_generate_attachment_metadata ahora se ejecuta dos veces, primero con contexto de creación y después de actualización, de modo que cualquier callback enganchado debe ser idempotente. El tercero: si tienes una política de seguridad de contenido estricta, necesita permitir worker-src con blob:, o el procesado cae al servidor sin avisar.
Como contrapunto honesto, la propia documentación señala algo que las notas de prensa omiten: con este modelo el cliente sube el original y todos los tamaños generados, así que el total de bytes transferidos durante la subida en realidad aumenta respecto al camino de servidor, que solo recibía el original. El ahorro está en CPU y memoria del servidor y en el peso final servido al visitante, no en el tráfico de subida.
Existe un filtro, wp_client_side_media_processing_enabled, y una función wp_is_client_side_media_processing_enabled() para consultar el estado. Si mantienes sitios con flujos de medios complejos, la recomendación es probar explícitamente con el filtro devolviendo false para confirmar que tu camino de respaldo sigue vivo.
Además del motor, cambia el interfaz: hay un nuevo modal de edición de medios que sustituye a la herramienta de recorte en línea y reúne recorte libre y por proporción, volteo, rotación precisa y edición de metadatos en un solo flujo. Es el complemento visual de lo que ya comentamos sobre bloques, medios y rendimiento en WordPress 7.
4. Bloques nuevos e iconos registrables
Llegan dos bloques al núcleo. El bloque Pestañas permite organizar contenido en paneles tabulados en lugar de mostrarlo todo de golpe, algo que hasta ahora exigía un plugin o un bloque a medida en prácticamente todos los proyectos corporativos. Y el bloque Lista de reproducción agrupa varios archivos de audio con una vista opcional de forma de onda.
Para quien desarrolla, la novedad relevante es que la API de iconos SVG del core se abre al público. Aparecen cuatro funciones —wp_register_icon_collection(), wp_unregister_icon_collection(), wp_register_icon() y wp_get_icon()— junto con una clase WP_Icon_Collections_Registry y rutas REST de solo lectura en /wp/v2/icon-collections y /wp/v2/icons. Los nombres van con espacio de nombres, en la forma coleccion/nombre-icono.
Un detalle a tener en cuenta: la sanitización de los SVG es estricta. Solo se permiten las etiquetas svg, path y polygon, el atributo fill únicamente en las dos últimas y stroke en ninguna. Los iconos construidos con trazos en lugar de rellenos perderán el trazo. Si vas a registrar el set de iconos de la marca de un cliente, conviértelos a rellenos antes.
5. Barra de administración persistente y notas con menciones
La barra de administración ahora acompaña en el editor de entradas y en el editor de sitio, salvo en modo sin distracciones. El logotipo de WordPress deja paso a un botón de retroceso dedicado, y el icono del sitio, cuando está configurado, aparece en la barra. Es un cambio pequeño de interfaz pero con efecto real: reduce la sensación de «estar perdido» dentro del editor de sitio, que era una queja constante de los equipos editoriales.
La contrapartida es que un toolbar persistente en el editor de sitio es comportamiento nuevo. Si tienes plugins que añaden nodos a la barra, conviene comprobar que siguen funcionando ahí. La documentación incluye la vía para excluirse, comprobando la pantalla actual dentro de admin_bar_menu.
En el terreno de la colaboración, las notas del editor ganan texto enriquecido y menciones con arroba, con notificación por correo, la posibilidad de anotar sobre una selección de texto concreta en lugar de sobre el bloque entero y de abrir varias conversaciones sobre el mismo bloque. Es un avance útil para flujos de revisión entre agencia y cliente.
6. La capa de IA: qué está construyendo WordPress de verdad
Aquí está, en nuestra opinión, la parte más interesante de la versión, y curiosamente es la que no aparece en la página de novedades para usuarios. Toda la información vive en las notas de desarrollo.
El contexto: WordPress no está metiendo un asistente de IA en el escritorio. Está construyendo la fontanería para que cualquier agente —propio, de un plugin o externo vía el adaptador MCP— pueda descubrir qué sabe hacer un sitio e invocarlo de forma controlada. Esa fontanería se llama Abilities API, apareció en la versión 6.9, y 7.1 la desarrolla de forma sustancial. Si quieres el contexto de negocio previo, lo tratamos al hablar de los conectores de IA de WordPress 7 y su coste.
6.1 Qué es una capacidad y por qué esto importa a un CTO
Una ability es una acción registrada en el sitio con un nombre, un esquema de entrada, un esquema de salida y una comprobación de permisos. Ejemplos que trae el propio core: core/get-site-info, core/get-user-info, core/get-environment-info. La gracia del planteamiento es que un agente ya no necesita saber cómo está construido tu WordPress: pregunta qué capacidades hay disponibles, lee sus esquemas y las invoca.
Traducido a lenguaje de dirección: esto convierte el sitio en algo que un sistema automático puede operar. Y eso, que abre posibilidades reales de automatización, es también exactamente el tipo de superficie que hay que gobernar antes de que se gobierne sola. Es el mismo debate que planteábamos al analizar los casos reales de agentes de IA en la empresa: la pregunta no es si funciona, sino quién autoriza qué.
6.2 Los nuevos filtros del ciclo de ejecución
WordPress 7.1 añade nueve filtros y una acción a la Abilities API, y su lectura conjunta deja bastante claro el objetivo: dar puntos de control en cada fase de la invocación. Los cuatro que definen el ciclo son wp_pre_execute_ability, que permite cortocircuitar la ejecución y devolver un resultado sin llegar a ejecutar nada; wp_ability_normalize_input, para transformar la entrada antes de validarla; wp_ability_permission_result, para sobrescribir la decisión de autorización; y wp_ability_execute_result, para filtrar o recuperar el resultado.
A ellos se suman wp_ability_validate_input y wp_ability_validate_output —importante: los validate_callback y sanitize_callback declarados en el esquema de una capacidad no se ejecutan, hay que moverlos aquí— y la acción wp_ability_invoked, que se dispara al principio de todo y está pensada para auditoría, telemetría y trazabilidad.
Sobre esa acción hay una advertencia explícita en la documentación que merece la pena repetir: recibe la entrada sin normalizar, así que registrarla indiscriminadamente puede acabar volcando credenciales o datos personales a tus logs. Si vas a montar auditoría de invocaciones de IA —y deberías—, filtra qué registras.
6.3 El flag público y la exposición de datos
La versión introduce una clave de metadatos unificada, meta.public, que actúa como valor por defecto de exposición hacia clientes externos y que las banderas específicas de cada canal, como show_in_rest, pueden sobrescribir. Las tres capacidades del core mencionadas antes ya se han migrado a ella, y la documentación anuncia que el adaptador MCP de WordPress respetará esta bandera unificada a partir de su próxima versión.
La frase que conviene subrayar y llevarse a la reunión de arquitectura es esta: los desarrolladores no deben tratar public, show_in_rest ni ninguna otra bandera de exposición como una frontera de seguridad. La autorización tiene que aplicarla la propia capacidad. Es un aviso que hemos visto fallar mil veces en APIs internas: confundir «no está listado» con «no es accesible». Si te interesa el enfoque sistemático, lo desarrollamos en nuestro artículo sobre desarrollo seguro según ISO 27001 y el ENS.
6.4 Esquemas JSON para clientes de IA
La última pieza es más discreta pero muy reveladora de hacia dónde va esto. Aparece wp_prepare_json_schema_for_client(), una función que convierte los esquemas internos de WordPress a JSON Schema portable, con perfiles para Draft 4 y para la API REST. Su motivo declarado es la compatibilidad con clientes REST y con clientes de IA y MCP.
Dicho de otro modo: WordPress está estandarizando cómo se describe a sí mismo para que una máquina lo entienda. Esa es la infraestructura previa a cualquier ecosistema de agentes serio, y es la razón por la que conviene ir mirando esto ahora, aunque no tengas ningún caso de uso de IA sobre la mesa este trimestre.
¿Actualizas a WordPress 7.1 sin saber qué se va a romper?
Revisamos tu tema y tus plugins a medida contra los cambios de esta versión, preparamos un entorno de pruebas y hacemos la actualización con plan de vuelta atrás. Si además quieres abrir la puerta a la capa de IA, definimos primero qué capacidades se exponen y con qué permisos.
7. Lo que no ha entrado (y por qué importa saberlo)
Tan informativo como la lista de novedades es la lista de lo que se quedó fuera, porque marca qué esperar en las próximas versiones.
La edición colaborativa en tiempo real no ha llegado. Se probó extensamente durante el ciclo de 7.1 pero no está activada en la versión final; sigue el trabajo sobre la experiencia de edición, la resolución de conflictos y la compatibilidad. Lo que sí ha llegado son las notas con menciones que comentábamos antes, que cubren una parte del caso de uso.
React 19 se ha aplazado. WordPress 7.1 sigue con React 18.3. La actualización se revirtió y continúa como experimento en el plugin Gutenberg desde su versión 23.4. Para una agencia esto es una buena noticia y un aviso a la vez: no hay deuda que pagar hoy, pero llegará, y ya puedes probar tus bloques a medida activando el experimento. Los dos puntos de fallo habituales son el react/jsx-runtime empaquetado y las APIs heredadas de React que ya se eliminaron.
El bloque clásico se queda. Se anunció durante el ciclo que se ocultaría del insertador y después se revirtió la decisión. En 7.1 sigue disponible. Si tienes clientes con flujos que dependen de él, no hay urgencia.
8. Antes de actualizar: lo que puede romperse
Esta es la sección que recomendamos leer dos veces. WordPress 7.1 contiene varios cambios que no producen errores visibles pero sí alteran comportamiento o aspecto en sitios con desarrollo a medida.
- El editor de entradas siempre va dentro de un iframe. Antes dependía de la versión de la API de bloques de los bloques presentes; ese escape ha desaparecido. Los bloques a medida que acceden a
documentowindowglobales en lugar de al documento del lienzo van a fallar. La corrección pasa por usarownerDocumentydefaultView, y por enganchar los listeners conuseRefEffect. - Cambia el marcado de las tablas de listado del escritorio. El
th scope="row"se ha movido de la columna de la casilla de selección a la del título. Cualquier CSS o JavaScript que use selectores comoth.check-column,td.column-titleotd .row-actionsdeja de aplicar. Es la causa más probable de que una columna personalizada del escritorio de un cliente aparezca descuadrada tras actualizar. - Baja la especificidad de las clases de preset a nivel de bloque. Las clases generadas desde
settings.blocksentheme.jsonahora se envuelven en:where(), lo que baja su especificidad. Los temas que dependían de que esas reglas ganaran a otras van a ver cambios visuales sutiles y difíciles de diagnosticar. - El bloque de navegación deja de propagar el tamaño de fuente a sus hijos. Ya no se emiten las clases
has-{slug}-font-sizeen los elementos del menú. Si el tema las usaba como gancho de estilo, hay que restaurar el comportamiento con un filtrorender_block. - jQuery UI pasa de 1.13.3 a 1.14.2. Desaparecen
$.fn._form,$.ui.ie,$.ui.safeActiveElementy$.ui.safeBlur. El core no los usaba, pero los plugins antiguos sí. Se deja activadojQuery.uiBackCompatpara amortiguar el golpe. - Los controles de formulario del editor pasan a 40 píxeles de alto sin excepción. La propiedad
__next40pxDefaultSizedeja de tener efecto y la propiedadsizequeda obsoleta en varios componentes. Los paneles de ajustes a medida cambiarán de aspecto. - El scroll infinito de la mediateca se activa por defecto. El filtro
media_library_infinite_scrollingcambia su valor por defecto de falso a verdadero, con una opción por usuario para desactivarlo. La propia documentación de accesibilidad lo reconoce como una regresión conocida, así que si tu cliente tiene requisitos de accesibilidad, conviene forzar el filtro. - Cambia la semántica del filtro
notify_post_author. La comprobación de aprobación se ejecuta ahora antes del filtro, de modo que forzar notificaciones con un__return_truepasa a generar correos también para comentarios en moderación, marcados como spam o en la papelera. - Las entidades sin paginación devuelven la colección completa.
getEntityRecords()ya solo trocea resultados en entidades que declaran soportar paginación. En sitios con muchos registros, un bucle que antes recibía diez elementos ahora puede recibir miles. - Componentes eliminados. Desaparecen el componente
Navigationy__experimentalApplyValueToSides, obsoletos desde la 6.8. El paquete@wordpress/nuxpasa a ser un contenedor vacío.
Ninguno de estos cambios es dramático por separado. Juntos, en un sitio corporativo con cinco años de desarrollo a medida encima, son motivo suficiente para no actualizar en producción un viernes por la tarde.
9. Requisitos y cómo plantear la actualización
No hay un cambio de requisitos mínimos anunciado con esta versión. La recomendación oficial vigente sigue siendo PHP 8.3 o superior y MariaDB 10.11 o MySQL 8.0 en adelante, con HTTPS obligatorio en toda instalación. WordPress todavía arranca con PHP 7.4 y MySQL 5.5.5, pero esas versiones están fuera de soporte y son, en la práctica, un riesgo de seguridad que asumes tú.
Sí cambian, en cambio, los requisitos del lado del navegador: jQuery UI 1.14.2 abandona todas las versiones de Internet Explorer y Edge Legacy, y el procesado de medios en el navegador exige Chromium 137 o superior.
9.1 El procedimiento que aplicamos nosotros
Primero, copia del sitio en un entorno de pruebas idéntico al de producción, no en un local con otra versión de PHP. Segundo, inventario de plugins y de código a medida, cruzado contra la lista de la sección anterior: bloques propios, columnas personalizadas del escritorio, hooks de imágenes, personalizaciones de la mediateca y CSS que dependa de la especificidad de los presets. Tercero, actualización en pruebas y revisión visual de las plantillas clave, incluyendo el escritorio y no solo el frontal. Cuarto, ventana de despliegue con copia de seguridad reciente y plan de vuelta atrás.
Y una recomendación que damos siempre: no dejes la actualización para dentro de tres meses «cuando haya tiempo». Los incidentes graves de WordPress no vienen de actualizar pronto, vienen de no actualizar; lo vimos con toda claridad al analizar el caso de wp2shell y cómo responder ante una vulnerabilidad crítica. Si tu política de mantenimiento no contempla ventanas periódicas, ese es el problema de fondo, y lo abordamos en nuestra guía de seguridad de WordPress para empresas.
10. Preguntas frecuentes
¿Debo actualizar ya a WordPress 7.1?
En sitios sencillos, con tema estándar y pocos plugins, sí, tras una copia de seguridad. En sitios con desarrollo a medida, pásalo primero por un entorno de pruebas: los cambios del iframe del editor y del marcado del escritorio afectan sobre todo a ese perfil.
¿Los estilos responsive nuevos sustituyen a mi plugin de responsive?
En muchos casos sí, pero no migres de golpe. Convive con ambos en pruebas, comprueba que los puntos de corte coinciden con los de tu tema y desinstala después.
¿La Abilities API supone algún riesgo de seguridad?
El riesgo no está en la API, está en registrar capacidades sin comprobar permisos dentro de ellas. La documentación insiste en que las banderas de exposición no son una frontera de autorización. Empieza por capacidades de solo lectura y con aprobación humana para cualquier escritura.
¿El procesado de imágenes en el navegador se puede desactivar?
Sí, mediante el filtro wp_client_side_media_processing_enabled. Es la vía recomendada si tienes hooks propios de generación de miniaturas que dejarían de ejecutarse.
¿Cuándo llegará la edición colaborativa en tiempo real?
No hay fecha. Se probó durante este ciclo y no se activó en la versión final. El trabajo continúa de cara a una integración futura en el núcleo.
Conclusión
WordPress 7.1 es una versión con dos caras. La visible es de producto: diseño responsive sin CSS, estados interactivos, medios más rápidos y menos dependientes del servidor, dos bloques que llevábamos años resolviendo con plugins. Es la clase de mejora que reduce el número de extensiones instaladas en un sitio, y eso siempre es una buena noticia para la seguridad y para el mantenimiento.
La cara menos visible es estructural. Con la Abilities API, los filtros del ciclo de ejecución, la bandera unificada de exposición y los esquemas JSON portables, WordPress está montando la infraestructura para que agentes de IA operen sitios de forma gobernada. No hay un asistente que puedas encender hoy, pero la fontanería ya está puesta, y las decisiones sobre qué se expone y quién autoriza qué es mejor tomarlas antes de que alguien instale un plugin que las tome por ti.
Nuestro consejo, si mantienes sitios de empresa: planifica la actualización esta semana o la siguiente en un entorno de pruebas, revisa la lista de cambios que pueden romperse, y aprovecha para poner por escrito la política de exposición de capacidades. Esta última parte no la pide nadie todavía. La va a pedir alguien pronto.
Si quieres el contexto completo del salto de versión mayor, empieza por la guía de actualización a WordPress 7, y complétala con los capítulos sobre el nuevo escritorio y las DataViews y sobre las revisiones con Visual Diff.
