Atualizacao, 23 de maio de 2026: O WordPress 7.0 com o nome de código Armstrong foi lançado. O lançamento encerra a Fase 3 do roteiro Gutenberg com infraestrutura fundamental de IA (Abilities API + AI Services Registry + AI Client), um painel modernizado, Command Palette em todo o lado, CSS personalizado ao nivel do bloco e o bloco Icons. A colaboracao em tempo real foi retirada nos testes RC e nao integra a 7.0. Este guia e o resumo pos-lançamento; as secções antigas do roteiro abaixo sao mantidas como contexto historico, nao como descricao do que esta 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 construido por mais de 900 contribuidores. A mudança principal e a infraestrutura de IA no núcleo: a superficie Abilities API para operacoes seguras de admin, o AI Services Registry para integracao de modelos alojados e o WordPress AI Client em torno do qual os plugins de terceiros se estão agora a padronizar. O painel admin modernizado, Command Palette disponivel em todo o lado no wp-admin, CSS personalizado ao nivel do bloco e o bloco Icons tambem foram entregues. A colaboracao em tempo real foi retirada deste lançamento durante os testes RC e nao faz parte da atualização.
Para uma polemica mais afiada sobre o que a superficie 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 implicacao de segurança pos-lançamento, leia a nossa analise do relatorio GuardingWP State of WordPress Security 2026, que coloca a nova superficie de chaves de IA em contexto com a baseline de 53 por cento de CVEs nao corrigidos.
Siga make.wordpress.org/core e o feed oficial wordpress.org/news para lancamentos subsequentes de patches.
Saiba mais sobre desenvolvimento profissional de WordPress na WPPoland.
Data de lançamento e nome de código do WordPress 7.0
O WordPress 7.0 com o nome de código Armstrong foi lançado em maio de 2026 após um ciclo release candidate invulgarmente longo (o RC4 saiu a 14 de maio de 2026 e o lançamento final seguiu pouco depois). O nome “Armstrong” da continuidade a tradicao do WordPress de batizar as principais versoes com nomes de musicos de jazz.
Se esta a planear uma atualização em produção, a janela mais segura continua a ser de duas a quatro semanas após o lançamento final, quando o primeiro ciclo de patches apanha os problemas de compatibilidade reportados por early adopters.
O que foi efetivamente entregue na 7.0 Armstrong
Esta e a lista confirmada de funcionalidades a partir do anuncio de lançamento do wordpress.org, nao a intencao anterior do roteiro. Tudo o que estava no roteiro antigo e nao consta aqui nao foi entregue na 7.0.
- Infraestrutura de IA no núcleo. A Abilities API para operacoes seguras de admin atraves de intents estruturados, o AI Services Registry para ligar fornecedores de modelos alojados (Anthropic, OpenAI, Vercel AI Gateway, auto-alojados) e o WordPress AI Client contra o qual os plugins de terceiros estão agora a construir. Esta e a mudança de plataforma que define o lançamento.
- Command Palette em todo o lado. Cmd-K / Ctrl-K abre a Command Palette em todos os ecras do wp-admin, nao apenas no editor de blocos. A superficie de atalhos para utilizadores avancados e agora de primeira classe.
- CSS personalizado ao nivel do bloco. Cada bloco pode transportar o seu proprio CSS, limitado a esse bloco. Remove uma razao de longa data para descer a um tema personalizado.
- Bloco Icons. Um bloco nativo para incorporar icones SVG a partir de uma biblioteca curada, com tokens de cor sensiveis ao tema.
- Painel modernizado. Superficies de aterragem do admin renovadas, com experiencias de IA agente visíveis por tras de uma feature flag.
- PHP 7.4 como runtime minimo. Os sites ainda em PHP mais antigo tem de atualizar o ambiente do servidor antes de atualizar para a 7.0.
- Mais de 900 contribuidores. O Product Manager da WP Charitable, David Bisset, agradeceu publicamente aos contribuidores e “aos seus conjuges, parceiros, familias, animais de estimacao, mecanismos de coping e conselheiros que os apoiaram” - que e a linha mais honesta escrita sobre uma versão maior do WordPress em anos.
O que nao foi entregue e ja nao e esperado na linha 7.0:
- A colaboracao em tempo real foi retirada deste lançamento após os testes release candidate. A descricao anterior do roteiro mais a frente neste guia e preservada como contexto historico.
Seguranca: proteger as chaves API dos fornecedores de IA desde o primeiro día
O fundador da Patchstack, Oliver Sild, publicou publicamente no X em torno do lançamento: “there will be an absolute rush by hackers to steal API keys.” O risco e concreto. Uma credencial wp-admin comprometida numa instalação 7.0 ja nao permite apenas a um atacante alterar conteúdo; permite-lhe tambem 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 nao tem throttle interno e varios plugins a partilhar uma chave podem esgotar o limite de tokens em menos de um minuto.
A superficie de controlo a aplicar e simples e e a mesma superficie de controlo que uma equipa financeira aplicaria a qualquer credencial faturavel 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.
- Aplicar rate limits no gateway, não no plugin. Se o seu fornecedor suportar rate limits por chave (Anthropic, OpenAI, Vercel AI Gateway suportam todos), defina-os suficientemente baixos 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. A Abilities API expõe IDs de operações; registe-os num fluxo separado do audit log normal do wp-admin.
Em Portugal, o CNCS exige notificacao de incidentes de segurança a entidades essenciais ao abrigo do regime juridico da segurança do ciberespaco; trate o abuso de chaves de IA armazenadas em wp-admin como um incidente reportavel e prepare a cadeia de evidencia para o relatorio inicial em 24 horas. Estes controlos mapeiam diretamente para as obrigacoes de cadeia de fornecimento ja exigidas pelo artigo 21 paragrafo 2 alinea d da NIS2 para entidades no ambito. Trate a nova superficie de IA como uma nova classe de acordo de terceiros TIC, registando-a em conformidade.
Roteiro do WordPress 7.0
O WordPress 7.0 fica no fim 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, padroes, navegacao | Concluida |
| Fase 3 | Colaboracao, fluxos de trabalho, integracao de IA | WordPress 7.0 |
| Fase 4 | Multilinguismo | Planeada (2027+) |
A Fase 4 trara capacidades multilingües nativas, o que significa que o WordPress finalmente tratara a traducao de conteúdos ao nivel do núcleo em vez de depender de plugins como o WPML ou o Polylang. Para agencias que hoje gerem sites multilingües, esta e a funcionalidade a vigiar no roteiro pos-7.0.
IA no WordPress agora que a 7.0 foi lancada
A versão honesta de “funcionalidades de IA no WordPress 7.0” comeca pelo que ja funciona em 6.x, porque e o que sites reais estão a correr.
Disponivel hoje, em WordPress de produção:
- Yoast e Rank Math ambos incluem assistentes de escrita assistidos por IA (titulos, meta descricoes, sugestoes de ligacoes internas) construidos sobre APIs de modelos de terceiros.
- Jetpack AI Assistant oferece geracao no editor, sumarizacao e traducao. A qualidade varia por idioma e prompt.
- Plugins independentes de geracao de conteúdo existem numa ampla gama de qualidade; uteis para rascunhos, perigosos quando ligados diretamente a publicacao 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 especifico do fornecedor atras de uma interface para que trocar de modelo seja uma alteração de configuracao, nao uma reescrita.
- Execute tudo o que demore mais que alguns segundos atraves do Action Scheduler, nao um pedido sincrono. Este e o mesmo padrao 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 opcoes de plugins ou ficheiros.envcommitados num repositorio. - Coloque em cache as respostas com chave num hash do prompt mais a versão do modelo. Chamadas de IA sao caras e frequentemente repetidas.
Modos de falha contra os quais vale a pena projetar desde o primeiro día:
- Vazamento de chaves de API atraves de auto-atualizações de plugins ou backups que incluem dumps de
wp-content. - Falhas de rate-limit durante picos de trafego, que silenciosamente degradam a experiencia do editor se nao houver fallback.
- Factos, citacoes ou especificacoes de produto alucinados publicados sem um passo de revisão humana. O custo de uma pagina ma na pesquisa e superior ao custo de qualquer fluxo de trabalho de revisão.
Se a 7.0 introduzir uma camada de abilities ou connectors no core, aplicam-se as mesmas fronteiras: a superficie da API muda, os modos de falha nao. Para etica e enquadramento editorial, veja o guia de etica para conteúdo de IA para editores.
Como preparar sem adivinhar a migracao
O que pode fazer agora e reduzir o custo futuro de migracao independentemente do que a 7.0 vier a ser. O trabalho e ingrato e compensa em cada release, nao 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 construidos contra versoes iniciais de
@wordpress/scripts. Fixe e teste contra a ultima versão estavel. - Page builders com a sua propria camada de renderização. Estas sao a causa mais comum de divida “nao podemos atualizar”.
- Endpoints REST personalizados sem versionamento. Adicione namespacing
/v1/agora para que um aumento futuro nao 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 nao testado e teatro.
- Atualizacoes de plugins e temas a correr numa cadencia regular, nao adiadas até ao próximo grande release. Sites presos no 6.0 estão presos porque ninguem 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 e o mesmo que tem funcionado para todos os releases maiores do WordPress: 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 incluido) reflete o que foi efetivamente entregue.
O que fazer na semana de lançamento da 7.0
Com a 7.0 entregue, o trabalho util e operacional: atualização em staging, verificacoes 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 alteracoes de ultima hora no field guide. Para um projeto existente em 6.x, mantenha block themes, theme.json e a REST API como a baseline compativel com o futuro.
Se quiser ajuda a auditar uma stack quanto a prontidao de atualização, a nossa equipa de desenvolvimento WordPress faz esse trabalho para sites de produção em cada ciclo de release.
