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.

Según el plan, con Notes en 7.2 los equipos editoriales podrían:

• 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.

Actualización, 23 de octubre de 2026: el anuncio de la Beta 1 del 20 de octubre menciona reacciones emoji en las notas, un nuevo icono en la barra de herramientas, notas en el lienzo del editor y un modo minimizado de Notes. El modo de sugerencias no aparece en esa lista, así que no planifiques flujos editoriales en 7.2 que dependan de él.

#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.

Actualización, 20 de octubre de 2026: el anuncio de la Beta 1 no menciona el modo sudo, ni en la parte para editores ni en la parte para desarrolladores. Si llega a la 7.2, será en una beta posterior.

#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.

Actualización, 18 de octubre de 2026: el plugin MCP Adapter está en la versión 0.7.1, publicada el 15 de octubre de 2026. Limita a 4 KiB los datos de inicialización de sesión que guarda (los clientes afectados se reconectan una vez), devuelve errores más claros para abilities no disponibles y añade una guía para propietarios de sitios sobre cómo conectar un cliente de IA con Application Passwords y resolver problemas. Para autores de plugins hay un cambio de la 0.7.0: incluir el adaptador como librería está obsoleto y los sitios deben instalar el plugin.

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.

Actualización, 24 de octubre de 2026: Gutenberg 24.2, publicado el 14 de octubre, activa por defecto en el plugin el experimento de React 19. Los sitios con el plugin cargan React 19 para los scripts react y react-dom, salvo que esté activo un tema o plugin de la lista de incompatibilidades conocidas, en cuyo caso siguen con React 18. Si algo deja de funcionar, puedes desactivar React 19 en Gutenberg, Experiments. El equipo de Gutenberg pide a los autores de plugins y temas que usan React que prueben con la 24.2 y comuniquen los fallos, y ofrece el nuevo paquete @wordpress/react-inert-value para fijar el atributo inert de forma que funcione con ambas versiones. El anuncio de la Beta 1 no menciona React 19, así que prueba tu código React con Gutenberg 24.2 en lugar de dar por hecho lo que incluirá el propio WordPress 7.2.

#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.

Actualización, 20 de octubre de 2026: la Beta 1 salió según el calendario y el anuncio confirma el 8 de diciembre de 2026 como fecha de la versión final. La Secrets API está en la Beta 1 (Trac #66187): cifrado en reposo, rotación de credenciales y proveedores de almacenamiento personalizables. Los desarrolladores reciben además una Abilities API ampliada para acceder y consultar datos de WordPress, renderizado de HTML de confianza y navegación reactiva en la Interactivity API, y un panel que carga scripts y hojas de estilo por separado en lugar de en grandes archivos combinados y que precarga los recursos de la siguiente pantalla. La biblioteca de medios redimensiona, comprime y convierte imágenes en el navegador antes de subirlas. La prueba más rápida es wp core update --version=7.2-beta1 en una copia de staging.

Actualización, 21 de octubre de 2026: el anuncio de la Beta 1 menciona también un widget del escritorio On This Day (Trac #65116), que muestra entradas publicadas en la misma fecha en años anteriores, una dirección propia que redirige a una entrada elegida al azar (Trac #64498), sombra de texto con ajustes predefinidos en theme.json e iconos de la biblioteca de iconos de WordPress en lugar de Dashicons en la barra de administración y el menú lateral. Las notas pasan al lienzo del editor y ganan reacciones con emoji y un icono en la barra de herramientas. El anuncio no menciona el modo sudo ni el modo de sugerencias en las notas, así que revisa sus tickets en Trac y las notas para desarrolladores antes de RC1 (17 de noviembre) antes de planificar trabajo que dependa de ellos.

Actualización, 3 de noviembre de 2026. La numeración de las betas se desplazó tras el lanzamiento de seguridad. La Beta 2 salió el 27 de octubre para pruebas (wp core update --version=7.2-beta2 en staging). El 28 de octubre la página de WordPress 7.2 registra la Beta 3 junto con WordPress 7.1.4 (el paquete wordpress-7.2-beta3.zip lleva la marca de tiempo de ese día). La party del 3 de noviembre es ahora la Beta 4, y el 10 de noviembre es la Beta 5; la RC1 sigue el 17 de noviembre y la final el 8 de diciembre. En el momento de esta actualización el zip de la Beta 4 aún no estaba publicado - espera al enlace ZIP en make.wordpress.org/core/7-2 o a la noticia en WordPress.org News antes de subir staging más allá de beta3. Mantén producción en 7.1.4.

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.

Actualización, 24 de octubre de 2026: Un commit en el núcleo del 19 de octubre de 2026 de Weston Ruter (r64585) retira la concatenación de scripts y estilos en el escritorio de administración y en la pantalla de acceso. wp-admin/load-scripts.php y wp-admin/load-styles.php responden ahora a cada petición con 410 Gone y una explicación de una línea en texto plano, sin cargar WordPress. La constante CONCATENATE_SCRIPTS ya no se lee y ya no aparece en Salud del sitio. La revisión de compatibilidad del pull request 14463 recorrió los directorios de plugins y temas: ningún tema de ese directorio usa el código retirado, y unos 45 plugins piden los dos cargadores directamente, casi siempre desde sus propios diálogos, vistas previas o pantallas de configuración. Entre los plugins mantenidos, la revisión nombra Ad Inserter (los controles de la ventana de vista previa probablemente fallan), CartFlows (una petición fallida en cada pantalla de administración, sin efecto visible), Modula (su diálogo de galería del editor clásico no inserta nada) y UiPress Lite (la barra de herramientas sin estilos en sus pantallas).

Qué revisar en una copia de pruebas con la Beta 1:

• Si gestionas el sitio: abre los diálogos, vistas previas y pantallas de configuración de tus plugins y mira en la pestaña de red del navegador si hay peticiones a load-scripts.php o load-styles.php que devuelven 410. El síntoma visible es una página sin estilos o un botón que no hace nada. Esta prueba es sugerencia nuestra, no viene de las fuentes.
• Si desarrollas plugins: sustituye las URL de los cargadores escritas a mano por recursos encolados, o por wp_print_scripts() y wp_print_styles() en una página independiente, como recomienda la revisión.
• Si desarrollas plugins: el código que pone do_concat en true, o devuelve false desde print_head_scripts, print_footer_scripts, print_admin_styles o print_late_styles para retener la salida, deja de funcionar, porque cada elemento se imprime de inmediato como etiqueta propia.
• Si desarrollas plugins: _print_scripts(), _print_styles(), script_concat_settings(), in_default_dir() y WP_Dependencies::get_etag() quedan obsoletos, y engancharse a los cuatro filtros de impresión genera ahora un aviso de obsolescencia. Las propiedades obsoletas de WP_Scripts y WP_Styles siguen declaradas y no generan aviso.

Revisar los plugins en una copia de pruebas antes de una versión mayor forma parte de nuestro mantenimiento de WordPress.

Ya estoy preparando mis instalaciones headless de Astro y las integraciones con servidores MCP para consumir de forma segura la nueva Secrets API y adaptarlas 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.