Plano de desenvolvimento do WordPress 7.2: modo sudo, Secrets API, notas do Gutenberg e equipa de lançamento

#Quem lidera o lançamento do WordPress 7.2

Matt Mullenweg é o Release Lead da equipa de lançamento do WordPress 7.2, segundo a página de lançamento do 7.2. A mesma página indica o resto da equipa:

O ciclo de lançamento coincide com uma breve disputa de liderança na Automattic, a empresa que Mullenweg dirige. A 10 de setembro de 2026, a Automattic anunciou que ele estava de licença e que o diretor financeiro, Mark Davies, assumiria a empresa como CEO interino. A 12 de setembro, um porta-voz da empresa disse à CMSWire que Mullenweg era presidente do conselho e CEO com o apoio total do conselho de administração, e a Automattic fixou mais tarde a sua ausência em 33 horas e 20 minutos, sem explicar a licença. O seu papel no projeto open source WordPress não mudou nesses dias: a diretora executiva do WordPress, Mary Hubbard, afirmou que ele continuava a liderar o projeto (WebHosting.Today).

A equipa de lançamento toma e comunica as decisões sobre o lançamento e recolhe contributos da comunidade. As reuniões semanais de programadores decorrem no canal #core do Slack Making WordPress, às quartas-feiras, às 15:00 UTC.

#Gutenberg Notes no WordPress 7.2

As Notes já fazem parte do núcleo. O WordPress 7.1 trouxe notas inline sobre texto selecionado, texto formatado no corpo das notas, preenchimento automático de @menções e notificações por email para os utilizadores mencionados, segundo a issue de iteração das Notes para o 7.2. O plano indica três acréscimos para o 7.2.

Com as Notes no 7.2, as equipas editoriais deverão poder:

• Propor uma alteração no modo de sugestão, que o autor depois aceita ou rejeita.
• Adicionar reações emoji às notas para comentários rápidos.
• Adicionar uma nota a partir da barra de ferramentas do bloco, porque hoje a opção é difícil de encontrar.

Na atualização de 30 de setembro dessa issue, o modo de sugestão estava atrás de uma experiência distribuída por nove pull requests que ainda não tinham tido revisão completa, as reações emoji tinham transitado do 7.1 e passado para um novo seletor de emoji, e o pull request do atalho na barra de ferramentas estava aprovado. Uma issue de acompanhamento separada para o 7.3 reúne o trabalho que não caberá nesta versão, por isso consulte as dev notes da Beta 1 antes de prometer o modo de sugestão a uma equipa editorial.

#Colaboração em tempo real no WordPress 7.2

A edição colaborativa em tempo real não faz parte do 7.2. O plano deixa-a de fora enquanto as decisões de arquitetura não estiverem fechadas. A colaboração em tempo real foi retirada do WordPress 7.0 e, a 18 de setembro de 2026, Chris Zarate propôs uma abordagem com conhecimento do servidor. Hoje os navegadores fundem as edições diretamente e enviam o resultado quando alguém guarda. Com a proposta, cada atualização passa pelo WordPress, que regista quem a fez, verifica a autorização, funde-a e guarda o resultado, e depois envia aos restantes participantes as alterações que lhes faltam ou assinala um conflito para revisão. Os navegadores deixariam de trocar atualizações entre si.

A publicação refere que a exploração está numa fase inicial e não está pronta para o núcleo. Três motores de sincronização candidatos (Yjs-server, Distributed Editing e Intent log) vivem no repositório gutenberg-sync-engines como plugin exploratório. O alojamento é o custo em aberto: fundir no servidor acrescenta carga, consultas frequentes saem mais caras em planos com poucos recursos e um transporte WebSocket exigiria um daemon a correr fora do conjunto de workers PHP, gerido pelo fornecedor de alojamento.

#O que é o modo sudo no WordPress 7.2

À medida que a web se adapta a varreduras automatizadas e a scripts sofisticados de roubo de sessões (session hijacking), a autenticação tradicional do administrador deixa de ser suficiente. Se um atacante intercetar os cookies ou o token de sessão de um administrador ativo, obtém acesso total ao site sem restrições.

O plano inclui o modo sudo no 7.2: nova autenticação antes de ações altamente privilegiadas. O nome vem do comando Unix sudo. Um cookie de sessão roubado deixaria de bastar para executar uma ação privilegiada, porque a ação volta a pedir as credenciais.

Ainda não é público quais as ações que ficarão protegidas. O plano diz que se seguirão uma proposta e um apelo à colaboração, e nenhuma proposta de modo sudo tinha sido publicada em make.wordpress.org/core quando verificámos, a 12 de outubro de 2026. Até lá, a preparação útil é um inventário: liste os ecrãs de administração personalizados e os endpoints REST dos seus plugins que alteram utilizadores, funções e capacidades, ficheiros ou configurações de segurança, porque são esses os fluxos que um passo de nova autenticação passaria a proteger.

#Secrets API do WordPress 7.2 para chaves API

O armazenamento de credenciais confidenciais (tais como chaves API de Stripe, tokens de Mailchimp ou credenciais de bases de dados personalizadas) tem sido historicamente uma vulnerabilidade de arquitetura no WordPress. Durante mais de duas décadas, os programadores não tinham outra opção senão fixar (hardcode) as chaves no ficheiro wp-config.php ou guardá-las como opções sem cifra na tabela wp_options.

A proposta de Secrets API de Eric Mann, de 25 de agosto de 2026, aponta ao 7.2 com um armazenamento de primeiro nível para credenciais. A descrição do problema é concreta: chaves em texto simples na tabela de opções acabam em dumps da base de dados, cópias de segurança, clones de staging e saídas da linha de comandos, e os plugins que cifram as suas próprias chaves fazem-no cada um à sua maneira. As integrações de IA aumentam ainda mais o custo de uma chave exposta.

O desenho proposto:

• A cifra está sempre ativa. Cada segredo recebe a sua própria chave de dados, envolvida por uma chave mestra, que por sua vez é envolvida pela chave do site (cifra em envelope). Não existe modo de texto simples nem constante para desligar a cifra. A criptografia usa libsodium, com sodium_compat como alternativa.
• O armazenamento predefinido é a tabela de opções, que guarda apenas texto cifrado com autoload=no, excluído de options.php e do endpoint REST de configurações. Uma constante dedicada é a fonte de chave preferida; os sites sem ela recorrem a uma chave derivada dos salts existentes.
• Os armazenamentos externos ligam-se através de um drop-in. Um drop-in secrets.php expõe dois pontos de extensão separados: armazenamento (por exemplo HashiCorp Vault ou AWS Parameter Store) e keyring (um KMS ou HSM).
• Falha de forma fechada. Quando o backend não está acessível, a chamada falha sem alternativa local. Os valores só podem ser escritos: não há exportação.

#Funções da Secrets API no 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() devolve um objeto WP_Secret, não uma string. O valor obtém-se através de reveal(), e fingerprint() fornece um identificador seguro para registar em logs. O objeto oculta-se a si próprio nos logs, em var_dump() e nas mensagens de erro, e recusa a serialização. A função devolve null quando o segredo não existe e um WP_Error quando existe mas não pode ser decifrado. Por convenção, os nomes levam um prefixo no formato plugin-slug/secret-name.

Duas capacidades protegem o armazenamento: manage_secrets e manage_network_secrets. Em multisite, uma chave raiz da rede deriva subchaves por site, e os segredos do site e da rede usam funções separadas, sem recurso implícito de uns para os outros. A rotação é conduzida pelo operador, com duas posições de versão, CURRENT e PREVIOUS, e um hook é disparado em cada escrita com o autor, a data e hora e as impressões digitais antiga e nova.

Não há filtro no caminho de leitura, de propósito: um filtro permitiria a qualquer plugin intercetar credenciais, por isso os fornecedores de alojamento ligam-se através de providers. A proposta também é explícita quanto aos seus limites. Qualquer código que corra dentro do WordPress pode chamar wp_get_secret(), e o slug do plugin no nome de um segredo não é autenticado, pelo que a API não isola os segredos de um plugin dos de outro. O que elimina são as chaves em texto simples em dumps, cópias de segurança e cópias de staging.

Para as agências e programadores que criam integrações modernas com WordPress (incluindo integrações com agentes de IA, onde as chaves API são utilizadas intensamente), a Secrets API oferece um enquadramento estandarizado que aproxima a segurança do WordPress dos padrões corporativos.

#Como migrar chaves de API de plugins para a Secrets API

A proposta não inclui ecrã de administração no 7.2: um ecrã de configurações fica adiado para o 7.3. O suporte de WP-CLI está no âmbito do 7.2, para que as credenciais deixem de aparecer no histórico da shell e nas listas de processos, mas os nomes dos comandos ainda não estão decididos (é uma das questões em aberto na publicação). A proposta prevê primeiro um plugin de funcionalidade e depois um patch para o núcleo com a mesma API.

No código do plugin, a migração é um passo deliberado por opção, através de wp_import_option_as_secret(), e não uma varredura automática. Os segredos importados ficam marcados para rotação, porque o valor antigo em texto simples já viajou para todas as cópias de segurança feitas até agora. Uma leitura segura entre versões, para um plugin que tem de funcionar no 7.1 e no 7.2, tem este aspeto:

$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', '' );
}

As assinaturas vêm da proposta e podem mudar antes da Beta 1, por isso mantenha a verificação function_exists() e o caminho antigo para os sites no 7.1. A proposta não diz se a importação remove a opção original, por isso consulte a dev note antes de apagar o que quer que seja. Quando a chave estiver na Secrets API, faça a rotação junto do fornecedor de pagamentos ou da API.

#Porque é que os fornecedores de alojamento contestam a proposta da Secrets API

A discussão nos comentários da proposta mostra onde o desenho ainda é contestado. Chris Reynolds, da Pantheon, escreveu que a Pantheon usa um armazenamento externo de segredos com acesso só de leitura a partir das aplicações, perguntou se os providers só de leitura estão no âmbito e como devem os plugins tratar o WP_Error que uma escrita devolveria, e notou que os armazenamentos de plataforma que precisam de texto simples entram em conflito com o modelo de drop-in. Ryan McCue, da Altis, opôs-se à proposta na forma atual e defendeu que o WordPress deveria apenas ler segredos, deixando a cifra a HSM externos.

Eric Mann respondeu que um provider só de leitura pode transformar o setter numa operação sem efeito e que os fornecedores de alojamento poderão substituí-lo por um provider mais robusto, com um exemplo para AWS Secrets Manager no seu repositório secrets-api. Um pull request para o wordpress-develop (#13759) trata das preocupações sobre os providers de alojamento. Continuam em aberto cinco questões na publicação, entre elas se duas posições de versão bastam e que comandos WP-CLI vêm primeiro.

Para quem desenvolve plugins, a consequência prática é que wp_set_secret() pode falhar num alojamento gerido, por desenho. Um formulário de configurações que guarda uma chave tem de mostrar o erro devolvido em vez de presumir que correu bem.

#Alterações nas Application Passwords no WordPress 7.2

A secção de segurança do plano inclui também o reforço das Application Passwords: melhorias de UX, uma notificação por email quando é adicionada uma nova application password, correções na deteção do ambiente, tratamento mais seguro de default_role e suporte para cookies SameSite. O trabalho é acompanhado nos tickets Trac #66009, #63927, #57388, #46744 e #37000. Um processamento de HTML reforçado sobre a HTML API completa a lista de segurança.

As application passwords são a credencial usada pela maioria das integrações com a REST API, pelo que a notificação dá ao dono do site um sinal quando alguém adiciona uma sem o seu conhecimento.

#Outras funcionalidades no plano do WordPress 7.2

O Ipsum, o novo tema predefinido, é um tema de blog minimalista pensado como tela em branco, com sublinhados pontilhados, alguns conjuntos tipográficos e variações de estilo que mudam as cores de toda a página, imagens incluídas. Todas as combinações de cor e estilo cumprem o contraste WCAG AA, segundo a publicação de apresentação de Henrique Iamarino. O Ipsum põe também fim aos nomes baseados no ano para os temas predefinidos. O código está no GitHub para testes, e a equipa descreve o calendário como apertado.

O trabalho de IA continua no plugin AI, sem garantia de chegar ao núcleo: mais abilities (cobertura experimental só de leitura para multimédia, taxonomias e comentários), um MCP Adapter atualizado para a especificação MCP atual e distribuído através do diretório de plugins, identidades de agentes com permissões auditáveis e respostas em streaming no PHP AI Client.

Em blocos e APIs, o plano inclui um bloco Description list para <dl>, <dt> e <dd>, pesquisa por palavra-chave no bloco Icon, uma diretiva data-wp-html e um router na Interactivity API, e renderização do lado do servidor para o bloco Table of Contents, para que possa tornar-se estável. A atualização para React 19 já chegou em grande parte ao Gutenberg, mas dificilmente será incluída por completo no 7.2.

Na administração, as DataViews e DataForms passam a ter vistas, campos e ações registados no servidor, e o inspetor de artigos está a ser substituído por um DataForm. As mensagens de erro ficam mais fáceis de diagnosticar e ganham um botão de cópia, e uma base reconstruída do Site Editor permite aos plugins registar os seus próprios ecrãs. No desempenho, a concatenação de scripts e estilos está a ser substituída por prefetching (Trac #57548), a par do trabalho do plugin Enhanced Responsive Images.

#Calendário de lançamento do WordPress 7.2

David Baumwald publicou o calendário do WordPress 7.2 no make.wordpress.org a 6 de outubro de 2026. Cada etapa começa às 15:00 UTC.

A Beta 1 é o momento em que os contribuidores do núcleo passam para testes e correção de erros e em que começam a surgir as dev notes. A RC1 traz o Field Guide, o congelamento rígido das strings e o ramo de lançamento. Depois do congelamento de funcionalidades só entram correções de erros, com as regressões primeiro.

Instale a Beta 1 numa cópia de staging do site a 20 de outubro e repita os testes de plugins e tema com a RC1 a 17 de novembro, para que os conflitos apareçam em staging antes de 8 de dezembro.

#Como testar a beta do WordPress 7.2

Há dois caminhos documentados. O plugin WordPress Beta Tester, que se encontra em Ferramentas, Beta Testing (Definições em multisite), muda o atualizador integrado do canal predefinido Point release para Bleeding edge (trunk) ou para pacotes beta e RC. Na linha de comandos, wp core update aceita --version=nightly ou o caminho para um ficheiro zip descarregado. Faça primeiro uma cópia de segurança e mantenha as betas fora da produção.

O que testar decorre do plano: plugins que guardam chaves de API em opções, fluxos de administração personalizados que alteram utilizadores ou ficheiros, fluxos editoriais que dependem das Notes e temas filhos, se tenciona migrar um site para o Ipsum.

#Como preparar o site para o WordPress 7.2

O WordPress 7.2 constitui uma das atualizações estruturais mais significativas de 2026. A fusão de fluxos de colaboração no editor com infraestruturas de segurança robustas no backend exige que as agências e programadores preparem os seus ecossistemas desde já.

Na WPPoland estamos a adaptar os nossos desenvolvimentos headless de Astro e integrações de servidores MCP para consumir de forma segura a nova Secrets API e responder corretamente aos pedidos de reautenticação do Modo Sudo.

Pretende assegurar o seu sistema WordPress corporativo ou migrar as suas extensões para as novas normas do núcleo de 2026? Contacte-me hoje mesmo para obter um plano de migração personalizado.