Plan de desarrollo de WordPress 7.2: modo sudo, Secrets API, Gutenberg Notes y el equipo de lanzamiento

#Quién lidera el lanzamiento de WordPress 7.2

Matt Mullenweg es el Release Lead del equipo de lanzamiento de WordPress 7.2, según la página del lanzamiento 7.2. La misma página detalla el resto del equipo:

El ciclo de lanzamiento coincide con una breve disputa por la dirección de Automattic, la empresa que dirige Mullenweg. El 10 de septiembre de 2026 Automattic comunicó que estaba de baja y que el director financiero, Mark Davies, dirigiría la empresa como CEO interino. El 12 de septiembre un portavoz de la compañía dijo a CMSWire que Mullenweg era presidente y CEO con el pleno apoyo del consejo, y más tarde Automattic cifró su ausencia en 33 horas y 20 minutos sin explicar el motivo de la baja. Su papel en el proyecto de código abierto WordPress no cambió durante esos días: la directora ejecutiva de WordPress, Mary Hubbard, afirmó que seguía siendo el líder del proyecto (WebHosting.Today).

El equipo de lanzamiento toma y comunica las decisiones sobre la versión y recoge las aportaciones de la comunidad. Las reuniones semanales de desarrollo se celebran en el canal #core del Slack de Making WordPress los miércoles a las 15:00 UTC.

#Gutenberg Notes en WordPress 7.2

Notes ya está en el núcleo. WordPress 7.1 incorporó notas en línea sobre texto seleccionado, texto enriquecido en el cuerpo de las notas, autocompletado de @menciones y avisos por correo a los usuarios mencionados, según la issue de iteración de Notes para 7.2. El plan de desarrollo nombra tres novedades para 7.2.

Con Notes en 7.2, los equipos editoriales deberían poder:

• Proponer un cambio en modo de sugerencias, que el autor después acepta o rechaza.
• Añadir reacciones emoji a las notas para dar comentarios rápidos.
• Añadir una nota desde la barra de herramientas del bloque, porque hoy esa opción cuesta encontrarla.

Según la actualización de esa issue del 30 de septiembre, el modo de sugerencias está detrás de un experimento repartido en nueve pull requests que aún no habían tenido una revisión completa, las reacciones emoji se arrastraron desde 7.1 y pasaron a un nuevo selector de emoji, y la pull request del acceso desde la barra de herramientas estaba aprobada. Una issue de seguimiento aparte para 7.3 recoge el trabajo que no llegue a tiempo, así que revisa las notas para desarrolladores de la Beta 1 antes de prometer el modo de sugerencias a un equipo editorial.

#Colaboración en tiempo real en WordPress 7.2

La edición colaborativa en tiempo real no forma parte de 7.2. El plan la deja fuera mientras se cierran las decisiones de arquitectura. La colaboración en tiempo real se retiró de WordPress 7.0, y el 18 de septiembre de 2026 Chris Zarate propuso un enfoque consciente del servidor. Hoy los navegadores fusionan los cambios directamente y envían el resultado cuando alguien guarda. Con la propuesta, cada actualización pasa por WordPress, que registra quién la hizo, comprueba la autorización, la fusiona y guarda el resultado, y después envía a los demás participantes los cambios que les faltan o señala un conflicto para revisarlo. Los navegadores dejarían de intercambiar actualizaciones entre sí.

El artículo dice que la exploración está en una fase temprana y no está lista para el núcleo. Tres motores de sincronización candidatos (Yjs-server, Distributed Editing e Intent log) están en el repositorio gutenberg-sync-engines como plugin exploratorio. El coste pendiente es el alojamiento: fusionar en el servidor añade carga, las consultas frecuentes (polling) salen más caras en planes con pocos recursos, y un transporte por WebSocket necesitaría un daemon que funcione fuera del conjunto de workers de PHP, gestionado por el proveedor de alojamiento.

#Qué es el modo sudo en WordPress 7.2

A medida que la web se adapta a escaneos automatizados y a scripts sofisticados de secuestro de sesiones (session hijacking), la autenticación tradicional del administrador ya no es suficiente. Si un atacante intercepta las cookies o el token de sesión de un administrador activo, obtiene acceso sin restricciones a todo el sitio.

El plan de desarrollo incluye el modo sudo para 7.2: volver a autenticarse antes de acciones con privilegios elevados. El nombre viene del comando de Unix sudo. Una cookie de sesión robada ya no bastaría para ejecutar una acción privilegiada, porque la acción vuelve a pedir las credenciales.

Qué acciones quedarán protegidas aún no es público. El plan indica que llegarán una propuesta y una convocatoria para colaborar, y cuando lo comprobamos el 12 de octubre de 2026 no se había publicado ninguna propuesta del modo sudo en make.wordpress.org/core. Hasta entonces, la preparación útil es un inventario: haz una lista de las pantallas de administración personalizadas y los endpoints REST de tus plugins que modifican usuarios, roles y capacidades, archivos o ajustes de seguridad, porque esos son los flujos delante de los que se colocaría un paso de reautenticación.

#Secrets API de WordPress 7.2 para claves API

El almacenamiento de credenciales confidenciales (como claves API de Stripe, tokens de Mailchimp o contraseñas de bases de datos personalizadas) ha sido históricamente una vulnerabilidad de la arquitectura en WordPress. Durante más de dos décadas, los desarrolladores no tenían otra opción que programar de forma fija (hardcode) las claves en wp-config.php o guardarlas como texto plano en la tabla wp_options.

La propuesta de Secrets API de Eric Mann, del 25 de agosto de 2026, apunta a 7.2 con un almacén de primer nivel para credenciales. El problema que plantea es concreto: las claves en texto plano de la tabla de opciones acaban en volcados de la base de datos, copias de seguridad, clones de staging y salidas de la línea de comandos, y los plugins que cifran sus propias claves lo hacen cada uno a su manera. Las integraciones de IA elevan todavía más el coste de una clave filtrada.

El diseño propuesto:

• El cifrado está siempre activo. Cada secreto recibe su propia clave de datos, envuelta por una clave maestra, que a su vez queda envuelta por la clave del sitio (cifrado de sobre). No hay modo de texto plano ni constante para desactivar el cifrado. La criptografía usa libsodium, con sodium_compat como alternativa.
• El almacén por defecto es la tabla de opciones, que solo guarda texto cifrado con autoload=no, excluido de options.php y del endpoint REST de ajustes. La fuente de clave preferida es una constante específica; los sitios que no la tienen recurren a una clave derivada de las sales existentes.
• Los almacenes externos se conectan mediante un drop-in. Un drop-in secrets.php expone dos puntos de extensión separados: almacenamiento (por ejemplo HashiCorp Vault o AWS Parameter Store) y llavero (un KMS o un HSM).
• Falla de forma cerrada. Si el backend no responde, la llamada falla sin alternativa local. Los valores son de solo escritura: no hay exportación.

#Funciones de la Secrets API en WordPress 7.2

wp_set_secret( string $name, string $value ): bool|WP_Error
wp_get_secret( string $name, string $version = WP_Secret_Version::CURRENT ): WP_Secret|null|WP_Error
wp_delete_secret( string $name ): bool|WP_Error
wp_import_option_as_secret( string $option, string $name ): bool|WP_Error

wp_get_secret() devuelve un objeto WP_Secret, no una cadena. El valor se obtiene con reveal(), y fingerprint() da un identificador que se puede registrar en logs sin riesgo. El objeto se enmascara en los logs, en var_dump() y en la salida de errores, y rechaza la serialización. La función devuelve null cuando el secreto no existe y un WP_Error cuando existe pero no se puede descifrar. Por convención, los nombres llevan espacio de nombres con el formato plugin-slug/secret-name.

Dos capacidades protegen el almacén: manage_secrets y manage_network_secrets. En multisite, una clave raíz de red deriva subclaves por sitio, y los secretos del sitio y los de la red usan funciones separadas sin alternativa implícita entre ellas. La rotación la decide el operador, con dos versiones, CURRENT y PREVIOUS, y en cada escritura se dispara un hook con el actor, la marca de tiempo y las huellas antigua y nueva.

No hay ningún filtro en la lectura, a propósito: un filtro permitiría a cualquier plugin interceptar credenciales, así que los proveedores de alojamiento se conectan mediante proveedores de almacenamiento. La propuesta también es explícita sobre sus límites. Cualquier código que se ejecute dentro de WordPress puede llamar a wp_get_secret(), y el slug del plugin en el nombre de un secreto no está autenticado, así que la API no aísla los secretos de un plugin de los de otro. Lo que elimina son las claves en texto plano en volcados, copias de seguridad y copias de staging.

Para las agencias y desarrolladores que crean integraciones modernas con WordPress (incluidas las integraciones con agentes de IA, donde se usan intensamente las claves API), la Secrets API ofrece un marco estandarizado que acerca la seguridad de WordPress a los estándares corporativos.

#Cómo migrar las claves API de un plugin a la Secrets API

La propuesta no incluye pantalla de administración en 7.2: la pantalla de ajustes se aplaza a 7.3. El soporte de WP-CLI sí entra en el alcance de 7.2, para que las credenciales dejen de aparecer en el historial de la shell y en las listas de procesos, pero los nombres de los comandos aún no están decididos (es una de las preguntas abiertas del artículo). La propuesta prevé primero un plugin de funcionalidad y después un parche para el núcleo con la misma API.

En el código del plugin, la migración es un paso deliberado por cada opción mediante wp_import_option_as_secret(), no un barrido automático. Los secretos importados se marcan para rotación, porque el antiguo valor en texto plano ya ha viajado a todas las copias de seguridad hechas hasta ahora. Una lectura segura entre versiones, para un plugin que tiene que funcionar en 7.1 y en 7.2, queda así:

$name = 'my-plugin/stripe-key';

if ( function_exists( 'wp_get_secret' ) ) {
	$secret = wp_get_secret( $name );
	if ( null === $secret && get_option( 'my_plugin_stripe_key' ) ) {
		wp_import_option_as_secret( 'my_plugin_stripe_key', $name );
		$secret = wp_get_secret( $name );
	}
	$key = $secret instanceof WP_Secret ? $secret->reveal() : '';
} else {
	$key = (string) get_option( 'my_plugin_stripe_key', '' );
}

Las firmas salen de la propuesta y pueden cambiar antes de la Beta 1, así que mantén la comprobación con function_exists() y el camino antiguo para los sitios en 7.1. La propuesta no aclara si la importación elimina la opción original, así que consulta la nota para desarrolladores antes de borrar nada. Cuando la clave ya esté en la Secrets API, rótala en el proveedor de pagos o de la API.

#Por qué los proveedores de alojamiento critican la propuesta de Secrets API

Los comentarios bajo la propuesta muestran dónde el diseño sigue en discusión. Chris Reynolds, de Pantheon, explicó que Pantheon usa un almacén de secretos externo al que las aplicaciones solo acceden en modo lectura, preguntó si los proveedores de solo lectura entran en el alcance y cómo deberían gestionar los plugins el WP_Error que devolvería una escritura, y señaló que los almacenes de plataforma que necesitan el texto plano chocan con el modelo del drop-in. Ryan McCue, de Altis, se opuso a la propuesta tal como está redactada y defendió que WordPress solo debería leer secretos, dejando el cifrado a HSM externos.

Eric Mann respondió que un proveedor de solo lectura puede convertir el setter en una operación vacía y que los proveedores de alojamiento podrán sustituirlo por un proveedor más robusto, con un ejemplo para AWS Secrets Manager en su repositorio secrets-api. Una pull request a wordpress-develop (#13759) aborda las objeciones sobre los proveedores de alojamiento. En el artículo quedan cinco preguntas abiertas, entre ellas si bastan dos versiones y qué comandos de WP-CLI llegan primero.

Para quien desarrolla plugins, la consecuencia práctica es que wp_set_secret() puede fallar por diseño en un alojamiento gestionado. Un formulario de ajustes que guarda una clave debe mostrar el error devuelto en lugar de dar por hecho que la operación ha salido bien.

#Cambios en Application Passwords en WordPress 7.2

La sección de seguridad del plan también incluye el refuerzo de Application Passwords: mejoras de experiencia de uso, un aviso por correo cuando se añade una nueva contraseña de aplicación, correcciones en la detección del entorno, un manejo más seguro de default_role y soporte para cookies SameSite. El trabajo se sigue en los tickets de Trac #66009, #63927, #57388, #46744 y #37000. Un procesamiento de HTML reforzado sobre la HTML API completa la lista de seguridad.

Las contraseñas de aplicación son la credencial que usan la mayoría de las integraciones con la REST API, así que el aviso alerta al propietario del sitio cuando alguien añade una sin que lo sepa.

#Otras novedades del plan de WordPress 7.2

Ipsum, el nuevo tema por defecto, es un tema de blog minimalista concebido como lienzo en blanco, con subrayados de puntos, unos pocos juegos tipográficos y variaciones de estilo que cambian el color de toda la página, imágenes incluidas. Todas las combinaciones de color y estilo cumplen el contraste WCAG AA, según el artículo de presentación de Henrique Iamarino. También pone fin a los nombres de temas por defecto basados en el año. El código está en GitHub para pruebas, y el equipo reconoce que los plazos son ajustados.

El trabajo de IA continúa en el plugin AI, sin garantía de que llegue al núcleo: más habilidades (cobertura experimental de solo lectura para medios, taxonomías y comentarios), un MCP Adapter actualizado a la especificación actual de MCP y distribuido a través del directorio de plugins, identidades de agente con permisos auditables y respuestas en streaming en el PHP AI Client.

En bloques y APIs, el plan incluye un bloque de lista de descripciones para <dl>, <dt> y <dd>, búsqueda por palabra clave en el bloque Icon, una directiva data-wp-html y un router en la Interactivity API, y renderizado en el servidor para el bloque Table of Contents para que pueda pasar a estable. La actualización a React 19 ya está en gran parte en Gutenberg, pero es poco probable que llegue completa en 7.2.

En el escritorio de administración, DataViews y DataForms reciben vistas, campos y acciones registrados en el servidor, y el inspector de entradas se está sustituyendo por un DataForm. Los mensajes de error son más fáciles de diagnosticar y tienen un botón para copiarlos, y una base reconstruida del Editor del sitio permite a los plugins registrar sus propias pantallas. En rendimiento, la concatenación de scripts y estilos se está sustituyendo por la precarga (Trac #57548), junto con trabajo procedente del plugin Enhanced Responsive Images.

#Calendario de WordPress 7.2

David Baumwald publicó el calendario de WordPress 7.2 en make.wordpress.org el 6 de octubre de 2026. Cada etapa empieza a las 15:00 UTC.

La Beta 1 marca el momento en que los colaboradores del núcleo pasan a probar y corregir errores y empiezan a aparecer las notas para desarrolladores. La RC1 trae la Field Guide, la congelación definitiva de cadenas y la rama del lanzamiento. Tras la congelación de funcionalidades solo se incorporan correcciones de errores, empezando por las regresiones.

Instala la Beta 1 en una copia de staging de tu web el 20 de octubre y repite las pruebas de plugins y tema con la RC1 el 17 de noviembre, para que los conflictos aparezcan en staging antes del 8 de diciembre.

#Cómo probar la beta de WordPress 7.2

Hay dos vías documentadas. El plugin WordPress Beta Tester, que encontrarás en Herramientas, Beta Testing (Ajustes en multisite), cambia el actualizador integrado del canal por defecto Point release a Bleeding edge (trunk) o a los paquetes beta y RC. Desde la línea de comandos, wp core update acepta --version=nightly o la ruta a un archivo zip descargado. Haz antes una copia de seguridad y no instales betas en producción.

Qué probar se deduce del plan: plugins que guardan claves API en opciones, flujos de administración personalizados que modifican usuarios o archivos, flujos editoriales que dependen de Notes, y temas hijo si piensas pasar un sitio a Ipsum.

#Cómo preparar tu web para WordPress 7.2

WordPress 7.2 representa una de las actualizaciones estructuralmente más significativas de 2026. La combinación de flujos de trabajo de edición colaborativa e infraestructuras endurecidas de seguridad en el backend exige que las agencias y desarrolladores comiencen a preparar sus configuraciones desde ahora.

En WPPoland ya estamos preparando nuestros desarrollos headless de Astro e integraciones con servidores de MCP para consumir de forma segura la nueva Secrets API y adaptarnos a los flujos de reautenticación del modo sudo.

¿Quieres asegurar tu instalación corporativa de WordPress o migrar tus plugins personalizados a los nuevos estándares del núcleo de 2026? Contáctame hoy mismo para obtener un plan de migración a medida.