Introducción
WordPress 7.2 está programado para el 8 de diciembre de 2026. Las versiones beta ya están disponibles y el plugin de Gutenberg ya ha incluido varios de los cambios más importantes. Eso significa que el riesgo no espera al día del lanzamiento oficial. Cualquier sitio de cliente que todavía use el plugin de Gutenberg para obtener los bloques más recientes ya está ejecutando parte del nuevo código. Una página de ajustes que queda en blanco, un bloque que deja de responder o una pantalla de administración que se comporta de forma diferente pueden aparecer semanas antes de que llegue la actualización del núcleo.
Para agencias y equipos de producto que desarrollan plugins, bloques personalizados o sitios de clientes, esta no es una actualización rutinaria. Es una versión que elimina en silencio código obsoleto desde hace tiempo, endurece la validación de tipos, cambia la forma en que se cargan los assets del administrador e introduce nuevas APIs que vale la pena aprovechar. El costo de esperar hasta la última semana es más alto de lo habitual porque parte de los problemas ya está viva en producción.
Por qué esta versión importa más que las notas de marketing
La mayor parte de la cobertura se centrará en el nuevo tema predeterminado, las mejoras de Notes y el bloque de Tabla de Contenidos que pasa a estable. Esas funciones importan para los editores. Para los desarrolladores, los elementos de mayor impacto están más abajo en el registro de cambios. React 19 ya es el valor predeterminado en las versiones recientes de Gutenberg. Se eliminaron el estado antiguo del router, las capas de compatibilidad de la API de Fuentes y varios helpers de la Interactivity API. theme.json ya no perdona en silencio valores con tipos incorrectos. Los atributos de bloque se tratan ahora de forma explícita como no confiables en el momento del renderizado. Los scripts del administrador ya no se concatenan. Las herramientas de pruebas unitarias se están alejando de Jest.
Cada uno de estos cambios es pequeño por sí solo. Juntos forman una lista de verificación que todo producto serio de WordPress o código de cliente debería recorrer antes de diciembre. Los sitios que se salten el trabajo descubrirán los problemas en producción en lugar de en staging.
Qué puede romper tu código actual
React 19 ya está activo en sitios con Gutenberg
Gutenberg 24.2 carga React 19 para react y react-dom de forma predeterminada. Solo los sitios que ejecutan un tema o plugin de una lista conocida de incompatibilidades se quedan en React 18. Eso significa que la actualización no espera a la versión 7.2 del núcleo. Un cliente que mantiene activo el plugin de Gutenberg ya está probando tu código contra React 19.
Los cambios que más afectan al código de WordPress son claros pero fáciles de pasar por alto. defaultProps en componentes de función se ignora, por lo que los valores predeterminados deben moverse a la lista de parámetros. ReactDOM.render desapareció, lo que implica que cualquier llamada restante a wp.element.render debe convertirse en createRoot. propTypes se ignoran en silencio. El atributo inert se comporta de forma diferente y Gutenberg incluye un pequeño paquete de ayuda para mantener ambos versiones de React correctas.
// before: silently ignored in React 19
function Badge( { label } ) { /* ... */ }
Badge.defaultProps = { label: 'New' };
// after
function Badge( { label = 'New' } ) { /* ... */ }La respuesta práctica es sencilla. Instala Gutenberg 24.2 en un sitio de staging, abre cada pantalla de administración y cada bloque que entregas, y observa la consola. Si algo se rompe en un sitio en producción, React 19 se puede desactivar en Gutenberg > Experiments, pero eso solo gana tiempo.
Se está eliminando código obsoleto
Las versiones recientes de Gutenberg limpiaron varias superficies que llevaban tiempo marcadas como obsoletas. La capa de compatibilidad de la API de Fuentes, el paquete expuesto wp.sync y un conjunto de deprecaciones vencidas de la Interactivity API desaparecieron. El estado de navegación antiguo del router está deprecado a favor de una API más limpia. El código que todavía comprueba state.navigation.hasStarted debe pasar a state.navigating. state.initiator está disponible cuando necesitas saber qué bloque inició la navegación.
// deprecated
if ( state.navigation.hasStarted ) { /* show loader */ }
// use
if ( state.navigating ) { /* show loader */ }Estas eliminaciones no son sorpresas. Llevaban avisos de deprecación desde hace tiempo. La diferencia en 7.2 es que los avisos se convierten en errores reales.
theme.json deja de perdonar tipos incorrectos
Global Styles ahora ignora los valores de theme.json cuyos tipos no coinciden con el esquema. Un número donde se espera una cadena CSS, o una cadena donde corresponde un objeto, simplemente se descarta. Un ajuste que parecía funcionar puede dejar de hacerlo sin ningún error evidente en el navegador.
Agregar la línea del esquema oficial a cada theme.json que mantienes convierte estos errores en advertencias del editor en lugar de fallos silenciosos.
{
"$schema": "https://schemas.wp.org/trunk/theme.json"
}Los atributos de bloque se tratan oficialmente como no confiables
La documentación ahora lo dice con claridad. Los atributos de bloque y los valores de Global Styles son no confiables en el momento del renderizado. Cualquier persona con acceso al editor, una importación o una llamada REST puede colocar datos arbitrarios en un atributo. Cada valor que llega al front-end debe escaparse en render.php. Tratar los atributos como datos confiables ya no es un patrón aceptable.
<a <?php echo get_block_wrapper_attributes(); ?>
href="<?php echo esc_url( $attributes['url'] ?? '' ); ?>">
<?php echo esc_html( $attributes['label'] ?? '' ); ?>
</a>Se desactiva NO_BACKSLASH_ESCAPES
WordPress desactiva el modo SQL NO_BACKSLASH_ESCAPES en su sesión de base de datos. En la mayoría de los hosts esto no cambia nada. En hosts que establecen el modo de forma global, las consultas que antes funcionaban pueden empezar a devolver resultados incorrectos o fallar. Revisar el sql_mode global y confirmar que tus consultas no dependen del comportamiento anterior vale la pena unos minutos.
wp db query "SELECT @@GLOBAL.sql_mode;"Si realmente necesitas el modo, el filtro solo funciona desde un drop-in db.php porque WordPress se conecta a la base de datos antes de que se carguen los plugins.
add_filter( 'incompatible_sql_modes', function ( $modes ) {
return array_diff( $modes, array( 'NO_BACKSLASH_ESCAPES' ) );
} );Dashicons abandona el menú de administración y los scripts dejan de concatenarse
La barra de administración y el menú pasan del font Dashicons a iconos SVG de @wordpress/icons. Los plugins que estilizan los iconos del menú mediante clases CSS de Dashicons o que pasan dashicons-* a add_menu_page necesitan volver a probarse. Un data URI de SVG ha funcionado durante años y sigue siendo la opción más segura.
Al mismo tiempo, los scripts y hojas de estilo del administrador ya no se concatenan. WordPress los carga de forma individual para mejorar el caché del navegador y precarga los assets de la siguiente pantalla que el usuario probablemente abrirá. Los plugins que dependen del orden de carga, hacen dequeue de scripts del núcleo o trabajan alrededor de la concatenación deben probarse en Beta 1.
Las herramientas de pruebas se alejan de Jest
@wordpress/scripts cambió su ejecutor de pruebas unitarias a Vitest y deprecó las herramientas de Jest. El cambio es mecánico para la mayoría de las suites de pruebas, pero la configuración personalizada de Jest, las rutas de snapshots y la dependencia de los globales de Jest requieren tiempo real de migración. Hacer el trabajo en una tarde tranquila ahora es preferible a hacerlo en la semana del lanzamiento.
// Jest
const onSave = jest.fn();
jest.mock( '@wordpress/api-fetch' );
// Vitest
import { vi } from 'vitest';
const onSave = vi.fn();
vi.mock( '@wordpress/api-fetch' );Qué vale la pena construir encima
Secrets API
WordPress nunca ha tenido un lugar adecuado para las credenciales. Cada plugin que necesita una clave de API históricamente la ha escrito en la tabla de opciones en texto plano. Esa clave aparece después en los dumps de base de datos, en las copias de seguridad y en cada clon de staging. La Secrets API que llegó en Beta 1 ofrece cifrado en reposo, rotación de credenciales y la posibilidad de que los hosts muevan el almacenamiento a un proveedor externo. Una pantalla de ajustes está prevista para una versión posterior, pero las funciones del núcleo y el soporte de WP-CLI ya están presentes.
El patrón recomendado es enrutar cada clave que lee tu plugin a través de una sola función interna que haga fallback a get_option en versiones anteriores de WordPress. Cuando 7.2 se convierta en tu versión mínima soportada, pasar completamente a la nueva API es un solo cambio en lugar de muchos.
// One-time migration of an existing option.
// Rotate the key afterwards because the old plaintext value is already in your backups.
wp_import_option_as_secret( 'myplugin_api_key', 'myplugin/api-key' );
// At the point of use
$secret = wp_get_secret( 'myplugin/api-key' );
if ( $secret instanceof WP_Secret ) {
$api_key = $secret->reveal();
} elseif ( is_wp_error( $secret ) ) {
// The secret exists but cannot be read, for example after a key change
}Site Editor extensible
Este es el cambio con la cola más larga. Hoy un plugin que necesita una interfaz de administración real normalmente crea su propia página de menú, monta una aplicación React en un div y mantiene su propio enrutamiento y componentes de tabla. El Site Editor reconstruido, basado en el paquete de enrutamiento @wordpress/boot, permite a los plugins registrar pantallas y ajustes dentro de la misma interfaz que ya usan los editores. DataViews y DataForms siguen el mismo camino. Los campos, las acciones y las configuraciones de vista se vuelven registrables en el servidor.
Una lista de reservas, una vista de CRM o una pantalla de gestión de pedidos pueden vivir junto a las plantillas y las páginas con los mismos filtros, acciones masivas y diseños. El paquete sigue siendo algo que empaquetas tú mismo, lo que te da control de versión a través de varias versiones de WordPress. Prototipar ahora una vista de lista sencilla es una forma de bajo riesgo de conocer la nueva superficie.
Estilos responsive y block supports para bloques personalizados
Los breakpoints llegaron al editor en 7.1, pero solo para los controles del núcleo. Los controles personalizados del inspector se mantenían iguales en todos los dispositivos. 7.2 añade una API pública para estados de viewport en controles personalizados. Un cliente que cambia el editor a vista de tableta, ajusta el espaciado del núcleo y luego usa el control de columnas de tu bloque ya no verá que los valores de escritorio cambien por accidente.
Al mismo tiempo, el núcleo sigue ampliando los block supports. Sombras, fondos, degradados, bordes y dimensiones mínimas están disponibles en muchos más bloques que antes. Los selectores de sombra y los campos de altura mínima hechos a mano a menudo se pueden eliminar a favor de una declaración de supports. El resultado es menos código que mantener, valores que participan en Global Styles y cualquier manejo responsive y de estados que el núcleo añada después.
"supports": {
"shadow": true,
"dimensions": { "minHeight": true },
"background": { "backgroundImage": true, "gradient": true }
}La Interactivity API gana data-wp-html
Hasta ahora la Interactivity API podía renderizar texto de forma reactiva pero no tenía una forma soportada de renderizar HTML. Existían workarounds, pero no eran oficiales. La nueva directiva data-wp-html resuelve el problema. Los valores deben marcarse de forma explícita como confiables con asDangerousHTML, y el patrón limpio es sanitizar en el servidor y solo marcar el resultado como confiable en el store. La entrada del usuario nunca entra sin escapar.
wp_interactivity_state( 'myPlugin', array(
'descriptionHtml' => wp_kses_post( $description ),
) );import { asDangerousHTML, store } from '@wordpress/interactivity';
const { state } = store( 'myPlugin', {
state: {
get description() {
return asDangerousHTML( state.descriptionHtml );
},
},
} );<article data-wp-html="state.description"></article>Lo que recomendamos
Trata WordPress 7.2 como un ciclo de compatibilidad obligatorio y no como una actualización opcional. Coloca Beta 1 o la última beta en un sitio de staging. Instala Gutenberg 24.2 en un segundo entorno. Abre cada bloque y cada pantalla de administración que entregas con la consola abierta. Busca en tu código base defaultProps, wp.element.render y el estado de navegación antiguo del router. Añade la línea del esquema a cada theme.json. Escapa cada atributo en cada render.php. Migra las pruebas unitarias a Vitest. Enruta las claves de API a través de una sola abstracción que más adelante pueda llamar a la Secrets API. Prototipa una pantalla dentro del Site Editor extensible.
Ninguno de estos pasos es especialmente grande por sí solo. Juntos evitan el tipo de sorpresas en producción que dañan la confianza del cliente y consumen horas facturables que podrían haberse dedicado a trabajo nuevo.
Cómo abordamos esto en Boostmonitor
Cuando se acerca una versión mayor de WordPress, la tratamos como una revisión de arquitectura y no solo como un cambio de versión. Ejecutamos las bases de código completas de clientes y productos contra la beta y el Gutenberg más reciente en entornos de staging aislados. Buscamos primero los fallos silenciosos que nunca lanzan un error duro en el navegador, porque esos son los que aparecen semanas después como “algo se siente raro”. Migramos las herramientas de pruebas y el almacenamiento de credenciales temprano para que el cambio no choque con el lanzamiento de un cliente. Evaluamos nuevas APIs como el Site Editor extensible y la Secrets API frente a necesidades reales de producto y no frente a la descripción de marketing.
WordPress no es la limitación. La arquitectura y el timing sí lo son. Una versión como 7.2 recompensa a los equipos que se mantienen al día y penaliza a los que esperan hasta la semana anterior a la fecha oficial. Esa es la postura que aplicamos a cada plataforma de cliente y a cada producto interno que mantenemos.
Preguntas frecuentes
Cuándo se lanza WordPress 7.2
WordPress 7.2 está programado para el 8 de diciembre de 2026. El Release Candidate 1 está planeado para el 17 de noviembre. La página oficial de la versión en make.wordpress.org tiene el calendario actualizado.
React 19 ya está en el núcleo
El soporte completo de React 19 es poco probable que llegue al núcleo en 7.2. El plugin de Gutenberg carga React 19 de forma predeterminada desde la versión 24.2, por lo que cualquier sitio que ejecute el plugin ya está en la nueva versión.
La colaboración en tiempo real está incluida
No. La colaboración en tiempo real se dejó deliberadamente fuera del roadmap de 7.2. Notes con modo de sugerencias es la función de colaboración que llega en este ciclo.
Qué deben probar primero los desarrolladores de plugins
Los bloques y las pantallas de administración en Gutenberg 24.2 con React 19, cualquier uso restante de deprecaciones eliminadas, la corrección de tipos en theme.json y el escape correcto de los atributos de bloque en render.php.
Qué es la Secrets API
Es un nuevo almacén cifrado para credenciales como claves de API. Llegó en Beta 1 con funciones para guardar y recuperar secretos, además de soporte de WP-CLI. Una pantalla de ajustes está prevista para una versión posterior.
