Em 12 de setembro de 2026, a Secrets API ainda não é uma API confirmada no WordPress 7.2: ela está em fase de feature plugin, antes do merge no Core. A proposta publicada no Make WordPress Core define uma interface de armazenamento criptografado para chaves de API, tokens e outras credenciais, com suporte de WP-CLI e pontos de extensão para provedores externos. O plano é decidir antes da Beta 1 do WordPress 7.2 se a API entra nessa versão ou se será adiada para 7.3. Por isso, desenvolvedores já podem testar o desenho, mas não devem tratar a presença dessas funções no Core como garantida.
Primeiro: a API ainda não está confirmada no Core 7.2
A proposta foi publicada em 25 de agosto de 2026 e ganhou um feature plugin para que contribuidores e autores de plugins possam testar o comportamento antes do patch do Core. Em 10 de setembro, o resumo do Dev Chat registrou que já havia uma implementação inicial em funcionamento e pediu feedback, especialmente sobre interoperabilidade com provedores externos.
O repositório do projeto descreve o estado atual como “pre-core-merge”: a superfície pública do feature plugin está definida, mas o código ainda não foi incorporado ao WordPress. O calendário do 7.2 marca a Beta 1 para 20–22 de outubro de 2026; a própria proposta usa essa janela como limite prático para entrar na versão, com a alternativa explícita de adiar para 7.3 se não estiver pronto.
Fontes principais: proposta da Secrets API, feature plugin no GitHub, resumo do Dev Chat de 9 de setembro e calendário do WordPress 7.2.
Que problema a Secrets API tenta resolver
Hoje, o Core não oferece uma abstração de primeira classe para credenciais. Plugins que precisam de uma chave de API ou token costumam recorrer à Options API ou a mecanismos próprios. Isso pode deixar valores sensíveis misturados a dados comuns do site e replicados em dumps de banco, backups, clones de staging e outros fluxos operacionais.
A proposta cria um caminho comum para que o plugin diga “isto é um segredo” e delegue armazenamento, criptografia, rotação e integração com infraestrutura ao WordPress ou ao provedor da hospedagem. O ganho pretendido não é tornar qualquer código PHP incapaz de ler o valor; é reduzir a exposição de credenciais em repouso e criar um ponto único para operações e auditoria.
Como o armazenamento proposto funciona
- Criptografia sempre ativa: não há modo de texto puro. A implementação padrão usa criptografia em repouso com hierarquia de chaves.
- Armazenamento padrão substituível: o WordPress pode manter registros criptografados usando a infraestrutura de opções, mas hosts podem trocar o provedor, o keyring ou o store por integrações com KMS, HSM ou serviços de segredos.
- Drop-in dedicado: um arquivo wp-content/secrets.php é o ponto proposto para instalar implementações alternativas.
- Duas versões do valor: CURRENT e PREVIOUS permitem rotação sem manter histórico indefinido.
- Falha fechada: se o backend de segredos ou o keyring estiver indisponível, a operação retorna erro; a proposta rejeita fallback silencioso para armazenamento menos seguro.
- Sem exportação em texto puro: o desenho não prevê um mecanismo de exportar valores secretos; migrações e ambientes de staging devem receber nova entrada de credenciais.
O feature plugin atual também separa três níveis de extensão: um WP_Secrets_Provider para plataformas em que o sistema externo é a fonte da verdade, um WP_Secrets_Keyring para substituir a proteção da chave raiz e um WP_Secrets_Store para trocar onde os registros ficam armazenados.
Como plugins acessariam um segredo por código
A API proposta é pequena. Para gravar, o desenho expõe wp_set_secret(); para ler, wp_get_secret(); para apagar, wp_delete_secret(); e para mover um valor conhecido da Options API, wp_import_option_as_secret().
A leitura foi desenhada para distinguir três estados: um objeto WP_Secret quando o valor existe e pode ser recuperado, null quando não existe e WP_Error quando existe, mas não pode ser lido — por exemplo, por falha de chave ou backend. Essa distinção evita que um plugin confunda “credencial ausente” com “credencial quebrada” e execute novamente um fluxo de conexão indevidamente.
O valor bruto exige uma chamada explícita a WP_Secret::reveal(). O objeto também oferece uma impressão digital por fingerprint(), útil para comparar ou auditar um segredo sem expor seu conteúdo. A convenção de nomes é plugin-slug/secret-name, mas o namespace é organizacional: a própria documentação atual deixa claro que ele não cria isolamento forte entre plugins no mesmo processo PHP.
Onde entra o WP-CLI
O WP-CLI está no escopo da proposta para o 7.2 porque funciona como primeiro consumidor oficial da API e ajuda a testar se a interface é suficiente para operações reais. Há também uma razão de segurança operacional: credenciais passadas diretamente como argumentos de shell podem acabar em histórico ou na lista de processos. Uma integração própria com a Secrets API pode oferecer fluxos de leitura e gravação que evitem esse padrão.
Entretanto, a proposta de agosto ainda pedia feedback sobre quais comandos deveriam existir e em qual ordem. Portanto, autores de documentação e automações não devem congelar nomes de comandos do feature plugin como se fossem uma interface definitiva do WordPress 7.2 até haver merge no Core e documentação oficial correspondente.
Como migrar chaves que hoje estão em wp_options
A proposta deliberadamente evita uma migração automática. O Core não consegue identificar com segurança quais opções são credenciais, e uma varredura heurística poderia mover ou quebrar dados que não são segredos.
O caminho proposto é explícito: cada plugin conhece o nome da opção antiga e decide, em sua própria rotina de atualização, quando importá-la com wp_import_option_as_secret(). Depois da importação, a credencial deve ser tratada como candidata a rotação. Criptografar um token que já circulou por backups, réplicas e caches não apaga as cópias históricas; trocar o valor no serviço externo é o que reduz esse risco residual.
O que fica fora da primeira versão — e o que é um não objetivo
| Item | Status no desenho atual | Implicação prática |
|---|---|---|
| Tela de administração para gerenciar segredos | Adiada; a proposta aponta 7.3 | O 7.2 prioriza semântica de armazenamento, acesso e extensibilidade, não uma UI completa. |
| Isolamento rígido entre plugins | Fora do escopo | Código que executa dentro do mesmo WordPress pode, em princípio, acessar segredos; namespace não é uma fronteira de privilégio. |
| Migração automática de opções existentes | Não prevista | Cada plugin deve migrar apenas credenciais que conhece e controlar seu próprio ciclo de upgrade. |
| Exportação de valores em texto puro | Deliberadamente ausente | Novos ambientes devem receber a credencial novamente em vez de transportar um dump de segredos. |
| Proteção contra execução arbitrária de código no processo PHP | Fora do modelo de ameaça | A API endurece armazenamento e exposição acidental, mas não derrota um invasor que já executa código com o WordPress. |
| Interface final de comandos do WP-CLI | Ainda sujeita ao processo de integração | Teste o feature plugin, mas espere a incorporação e a documentação do Core antes de depender de sintaxe definitiva. |
Como preparar plugins e integrações agora
- Faça um inventário de credenciais: liste chaves, tokens, senhas de integração e opções em que elas vivem hoje.
- Isole leitura e escrita em uma camada própria: evite espalhar chamadas a get_option() e update_option() por todo o plugin. Um adaptador torna a troca para a Secrets API menos invasiva.
- Adote nomes estáveis e com namespace: planeje chaves como meu-plugin/servico-token, sem tratar o namespace como mecanismo de autorização.
- Modele os três estados de leitura: diferencie ausente, disponível e erro de recuperação.
- Planeje importação e rotação separadamente: importar remove o texto puro do caminho normal; rotacionar reduz o risco das cópias históricas.
- Revise logs e ferramentas operacionais: evite registrar valores, colocar tokens em URLs ou repassá-los como argumentos de linha de comando.
- Teste em ambiente descartável: o feature plugin existe justamente para validar a API antes do merge. Use-o para encontrar incompatibilidades, inclusive com provedores de hospedagem.
- Mantenha fallback apenas enquanto necessário: se o plugin precisar suportar versões anteriores do WordPress, encapsule a compatibilidade e remova-a quando sua matriz de suporte permitir.
Calendário e decisão prática para o ciclo 7.2
O WordPress 7.2 está em alpha. A Beta 1 está prevista para 20–22 de outubro e o lançamento final para 8–10 de dezembro de 2026. A proposta da Secrets API estabelece que, antes da Beta 1, o trabalho deve estar incorporado ao Core ou ser explicitamente adiado para 7.3, em vez de entrar apressadamente.
Para quem mantém plugins, a ação útil agora é preparar arquitetura e testes, não assumir disponibilidade. O feature plugin oferece um alvo concreto para experimentação e a proposta já esclarece princípios importantes — criptografia obrigatória, importação explícita, ausência de exportação e falta de isolamento por plugin —, mas a decisão que transforma isso em API oficial do WordPress depende do processo de merge do Core.
