WordPress 7.1 unifica a exposição de abilities para agentes
Dante Testa
09/08/2026 · 11 min de leitura · 30 visualizações
WordPress 7.1 cria uma política comum para abilities públicas
O WordPress 7.1 ganhou em 4 de agosto de 2026 um novo metadado para a Abilities API: meta.public. Ele permite declarar, em um único lugar, que uma ação foi criada para ser descoberta por clientes externos, como a REST API, adaptadores MCP e agentes de IA. A mudança reduz configurações repetidas, mas não abre uma ability para qualquer pessoa. Exposição e autorização continuam sendo decisões separadas, e cada execução ainda depende de autenticação, capacidades do usuário e permission_callback.
Para quem desenvolve plugins de WordPress com IA, esse detalhe resolve um problema de arquitetura. Antes, a intenção de exposição precisava ser repetida em propriedades específicas de cada canal, como show_in_rest. À medida que REST, MCP, WP-CLI e futuras integrações passam a consumir a mesma ação, duplicar a política aumenta a chance de uma configuração divergir da outra.
A novidade está prevista para o WordPress 7.1, cuja versão final tem lançamento programado para 19 de agosto de 2026. Portanto, o código deve ser testado em ambiente compatível com a versão em desenvolvimento e não tratado como disponível automaticamente em sites que ainda executam WordPress 7.0 ou anterior.
O que o novo public realmente declara
Uma ability descreve uma unidade de funcionalidade: nome, rótulo, esquemas de entrada e saída, callback de execução e verificação de permissão. Um plugin pode registrar, por exemplo, uma ação para exportar usuários, consultar estatísticas ou criar um rascunho. O metadado public acrescenta a essa descrição uma intenção de consumo externo.
O formato básico apresentado no Dev Note é este:
wp_register_ability(
'my-plugin/export-users',
array(
'label' => __( 'Export users', 'my-plugin' ),
'description' => __( 'Exports user data as CSV.', 'my-plugin' ),
'category' => 'data-export',
'execute_callback' => 'my_plugin_export_users',
'permission_callback' => function (): bool {
return current_user_can( 'export' );
},
'meta' => array(
'public' => true,
),
)
);Nesse exemplo, public => true informa que a ability pode ser considerada por canais externos. Para REST, o WordPress 7.1 usa esse valor como padrão de show_in_rest. A decisão não ignora a função que exige a capacidade export. Um cliente pode descobrir a existência da ação e, mesmo assim, receber uma recusa ao tentar executá-la com uma conta sem permissão.
Essa distinção merece ser escrita na documentação do plugin. Chamar a propriedade de “pública” pode sugerir acesso anônimo, mas o significado técnico é exposição para clientes. Ela não substitui login, autorização, nonce quando aplicável, política do transporte ou validação de argumentos.
Como a precedência evita perda de controle
O WordPress resolve a exposição REST com uma cadeia simples:
$show_in_rest = $meta['show_in_rest'] ?? $meta['public'] ?? false;O valor específico do canal ganha do valor geral. Se não existir configuração REST, o sistema herda public. Sem nenhum dos dois, a ability permanece fora do REST. O uso de coalescência nula é relevante porque um false explícito precisa ser preservado; ele não pode ser confundido com ausência de configuração.
| Metadados registrados | public efetivo | REST efetivo |
|---|---|---|
| nenhum metadado de exposição | false | false |
public => true | true | true |
public => true e show_in_rest => false | true | false |
public => false e show_in_rest => true | false | true |
Isso permite quatro políticas úteis. Uma ability pode ser privada em todos os canais; pública por padrão; pública em geral, mas bloqueada no REST; ou privada em geral, mas liberada apenas no REST. Integrações novas devem seguir a mesma lógica: primeiro o valor específico do canal, depois public, por fim o padrão interno da integração.
Um cuidado adicional aparece quando o valor específico é null. O Dev Note informa que null é tratado como não definido e faz o sistema consultar o próximo nível. Se o objetivo é bloquear um canal, use false de maneira explícita.
O que muda para REST, MCP e WP-CLI
A REST API é o primeiro consumidor incorporado ao Core. Uma ability com public => true passa a herdar show_in_rest => true, a menos que o plugin registre uma exceção. A propriedade geral também entra no esquema REST de metadados, permitindo que clientes inspecionem a intenção de exposição.
O MCP Adapter oficial do WordPress recebeu trabalho para herdar meta.public quando meta.mcp.public não estiver definido. O pull request 254 descreve a mesma precedência: uma configuração específica de MCP continua autoritativa. No repositório consultado em 8 de agosto de 2026, a documentação da branch principal já orienta o uso do valor geral e mantém meta.mcp.public como substituição específica.
Isso não significa que qualquer instalação está automaticamente atualizada. A versão estável do plugin instalada no site pode ficar atrás da branch principal. Antes de migrar uma configuração, compare o changelog e a versão do MCP Adapter usada no ambiente. Se ela ainda não herdar meta.public, remover meta.mcp.public pode fazer a ability desaparecer do servidor MCP.
O WP-CLI segue outra política. Segundo o Dev Note, sua listagem de abilities não aplica esse filtro de exposição e pode retornar todas as ações registradas. Isso reforça que public não é uma fronteira de segurança. Cada canal decide como descobrir ações; a ability decide se a conta pode executá-las.
Compatibilidade com plugins existentes
A alteração é aditiva. wp_register_ability() mantém assinatura e retorno, e configurações antigas com show_in_rest continuam funcionando. Uma ability sem public nem show_in_rest permanece indisponível no REST. A diferença é que seus metadados resolvidos passam a incluir public => false, oferecendo um booleano consistente para consumidores.
Três abilities do Core migraram para o novo padrão:
core/get-site-info;core/get-user-info;core/get-environment-info.
A disponibilidade REST delas não mudou. O objetivo foi registrar, em um nível mais amplo, que são ações feitas para clientes externos. Essa informação também permite que integrações além do REST reconheçam a intenção sem depender de um detalhe específico de outro canal.
Plugins não precisam trocar toda ocorrência de show_in_rest imediatamente. A migração faz sentido quando a ação deve servir a vários tipos de cliente. Quando a exposição foi desenhada somente para REST, manter a configuração específica expressa melhor a intenção.
Um roteiro de migração sem surpresa
1. Faça inventário das abilities
Liste nome, função, dados lidos ou alterados, canal atual, capacidade exigida e callback de permissão. A migração não deve começar com uma substituição global de texto. Algumas ações foram expostas apenas para uma interface específica e não deveriam se tornar candidatas a todos os clientes.
2. Classifique a intenção de exposição
Use public => true somente quando a ability foi projetada para clientes externos em geral. Para uma integração exclusiva, mantenha o metadado do canal. Para uma ação interna, não registre exposição e confira se o padrão continua false.
3. Preserve exceções explícitas
Uma ability geral pode precisar ficar fora do REST por tamanho de resposta, semântica do transporte ou risco operacional. Nesse caso, combine public => true com show_in_rest => false. O mesmo princípio vale para meta.mcp.public quando o adaptador instalado oferece esse controle.
4. Reavalie permission_callback
Não use __return_true por conveniência em uma ação que lê dados privados ou modifica estado. Confira capacidade, proprietário do recurso, tipo de conteúdo e escopo do site. Em multisite, uma permissão válida em um site não deve ser presumida na rede inteira.
5. Valide entrada e saída
Esquemas ajudam clientes e agentes a formar chamadas corretas, mas não substituem validação de negócio. Limite quantidades, enumere valores aceitos, normalize identificadores e recuse recursos fora do escopo. O resultado também precisa respeitar o esquema declarado.
6. Teste a matriz de canais
Cubra pelo menos quatro casos: padrão privado, público herdado, opt-out específico e opt-in específico. Faça a descoberta e a execução com uma conta autorizada e outra sem capacidade. Uma suíte que testa apenas o caminho permitido não comprova a recusa.
7. Confira a versão de cada consumidor
WordPress Core, MCP Adapter e clientes externos evoluem em ritmos diferentes. Registre as versões do teste e repita a matriz após atualização. O fato de a branch principal documentar um comportamento não garante que o pacote instalado já o contenha.
Exposição segura para agentes de IA
Agentes acrescentam um motivo para reduzir ambiguidade. Eles descobrem ferramentas a partir de nomes, descrições e esquemas e podem escolher uma ação dentro de um plano maior. Quanto mais amplo o catálogo, maior o espaço para seleção equivocada, combinação perigosa ou uso fora do contexto esperado.
Adote descrições que indiquem efeito e limite. “Gerenciar conteúdo” é amplo demais; “criar rascunho de post sem publicar” oferece uma fronteira compreensível. Marque operações destrutivas quando a integração aceitar anotações, imponha limites de lote e peça confirmação humana antes de ações irreversíveis.
Também separe leitura e escrita. Uma única ability que consulta, altera e publica dificulta autorização e auditoria. Unidades menores permitem expor leitura para mais clientes e reservar escrita para contas ou fluxos específicos. A composição pode acontecer em uma camada de orquestração que mantenha logs e pontos de aprovação.
No transporte MCP, autenticação e permissão continuam essenciais. O próprio pull request do adaptador afirma que herdar public não altera verificações de capacidade nem permission_callback. A mudança organiza a descoberta; ela não concede privilégios.
Como auditar depois da implantação
Registre quais abilities aparecem em cada canal e compare o resultado com o inventário esperado. Se uma atualização tornar uma ação nova pública, o diff deve chamar atenção. Guarde nome da ability, usuário, canal, argumentos não sensíveis, resultado, horário e identificador de correlação. Nunca grave chaves, tokens ou conteúdo privado apenas para “ter log”.
Inclua testes negativos operacionais:
- uma conta sem a capacidade exigida tenta executar;
- uma ability pública é bloqueada explicitamente no REST;
- uma ability privada recebe opt-in somente no MCP;
- um argumento excede o limite definido;
- o recurso pertence a outro autor ou site;
- o cliente tenta encadear uma leitura autorizada com uma escrita não autorizada.
O objetivo não é provar que a ferramenta funciona uma vez. É demonstrar que ela falha de forma previsível quando o pedido ultrapassa o contrato.
Perguntas frequentes
public => true permite acesso sem login?
Não. O metadado controla descoberta e exposição por clientes. Autenticação, capacidades e permission_callback continuam definindo quem executa.
Preciso remover show_in_rest?
Não. A configuração continua válida. Use public quando a intenção for atender vários canais e mantenha show_in_rest quando a política for específica do REST ou precisar substituir o padrão.
O MCP Adapter já entende public?
A branch principal consultada em 8 de agosto de 2026 documenta a herança e o pull request correspondente. Confirme a versão estável instalada antes de depender desse comportamento.
Isso vale para WordPress 7.0?
O novo metadado resolvido faz parte do WordPress 7.1. Plugins que oferecem compatibilidade com versões anteriores precisam testar a presença da versão necessária ou manter uma estratégia compatível.
A vantagem é declarar intenção uma vez
O meta.public oferece uma política comum para um ecossistema em que a mesma ability pode alimentar REST, MCP e outros clientes. Ele reduz repetição e dá às integrações um sinal estável sobre ações feitas para consumo externo.
O ganho depende de uma leitura correta: público não significa irrestrito. Uma migração segura preserva exceções por canal, fortalece permission_callback, valida esquemas e testa recusas. Para agentes de IA, essa disciplina transforma um catálogo de ações em uma superfície controlável e evita que conveniência de descoberta seja confundida com autorização.
