Atualização, 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 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 e o resumo pos-lançamento; as secções antigas do roteiro abaixo são mantidas como contexto histórico, não como descrição 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 construído por mais de 900 contribuidores. A mudança principal e a infraestrutura de IA no núcleo: a superfície Abilities API para operações seguras de admin, o AI Services Registry para integração 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 disponível em todo o lado no wp-admin, 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.
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.
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 tradição do WordPress de batizar as principais versões com nomes de musicos de jazz.
Se está 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. Esse ciclo de patches já começou: o WordPress 7.0.1 saiu a 9 de julho de 2026, uma versão de manutenção que corrige problemas do painel de administração redesenhado, um bug de sanitização de CSS e regressões do editor de blocos. Se atualizar agora para a linha 7.0, vá diretamente para a 7.0.1 em vez da 7.0.0.
O que foi efetivamente entregue na 7.0 Armstrong
Esta e a lista confirmada de funcionalidades a partir do anúncio de lançamento do wordpress.org, 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. A Abilities API para operações seguras de admin através 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 ecrãs do wp-admin, não apenas no editor de blocos. A superfície de atalhos para utilizadores avançados e agora de primeira classe.
- CSS personalizado ao nível do bloco. Cada bloco pode transportar o seu próprio CSS, limitado a esse bloco. Remove uma razão de longa data para descer a um tema personalizado.
- Bloco Icons. Um bloco nativo para incorporar ícones SVG a partir de uma biblioteca curada, com tokens de cor sensíveis ao tema.
- Painel modernizado. Superfícies de aterragem do admin renovadas, com experiências de IA agente visíveis por trás de uma feature flag.
- PHP 7.4 como runtime mínimo. 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, famílias, animais de estimação, 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 não foi entregue e já não e esperado na linha 7.0:
- A colaboração em tempo real foi retirada deste lançamento após os testes release candidate. A descrição anterior do roteiro mais a frente neste guia e preservada como contexto histórico.
Segurança: 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 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.
- 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 notificação de incidentes de segurança a entidades essenciais ao abrigo do regime jurídico da segurança do ciberespaco; trate o abuso de chaves de IA armazenadas em wp-admin como um incidente reportável e prepare a cadeia de evidência para o relatório inicial em 24 horas. 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.
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, padrões, navegação | Concluida |
| Fase 3 | Colaboração, fluxos de trabalho, integração 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 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.
IA no WordPress agora que a 7.0 foi lancada
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.
Se a 7.0 introduzir uma camada de abilities ou 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.
Como preparar sem adivinhar a migração
Agora que a 7.0 saiu e a 7.0.1 está disponível, 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 prevista para agosto. 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 agora à linha 7.0 e à 7.1 em agosto: 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.x 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.
O que fazer na semana de lançamento da 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.
