A 12 de septiembre de 2026, la Secrets API todavía no es una API confirmada en el núcleo de WordPress 7.2: se encuentra como feature plugin antes de su integración en Core. La propuesta publicada en Make WordPress Core define una interfaz de almacenamiento cifrado para claves de API, tokens y otras credenciales, con soporte de WP-CLI y puntos de extensión para proveedores externos. El plan es decidir antes de la Beta 1 de WordPress 7.2 si la API entra en esa versión o se aplaza a 7.3. Los desarrolladores ya pueden probar el diseño, pero no deben considerar garantizada la presencia de esas funciones en Core.
Primero: la API aún no está confirmada en el Core de WordPress 7.2
La propuesta se publicó el 25 de agosto de 2026 y fue seguida por un feature plugin para que contribuidores y autores de plugins puedan probar el comportamiento antes del parche de Core. El 10 de septiembre, el resumen del Dev Chat señaló que ya existía una implementación inicial funcional y pidió comentarios, especialmente sobre la interoperabilidad con proveedores externos.
El repositorio del proyecto describe el estado actual como “pre-core-merge”: la superficie pública del feature plugin está definida, pero el código todavía no se ha incorporado a WordPress. El calendario de 7.2 sitúa la Beta 1 entre el 20 y el 22 de octubre de 2026; la propia propuesta trata esa ventana como el límite práctico para integrar la API, con la opción explícita de aplazarla a 7.3 si no está lista.
Fuentes principales: la propuesta de la Secrets API, el feature plugin en GitHub, el resumen del Dev Chat del 9 de septiembre y el calendario de WordPress 7.2.
Qué problema intenta resolver la Secrets API
Actualmente, Core no ofrece una abstracción de primera clase para credenciales. Los plugins que necesitan una clave de API o un token suelen recurrir a la Options API o a mecanismos propios. Eso puede dejar valores sensibles mezclados con datos comunes del sitio y copiados en volcados de base de datos, copias de seguridad, clones de staging y otros flujos operativos.
La propuesta crea un camino común para que un plugin diga “esto es un secreto” y delegue almacenamiento, cifrado, rotación e integración con infraestructura a WordPress o al proveedor de hosting. El beneficio buscado no es impedir que cualquier código PHP pueda leer el valor; es reducir la exposición de credenciales en reposo y crear un punto único para operaciones y auditoría.
Cómo funciona el modelo de almacenamiento propuesto
- Cifrado siempre activo: no hay modo de texto plano. La implementación predeterminada usa cifrado en reposo con una jerarquía de claves.
- Almacenamiento predeterminado reemplazable: WordPress puede mantener registros cifrados usando la infraestructura de opciones, mientras que los hosts pueden sustituir el proveedor, el keyring o el store por integraciones con KMS, HSM o servicios de secretos.
- Drop-in dedicado: un archivo wp-content/secrets.php es el punto propuesto para instalar implementaciones alternativas.
- Dos posiciones de valor: CURRENT y PREVIOUS permiten rotación sin conservar un historial ilimitado.
- Fallo cerrado: si el backend de secretos o el keyring no está disponible, la operación devuelve un error; el diseño rechaza un fallback silencioso a almacenamiento local menos seguro.
- Sin exportación en texto plano: el diseño no ofrece un mecanismo para exportar valores secretos; migraciones y entornos de staging deben volver a recibir las credenciales.
El feature plugin actual también separa tres niveles de extensión: WP_Secrets_Provider para plataformas en las que un sistema externo es la fuente de verdad, WP_Secrets_Keyring para sustituir la protección de la clave raíz y WP_Secrets_Store para cambiar dónde se guardan los registros.
Cómo accederían los plugins a un secreto desde código
La API propuesta es deliberadamente pequeña. El diseño expone wp_set_secret() para escribir, wp_get_secret() para leer, wp_delete_secret() para borrar y wp_import_option_as_secret() para mover un valor conocido desde la Options API.
La lectura está diseñada para distinguir tres estados: un objeto WP_Secret cuando el valor existe y puede recuperarse, null cuando no existe y WP_Error cuando existe pero no puede leerse, por ejemplo por un problema de clave o de backend. Esta separación evita que un plugin confunda “credencial ausente” con “credencial dañada” y reinicie incorrectamente un flujo de conexión.
Obtener la cadena en bruto exige una llamada explícita a WP_Secret::reveal(). El objeto también ofrece fingerprint(), útil para comparar o auditar un secreto sin exponer su contenido. La convención de nombres es plugin-slug/secret-name, pero el namespace es organizativo: la documentación actual deja claro que no crea un aislamiento fuerte entre plugins que se ejecutan en el mismo proceso PHP.
Dónde entra WP-CLI
WP-CLI está dentro del alcance de la propuesta para 7.2 porque sirve como primer consumidor oficial y ayuda a comprobar si la API es suficiente para tareas operativas reales. También existe una razón de seguridad operativa: las credenciales pasadas directamente como argumentos del shell pueden terminar en el historial o en la lista de procesos. Una integración nativa con la Secrets API puede ofrecer flujos de lectura y escritura que eviten ese patrón.
Sin embargo, la propuesta de agosto todavía pedía comentarios sobre qué comandos deberían existir y en qué orden. Por eso, autores de documentación y responsables de automatizaciones no deberían fijar los nombres de comandos del feature plugin como si fueran una interfaz definitiva de WordPress 7.2 hasta que exista integración en Core y documentación oficial.
Cómo migrar claves que hoy están en wp_options
La propuesta evita deliberadamente una migración automática. Core no puede determinar con seguridad qué opciones son credenciales, y una búsqueda heurística podría mover o romper datos que en realidad no son secretos.
El camino propuesto es explícito: cada plugin conoce el nombre de su opción antigua y decide, en su propia rutina de actualización, cuándo importarla con wp_import_option_as_secret(). Después de la importación, la credencial debe considerarse candidata a rotación. Cifrar un token que ya pasó por copias de seguridad, réplicas y cachés no borra las copias históricas; cambiar el valor en el servicio externo es lo que reduce ese riesgo residual.
Qué queda fuera de la primera versión — y qué es un no objetivo
| Elemento | Estado en el diseño actual | Implicación práctica |
|---|---|---|
| Pantalla de administración para gestionar secretos | Aplazada; la propuesta apunta a 7.3 | 7.2 prioriza la semántica de almacenamiento, acceso y extensibilidad, no una UI completa. |
| Aislamiento fuerte entre plugins | Fuera de alcance | El código que se ejecuta dentro del mismo WordPress puede, en principio, acceder a secretos; el namespace no es una frontera de privilegio. |
| Migración automática de opciones existentes | No prevista | Cada plugin debe migrar solo las credenciales que conoce y controlar su propio ciclo de actualización. |
| Exportación de valores en texto plano | Deliberadamente ausente | Los nuevos entornos deben volver a recibir la credencial en lugar de transportar un volcado de secretos. |
| Protección contra ejecución arbitraria de código en el proceso PHP | Fuera del modelo de amenaza | La API refuerza el almacenamiento y reduce la exposición accidental, pero no vence a un atacante que ya ejecuta código como WordPress. |
| Interfaz final de comandos de WP-CLI | Todavía sujeta al proceso de integración | Prueba el feature plugin, pero espera la integración y documentación de Core antes de depender de una sintaxis definitiva. |
Cómo preparar plugins e integraciones ahora
- Haz un inventario de credenciales: enumera claves de API, tokens, contraseñas de integración y las opciones donde viven actualmente.
- Encapsula lectura y escritura en una capa propia: evita dispersar get_option() y update_option() por todo el plugin. Un adaptador hace menos invasivo un futuro cambio a la Secrets API.
- Usa claves estables y con namespace: planifica nombres como mi-plugin/token-servicio, sin tratar el namespace como autorización.
- Modela los tres estados de lectura: distingue ausente, disponible y error de recuperación.
- Planifica importación y rotación por separado: importar retira el texto plano del camino normal; rotar reduce el riesgo de copias históricas.
- Revisa logs y herramientas operativas: evita registrar valores, colocar tokens en URL o pasarlos como argumentos de línea de comandos.
- Prueba en un entorno desechable: el feature plugin existe para validar la API antes del merge. Úsalo para detectar incompatibilidades, incluso con proveedores de hosting.
- Mantén fallbacks de compatibilidad solo mientras sean necesarios: si tu plugin soporta versiones anteriores de WordPress, encapsula el fallback y elimínalo cuando tu matriz de soporte lo permita.
Calendario y decisión práctica para el ciclo 7.2
WordPress 7.2 se encuentra actualmente en alpha. La Beta 1 está prevista para el 20–22 de octubre y el lanzamiento final para el 8–10 de diciembre de 2026. La propuesta de la Secrets API establece que, antes de la Beta 1, el trabajo debe integrarse en Core o aplazarse explícitamente a 7.3, en lugar de entrar con prisas.
Para quienes mantienen plugins, la acción útil ahora es preparar arquitectura y pruebas, no asumir disponibilidad. El feature plugin ofrece un objetivo concreto para experimentar y la propuesta ya fija principios importantes — cifrado obligatorio, importación explícita, ausencia de exportación y falta de aislamiento por plugin —, pero la decisión que convierte esto en una API oficial de WordPress aún depende del proceso de merge de Core.
