WordPress 7.2 será la última versión principal de 2026. El calendario oficial sitúa la Beta 1 entre el 20 y el 22 de octubre y la versión final entre el 8 y el 10 de diciembre. A 12 de septiembre, el ciclo todavía está antes de la Beta 1, por lo que este es un buen momento para preparar un entorno descartable, seguir trunk y las versiones recientes de Gutenberg y detectar incompatibilidades mientras el código sigue cambiando. La clave es separar dos cosas: probar lo que ya existe en desarrollo y considerar cada novedad de Gutenberg como una función garantizada de WordPress 7.2. El propio proyecto indica que las nuevas funciones solo se considerarán si están razonablemente listas. Consulta el calendario oficial de WordPress 7.2 y el resumen de septiembre para desarrolladores.
Qué cambia cuando llega la Beta 1
Antes de la Beta 1, trunk todavía recibe trabajo de desarrollo y puede cambiar con frecuencia. Cuando comienza la fase beta, el ciclo se concentra en pruebas y correcciones de errores mientras empiezan a consolidarse las Dev Notes. Esto hace que las semanas previas al 20–22 de octubre sean especialmente útiles para autores de plugins y temas: un conflicto detectado ahora puede revelar una API en transición, una deprecación o una regresión que todavía puede investigarse con contexto reciente.
No uses esta fase como motivo para actualizar producción. El objetivo debe ser un entorno donde sea aceptable romper el editor, perder contenido de prueba, desactivar extensiones y cambiar de versión repetidamente.
Prepara un entorno de pruebas que puedas romper
El escenario ideal es un staging, entorno local o instancia temporal que reproduzca la combinación real de tema, plugins críticos, PHP y contenido, pero sin datos sensibles ni tráfico de clientes. Para seguir la próxima versión principal, la documentación oficial permite usar el plugin WordPress Beta Tester en “Bleeding edge nightlies” o actualizar a trunk con WP-CLI. La guía de beta testing también recomienda este flujo para probar antes de las versiones preliminares formales.
Para cambios del editor, el resumen de septiembre recomienda ejecutar WordPress trunk junto con la versión más reciente de Gutenberg o abrir una instancia en Playground. Esto es útil porque parte del trabajo orientado al ciclo 7.2 aparece primero en Gutenberg. Conserva, sin embargo, una segunda instalación sin el plugin Gutenberg para distinguir el comportamiento del core en trunk del comportamiento experimental del plugin.
Matriz mínima de compatibilidad
| Capa | Qué probar | Por qué importa |
|---|---|---|
| Core | WordPress 7.1 estable y trunk de WordPress 7.2 | Comparar el último comportamiento estable con el desarrollo ayuda a identificar regresiones. |
| PHP | La versión usada en producción y al menos otra versión compatible con tu producto | Evita atribuir al core un error ligado a una combinación de PHP. La tabla oficial muestra WordPress 7.1 compatible con PHP 7.4 a 8.5; confirma de nuevo la matriz cuando se publique la documentación específica de 7.2. |
| Editor | Trunk sin Gutenberg y trunk con una versión reciente de Gutenberg | Separa los cambios ya integrados en el core del trabajo todavía experimental o en integración. |
| Tema | Tu tema principal y un tema predeterminado | Ayuda a aislar un conflicto del tema frente a una regresión de WordPress. |
| Plugins | Sin plugins, plugins críticos por separado y la pila completa | Muestra qué extensión introduce o expone el problema. |
| Navegador | Al menos los navegadores que declaras compatibles | Los errores del editor y de atajos pueden depender del entorno del navegador. |
La referencia oficial de PHP es PHP Compatibility and WordPress Versions. No supongas un nuevo requisito mínimo para 7.2 sin una nota oficial.
Plugins: empieza por las áreas con mayor riesgo de ruptura
Prioriza los plugins que modifican el editor, registran bloques, añaden pantallas de administración, alteran REST/AJAX, dependen de paquetes JavaScript de WordPress o mantienen integraciones con tipos de contenido y metadatos. Ejecuta primero los flujos que sostienen ingresos, publicación u operación: crear y editar contenido, guardar ajustes, procesar formularios, ejecutar tareas, autenticar integraciones y completar operaciones que escriben en la base de datos.
Entre los cambios ya destacados en Gutenberg 23.8 y 23.9 hay varios objetivos concretos de compatibilidad. Las plantillas de bloques internos están pasando de las props de InnerBlocks a la configuración del tipo de bloque; las props antiguas todavía funcionan, pero están deprecadas. DataViews está eliminando dependencias de APIs privadas, mientras que componentes que antes estaban detrás de esas APIs obtienen rutas públicas. Las variaciones y transformaciones de bloques también pueden declarar atajos de teclado. Si tu plugin toca estas áreas, no pruebes solo si la interfaz “abre”: verifica inserción, selección, transformaciones, undo/redo, guardado y recarga.
Lo mismo se aplica a extensiones del área de administración. Los editores ahora usan el esquema de colores del admin mediante un ThemeProvider y existe una exportación pública para leer esos colores. Los plugins que dibujan sus propios componentes en el admin deberían comprobar contraste, estados de foco y legibilidad con más de un esquema de colores.
Temas: céntrate en theme.json, Global Styles y espaciado
El trabajo reciente de Gutenberg incluye correcciones de schema para estados responsivos y pseudoestados en theme.json. También existen controles para desactivar la edición de estados y de responsividad mediante ajustes del editor sin eliminar los estilos ya definidos. Los temas que usan estas funciones deberían validar tres capas: lo que declara theme.json, lo que la interfaz de Global Styles permite editar y el CSS que realmente se renderiza en el front-end.
Otros puntos de Gutenberg 23.8/23.9 que merecen pruebas de regresión incluyen el estilo del elemento label, la edición de cite, campos de texto y selects en Global Styles, soporte de blockGap horizontal y vertical en el bloque Group, nuevos supports en bloques como List, Query No Results y Query Loop, además de ajustes en duotone, sombras y normalización del espaciado. No supongas que todos estos elementos llegarán sin cambios al 7.2 final; úsalos como mapa de pruebas mientras madura el ciclo.
Bloques y editor: prueba el comportamiento, no solo la apariencia
Un bloque puede verse correcto y aun así fallar en la serialización, en la selección o al volver a abrir una entrada. Para cada bloque propio o muy personalizado, prueba inserción, duplicación, transformaciones, drag and drop, atajos, copiar y pegar, undo/redo, guardar, recargar, vista de código cuando corresponda y renderizado en el front-end. Para bloques con InnerBlocks, incluye escenarios con plantilla inicial, inserción adicional y contenido ya existente.
Si tu plugin amplía el Site Editor, sigue también el trabajo del Site Editor extensible. El resumen de septiembre indica que este camino todavía es experimental, pero las directrices de contribución ya exigen que las nuevas funciones del Site Editor también funcionen allí. Es una señal para preparar pruebas, no para prometer soporte en producción antes de que se estabilice.
Hooks, logs y señales de deprecación
Activa observabilidad en el entorno de pruebas. Registra errores de PHP, supervisa el log de WordPress, mantén abierta la consola del navegador e inspecciona fallos de red. Avisos de funciones deprecadas, propiedades inesperadas, respuestas REST modificadas, errores JavaScript y cambios en el momento en que se ejecuta un hook pueden ser la primera señal de incompatibilidad.
Ejecuta el mismo flujo dos veces: una en la versión estable y otra en trunk. Si el comportamiento cambia, reduce la instalación a la configuración mínima posible. Una prueba con un tema predeterminado y los plugins desactivados es la base para decidir si has encontrado un problema del core; después reactiva solo el componente necesario para reproducirlo.
Cómo decidir si merece la pena reportar un fallo
Un reporte útil debe ser reproducible. El equipo de Test recomienda registrar el entorno, las versiones de WordPress y PHP, el navegador, el tema, los plugins, los pasos exactos, el comportamiento esperado y el resultado observado. La guía de reproducción de issues ofrece una plantilla e indica el plugin Test Reports para completar automáticamente parte de los datos del entorno.
Los problemas de WordPress Core normalmente se registran en Core Trac; las issues de Gutenberg van al repositorio de Gutenberg en GitHub. Antes de abrir algo nuevo, busca un ticket existente. Si puedes reproducirlo, añade tu escenario y los datos del entorno al ticket correspondiente. La documentación de Test Reports refuerza que el mejor lugar para el resultado de una prueba es el ticket, issue o pull request correspondiente.
Checklist práctico antes de la Beta 1
- Ahora: crea el staging o entorno local, registra versiones y copia los casos de prueba más importantes.
- Cada semana: actualiza trunk y, cuando tenga sentido, Gutenberg; ejecuta smoke tests en plugins y temas críticos.
- Plugins: busca deprecaciones, fallos de JavaScript, respuestas REST modificadas y problemas en pantallas de administración y bloques.
- Temas: revisa theme.json, Global Styles, style variations, espaciado, elementos y supports de bloques.
- Editor: prueba creación, edición, transformaciones, undo/redo, guardar, reabrir y renderizar en el front-end.
- Aislamiento: confirma cualquier regresión con un tema predeterminado y el conjunto mínimo posible de plugins.
- Beta 1: cuando llegue entre el 20 y el 22 de octubre, fija una ronda completa de regresión contra ese build y sigue las Dev Notes.
Lo que una prueba aprobada no demuestra
Que algo funcione hoy en trunk no garantiza compatibilidad con la versión final, porque el código todavía puede cambiar. Tampoco significa que una función vista en Gutenberg 23.8 o 23.9 se publique sin cambios en 7.2. El objetivo de esta fase es reducir sorpresas: detectar pronto dónde tu plugin, tema o bloque depende de un comportamiento que está cambiando y conservar un caso de prueba repetible en cada beta y release candidate.
Si tienes poco tiempo, concentra el esfuerzo en los flujos de mayor impacto y con mayor acoplamiento al editor o al core. Una lista corta de pruebas repetibles vale más que navegar al azar por el escritorio. Al llegar a la Beta 1, deberías saber qué componentes son críticos, qué escenarios ya tienen una baseline en WordPress 7.1 y cómo reproducir rápidamente cualquier diferencia en WordPress 7.2.
