WordPress 7.0: o que se sabe, o que e especulacao, o que fazer agora

Uma nota inicial: no momento da escrita (abril de 2026), o WordPress 7.0 está no roteiro público mas não foi lançado. Listas de funcionalidades específicas, alterações de esquema e cronogramas de migração que circulam online, incluindo posts que se apresentam como "guia completo", são em parte previsão, em parte lista de desejos. Trate qualquer afirmação definitiva sobre o 7.0 como especulação até aterrar num release candidate publicado no blog oficial Make WordPress e marcado no core trac.

O que sabemos pelos posts públicos do Make WordPress: o trabalho da Fase 3 sobre edição colaborativa está em curso, a integração mais profunda entre o Block Editor e os fornecedores de AI está a ser discutida em reuniões do core, e o modelo de templating do Site Editor está a ser refinado. O que ainda não sabemos: que funcionalidades de AI (se algumas) chegarão ao core versus continuarão como plugins, o mínimo final de PHP, ou a data exata de lançamento.

Se planeia trabalho que se sobrepõe ao ciclo do 7.0, o movimento honesto é seguir make.wordpress.org/core e os tickets do core trac diretamente, em vez de depender de previsões de terceiros. A comunidade portuguesa de WordPress, incluindo os organizadores do WordCamp Portugal, segue os mesmos canais. Este post é uma dessas previsões de terceiros; leia-o em conformidade.

Saiba mais sobre desenvolvimento profissional de WordPress na WPPoland.

#O que é realmente conhecido sobre o 7.0 agora

Removendo o enquadramento de marketing, o panorama é mais estreito do que sugerem a maioria dos posts “guia completo”.

Confirmado em discussão pública do Make WordPress:

• A Fase 3 do roteiro Gutenberg é o tema de trabalho, com colaboração e fluxo de trabalho editorial como as duas áreas que viram mais propostas públicas e PRs.
• A integração de AI está a ser prototipada no plugin Gutenberg e discutida em reuniões do core, mas a fronteira entre “entra no core” e “fica como plugin” não está resolvida.
• O Site Editor e o sistema de patterns continuam a ser iterados, com refinamentos da edição de templates e bloqueio de blocos a aterrar primeiro nos releases pontuais 6.x.

Não confirmado, apesar de afirmações frequentes:

• Uma data especifica de lançamento para o 7.0. Os calendarios de release escorregam; trate qualquer data unica como um alvo, nao um compromisso.
• Uma lista definitiva de funcionalidades de AI no core. Existem varias propostas, incluindo abilities independentes do fornecedor e uma UI de connectors, mas propostas nao sao releases.
• O aumento do minimo de PHP e as deprecations exatas. Estas decisoes sao tomadas tarde no ciclo.

Para agencias e equipas de produto que entregam em 2026, a conclusao pratica e mais simples do que qualquer lista de funcionalidades: construir em WordPress 6.x usando padroes compativeis com o futuro (block themes, theme.json, REST API, Action Scheduler para trabalho em segundo plano) para que, qualquer que seja o que o 7.0 acabe por entregar, a migração seja incremental em vez de uma reescrita.

#AI no WordPress hoje, e para onde o 7.0 pode ir

A versão honesta de “funcionalidades de AI no WordPress 7.0” comeca pelo que ja funciona em 6.x, porque e o que sites reais estao a correr.

Disponivel hoje, em WordPress de producao:

• Yoast e Rank Math (com versoes em portugues) ambos incluem assistentes de escrita assistidos por AI (titulos, meta descricoes, sugestoes de ligacoes internas) construidos sobre APIs de modelos de terceiros.
• Jetpack AI Assistant oferece geracao no editor, sumarizacao e tradução. A qualidade varia por idioma e prompt; a qualidade em portugues europeu e razoavel para rascunhos mas exige revisao editorial.
• Plugins independentes de geracao de conteudo existem numa ampla gama de qualidade; uteis para rascunhos, perigosos quando ligados diretamente a publicacao sem revisao humana.
• A Automattic e equipas de contribuidores executam experimentos da Fase 3, incluindo edicao colaborativa e chamadas de AI no lado do editor, no plugin Gutenberg antes de qualquer merge no core.

Uma arquitetura pragmatica para adicionar AI a um site WordPress hoje, que provavelmente sobrevivera ao que o 7.0 entregar:

• Exponha um pequeno endpoint REST API por fornecedor (OpenAI, Anthropic, Google, ou um modelo auto-hospedado). Mantenha o codigo especifico do fornecedor atras de uma interface para que trocar de modelo seja uma alteracao 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.php ou via um cofre de segredos gerido carregado no boot. Nunca coloque chaves vivas em opcoes de plugins ou ficheiros .env commitados num repositorio.
• Coloque em cache as respostas com chave num hash do prompt mais a versão do modelo. Chamadas de AI sao caras e frequentemente repetidas.

Modos de falha contra os quais vale a pena projetar desde o primeiro dia:

• Vazamento de chaves de API atraves de auto-atualizacoes 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 revisao humana. O custo de uma pagina ma na pesquisa e superior ao custo de qualquer fluxo de trabalho de revisao.

Se o 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 conteudo de AI para editores.

#Como preparar sem adivinhar a migração

Escrever um guia “como migrar para o 7.0” passo a passo antes do 7.0 ser lançado e desonesto. Os comandos especificos da versão, a rotina de atualizacao da base de dados, as novas configuracoes de admin: nada disso e final. Quem publica passos exatos de migração hoje esta a preencher espacos em branco com pressupostos.

O que pode fazer agora e reduzir o custo futuro de migração independentemente do que o 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 atualizacao maior:

• Temas que ainda usam template tags em functions.php em 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 renderizacao. 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 quando o 7.0 for lançado:

• Um ambiente de staging que espelhe a versão de PHP, conjunto de plugins e volume de conteudo de producao. 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 ate ao proximo grande release. Sites presos no 6.0 estao presos porque ninguem atualizou do 6.1 ao 6.8.
• Uma pequena lista de autores de plugins em quem confia, com contactos de email. Quando o 7.0 for lançado, vai querer saber dentro de uma semana quais dos seus plugins estao testados contra ele.

Quando o 7.0 atingir efetivamente RC no calendario oficial de releases, o caminho de atualizacao 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 apos a disponibilidade geral antes de tocar em producao 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 ate o 7.0 ser efetivamente lançado

Ate o WordPress 7.0 atingir uma release tagged em wordpress.org, o mais util que qualquer equipa pode fazer e ignorar os posts de previsao (este incluido) e seguir as fontes primarias: o blog Make WordPress core, as notas de release do Gutenberg, e o milestone do trac para 7.0.

Para um projeto existente que entrega em 2026, construa numa release atual 6.x usando block themes, theme.json e a REST API. Trate a AI como uma camada de integração atras dos seus proprios endpoints, nao como uma funcionalidade pela qual espera que o core forneca. Quando o 7.0 chegar, a migração torna-se uma questao de quais das suas integracoes personalizadas podem ser substituidas por uma API do core, nao uma reescrita.

Se quiser ajuda a auditar uma stack quanto a prontidao de atualizacao, a nossa equipa de desenvolvimento WordPress faz esse trabalho para sites de producao em cada ciclo de release.