Atualização, . Corrigido com o field guide e os anúncios de lançamento: a data de lançamento é 20 de maio de 2026, os contribuidores são 875+, o núcleo não tem nenhum “AI Services Registry” e a Abilities API do lado do servidor chegou na 6.9. O PHP 7.2 e 7.3 foram removidos e o mínimo é o 7.4. A colaboração em tempo real ficou fora da 7.0. O WordPress 7.1 já saiu (19 de agosto de 2026) e a versão mais recente é a 7.1.4.
Atualização, 23 de maio de 2026: O WordPress 7.0 com o nome de código Armstrong foi lançado. O lançamento traz infraestrutura fundamental de IA (AI Client, Connectors e Abilities no cliente, sobre a Abilities API da 6.9), um painel modernizado, Command Palette na barra de administração, CSS personalizado ao nível do bloco e o bloco Icons. A colaboração em tempo real foi retirada nos testes RC e não integra a 7.0. Este guia é o resumo pós-lançamento; as secções antigas do roteiro abaixo são mantidas como contexto histórico, não como descrição do que está ativo numa instalação 7.0 hoje.
O WordPress 7.0 "Armstrong" foi lançado em maio de 2026 após um ciclo release candidate mais longo do que o habitual. O lançamento foi construído por mais de 875 contribuidores. A mudança principal é a infraestrutura de IA no núcleo: o WordPress AI Client, um ecrã de Connectors para fornecedores de modelos alojados e um pacote de Abilities no cliente que complementa a Abilities API da 6.9. O painel admin modernizado, a Command Palette na barra de administração, CSS personalizado ao nível do bloco e o bloco Icons também foram entregues. A colaboração em tempo real foi retirada deste lançamento durante os testes RC e não faz parte da atualização.
Para uma polémica mais afiada sobre o que a superfície de IA do 7.0 significa concretamente para os autores de plugins, leia o nosso texto sobre porque um servidor MCP no seu plugin WordPress e o movimento de IA que sobrevive. Para a implicação de segurança pos-lançamento, leia a nossa análise do relatório GuardingWP State of WordPress Security 2026, que coloca a nova superfície de chaves de IA em contexto com a baseline de 53 por cento de CVEs não corrigidos. Quando WordPress.com Agent e MCP write chega, e quando o self-hosted com abilities continua a ser necessário, está nessa comparação.
Siga make.wordpress.org/core e o feed oficial wordpress.org/news para lançamentos subsequentes de patches.
Saiba mais sobre desenvolvimento profissional de WordPress na WPPoland.
Quando saíram o WordPress 7.0, o 7.0.1 e o 7.1
O WordPress 7.0 com o nome de código Armstrong foi lançado a 20 de maio de 2026 após um ciclo release candidate invulgarmente longo (o field guide foi publicado a 14 de maio). O nome “Armstrong” dá continuidade à tradição do WordPress de batizar as versões principais com nomes de músicos de jazz.
Em sites de clientes, espero pela primeira versão de manutenção antes de tocar em produção. O WordPress 7.0.1 saiu a 9 de julho de 2026 com 31 correções de erros, e seguiram-se versões de segurança durante o verão. O WordPress 7.1 “Mary Lou” foi lançado a 19 de agosto de 2026 e a versão mais recente é a 7.1.4 (28 de outubro de 2026, segurança). Hoje, um site que passa para o WordPress 7 deve aterrar na linha 7.1.x (ou na 7.0.x se um plugin bloquear a 7.1), nunca na 7.0.0.
O que há de novo no WordPress 7.0 Armstrong?
Esta é a lista de funcionalidades do anúncio de lançamento do wordpress.org e do field guide da 7.0, não a intenção anterior do roteiro. Tudo o que estava no roteiro antigo e não consta aqui não foi entregue na 7.0.
- Infraestrutura de IA no núcleo. Um ecrã de Connectors em Definições para ligar fornecedores de modelos alojados (Anthropic, Google e OpenAI por omissão) e o WordPress AI Client contra o qual os plugins de terceiros estão agora a construir. A Abilities API chegou na 6.9; a 7.0 acrescenta um pacote de Abilities no cliente. Esta é a mudança de plataforma que define o lançamento.
- Atalho para a Command Palette. A barra de administração ganha uma entrada para a Command Palette, que se abre com Cmd-K ou Ctrl-K.
- CSS personalizado ao nível do bloco. Acrescente CSS próprio a um único bloco, diretamente na publicação ou na página.
- Bloco Icons. Um bloco nativo para acrescentar ícones a um desenho.
- Painel modernizado. Um novo esquema de cores “Modern” no admin, transições de vista entre ecrãs, uma página própria da Font Library e revisões visuais.
- PHP 7.4 como runtime mínimo. O suporte para PHP 7.2 e 7.3 foi removido, por isso os sites nessas versões têm de atualizar o PHP antes de atualizar para a 7.0.
- Mais de 875 contribuidores, mais de 200 deles estreantes, segundo o anúncio de lançamento.
O que não foi entregue e já não é esperado na linha 7.0:
- A colaboração em tempo real foi retirada deste lançamento após os testes release candidate. A equipa do núcleo avança agora para um desenho consciente do servidor: a experiência do Gutenberg guardava uma cópia da publicação num documento CRDT em cada navegador e fundia aí as edições. A descrição anterior do roteiro sobre colaboração não está na 7.0.
Como funciona a Abilities API no WordPress 7
A Abilities API descreve o que um site pode fazer, com nome, esquemas de entrada e saída e um callback de permissões. Não está presa a um fornecedor de modelos: o WordPress AI Client e o ecrã de Connectors tratam do lado do fornecedor. A categoria tem de ser registada primeiro com wp_register_ability_category() em wp_abilities_api_categories_init (nota de desenvolvimento da 6.9). Um exemplo mínimo:
// Registar uma ability (6.9 e posteriores)
add_action( 'wp_abilities_api_init', function () {
wp_register_ability( 'my-plugin/get-post-count', array(
'label' => __( 'Get post count', 'my-plugin' ),
'description' => __( 'Returns the number of published posts.', 'my-plugin' ),
'category' => 'content-management',
'execute_callback' => fn() => (int) wp_count_posts()->publish,
'permission_callback' => fn() => current_user_can( 'read' ),
) );
} );
// Executá-la
$count = wp_get_ability( 'my-plugin/get-post-count' )->execute();Nenhuma das duas peças trata de limites de utilização nem de faturação. O núcleo também não gera por si só texto alternativo, resumos ou traduções: essas funcionalidades vêm de plugins construídos sobre o AI Client, e nada corre até configurar uma chave de fornecedor.
Como proteger as chaves API de IA no WordPress 7
O fundador da Patchstack, Oliver Sild, publicou publicamente no X em torno do lançamento:
“vai haver uma corrida desenfreada dos hackers para roubar chaves de API.”
Oliver Sild, Patchstack, via X, tradução própria
O risco e concreto. Uma credencial wp-admin comprometida numa instalação 7.0 já não permite apenas a um atacante alterar conteúdo; permite-lhe também drenar uma fatura mensal de tokens de quatro ou cinco digitos contra o seu fornecedor de IA antes que a fatura o apanhe. Justin Nealey sinalizou em separado que o WP AI Client não tem throttle interno e vários plugins a partilhar uma chave podem esgotar o limite de tokens em menos de um minuto.
A superfície de controlo a aplicar e simples e e a mesma superfície de controlo que uma equipa financeira aplicaria a qualquer credencial faturável recem-emitida:
- Definir o escopo das chaves API por connector, não por site. Uma chave por fornecedor por connector. Rodar numa cadência publicada.
- Limitar o consumo no gateway, não no plugin. A Anthropic permite definir limites de taxa e de gasto mais baixos por workspace, a OpenAI aplica limites de taxa por organização e projeto, e o Vercel AI Gateway permite definir orçamentos de gasto por chave de API (não aplica rate limits próprios nos planos pagos). Dê ao site o seu próprio workspace, projeto ou chave e defina o limite suficientemente baixo para que um consumo anómalo seja visível num ciclo de faturação.
- Alertar sobre gastos anómalos de tokens dentro do ciclo, não no fim do mês. A maioria dos fornecedores expõe uma API diária de faturação; ligue-a à sua monitorização.
- Registar em audit log a utilização dos connectors do lado do WordPress. Registe cada execução de uma ability e cada chamada a um connector num fluxo separado do audit log normal do wp-admin.
Em Portugal, o artigo 42.º do Decreto-Lei n.º 125/2025 (regime jurídico da cibersegurança) obriga as entidades essenciais, importantes e públicas relevantes a enviar ao CNCS a notificação inicial de um incidente significativo até 24 horas após concluírem que existe. Se estiver nesse âmbito, avalie se o abuso de chaves de IA armazenadas em wp-admin é um incidente significativo e prepare a cadeia de evidência para essa notificação. Estes controlos mapeiam diretamente para as obrigações de cadeia de fornecimento já exigidas pelo artigo 21 parágrafo 2 alinea d da NIS2 para entidades no âmbito. Trate a nova superfície de IA como uma nova classe de acordo de terceiros TIC, registando-a em conformidade.
Em que fase do Gutenberg está o WordPress 7.0?
O WordPress 7.0 fica a meio da Fase 3 do plano de quatro fases do projeto Gutenberg:
| Fase | Foco | Estado |
|---|---|---|
| Fase 1 | Editor de blocos (Gutenberg) | Concluida |
| Fase 2 | Full Site Editing, padrões, navegação | Concluida |
| Fase 3 | Colaboração, fluxos de trabalho, integração de IA | Em curso (a 7.0 entregou a base de IA, não a colaboração em tempo real) |
| Fase 4 | Multilinguismo | Planeada |
A Fase 4 trara capacidades multilingües nativas, o que significa que o WordPress finalmente tratara a tradução de conteúdos ao nível do núcleo em vez de depender de plugins como o WPML ou o Polylang. Para agências que hoje gerem sites multilingües, esta e a funcionalidade a vigiar no roteiro pos-7.0.
Como usar IA no WordPress 7 hoje
A versão honesta de “funcionalidades de IA no WordPress 7.0” começa pelo que já funciona em 6.x, porque e o que sites reais estão a correr.
Disponível hoje, em WordPress de produção:
- Yoast e Rank Math ambos incluem assistentes de escrita assistidos por IA (títulos, meta descrições, sugestões de ligações internas) construídos sobre APIs de modelos de terceiros.
- Jetpack AI Assistant oferece geração no editor, sumarização e tradução. A qualidade varia por idioma e prompt.
- Plugins independentes de geração de conteúdo existem numa ampla gama de qualidade; úteis para rascunhos, perigosos quando ligados diretamente a publicação sem revisão humana.
- A Automattic e equipas de contribuidores executam experimentos da Fase 3, incluindo edição colaborativa e chamadas de IA no lado do editor, no plugin Gutenberg antes de qualquer merge no core.
Uma arquitetura pragmatica para adicionar IA a um site WordPress hoje, que provavelmente sobrevivera ao que a 7.0 entregar:
- Exponha um pequeno endpoint REST API por fornecedor (OpenAI, Anthropic, Google, ou um modelo auto-hospedado). Mantenha o código específico do fornecedor atrás de uma interface para que trocar de modelo seja uma alteração de configuração, não uma reescrita.
- Execute tudo o que demore mais que alguns segundos através do Action Scheduler, não um pedido sincrono. Este e o mesmo padrão que o WooCommerce usa; escala.
- Armazene chaves de API como constantes em
wp-config.phpou via um cofre de segredos gerido carregado no boot. Nunca coloque chaves vivas em opções de plugins ou ficheiros.envcommitados num repositório. - Coloque em cache as respostas com chave num hash do prompt mais a versão do modelo. Chamadas de IA são caras e frequentemente repetidas.
Modos de falha contra os quais vale a pena projetar desde o primeiro día:
- Vazamento de chaves de API através de auto-atualizações de plugins ou backups que incluem dumps de
wp-content. - Falhas de rate-limit durante picos de tráfego, que silenciosamente degradam a experiência do editor se não houver fallback.
- Factos, citações ou especificações de produto alucinados publicados sem um passo de revisão humana. O custo de uma página ma na pesquisa e superior ao custo de qualquer fluxo de trabalho de revisão.
Agora que a 7.0 inclui uma camada de abilities e connectors no core, aplicam-se as mesmas fronteiras: a superfície da API muda, os modos de falha não. Para etica e enquadramento editorial, veja o guia de etica para conteúdo de IA para editores.
O que verificar antes de atualizar para o WordPress 7
Agora que a 7.0 e a 7.1 saíram, os comandos específicos da versão e a rotina de atualização da base de dados são conhecidos, e as secções acima refletem o que efetivamente chegou. A parte disciplinada não são os comandos, é a preparação que torna qualquer atualização maior de baixo risco, e essa mesma preparação aplica-se agora à passagem para a linha 7.0 e à atualização para a 7.1. O trabalho é ingrato e compensa em cada release, não apenas neste.
Audite as partes da stack mais propensas a quebrar numa atualização maior:
- Temas que ainda usam template tags em
functions.phpem vez de block themes. Converta para block themes ou planeie o trabalho. - Blocos Gutenberg personalizados construídos contra versões iniciais de
@wordpress/scripts. Fixe e teste contra a última versão estável. - Page builders com a sua própria camada de renderização. Estas são a causa mais comum de dívida “não podemos atualizar”.
- Endpoints REST personalizados sem versionamento. Adicione namespacing
/v1/agora para que um aumento futuro não seja disruptivo.
Configure a infraestrutura aborrecida que lhe permite atualizar rapidamente:
- Um ambiente de staging que espelhe a versão de PHP, conjunto de plugins e volume de conteúdo de produção. A paridade da base de dados importa mais do que as pessoas esperam.
- Backups automatizados com um caminho de restauro testado. Um backup não testado e teatro.
- Atualizações de plugins e temas a correr numa cadência regular, não adiadas até ao próximo grande release. Sites presos no 6.0 estão presos porque ninguém atualizou do 6.1 ao 6.8.
- Uma pequena lista de autores de plugins em quem confia, com contactos de email. Vai querer saber dentro de uma semana quais dos seus plugins estão testados contra a 7.0.
O caminho de atualização é o mesmo que tem funcionado para todos os releases maiores do WordPress, e aplica-se tanto à linha 7.0 como à 7.1: corra em staging primeiro, observe o log de erros, espere duas a quatro semanas após a disponibilidade geral antes de tocar em produção para sites de clientes, e leia o post oficial de field guide no Make WordPress antes de assumir que qualquer guia de terceiros (este incluído) reflete o que foi efetivamente entregue.
Migração para o WordPress 7: quando compensa contratar uma agência
A maioria dos sites não precisa de uma agência para migrar para o WordPress 7. Com um tema mantido e uma dúzia de plugins conhecidos, o staging e a checklist acima chegam, e pagar a alguém para clicar em “Atualizar” é orçamento desperdiçado.
Os casos em que a ajuda externa compensa mesmo são mais estreitos: uma loja WooCommerce onde uma hora de checkout em baixo custa dinheiro a sério, sobretudo com Multibanco ou MB Way no fluxo de pagamento, um site ainda em PHP 7.2 ou 7.3 que precisa de sequenciar a atualização do PHP com a do WordPress, plugins à medida cujos autores desapareceram, ou um page builder com camada de renderização própria que prendeu o site a uma versão antiga do core. Aí o trabalho não é a atualização em si, mas o desenlear antes dela, e isso é desenvolvimento WordPress normal, não um produto especial de migração. Se preferir entregar o ciclo completo (staging, atualização, plano de rollback e a monitorização depois), é exatamente isso que um contrato contínuo de manutenção WordPress cobre; o preço é individual e depende do estado da stack. Para um pré-voo estruturado de redirecionamentos, PHP e risco de plugins antes da janela de atualização, comece pela avaliação de migração WordPress.
Onde acompanhar as alterações do WordPress 7.0?
Com a 7.0 entregue, o trabalho útil e operacional: atualização em staging, verificações de compatibilidade de plugins, testes de fluxos WooCommerce e LMS, e um plano de rollback antes de produção.
Siga o blog Make WordPress core, as notas de release do Gutenberg e o milestone do trac para alterações de última hora no field guide. Para um projeto existente em 6.x, mantenha block themes, theme.json e a REST API como a baseline compatível com o futuro.
Se quiser ajuda a auditar uma stack quanto a prontidão de atualização, a nossa equipa de desenvolvimento WordPress faz esse trabalho para sites de produção em cada ciclo de release.
A prontidão para upgrade também implica que as novas superfícies de IA continuem citáveis: encaixamos isso em controlos de GEO e LLMO quando os conectores 7.0 começam a escrever em páginas públicas.
