Essa nova extensão de código aberto permite que usuários autenticados ocultem facilmente a barra de administração, enquanto mantém atalhos úteis na barra de ferramentas do navegador, oferece acesso rápido a todos os seus sites WordPress e adiciona ferramentas úteis para desenvolvedores e criadores de conteúdo.

Por padrão, a barra de administração fica no topo de cada página que se está vendo enquanto se está conectado ao WordPress, mantendo o painel, o editor e seu perfil sempre acessíveis. Essa conveniência tem um custo: a barra ocupa espaço na área de visualização, de modo que a página na tela nunca é exatamente a mesma que o visitante vê. Em sites que utilizam recursos mais dinâmicos, como cabeçalhos fixos ou efeitos acionados pela rolagem da página, ela pode gerar efeitos visuais estranhos (artefatos) que levam você a procurar por um erro que não existe. Além disso, a barra de administração pode se tornar exageradamente carregada à medida que plugins adicionam seus próprios recursos e atalhos a ela. Desativá-la nas configurações de perfil troca um problema por outro, pois os atalhos desaparecem junto.

Esse problema foi o ponto de partida para a criação desta extensão. Ela oculta a barra de administração nos sites que você escolher e mantém os atalhos mais usados ​​a apenas um clique de distância. Para trazer a barra completa de volta bastam dois cliques, sem necessidade de ir até o painel.

O que começou como uma solução para esse dilema específico evoluiu para algo mais amplo: uma maneira de identificar o WordPress onde quer que você o encontre na Web, acessar seus próprios sites de qualquer lugar e ter à mão um conjunto de ferramentas para testes e revisões.

Enquanto você navega, o ícone na barra de ferramentas indica se o site atual utiliza WordPress e se você está conectado, tudo isso de forma discreta. Em um site que você gerencia, abrir a extensão revela atalhos para o painel ou para o editor referente ao post, página, taxonomia ou modelo que está sendo visualizado, incluindo páginas baseadas em modelos que abrem no Editor do Site em temas de blocos. Um iniciador armazenado localmente memoriza os sites WordPress aos quais você faz acesso, mantendo-os acessíveis mesmo quando você está navegando em outros lugares.

Algumas ferramentas também se mostram mais adequadas para o navegador do que para um plugin do WordPress. A extensão pode exibir os limites de blocos sobre a página montada, abrir uma janela de prévia com dimensões de tela de celular, recarregar a página ignorando o cache ou limpar cookies e o armazenamento local do site que você está acessando. Algumas dessas ações são difíceis de executar de dentro do próprio site e nenhuma delas exige a instalação de plugins ou outro software, de modo que as mesmas ferramentas ficam disponíveis em qualquer site WordPress que você visitar.

Todo esse processo ocorre no sua máquina. A extensão lê a página exibida para identificar o conteúdo e, quando precisa de informações além das que a página fornece, consulta o site. Suas preferências e a lista de sites aos quais você faz acesso permanecem no seu navegador. Nenhum dado é enviado para outros locais e não há qualquer tipo de rastreamento ou coleta de dados analíticos.

A extensão começou como um projeto independente e tornou-se um projeto oficial com o apoio ativo de Matt Mullenweg. Entre os colaboradores de destaque estão Fabian Kägy, colaborador do núcleo do WordPress e colega na Fueled (anteriormente 10up), que ajudou a definir grande parte do projeto e arquitetura iniciais, e Khokan Sardar, que contribuiu com diversas correções no código. Vários outros colegas da Fueled realizaram testes extensivos e influenciaram a configuração final da ferramenta.

Você pode acompanhar o desenvolvimento no repositório do GitHub, onde o envio de relatos de erros e pull requests são bem-vindos.

Você pode atualizar para o WordPress 7.0.4 baixando-o em WordPress.org ou acessando o Painel do seu site em Painel → Atualizações e clicando em Atualizar agora. Os sites que possuem suporte a atualizações automáticas em segundo plano começarão a ser atualizados em breve.

Para mais informações, consulte a página de documentação do WordPress 7.0.4 no HelpHub.

Atualização de segurança incluída nesta versão

A equipe de segurança gostaria de agradecer à equipe da pwn.ai por relatar com responsabilidade a seguinte vulnerabilidade e permitir que ela seja corrigida nesta versão:

• Execução remota de código (RCE) para usuários autenticados com perfil de Autor ou superior (Author+) por meio de envio (upload) de arquivo malicioso em sites que utilizam Imagick e Ghostscript.

Backports (Retroaplicação de correções)

Como cortesia, essas correções estão sendo aplicadas via backport desde a versão 4.7 até a versão 7.1 RC3 (que está prevista para sair ainda hoje). Lembramos que apenas a versão mais recente do WordPress recebe suporte ativo. Os backports estão em andamento e serão lançados à medida que estiverem prontos.

Referências CVE e GHSA

Mais detalhes podem ser encontrados no alerta de segurança oficial: CVE-2026-65640 / GHSA-8vr3-7mxf-gx8w.

Agradecemos aos colaboradores do WordPress

Este lançamento foi liderado por John Blackbourn, com contribuições significativas de Dennis Snell e Jeremy Felt. Além disso, o WordPress 7.0.4 e seus backports não teriam sido possíveis sem as valiosas contribuições das seguintes pessoas:

Aaron D. Campbell, Aaron Jorbin, Adam Silverstein, Aki Hamano, Alex Concha, Barry, Dennis Snell, Ehtisham Siddiqui, Jeremy Felt, John Blackbourn, Jonathan Desrosiers, Lance Willett, Marin Atanasov, Mohammad Jangda, Sergey Biryukov, vortfu, Weston Ruter e representantes da WP Engine.

Você pode atualizar para o WordPress 7.0.3 baixando-o do WordPress.org ou visitando o Painel do seu site → Atualizações e clicando em Atualizar agora. Os sites que suportam atualizações automáticas em segundo plano começarão a ser atualizados em breve.

Para mais informações, visite o HelpHub do WordPress 7.0.3.

Atualizações de segurança incluídas nesta versão

A equipe de segurança gostaria de agradecer às seguintes pessoas por relatar vulnerabilidades de forma responsável e permitir que elas sejam corrigidas nesta versão:

• XSS refletido na tela de login antes da autenticação, com potencial para execução de código PHP (relatado pela equipe da pwn.ai).
• XSS armazenado por colaboradores ou superiores em posts através da opção de emojis (relatado por Asaf Mozes – amosec).
• XSS armazenado por colaboradores ou superiores no bloco de Conteúdo do Post (relatado por N05ec@LZU).
• XSS armazenado por colaboradores ou superiores na Edição Rápida em sites com muitos usuários (relatado por Naveen S e Ajmal Moochingal).
• XSS armazenado por colaboradores ou superiores no bloco de Data do Post (relatado por Alex Concha, da equipe de segurança do WordPress).
• Elevação de privilégios em redes multisite com cadastro de usuários liberado, permitindo que um usuário crie um novo site (relatado pela Aikido Security).
• Vazamento de informações no bloco de Comentários Recentes, expondo comentários de posts protegidos por senha (relatado por Ehtisham Siddiqui, da equipe de segurança do WordPress).
• Enumeração (descoberta) de links amigáveis de posts (relatado por HDWSec).
• Exposição de notas internas nos feeds de comentários (relatado por Elio Gubser).
• Injeção de CSS por autores ou superiores, burlando o filtro de atributos seguros (relatado pela Anthropic).
• Burlar o processo de confirmação de e-mail (relatado por Omar Hasan).
• Falsificação de requisição no lado do servidor (SSRF) na validação de URLs, permitindo conexões com a rede local (relatado por Andrew Mohawk e outros pesquisadores independentes).

Backports

Como cortesia, essas correções estão sendo suportadas, quando necessário, para todas as versões elegíveis para receber correções de segurança (atualmente até 4.7). Como lembrete, apenas a versão mais recente do WordPress é ativamente suportada. Os backports estão em andamento e serão enviados à medida que se tornarem prontos.

O WordPress 7.1 RC2 também foi lançado, contendo todas as correções aplicáveis.

Referências CVE e GHSA

Detalhes da vulnerabilidade XSS da tela de login podem ser encontrados no aviso: CVE-2026-64638 / GHSA-52p2-r8wf-jcrf.

Agradecimento aos colaboradores do WordPress

Este lançamento foi liderado por John Blackbourn. Além dos pesquisadores de segurança mencionados acima, o WordPress 7.0.3 e seus backports não teriam sido possíveis sem as contribuições significativas das seguintes pessoas:

Aaron D. Campbell, Aaron Jorbin, Adam Silverstein, adrianmoldovanwp, Aki Hamano, Alex Concha, Andrew Duthie, Andrew Serong, annezazu, Barry, Bernie Reiter, Daniel, Daniel Richards, David Biňovec, Dennis Snell, Ehtisham Siddiqui, Erwan Le Rousseau, Fabian Kaegy, fiocavallari, George Mamadashvili, gubser, Isabel Brison, Jarda Snajdr, Jb Audras, Jeremy Felt, Joe Dolson, Joe Hoyle, John Blackbourn, Jon Surrell, Jonathan Desrosiers, Khokan Sardar, Lance Willett, lucasbustamante, lucatume, Marco Ciampini, Marin Atanasov, Mohammad Jangda, Mukesh Panchal, Paul Kevan, Peter Wilson, ramonopoly, SergeyBiryukov, vortfu e Weston Ruter.

Esta versão do software WordPress ainda está em desenvolvimento. Não instale, execute ou teste esta versão do WordPress em sites de produção ou de missão crítica. Em vez disso, recomenda-se avaliar o RC1 em servidor e site de de testes.

O WordPress 7.1 RC1 pode ser testado usando qualquer um dos seguintes métodos:

A data de lançamento final programada para o WordPress 7.1 é 19 de agosto de 2026. O cronograma de lançamento completo pode ser encontrado aqui. Sua ajuda para testar versões Beta e RC é vital para tornar esta versão o mais estável e poderosa possível. Agradecemos a todos que contribuem testando!

Continue verificando o blog Make WordPress Core para posts relacionados a versão 7.1 nas próximas semanas para obter mais informações.

O que há no WordPress 7.1 RC1?

O WordPress 7.1 RC1 contém mais de 145 atualizações e correções desde a versão Beta 4, incluindo 57 no editor e 88 no núcleo.

Para obter uma visão geral do que há de novo no WordPress 7.1, leia o anúncio do Beta 1 e o WordPress 7.1 Dev Notes. Para obter um resumo abrangente, consulte o Guia de Campo do WordPress 7.1.

Você também pode explorar os detalhes técnicos de todos os problemas abordados desde a versão Beta 4 usando os links abaixo:

• Tíquetes fechados do GitHub para a versão 7.1 desde 29 de julho de 2026.
• Tíquetes fechados do Trac para a versão 7.1 desde 29 de julho de 2026.

Novos recursos desde o Beta 1

• Icons API : Novas APIs para registrar ícones e coleções de ícones no núcleo, prontas para que os plugins se estendam.
• Configuração de carregamento especulativo: os padrões de carregamento especulativo agora podem ser configurados por meio de variáveis de ambiente e constantes.
• Notificações por e-mail para @menções: As notificações por e-mail foram introduzidas quando mencionadas em uma nota.
• Revisões compartilháveis: Compartilhe links para revisões específicas para uma colaboração mais rápida.

Quer analisar mais profundamente os detalhes e as notas técnicas para este lançamento? Esses tíquetes e pull requests são apenas algumas das últimas atualizações:

• #GB-79839: Aplicar globalmente: escolha quais estilos de bloco modificados aplicar
• #GB-80814: Nova configuração de editor responsivo para ocultar estilos responsivos
• #GB-80107: Guias: botões na barra de ferramentas para reordenar guias
• #GB-80046: DataViews: seleção de intervalo de cliques para deslocamento
• #65636: Pré-carregue solicitações de API REST buscadas no carregamento do editor
• #65613: As notas foram excluídas das consultas de feed de comentários
• #65491: KSES permite o atributo autofocus em elementos de dialog
• #65517: Os limites de upload para multisite são aplicados ao fazer o upload de mídia de uma URL.
• #62757 : Atualizada a biblioteca da interface do usuário do jQuery para a versão 1.14.2

Como você pode contribuir

O WordPress é um software de código aberto possibilitado por uma comunidade apaixonada de pessoas que colaboram e contribuem para o seu desenvolvimento. Os recursos abaixo descrevem várias maneiras de ajudar a plataforma web de código aberto mais popular do mundo, independentemente de sua experiência técnica.

Envolva-se em testes

Testar problemas é crucial para o desenvolvimento de qualquer software. É também uma forma significativa de qualquer pessoa contribuir.

Sua ajuda para testar a versão do WordPress 7.1 RC1 é fundamental para garantir que a versão final seja a melhor possível. Embora testar o processo de atualização seja essencial, experimentar novos recursos é igualmente importante. Este guia detalhado irá orientá-lo através de recursos de teste no WordPress 7.1.

Atualize seu tema ou plugin

Para autores de plugins e temas, seus produtos desempenham um papel integral na extensão da funcionalidade e do valor do WordPress para todos os usuários.

Agradecemos por continuar a testar seus temas e plugins com os lançamentos beta do WordPress 7.1. Com o RC1, você deverá concluir seus testes e atualizar a versão “Tested up to” no arquivo readme do seu plugin para 7.1.

Se você encontrar problemas de compatibilidade, publique informações detalhadas no fóruns de suporte.

Teste em suas plataformas de hospedagem

Os hosts da Web fornecem infraestrutura vital para o suporte ao WordPress e seus usuários. O teste em sistemas de hospedagem ajuda a informar o processo de desenvolvimento, garantindo que o WordPress e as plataformas de hospedagem sejam totalmente compatíveis, livres de erros, otimizados para a melhor experiência possível do usuário e que as atualizações sejam implementadas para sites de clientes sem problemas.

Quer testar o WordPress no seu sistema de hospedagem? Comece a configurar testes de hospedagem distribuída aqui. Agradecemos a todos os hosts da web que ajudam a testar o WordPress!

Curioso sobre os lançamentos e testes em geral? Acompanhe as iniciativas de teste no Make Core e junte-se ao canal #core-test no Making WordPress Slack.

Agradecemos a @krupajnanda, @annezazu,
@amykamala, @wildworks e @masteradhoc pela colaboração no post original.

Esta versão beta destina-se apenas a testes e desenvolvimento. Não instale, execute ou teste esta versão do WordPress em sites de produção ou de missão crítica. Em vez disso, use um ambiente de teste ou local para explorar os novos recursos.

Como testar o WordPress 7.1 Beta 4

Você pode testar o WordPress 7.1 Beta 4 de qualquer uma das seguintes maneiras:

A data de lançamento final programada para o WordPress 7.1 é 19 de agosto de 2026. O cronograma de lançamento completo pode ser encontrado aqui. Sua ajuda para testar versões Beta e RC é vital para tornar esta versão o mais estável e poderosa possível. Agradecemos a todos que contribuem testando!

Saiba o que há de novo no WordPress 7.1 : Leia o anúncio do Beta 1 para detalhes e destaques.

Qual a importância dos testes?

O teste de erros é uma parte crítica do desenvolvimento de qualquer software, e é uma maneira significativa de qualquer pessoa contribuir, seja você tendo experiência ou não. Detalhes sobre o que testar no WordPress 7.1 estão disponíveis aqui.

Se você encontrar um problema, por favor, compartilhe-o na área Alfa / Beta dos fóruns de suporte. Se você está confortável em enviar um relatório de erros reproduzível, você pode fazê-lo via WordPress Trac. Você também pode verificar seu problema contra essa lista de erros conhecidos.

Curioso sobre testes de lançamentos em geral e como começar? Acompanhe as iniciativas de teste no Make Core e junte-se ao canal #core-test no Making WordPress Slack.

O que há no WordPress 7.1 Beta 4?

O WordPress 7.1 Beta 4 contém mais de 114 atualizações e correções desde a versão do Beta 3, incluindo 51 no editor e 63 no núcleo.

Cada ciclo beta se concentra em correções de erros, e mais estão a caminho com sua ajuda através de testes. Você pode navegar pelos detalhes técnicos para todas as questões abordadas desde o Beta 3 usando esses links:

• Tíquetes fechaos do GitHub para a versão 7.1 desde 22 de julho de 2026.
• Tíquetes fechados do Trac para a versão 7.1 desde 22 de julho de 2026.

A versão Beta 4 traz uma rodada de correções que tornam o editor mais suave para trabalhar. As notas agora permanecem ligadas de forma confiável à passagem a que se referem, e as pessoas marcadas são exibidas de forma limpa e clara.

Agradecemos a @ krupajnanda, @annezazu, @wildworks e @amykamala pela colaboração no post original.

Isso é útil, mas o desenvolvimento de plugins e temas geralmente envolve mais de um ambiente isolado. Você pode precisar de um site limpo para reproduzir um problema, de um site salvo para continuar a depuração, de outro site configurado com uma versão diferente do PHP e de uma forma de inspecionar todos eles sem navegar pela interface.

Atualizações recentes do Playground facilitam a automação desses fluxos de trabalho. O site do Playground agora disponibiliza um objeto de gerenciamento de sites para o JavaScript executado na página principal. O código no console do navegador ou em uma ferramenta de automação pode acessar esse objeto por meio de window.playgroundSites para listar e alternar entre sites, salvar sites temporários, renomear sites salvos, alterar configurações do ambiente de execução ou obter o PlaygroundClient do site ativo.

Este post mostra como quem desenvolve plugins e temas pode usar essa API no console do navegador para agilizar tarefas do dia a dia.

Uma interface para gerenciar sites

Antes dessas atualizações, tudo o que ficava fora da interface do Playground precisava recriar o comportamento de gerenciamento de sites. Ferramentas MCP, o WebMCP nativo do navegador, experimentos no DevTools e componentes da interface precisavam de uma forma de listar, salvar, renomear ou alternar entre sites.

A nova PlaygroundSitesAPI oferece uma interface compartilhada para esses fluxos de trabalho. Depois que o site do Playground carrega, o JavaScript executado na página pode chamar essa interface por meio de window.playgroundSites. Isso permite gerenciar sites com código sem depender de uma automação frágil da interface.

Na prática, agora você pode abrir o DevTools e executar:

window.playgroundSites.list();

O resultado é um array de registros de sites:

[
  {
    slug: "quiet-river",
    name: "Quiet River",
    storage: "temporary",
    isActive: true,
  },
];

O campo storage indica se o site é temporário, está salvo no armazenamento do navegador ou está salvo no sistema de arquivos local. Sites temporários desaparecem quando a página é recarregada, a menos que você os salve primeiro.

Visão geral da API

Os fluxos de trabalho deste post usam estes métodos principais:

A API fica disponível depois que o Playground carrega os sites salvos. Se window.playgroundSites estiver indefinido, aguarde até que a interface do Playground termine de carregar. Em seguida, chame await window.playgroundSites.isReady() antes de executar comandos que dependem do cliente do site ativo.

Consulte a documentação da Sites API para ver a referência completa, incluindo métodos relacionados ao salvamento automático e ao salvamento explícito.

Execute os exemplos no site do Playground

Os exemplos a seguir usam a Sites API em playground.wordpress.net. Abra o site, aguarde o carregamento da interface do Playground, abra o console do DevTools do navegador e execute await window.playgroundSites.isReady(). Depois, cole os exemplos no console. Uma ferramenta de automação de navegador, como o Playwright, pode executar o mesmo JavaScript enquanto controla uma aba aberta no site do Playground.

Essa API faz parte do site do Playground. Ela não faz parte do pacote @wp-playground/client nem da Playground CLI e não é exposta por /remote.html quando você incorpora o Playground a outro aplicativo. Para sites incorporados e automações de teste que inicializam o próprio cliente do Playground, use a API JavaScript.

Cenário 1: Crie um site limpo para testar um plugin

Ao depurar um problema de plugin, comece com um site novo que corresponda ao ambiente desejado. O exemplo a seguir cria um site temporário com PHP 8.4, a versão mais recente do WordPress e acesso à rede ativado:

const slug = await window.playgroundSites.createNewTemporarySite(
  "plugin-test-php-84",
  {
    phpVersion: "8.4",
    wpVersion: "latest",
    networking: true,
  }
);

console.log(`Active test site: ${slug}`);

Use essa opção quando precisar de um ambiente limpo antes de instalar um plugin ou reproduzir um problema relatado. Neste momento, o site é temporário, portanto as alterações não persistem depois que a página é recarregada.

Cenário 2: Salve e renomeie uma reprodução de erro

Depois de reproduzir o erro, salve o site antes de fazer outras alterações. O salvamento transforma um site temporário em um site armazenado no navegador:

const saved = await window.playgroundSites.saveInBrowser(
  "Plugin compatibility test"
);

console.log(saved);

O objeto retornado inclui o slug e o tipo de armazenamento do site:

{
  slug: "plugin-test-php-84",
  storage: "opfs",
}

Depois de salvar, você pode renomear o site ativo:

await window.playgroundSites.rename(
  "Plugin compatibility test - PHP 8.4"
);

A ordem é importante. rename() funciona apenas com sites salvos. Se você chamar o método em um site temporário, o Playground gera este erro:

Cannot rename a temporary site. Save it first.

Cenário 3: Alterne entre sites de teste salvos

Ao manter sites separados para diferentes casos de reprodução, liste-os e alterne entre eles pelo slug:

const sites = window.playgroundSites.list();

console.table(
  sites.map((site) => ({
    slug: site.slug,
    name: site.name,
    storage: site.storage,
    active: site.isActive,
  }))
);

Para ativar um deles:

const target = window.playgroundSites
  .list()
  .find((site) => site.name.includes("Plugin compatibility"));

if (target) {
  await window.playgroundSites.setActiveSite(target.slug);
}

O método setActiveSite() aguarda a inicialização do site selecionado antes de concluir. Assim, os comandos seguintes podem pressupor com segurança que o site ativo está pronto.

Cenário 4: Inspecione o estado do plugin com PHP

A API de gerenciamento de sites dá acesso ao PlaygroundClient do site ativo. Esse cliente pode executar PHP no ambiente do WordPress.

function phpResponseText(response) {
  return "text" in response
    ? response.text
    : new TextDecoder().decode(response.bytes);
}

await window.playgroundSites.isReady();
const client = window.playgroundSites.getClient();

if (!client) {
  throw new Error("The active Playground site has not booted yet.");
}

const response = await client.run({
  code: `<?php
require_once "/wordpress/wp-load.php";

echo json_encode([
  "php" => phpversion(),
  "wp" => get_bloginfo("version"),
  "active_plugins" => get_option("active_plugins"),
]);
`,
});

console.log(phpResponseText(response));

Com isso, você pode consultar diretamente no banco de dados do WordPress os dados de um plugin, sem navegar pelo wp-admin. Substitua o PHP por verificações específicas de opções, dados do tema ativo, tipos de post personalizados ou linhas específicas do plugin no banco de dados.

Por exemplo, para inspecionar uma opção:

const response = await client.run({
  code: `<?php
require_once "/wordpress/wp-load.php";
echo wp_json_encode(get_option("woocommerce_currency"));
`,
});

console.log(phpResponseText(response));

O Playground usa SQLite para armazenamento no WordPress. Portanto, prefira APIs do WordPress, como get_option() e $wpdbem vez de depender de comportamentos específicos de SQL de um banco de dados.

Cenário 5: Altere as configurações do ambiente de execução de um site salvo

Às vezes, um erro ocorre apenas com uma versão específica do PHP ou com o acesso à rede ativado. Depois que o site ativo estiver salvo, você pode atualizar diretamente as configurações do ambiente de execução:

await window.playgroundSites.setPhpVersion("8.3");
await window.playgroundSites.setNetworking(true);

Esses métodos exigem um site salvo. Se o site ativo for temporário, salve-o primeiro:

await window.playgroundSites.saveInBrowser("Network test");
await window.playgroundSites.setNetworking(true);

Este é um bom fluxo de trabalho para testes de compatibilidade:

1. Crie um site limpo.
2. Instale e configure o plugin.
3. Salve o site.
4. Alterne entre versões do PHP.
5. Execute novamente as mesmas verificações do plugin.

Cenário 6: Crie uma pequena lista de verificação de compatibilidade

Você pode combinar as chamadas da API em uma lista de verificação manual no DevTools. Este exemplo cria e salva um site, coleta informações básicas de versão e deixa o resultado no console:

async function prepareCompatibilitySite() {
  function phpResponseText(response) {
    return "text" in response
      ? response.text
      : new TextDecoder().decode(response.bytes);
  }

  const slug = await window.playgroundSites.createNewTemporarySite(
    "compatibility-check",
    {
      phpVersion: "8.4",
      wpVersion: "latest",
      networking: true,
    }
  );

  await window.playgroundSites.saveInBrowser(
    "Compatibility check - PHP 8.4"
  );

  await window.playgroundSites.isReady();
  const client = window.playgroundSites.getClient();
  if (!client) {
    throw new Error("The compatibility site has not booted yet.");
  }

  const response = await client.run({
    code: `<?php
require_once "/wordpress/wp-load.php";
echo wp_json_encode([
  "site_url" => get_site_url(),
  "php" => phpversion(),
  "wp" => get_bloginfo("version"),
  "theme" => wp_get_theme()->get("Name"),
]);
`,
  });

  return {
    site: window.playgroundSites
      .list()
      .find((site) => site.slug === slug),
    info: JSON.parse(phpResponseText(response)),
  };
}

console.log(await prepareCompatibilitySite());

Isso não substitui um conjunto completo de testes. É uma forma rápida de preparar e inspecionar um site de teste no navegador durante a triagem de um problema relatado.

Como isso se relaciona com as atualizações recentes do Playground

Atualizações recentes do Playground também adicionaram pontos de integração mais completos com IA e automação do navegador por meio de MCP e WebMCP. A mesma API centralizada de gerenciamento de sites oferece suporte a essas integrações. Assim, agentes de IA e ferramentas nativas do navegador podem gerenciar sites do Playground por meio de operações explícitas, em vez de clicar em menus.

Por exemplo:

• list() corresponde naturalmente a “mostre meus sites do Playground”.
• setActiveSite(slug) corresponde a “abra o site chamado Plugin compatibility test”.
• saveInBrowser(name) corresponde a “salve esta reprodução para que eu possa retomá-la depois”.
• getClient() dá às ferramentas acesso à execução de PHP, a solicitações HTTP e a operações no sistema de arquivos.

O resultado é uma base mais simples para os fluxos de trabalho de agentes. Um agente de programação pode manter um site para investigação, outro para uma reprodução limpa e mais um para verificar uma correção, sem depender do estado visual da interface.

Para ver as instruções de configuração, consulte Conecte agentes de programação ao WordPress Playground com MCP. Para ver as opções de configuração baseadas em URL, como php, wp, networking e site-slug, consulte a documentação da Query API.

Limitações práticas

Considere estes detalhes:

• window.playgroundSites fica disponível somente depois que o Playground termina de carregar os sites salvos.
• Sites temporários precisam ser salvos antes que você possa renomeá-los, excluí-los ou atualizar suas configurações de PHP e rede.
• Chame isReady() antes de getClient() quando o site ativo ainda puder estar em inicialização. Até que o site esteja pronto, getClient() pode retornar undefined.
• saveToLocalFileSystem() pode abrir um seletor de diretório do navegador quando você não fornece uma referência ao diretório.
• O armazenamento do navegador continua sujeito às limitações do navegador. Limpar os dados do site pode remover sites salvos do Playground.

Experimente

Abra playground.wordpress.net, aguarde o carregamento do site, abra o DevTools e execute:

await window.playgroundSites.isReady();
window.playgroundSites.list();

Depois, crie um site temporário, salve-o, alterne entre sites salvos e use getClient() para inspecionar o estado do WordPress com PHP. Para quem desenvolve plugins e temas, isso transforma o Playground de um único ambiente isolado em um conjunto de ambientes de teste no navegador.

Os posts “O que há de novo no AI…” — identificados com a tag #ai-release — são publicados após cada versão do plugin AI para apresentar os novos recursos incluídos.

Temos o prazer de anunciar o lançamento do AI 1.2.0, a atualização mais recente do plugin canônico que oferece recursos de inteligência artificial no WordPress.

Esta versão apresenta o novo experimento Suggest Reply, a geração de resumos de conteúdo em massa e duas novas Habilidades somente para leitura. Ela também simplifica a interface de configurações do plugin e aprimora o Type-ahead Text, o Connector Approvals, a acessibilidade e as possibilidades de extensão para desenvolvedores.

O que há de novo na versão 1.2.0?

Novo experimento: Suggest Reply

O AI 1.2.0 apresenta o novo experimento Suggest Reply para moderação de comentários. Quando ele está ativado, moderadores de comentários podem gerar uma resposta contextual na tela de administração de comentários ou no widget Atividade do painel. As sugestões podem considerar o comentário, o post ao qual ele pertence e diretrizes editoriais opcionais.

O experimento oferece:

• Tons de resposta amigáveis, profissionais e casuais, com o tom amigável selecionado por padrão.
• Instruções ou diretrizes editoriais opcionais.
• Inserção da sugestão diretamente no formulário de resposta embutido do WordPress.

As respostas geradas permanecem como sugestões para que um moderador possa revisá-las, editá-las e decidir se deseja publicá-las. Isso ajuda os sites a responder com mais eficiência sem tirar das pessoas o controle da conversa.

Geração de resumos de conteúdo em massa

Agora, o Content Summarization pode ser executado em vários posts ou páginas por meio da respectiva tabela de listagem. Depois de selecionar o conteúdo, os usuários podem escolher a nova ação em massa Generate Summary. O WordPress processa os itens selecionados e cria ou atualiza os resumos gerados por IA sem exigir que cada item seja aberto individualmente no editor.

Isso torna o Content Summarization mais prático para sites existentes que desejam adicionar resumos a uma biblioteca de conteúdo.

Nova Habilidade core/read-content

O AI 1.2.0 adiciona a nova Habilidade core/read-contentque oferece acesso estruturado e somente leitura ao conteúdo do WordPress por meio da API de Habilidades. A resposta padrão permanece intencionalmente enxuta, enquanto as permissões e as verificações de acesso de cada post determinam quais conteúdos e campos estarão disponíveis.

A Habilidade oferece:

• Recuperação de um único post pelo ID.
• Recuperação de um único post pelo tipo de post e slug.
• Consulta de coleções de posts.
• Filtragem por status, autor, ordem ascendente dos posts ou IDs de posts incluídos.
• Paginação e seleção de campos.
• Acesso mediante ativação explícita a campos mais pesados ou ao conteúdo bruto.

Isso oferece uma base útil para assistentes, agentes, ferramentas de automação e outras integrações que precisam localizar e ler o conteúdo do WordPress com segurança.

Nova Habilidade core/read-users

Esta versão também apresenta a Habilidade core/read-users. Ela pode recuperar um único usuário por ID, endereço de e-mail, login ou nicename, além de retornar uma coleção filtrada e paginada de usuários.

As consultas de coleções podem ser filtradas por função, conteúdo publicado, IDs de usuários incluídos e outros campos compatíveis. Por padrão, é retornado um conjunto enxuto de campos. Identificadores e campos sensíveis precisam ser solicitados explicitamente e continuam protegidos pelas permissões do WordPress.

Juntas, as Habilidades core/read-content, core/read-users e a Habilidade core/read-settings, apresentada anteriormente, amplia a implementação de referência do plugin para o acesso aos dados do WordPress com base em permissões.

Configurações mais simples com controles avançados opcionais

O AI 1.2.0 reorganiza as opções de configuração para tornar mais simples a experiência com as configurações principais. Uma nova opção, Advanced settings, está disponível no menu Developer Tools. Ela fica desativada por padrão, deixando cada Recurso ou Experimento com apenas seu controle principal de ativação e desativação.

Quando Advanced settings está ativada, opções adicionais ficam disponíveis onde houver compatibilidade, incluindo a seleção do provedor, seleção do modelo, estratégias de taxonomia e limites de sugestões.

Isso mantém as configurações comuns mais objetivas, preservando os controles detalhados para desenvolvedores e administradores avançados de sites.

Orientações mais claras para Connector Approvals

Quando o Connector Approvals está ativado, mas nenhum conector de IA foi aprovado, o plugin agora exibe um aviso embutido explicando que o plugin AI precisa ser aprovado antes de usar um conector de provedor de IA.

Anteriormente, os administradores poderiam não perceber a ausência dessa aprovação até tentarem usar um recurso de IA e encontrarem um erro. O novo aviso deixa clara a ação necessária durante a configuração do plugin.

Melhorias no Type-ahead Text

O experimento Type-ahead Text recebeu vários aprimoramentos nesta versão:

• Os recursos do Type Ahead não são mais carregados na interface do site.
• Descartar uma sugestão com a tecla Escape não aciona imediatamente outra solicitação.
• O posicionamento do texto fantasma foi aprimorado.
• Sugestões desatualizadas não se sobrepõem mais aos espaços reservados em blocos vazios.

Aprimoramentos de acessibilidade e fluxo de trabalho

Outras melhorias na interface e nos fluxos de trabalho incluem:

• O foco do teclado é restaurado de maneira mais confiável depois que as configurações de IA são salvas.
• As imagens dos cartões de recursos na página inicial do AI agora incluem textos alternativos descritivos para usuários de leitores de tela.
• A detecção do Content Summary agora funciona quando o bloco está aninhado dentro de outro bloco.
• As configurações iniciais são registradas antes de core/read-settings criar sua cópia das configurações.
• Valores explícitos de show_in_abilities são respeitados, mantendo a compatibilidade com o suporte futuro do núcleo do WordPress.

Essas mudanças mantêm o foco do projeto em tornar os fluxos de trabalho com IA previsíveis, acessíveis e compatíveis com as APIs do WordPress em constante evolução.

Atualizações para desenvolvedores e extensibilidade

O AI 1.2.0 apresenta o filtro wp_ai_client_default_request_timeoutque permite aos desenvolvedores personalizar o tempo limite de solicitações de longa duração feitas pelo cliente de IA.

Nesta versão, o filtro é aplicado apenas à geração de imagens, mas fica disponível para aplicação a outros recursos no futuro. O valor padrão continua sendo de 90 segundos, mas sites que usam provedores ou infraestruturas mais lentos agora podem aumentar ou ajustar esse valor.

A versão também inclui melhorias nos testes de ponta a ponta, versões corrigidas das dependências do npm, pacotes atualizados da interface do WordPress, capturas de tela novas e atualizadas e documentação sobre como colaboradores podem se tornar mantenedores do plugin.

O que vem a seguir na versão 1.3.0?

O trabalho já começou em outros recursos, experimentos e melhorias de infraestrutura planejados para a versão 1.3.0 e versões futuras, incluindo:

• Experimento atualizado: integração do Refine das Notes com colaboração em tempo real.
• Novas Habilidades: core/read-nav-menus e core/manage-settings.
• Novo experimento: Content Translations.
• Novo experimento: integração com o Editor de mídia experimental do Gutenberg, incluindo sugestões de corte sensíveis à área em foco.
• Nova ferramenta para desenvolvedores: controles de acesso por função e usuário.
• Nova ferramenta para desenvolvedores: importação e exportação de configurações.
• Novo experimento: Promoted AI Provider Connectors.
• Novo experimento: rastreamento da procedência do conteúdo para texto e imagens por meio do C2PA, com detecção de manifestos C2PA durante o envio.

Esses conceitos ainda estão em fase experimental, mas ajudam a testar como a IA pode oferecer suporte a fluxos de trabalho reais no WordPress.

Agradecimentos aos colaboradores!

Agradecemos a todas as pessoas que contribuíram para esta versão, incluindo:

@dkotter, @jeffpaul, @ankitkumarshah, @prasadkarmalkar, @gautam23, @justinjiajia, @jorgefilipecosta, @gziolo, @peterwilsoncc, @ovidiu-galatan, @justlevine, @jasonbahl, @prototipo88, @ishitaj34, @psykro, @intenzi, @yogeshbhutkar, @monzuralam, @sohampate1, @htperkins, @vedantere, @pablodiloreto e outras pessoas envolvidas na revisão, nos testes e nos 34 commits em 105 arquivos entre as versões 1.1.0 e 1.2.0.

Sua ajuda e seus comentários tornam possíveis esses recursos e experimentos.

Agradecemos também aos tradutores que colaboraram nos idiomas tcheco, inglês (Reino Unido), dinamarquês, japonês, coreano, persa, polonês, português (Brasil), russo, espanhol (Chile), espanhol (Espanha), turco e vietnamita, garantindo a disponibilidade dos pacotes de idiomas para os usuários.

Traduzir o plugin AI é uma excelente contribuição, e a participação de mais pessoas dessa forma é muito bem-vinda e valorizada!

Participe

Como sempre, comentários, testes e contribuições da comunidade são bem-vindos. Se você tem interesse na experiência de uso do editor, nas APIs, na acessibilidade, no desempenho ou em ética e políticas de IA, há muitas formas de participar.

Tradução do post original: What’s new in AI 1.2.0 (14 JULY 2026)?

Esta versão beta destina-se apenas a testes e desenvolvimento. Não instale, execute ou teste esta versão do WordPress em sites de produção ou de missão crítica. Em vez disso, use um ambiente de teste ou local para explorar os novos recursos.

Como testar o WordPress 7.1 Beta 3

Você pode testar o WordPress 7.1 Beta 3 de qualquer uma das seguintes maneiras:

A data de lançamento final programada para o WordPress 7.1 é 19 de agosto de 2026. O cronograma de lançamento completo pode ser encontrado aqui. Sua ajuda para testar versões Beta e RC é vital para tornar esta versão o mais estável e poderosa possível. Agradecemos a todos que contribuem testando!

Saiba o que há de novo no WordPress 7.1 : Leia o anúncio do Beta 1 para detalhes e destaques.

Qual a importância dos teste?

O teste de erros é uma parte crítica do desenvolvimento de qualquer software, e é uma maneira significativa de qualquer pessoa contribuir, seja você tendo experiência ou não. Detalhes sobre o que testar no WordPress 7.1 estão disponíveis aqui.

Se você encontrar um problema, por favor, compartilhe-o na área Alfa / Beta dos fóruns de suporte. Se você está confortável em enviar um relatório de erros reproduzível, você pode fazê-lo via WordPress Trac. Você também pode verificar seu problema contra essa lista de erros conhecidos.

Curioso sobre testes de lançamentos em geral e como começar? Acompanhe as iniciativas de teste no Make Core e junte-se ao canal #core-test no Making WordPress Slack.

O que há no WordPress 7.1 Beta 3?

Para obter detalhes técnicos sobre os mais de 71 problemas abordados desde o Beta 1, consulte os seguintes links:

• Tíquetes fechados do Trac para a versão 7.1 desde 15 de julho de 2026.
• Tíquetes fechados do Gutenberg desde 15 de julho de 2026.

Nota: A versão Beta 2 foi lançada em 17 de julho de 2026, como parte da versão do WordPress 7.0.2 e inclui correções de segurança importantes.

A versão Beta 3 introduz duas melhorias nos estilos

Aplicar mudanças de estilo locais globalmente não é mais uma ação de tudo ou nada. A opção aplicar globalmente no inspetor de blocos agora abre uma etapa de revisão rápida, permitindo que você escolha quais estilos modificados se aplicar globalmente, mantendo o resto como substituições locais.

Outras correções notáveis incluem melhorias nos uploads de mídia: uploads de GIF animados longos não são mais suspensos, imagens giradas usando metadados EXIF são processadas corretamente e o upload de uma única imagem HEIC no Safari não cria mais duas entradas.

O editor também inclui correções adicionais para as notas, estilo responsivo e CSS personalizado. Para desenvolvedores, o WordPress Coding Standards foi atualizado para a versão 3.4.0.

O suporte a endereço de e-mail Unicode não será incluído no WordPress 7.1. O trabalho continuará em um plugin da comunidade, permitindo testes mais amplos de considerações de compatibilidade, segurança e manuseio de dados.

Agradecemos a @krupajnanda, @annezazu, @wildworks e @amykamala pela colaboração no post original.

Você não precisa testar tudo. Escolha um ou dois módulos abaixo, explore os recursos e conte o que funcionou bem ou o que poderia ser melhorado.

Ambiente de teste: Abra a nova interface do Playground

O que queremos avaliar

Durante o teste, observe os seguintes pontos:

• Textos claros: Os botões, rótulos, descrições e instruções são fáceis de entender?
• Interações lógicas: Os fluxos funcionam como você espera? Está claro o que cada ação fará?
• Problemas de design: Há textos sobrepostos, conteúdo cortado, controles ausentes ou layouts quebrados?
• Sugestões úteis: Qual recurso ou pequena mudança tornaria a experiência mais fluida?

Testes em computadores e dispositivos móveis

Se possível, teste a interface tanto em um navegador para computador quanto em um navegador para dispositivos móveis.

Em dispositivos móveis:

• Deslize horizontalmente a barra de ferramentas inferior para encontrar ferramentas que não estejam visíveis, como Files, Logs ou Export.
• Os painéis das ferramentas são abertos no site. Use o botão X para fechar um painel.
• No painel Files, toque em Browse files para abrir a árvore de arquivos.
• Use o controle de envio de arquivos em vez de arrastar e soltar.

Não envie arquivos privados, senhas, chaves de API ou outras informações sensíveis durante o teste.

Escolha sua aventura de teste

Módulo 1: Criar e gerenciar Playgrounds

Um bom ponto de partida para um teste de cinco minutos.

1. Abra o ambiente de teste e aguarde o Playground inicial terminar de carregar. Um Playground é criado automaticamente quando a página é aberta.
2. Selecione New na barra de ferramentas inferior.
3. Na Blueprint gallery, selecione Vanilla WordPress. Ao selecionar o cartão, um novo Playground será criado imediatamente.
4. Abra Site details. Altere WordPress version ou PHP version e selecione Create a fresh Playground. Confirme se o novo Playground usa as versões selecionadas.
5. Em Site details, selecione Rename Playground e dê a ele um nome fácil de reconhecer. Você também pode renomeá-lo em Playgrounds → Actions (⋮) → Rename.
6. Abra Playgrounds, acesse o menu Actions (⋮) do Playground atual e selecione Save in browser storage. Confirme se o status muda de um salvamento automático para um Playground salvo permanentemente.
7. Atualize o navegador. Abra Playgrounds, encontre o site em Saved e abra-o novamente. Os Playgrounds salvos e os itens em Recent autosaves são exibidos separadamente.
8. Abra o menu Actions (⋮) do Playground salvo, selecione Delete e confirme a exclusão.

Observação: Os salvamentos automáticos são cópias periódicas e podem não incluir todas as alterações recentes. Use Save in browser storage quando quiser manter um Playground.

O que observar:

• Os Playgrounds inicial e novo foram carregados corretamente?
• Ficou claro que alterar uma versão cria um novo Playground?
• Foi fácil encontrar as ações de renomear, salvar, restaurar e excluir?
• Depois de atualizar a página, ficou clara a diferença entre Recent autosaves e Saved?
• Foi possível acessar todas as ações com facilidade em um dispositivo móvel?

Módulo 2: A experiência com Blueprints

Teste as diferentes formas de iniciar e inspecionar uma configuração personalizada.

1. Selecione New → Blueprint gallery.
2. Pesquise ou explore a galeria e leia as descrições exibidas nos cartões.
3. Selecione um cartão de Blueprint. O cartão inicia imediatamente um novo Playground, portanto, não há uma tela separada de detalhes.
4. Depois do carregamento, abra Blueprint na barra de ferramentas inferior para inspecionar o arquivo blueprint.json.
5. Selecione New → Blueprint URL, insira o URL de um Blueprint acessível publicamente e selecione Create Playground.
6. Selecione New → Write a Blueprint, edite o JSON de exemplo e selecione Create Playground.
7. Para manter o site resultante, use Playgrounds → Actions (⋮) → Save in browser storage. Para baixar o próprio Blueprint, abra Blueprint e selecione Export.

Cuidado: Em um Playground editável com salvamento automático, a opção Run Blueprint and reset site recria o Playground e substitui seus arquivos. Em um Playground salvo permanentemente, o editor de Blueprint fica disponível somente para leitura.

O que observar:

• Foi fácil explorar e pesquisar na galeria?
• Ficou claro que selecionar um cartão criaria imediatamente um Playground?
• Os fluxos de URL de Blueprint e JSON bruto exibiram mensagens úteis de validação e erro?
• Ficou clara a diferença entre salvar um Playground e exportar um Blueprint?
• A execução do Blueprint selecionado foi concluída sem falhas?

Módulo 3: Arquivos, banco de dados e registros

Teste as ferramentas para desenvolvedores.

1. Inicie um Playground e abra Files.
2. Em um dispositivo móvel, selecione Browse files para exibir a árvore de arquivos.
3. Teste Create new folder e Create new file. Digite um nome, confirme e verifique se o item continua visível depois que você selecionar outra coisa.
4. Abra um arquivo que não ofereça riscos, como readme.html, ou use o arquivo de teste que acabou de criar. Adicione um comentário curto, selecione Save file, abra o arquivo novamente e confirme se a alteração foi mantida. Evite editar wp-config.php neste teste.
5. Use Upload files para enviar um arquivo de teste pequeno e sem informações sensíveis. Em um computador, você também pode tentar arrastar um arquivo de teste para o gerenciador de arquivos e informar se isso funcionou.
6. Abra Database. Selecione Open Adminer ou Open phpMyAdmin e explore uma tabela sem alterar seus dados. Se o visualizador não puder ser instalado ou exibir um erro ao baixar ou buscar dados, inclua a mensagem de erro exata em seu comentário.
7. Abra Logs. Confirme se você vê o estado “Nothing logged yet” ou mensagens relevantes do PHP, do WordPress e do Playground. Se você se sentir à vontade, gere um aviso inofensivo em um arquivo de teste e verifique se ele aparece.

O que observar:

• Os arquivos e pastas recém-criados permaneceram disponíveis depois que o foco foi movido para outro lugar?
• Foi confortável usar o editor com o teclado de um dispositivo móvel?
• Os resultados das ações de salvar e enviar arquivos foram comunicados com clareza?

Módulo 4: Importação, exportação e compartilhamento

Teste como os dados do Playground são transferidos entre ambientes.

1. Em um Playground ativo, abra Export.
2. Em Download a copy, selecione Download as .zip. O arquivo ZIP deve conter os arquivos, o banco de dados e as edições atuais.
3. Selecione New → Import zip → Choose a .zip file… e importe o arquivo ZIP que acabou de baixar.
4. Depois que o Playground importado for carregado, verifique se suas páginas, configurações, arquivos e conteúdo foram restaurados.
5. Abra Export e selecione Copy link. Cole o resultado em um local seguro e confirme se o URL pode ser usado. Importante: Esse link recria apenas a configuração original do Blueprint. Ele não inclui alterações posteriores feitas nos arquivos ou no conteúdo.
6. Opcionalmente, teste Export to GitHub usando um repositório descartável que possa ser modificado com segurança. Conecte sua conta do GitHub e tente exportar um plugin, tema ou o diretório wp-content. A conexão com o GitHub não é mantida depois que o navegador é atualizado.

O que observar:

• A criação do arquivo ZIP foi concluída em um tempo razoável?
• A importação do ZIP restaurou corretamente o site atual?
• A interface explicou com clareza o que o link copiado inclui e o que não inclui?
• Os erros de permissão da área de transferência foram fáceis de entender?
• O escopo da exportação para o GitHub estava claro antes do envio dos arquivos?
• As mensagens de sucesso, andamento e erro foram úteis?

Como compartilhar seus comentários

Encontrou um erro ou tem uma ideia para melhorar o fluxo? Inclua:

• Seu dispositivo, sistema operacional e navegador.
• O módulo e a etapa que você testou.
• As etapas necessárias para reproduzir o problema.
• O que você esperava que acontecesse e o que realmente aconteceu.
• Suas impressões sobre a clareza dos textos, o funcionamento e o design visual.
• Capturas de tela ou gravações curtas da tela, quando possível.

Remova informações privadas, tokens de acesso, segredos de repositórios e arquivos pessoais das capturas ou gravações antes de publicá-las.

Compartilhe comentários, erros e ideias na issue oficial do GitHub:

New Dock UI review — Issue #4092

Você precisará acessar sua conta do GitHub para publicar um comentário.

Agradecemos sua ajuda para tornar o WordPress Playground melhor para todas as pessoas. Bons testes!

Tradução do artigo Help Us Test the New WordPress Playground UI!, publicado originalmente por Fellyph Cintra em 17 de julho de 2026.

A versão de manutenção de segurança 7.0.2 aborda um problema crítico e de alta gravidade de segurança.

Como este é um lançamento de segurança, é recomendável que você atualize seus sites imediatamente. Devido à gravidade, a equipe do WordPress.org habilitou atualizações forçadas por meio do sistema de atualização automática para sites que executam versões afetadas.

Para atualizar manualmente, você pode visitar seu Painel do WordPress, clicar em “Atualizações” e, em seguida, clicar em “Atualizar agora”, ou você pode baixar o WordPress 7.0.2 do WordPress.org. Em sites que suportam atualizações automáticas em segundo plano, o processo de atualização começará automaticamente.

Atualizações de segurança incluídas nesta versão

A equipe de segurança gostaria de agradecer às seguintes pessoas por relatar vulnerabilidades de forma responsável e permitir que elas sejam corrigidas nesta versão:

• Um problema que facilitava a injeção de SQL relatado pela equipe composta por TF1T, dtro e haongo.
• Um problema de confusão de rota da API REST e problema de injeção de SQL que leva a execução remota de código relatado por Adam Kues no Assetnote / Searchlight Cyber

Para mais informações sobre esta versão, visite o site do HelpHub.

Backports

• O WordPress 6.9 é afetado por ambas as vulnerabilidades. A versão 6.9.5 foi lançada contendo correções para ambos.
• O WordPress 6.8 é afetado apenas pela primeira vulnerabilidade. A versão 6.8.6 foi lançada contendo uma correção.
• A versão beta do WordPress 7.1 é afetada por ambas as vulnerabilidades. A versão 7.1 beta 2 foi lançada contendo correções para ambos.
• Versões do WordPress antes do 6.8 não são afetadas.

Agradecemos aos colaboradores do WordPress

Este lançamento foi liderado por John Blackbourn e Barry Abrahamson. Além dos pesquisadores de segurança mencionados acima, o WordPress 7.0.2 não teria sido possível sem as contribuições significativas das seguintes pessoas: Aaron Jorbin, Alex Concha, annezazu, Barry, David Baumwald, Dominik Schilling, Ehtisham Siddiqui, Joe Dolson, Joe Hoyle, John Blackbourn, Jonathan Desrosiers, Marius L. J., Matt Mullenweg, Mohammad Jangda, Peter Wilson, Sergey Biryukov, vortfu, Weston Ruter, além de representantes da Altis, Automattic, Bluehost, Cloudflare, GoDaddy, Hostinger e WP Engine.