WordPress 7.1: todo lo que trae la nueva versión para tus sitios

WordPress 7.1: todo lo que trae la nueva versión para tus sitios

WordPress 7.0.2 salió el 17 de julio de 2026 como release de seguridad y el core activó actualizaciones forzadas por la severidad de dos fallos. Mientras tanto, WordPress 7.1 Beta 4 se publicó el 29 de julio de 2026 y la estable está programada para el 19 de agosto de 2026. Si tenés un sitio en Uruguay (tienda, consultorio, agencia o blog), estos dos hitos te afectan de forma distinta: uno es parchear ya; el otro es planificar bien.

Este artículo resume lo que ya está estable en la línea 7.0, lo que se anuncia de forma oficial en la beta de 7.1, y cómo lo encaramos en Hosting del Sur cuando un cliente tiene mantenimiento de WordPress.

Por qué importa ahora (y no «cuando haya tiempo»)

La mayoría de los dueños de sitios actualizan WordPress cuando aparece el aviso amarillo en el escritorio. Eso alcanza para un parche menor. No alcanza cuando el propio proyecto WordPress marca un release como crítico y habilita forced updates.

Según el anuncio oficial de WordPress 7.0.2, el paquete corrige un problema de severidad crítica y otro de severidad alta. El equipo de seguridad recomendó actualizar de inmediato. Si tu sitio sigue en 7.0.0 o 7.0.1 (o en ramas 6.9 / 6.8 afectadas), el riesgo no es teórico.

En paralelo, 7.1 ya está en fase beta. La Beta 1 del 15 de julio de 2026 detalla las funciones que el core está probando. La Beta 4 del 29 de julio suma más de 114 correcciones desde la Beta 3 (51 en el editor y 63 en Core). Eso no es «listo para producción». Es software en prueba.

WordPress 7.0 «Armstrong»: lo que ya tenés disponible

WordPress 7.0 «Armstrong» se liberó el 20 de mayo de 2026. Es el major de este ciclo. Si tu hosting te dejó en 7.0.x y ya aplicaste 7.0.2, estas son las piezas que ya podés usar (según el anuncio oficial y el feature showcase de 7.0).

Base de IA en el core (opt-in, no magia automática)

7.0 mete en el núcleo un AI Client y una pantalla de Connectors: un hub para autenticar proveedores externos (incluida IA) y servicios que un plugin quiera conectar. La Abilities API da un marco común para que plugins y herramientas expongan capacidades de forma ordenada.

Importante para no vender humo: actualizar a 7.0 no «enciende la IA» sola. Las herramientas de generación de títulos, extractos, imágenes o alt text vienen del plugin oficial de IA, que es opcional. Si no conectás nada, el sitio sigue funcionando como siempre.

Escritorio más moderno y menos clics

El admin estrena esquema de color por defecto, botones e inputs retocados, y transiciones entre pantallas. La Command Palette queda accesible desde la barra superior con Ctrl+K / ⌘K. La Font Library, que antes estaba más atada a temas de bloques, pasa a funcionar también con temas clásicos e híbridos: instalás y gestionás tipografías desde un lugar central.

Diseño sin tanto CSS a mano

Varias cosas que antes pedían page builder o CSS custom entran al editor:

• Visibilidad por dispositivo: mostrar u ocultar un bloque en desktop, tablet o móvil sin tocar código.
• Overlays de navegación: el menú móvil deja de ser «lista de links y rezá». Podés armar el overlay con bloques, columnas y estilos propios.
• Patrones como unidad: al insertar un patrón se comporta como un bloque; editás contenido sin desarmar toda la estructura. El modo contentOnly protege el diseño de ediciones accidentales.
• CSS a nivel de bloque: un campo de CSS custom en el inspector del bloque, para ajustes puntuales.
• Revisiones visuales: timeline con marcadores de qué cambió, más legible que el diff de HTML puro.

Bloques nuevos y mejoras concretas

En 7.0 entran, entre otros, el bloque de Iconos, el de Breadcrumbs y mejoras al bloque de Headings. La galería gana lightbox con navegación. El Cover puede usar video embebido de fondo. Hay mejoras de performance en priorización de carga de imágenes (para que imágenes ocultas en overlays no frenen lo crítico) y carga on-demand de estilos de bloques en temas clásicos.

En números del Field Guide de 7.0: más de 419 tickets de Core cerrados en el milestone, con centenares de fixes y enhancements también del lado Gutenberg. No es un release cosmético.

Requisito de PHP

7.0 sube el mínimo a PHP 7.4. En la práctica, si tu hosting WordPress en Uruguay todavía te deja en 7.2 o 7.3, tenés un problema de plataforma, no solo de WordPress. En HDS trabajamos con PHP 8.x en los planes de hosting WordPress; es el piso sensato para rendimiento y soporte.

WordPress 7.0.2: el parche que no podés postergar

El 17 de julio de 2026, WordPress publicó 7.0.2. No trae features nuevas de producto. Trae seguridad.

Qué se corrigió (en lenguaje claro)

El anuncio oficial lista dos reportes:

1. Una inyección SQL facilitada (reportada por TF1T, dtro y haongo).
2. Una confusión de rutas en el endpoint batch de la REST API que, combinada con la inyección SQL, puede llevar a ejecución remota de código (reportada por Adam Kues de Assetnote / Searchlight Cyber).

Los identificadores públicos son CVE-2026-60137 y CVE-2026-63030.

En criollo: un atacante sin login podía, en versiones afectadas, abusar de la API REST por lotes y llegar a un escenario grave en el servidor. Por eso el core habilitó actualizaciones forzadas en sitios con auto-update activo.

Qué versiones quedan bien

Según el mismo anuncio y los backports:

Rama	Versión mínima segura para estos fallos
7.0.x	7.0.2
6.9.x	6.9.5 (ambos fallos)
6.8.x	6.8.6 (el primero; la cadena completa RCE arranca en 6.9)
7.1 beta	7.1 beta 2 en adelante
Anterior a 6.8	No afectadas por estos dos issues puntuales

«Anterior a 6.8 no afectada por estos dos» no significa «dejar el sitio en 5.x y dormir tranquilo». Significa solo el alcance de este advisory. Un core viejo sigue siendo un blanco para otras vulnerabilidades y plugins abandonados.

Cómo verificar en 2 minutos

1. Entrá al escritorio de WordPress.
2. Mirá la versión en el pie del admin o en Escritorio → Actualizaciones.
3. Si no ves 7.0.2 / 6.9.5 / 6.8.6 según tu rama, actualizá.
4. Si el panel dice «está actualizado» pero estás en una rama vieja (por ejemplo 6.9.4), no estás a salvo de este advisory.

Backup antes, sí. Pero no uses el backup como excusa para no parchear un RCE pre-auth.

WordPress 7.1 en beta: qué se sabe hasta ahora

La versión estable de 7.1 todavía no salió. Lo que sigue viene del anuncio de Beta 1 y de las notas de Beta 4. Puede haber ajustes hasta el release candidate y el 19 de agosto.

Estilos responsive de verdad (no solo mostrar/ocultar)

En 7.0 podías ocultar un bloque por viewport. En 7.1 la beta apunta a definir cómo se ve un bloque en distintos tamaños de pantalla desde el editor y desde Global Styles, sin CSS a mano. Los autores de temas pueden definir breakpoints propios en theme.json.

La Beta 4 sumó un opt-out (responsiveEditingEnabled) para sitios que quieran desactivar la edición responsive en el editor si el UX todavía les genera fricción de soporte. Los estilos responsive ya guardados siguen renderizando en el front. Eso es señal de que la feature es central, pero el equipo todavía escucha feedback de implementación.

Estados interactivos (hover, focus)

La beta describe controles estandarizados para estilar cómo reacciona un bloque al hover o al focus, tanto en Global Styles como en instancias sueltas. Menos CSS de «botón que cambia de color al pasar el mouse».

Notes más útiles para equipos

Notes (comentarios de colaboración asíncrona en el editor) crecen en la beta:

• Formato en el texto de la nota (negrita, itálica, código, links).
• @menciones a colaboradores.
• Varias conversaciones por el mismo bloque.
• Notas inline sobre una selección de texto, no solo sobre el bloque entero.
• Notas largas colapsables.

En Beta 4 se reportan fixes para que las notas queden bien ancladas al pasaje y las personas etiquetadas se muestren con claridad. La colaboración en tiempo real (varios editores a la vez en el mismo documento) no es el foco confirmado de este ciclo en los anuncios de 7.1; lo que avanza es el flujo asíncrono.

Medios: HEIC del iPhone, AVIF, WebP y editor unificado

El procesamiento client-side de medios en la beta amplía formatos: HEIC (fotos de iPhone), UltraHDR, AVIF, WebP, y conversión GIF a video para archivos más livianos. Hay indicador de progreso y reintentos si se corta la conexión.

El Media Editor Modal junta recorte libre o por ratio, rotación y edición de metadatos en un solo flujo. Las galerías pueden tomar medios ya adjuntos al post; la biblioteca de medios gana scroll infinito por defecto en la vista grilla.

Bloques nuevos anunciados en la beta

El anuncio de Beta 1 menciona, entre otros:

• Playlist: colección de audios (podcasts, música) con visualización opcional de waveform.
• Tabs: paneles con pestañas para organizar contenido sin alargar la página.

También hay mejoras en fondos (gradiente + imagen a la vez en más bloques), toggle «marcar como decorativa» en imágenes (accesibilidad), y barra de admin persistente dentro de los editores.

Calendario oficial (no inventado)

Según el cronograma de release parties de 7.1:

• Beta 1: 15 de julio de 2026
• Beta 4: 29 de julio de 2026
• RC 1: 5 de agosto de 2026
• Release estable: 19 de agosto de 2026 (alineado con WordCamp US)

Hasta que no exista el post de release estable en wordpress.org/news, cualquier «7.1 ya está» en un grupo de Facebook es ruido.

Impacto práctico para sitios uruguayos

Seguridad primero, features después

Si tu sitio vende, agenda turnos o recibe leads, el orden es:

1. Confirmar 7.0.2 / 6.9.5 / 6.8.6.
2. Revisar plugins y tema (actualizaciones y abandono).
3. Recién después planear el salto a 7.1 estable.

Un e-commerce en Montevideo o un hotel en Punta del Este no gana nada estrenando Tabs en beta si el core tiene un advisory crítico sin aplicar.

Rendimiento y celular

Mucha audiencia local entra por el teléfono. La visibilidad por dispositivo (7.0) y los estilos responsive por viewport (7.1 beta) bajan la dependencia de builders pesados. Menos plugin de «mobile menu + hide section + mega menu» suele significar menos CSS/JS y menos conflictos.

El procesamiento de medios en el navegador (7.1 beta) también alivia al servidor en uploads grandes: útil en conexiones inestables y en planes compartidos donde el CPU se comparte.

Plugins «a medida» y Divi / builders

Si tu sitio cuelga de un page builder o de un plugin custom viejo, un major (7.0 → 7.1) merece staging. El editor iframed y los cambios de Block API ya venian endureciéndose en 7.0; 7.1 sigue por ese camino. Probar en producción el día del release es la receta clásica del sitio en blanco un viernes a la tarde.

PHP y hosting

PHP 7.4 como mínimo de 7.0 es piso histórico, no techo. Para 2026 conviene 8.2 u 8.3. Si tu proveedor no te deja elegir versión de PHP o tarda semanas en parches de core, el cuello de botella no es WordPress: es el hosting.

Cómo gestionamos las actualizaciones major en HDS

En clientes con mantenimiento de WordPress no «apretamos Actualizar» y cruzamos los dedos. El flujo típico ante un major o un security release fuerte es este.

Antes

• Inventario: versión de core, PHP, tema, plugins críticos (WooCommerce, formularios, SEO, caché, seguridad).
• Backup completo (archivos + base) con retención clara.
• Copia en staging o clon cuando el sitio es sensible (tienda, membresías, turnos).
• Lectura del advisory oficial y del Field Guide / notas de beta, no de hilos de redes.

Durante

• En security releases como 7.0.2: priorizamos el parche. Si hay auto-update forzado, igual verificamos que la versión quedó aplicada (no siempre llega si el auto-update está desactivado o el firewall bloquea wordpress.org).
• En majors (7.0, y cuando salga 7.1 estable): actualizamos en staging, recorremos home, checkout o formularios clave, wp-admin y un par de plantillas del tema.
• Revisamos el log de errores de PHP y el front en móvil.

Después

• Confirmamos versión en el pie del admin.
• Miramos 24–48 h por regresiones (formulario que no envía, layout roto, plugin que asume una API vieja).
• Documentamos qué se actualizó y qué quedó pendiente (por ejemplo un plugin sin release compatible).

Si no tenés mantenimiento y administrás vos el sitio: el mismo orden aplica. La diferencia es quién hace el checklist y a qué hora.

Plan recomendado (y qué no hacer)

Hacé esto

1. Hoy: verificá que estás en 7.0.2, 6.9.5 o 6.8.6 según tu rama.
2. Esta semana: actualizá plugins y tema con backup previo; borrá lo que no uses.
3. Antes del 19 de agosto: armá un entorno de prueba si vas a subir a 7.1 el día del release o la semana siguiente.
4. Cuando salga 7.1 estable: leé el post oficial de release y el Field Guide; no te guíes solo por el changelog del panel.
5. PHP: pedile a tu host 8.2+ si todavía estás abajo.

No hagas esto

• Instalar 7.1 Beta 4 (ni ninguna beta) en el sitio que te genera plata. El propio anuncio lo dice: solo testing y desarrollo.
• Dejar auto-updates de major sin staging en un WooCommerce con stock y medios de pago.
• Actualizar core, tema y 15 plugins juntos un domingo a la noche sin backup.
• Asumir que «el hosting se encarga» si nunca contrataste ese servicio ni confirmaste el proceso.

Cierre

WordPress 7.0 ya cambió el piso: Connectors e IA opt-in, admin más usable, visibilidad por dispositivo, patrones más seguros de editar, bloques nativos que sacan plugins de encima. WordPress 7.0.2, del 17 de julio de 2026, fue un recordatorio de que la seguridad no espera al rediseño del home. WordPress 7.1, aún en beta al 29 de julio de 2026, apunta a estilos responsive por viewport, estados hover/focus, Notes más ricas y un flujo de medios mucho más amable con fotos de celular modernas.

Para un dueño de sitio en Uruguay la receta es aburrida y efectiva: parcheá lo crítico, proba lo major, no mezcles beta con producción. Si querés que ese proceso lo lleve alguien que vive de mantener WordPress en servidores propios, mirá el mantenimiento de WordPress y los planes de hosting WordPress. Y si estás eligiendo dónde hospedar desde cero, el hosting WordPress en Uruguay es el punto de partida.

Fuentes principales: WordPress 7.0 «Armstrong», 7.0.2 Release, 7.1 Beta 1, 7.1 Beta 4, Field Guide 7.0.