WordPress 7.2: novedades y cómo prepararte antes del 8-12

WordPress 7.2 llega el 8 de diciembre. Qué cambia, qué puede romper en tu web o tienda y cómo prepararte sin prisas: staging, copia y plugins.

Por Diego Meijide ·

WordPress 7.2 está en beta desde el 20 de octubre de 2026 y la versión final tiene fecha: 8 de diciembre. Todavía falta un mes largo, así que no hay nada que actualizar hoy. Pero sí hay cosas que mirar, porque algunos cambios de esta versión no se ven en el panel y los notan los plugins y los temas.

Una advertencia antes de seguir: todo lo que sigue sale de la beta y de las notas oficiales para desarrolladores. Una beta puede cambiar hasta que sale la versión final, y la propia entrada de lanzamiento pide no instalarla en webs en producción.

El calendario

Hito

Fecha

Beta 1

20-10-2026

Beta 2

27-10-2026

Beta 3

3-11-2026

Candidata a versión final (RC1)

17-11-2026

RC2

24-11-2026

Versión final

8-12-2026

Fuente: calendario oficial de 7.2. La fecha puede moverse si aparece algo grave.

Lo que verás tú, como dueño de una web

Un tema por defecto nuevo, y sin año en el nombre. Los temas que traía WordPress se llamaban Twenty Twenty-Five, Twenty Twenty-Four… Se acaba. El próximo se llama Ipsum, un tema de bloques para blogs, deliberadamente mínimo, y los temas por defecto futuros tendrán nombre propio y cambiarán «cuando el diseño lo pida», no cada año. Según el equipo, todas sus combinaciones de color cumplen el nivel AA de accesibilidad (WCAG).

Dos matices. El anuncio lo describe como una propuesta «planeada» para 7.2, y no he podido confirmar si ya viene dentro de la Beta 1. Y no cambia el tema que usas: si tu web tiene tema propio o comercial, Ipsum no te afecta. En general, los temas que trae WordPress de serie se incluyen pero no se activan por sí solos.

Más control sobre cómo se ve cada cosa en móvil y escritorio. La entrada de la beta habla de controles responsive en más herramientas (galerías, recorte de imágenes), sombras de texto, edición de menús desde la barra lateral del editor y notas que se quedan abiertas junto a los ajustes del bloque. Útil si editas tú mismo; invisible si no tocas el editor.

Las imágenes se procesan en el navegador antes de subirlas. La beta añade redimensionado, compresión y conversión de formato en el lado del cliente. En teoría, menos carga para el servidor. En la práctica conviene probarlo con tu flujo de subida habitual, sobre todo si usas un plugin de optimización de imágenes: dos cosas haciendo lo mismo no siempre se llevan bien.

Iconos nuevos en el panel. Los Dashicons de la barra de administración y del menú lateral se sustituyen por los de la biblioteca de iconos de WordPress. Es un cambio estético, pero tiene letra pequeña que verás más abajo.

Un cambio de seguridad que no es de 7.2 pero te afecta

Las notas para desarrolladores de 7.2 mencionan que las versiones de plugins pasan por una revisión automática de seguridad. No es una novedad de 7.2: funciona desde junio de 2026 y se anunció en septiembre.

Funciona así: cada versión nueva de un plugin del directorio de WordPress.org espera un periodo de espera (hoy, seis horas) antes de ofrecerse a los sitios. Durante ese tiempo la analizan varios modelos de IA junto con Jetpack Scan. Si la puntuación de riesgo es alta, la versión se bloquea y no se distribuye hasta que el autor publique otra corregida. Tu web sigue con la versión anterior, y el plugin no se retira del directorio.

El motivo, según el propio equipo: el 28 de julio se detectó así una puerta trasera en un plugin con unas 20.000 instalaciones antes de que llegara a ningún sitio.

Qué significa para ti, con dos precauciones:

  • Es una capa más, no una garantía. La documentación admite que los falsos positivos no son cero, y no hay forma de que lo detecte todo.
  • Solo cubre lo que se distribuye por WordPress.org. Los plugins premium que se actualizan desde la web del fabricante no pasan por ahí, o al menos la documentación oficial no dice que lo hagan.
  • Una consecuencia práctica que deduzco yo, no que diga la fuente: una actualización de seguridad de un plugin puede tardar algo más en aparecerte. No cambia nada de lo que tengas que hacer.

Lo que puede romper

Aquí está lo que de verdad mueve a probar en staging. La guía «What's new for developers (October 2026)» lista qué revisar antes de la beta.

wp_kses() reconstruida. Es la función que limpia el HTML que escriben usuarios o plugins antes de guardarlo o mostrarlo. Se está rehaciendo sobre la API de HTML del propio WordPress, con un objetivo de 7.2 o 7.3 según cómo vayan las pruebas. El resultado normaliza el HTML de salida, elimina el contenido de las etiquetas script y style y rechaza cierto SVG, MathML y comentarios mal formados. Si un plugin compara, guarda o prueba ese HTML tal cual, puede dar resultados distintos: WooCommerce ya ha tenido que ajustar una de sus pruebas. Hay un filtro temporal, wp_kses_force_legacy_parser, para volver al comportamiento antiguo, pero la propia guía lo trata como parche transitorio.

Iconos y CSS del panel. Unos 330 iconos del núcleo pasan a ser de trazo. Si un plugin o un tema tiene CSS propio para el panel que dependa de fill sobre esos iconos, puede verse mal. Estético, sí, pero un botón sin icono visible en un panel de pedidos es un problema.

Modo SQL. WordPress 7.2 quita NO_BACKSLASH_ESCAPES de la sesión de base de datos. Es una mejora: en servidores que lo tenían activo, las consultas con caracteres escapados podían fallar o devolver datos equivocados. Solo da guerra si algo a medida depende de ese modo.

Componentes del editor retirados en 7.4. Cinco componentes (Divider, ResponsiveWrapper, Scrollable, ZStack, Elevation) quedan obsoletos y se eliminarán en 7.4. No rompen nada hoy. Si tienes un plugin o bloque a medida, es una tarea para el desarrollador, con calma.

Compatibilidad con PHP. No he encontrado publicados los requisitos mínimos de PHP para 7.2. Para saber el estado actual, mira la tabla de compatibilidad de PHP y WordPress. Si todavía estás en una versión de PHP sin soporte, esa tarea es anterior a esta, como contamos en lo de la vulnerabilidad de PHP.

Cómo prepararte, según tu caso

Web de contenidos o de presentación, con pocos plugins.

Actualiza cuando salga la versión final y pasen unos días sin incidencias graves. Haz copia antes y revisa la home, un formulario y la página de contacto después.

Tienda WooCommerce.

No actualices el día 8. Espera a la primera versión de mantenimiento (los números tipo 7.2.1 suelen arreglar lo que la versión grande dejó pasar), y antes prueba en una copia: pedido de prueba completo, pasarela de pago, emails de pedido y cualquier plugin que toque el checkout. Es la misma lista de la guía de PHP, y por la misma razón.

Web con constructor visual o plugins a medida.

Pregunta, o mira en la ficha de cada plugin, si su desarrollador ya declara compatibilidad con 7.2. Un plugin que no se ha actualizado en dos años es el primero que vigilar. Si tienes código propio que limpia HTML con wp_kses(), que lo revise quien lo escribió ya, no en diciembre.

Si prefieres no mirar nada.

Es razonable. Tu hosting o quien te mantiene la web debería probarlo en una copia y avisarte si algo falla.

Una receta que sirve para cualquier versión

  1. Copia completa (archivos y base de datos) antes de tocar nada, guardada fuera del servidor.
  2. Actualiza primero lo que ya tienes: la rama actual de WordPress, plugins y tema. La guía para desarrolladores señala que en septiembre hubo tres versiones de seguridad.
  3. Clona la web a un entorno de pruebas y actualiza ahí.
  4. Prueba lo que da dinero: formulario, checkout, emails, área de cliente.
  5. Mira el registro de errores y la consola del navegador.
  6. Si todo va bien, repite en producción en una hora tranquila, no un viernes por la tarde.

Si quieres probar la beta tú mismo

Hazlo en una copia o en WordPress Playground, nunca en la web real. Con WP-CLI sería wp core update --version=7.2-beta1. Si te sale algo raro, se puede reportar en el foro Alpha/Beta de WordPress.org, y ayuda a que lo arreglen antes de diciembre.

Cuándo actualizar y cuándo no

La regla que recomiendo es simple, y sirve para esta versión y para las siguientes:

  • Versiones de seguridad: rápido, en uno o dos días. Quien ataca lee los mismos avisos que tú.
  • Versiones grandes (7.2, 7.3…): con una semana o dos de margen, primero en copia, y en tiendas con más cuidado aún.
  • Versiones menores de corrección (7.2.1…): cuando salen, tras mirar qué arreglan.

Datos contrastados el 25 de octubre de 2026, con la beta aún en marcha. Si ves algo desactualizado, escríbenos y lo corregimos.

Y si prefieres delegar el proceso, en AGENCIA RSE las pruebas en una copia y la revisión del checkout forman parte del mantenimiento WordPress. Pero con la receta de arriba puedes hacerlo tú.

¿Quieres que lo hagamos por ti? Mira cómo trabajamos en este servicio o cuéntanos tu caso en el chat.

¿Hablamos de tu web?

No hace falta que lo tengas todo claro. Cuéntanos qué tienes y qué te gustaría conseguir, y te diremos qué haríamos nosotros y cuánto costaría.

Primera consulta sin coste. Analizamos lo que nos cuentas y te damos una respuesta en 48 h laborables.

Tu proyecto Contratar mantenimiento

Asistente de proyectos

IA AGENCIA RSE · responde al momento

    Estás hablando con una IA. Puedes escribir o pulsar para responder por voz. Una persona revisa cada ficha antes de responderte.

    Pago seguro con Stripe

    Preparando el pago…