WordPress volta a planear três grandes versões em 2026 – e o 7.0 já está na mesa

O WordPress está a preparar-se para regressar a um ritmo de três grandes lançamentos (major releases) em 2026. A indicação saiu do mais recente Core Committers Check-in (reunião trimestral de committers do core com a liderança do projeto), onde se discutiu cadência, janelas de lançamento e um primeiro esboço do que pode vir a ser o WordPress 7.0.

Além do calendário, a conversa tocou em temas que vão influenciar diretamente quem desenvolve e mantém sites: a evolução do redesign do admin, a subida (ou não) da versão mínima de PHP suportada, e o espaço que a IA (inteligência artificial) deve ocupar no core – com destaque para o WordPress AI Client.

Um ponto importante de contexto: no início do ano, a Diretora Executiva Mary Hubbard tinha anunciado a intenção de lançar apenas uma major release em 2026, citando “ongoing legal matters” – uma referência ao processo da WP Engine – e também a pausa da Automattic nas contribuições para o WordPress, ajustando o nível de contributos no contexto do conflito legal. A discussão agora sugere uma mudança de direção para voltar a acelerar.

Cadência: a intenção é retomar três versões major em 2026

As notas da reunião, publicadas por Jonathan Desrosiers no Make WordPress Core, apontam que a “intenção” é voltar a um ciclo de três releases major no próximo ano. Dentro dessa cadência, o WordPress 7.0 é visto como candidato a chegar em março ou abril.

A hipótese de um lançamento em fevereiro foi descartada. O raciocínio foi pragmático: para cumprir essa data, o Beta 1 teria de cair no início de janeiro, uma altura em que muitos contribuidores ainda estão de férias, além de existirem várias funcionalidades em curso que não ficariam prontas a tempo.

Lançamentos alinhados com eventos? Ideia em aberto

Também se discutiu a possibilidade de alinhar releases major com eventos de referência – na linha do que aconteceu com o lançamento do WordPress 6.9 durante o State of the Word.

Mas a conversa sublinhou um custo real de coordenação: viagens, fusos horários e a disponibilidade do release squad (equipa de release) e dos contribuidores tornariam a operação mais complexa. Resultado: fica como possibilidade, não como plano fechado, e foi marcada para discussão futura.

O que pode entrar no WordPress 7.0: do editor ao WordPress AI Client

Uma parte significativa do encontro foi dedicada a potenciais funcionalidades para o 7.0, incluindo itens que estavam inicialmente no radar do WordPress 6.9 e que continuam a ser candidatos.

• Template activation (ativação de templates)
• Tabs block (bloco de Tabs/abas)
• Capacidades no lado do cliente para a Abilities API (Abilities API no client-side)
• Possível edição de media no lado do cliente (client-side media editing)

Ainda assim, o tema que ocupou mais tempo foi o WordPress AI Client – uma peça que, pela forma como está a ser desenhada, pode ter impacto direto na forma como plugins e temas integram serviços de IA sem reinventarem a roda.

WordPress AI Client: o que é e por que está a ser considerado para o core

O WordPress AI Client é um “client” (um SDK/cliente) pensado para oferecer uma forma nativa e agnóstica ao fornecedor (provider-agnostic) de plugins e temas falarem com serviços de IA. Em vez de cada produto integrar diretamente com uma API específica (OpenAI, Anthropic, etc.), a ideia é ter uma base comum, alinhada com as convenções do WordPress.

Segundo as notas, a versão 0.1.0 do WordPress AI Client foi lançada na semana anterior à reunião. O projeto adapta o PHP AI Client para o ecossistema WordPress e introduz vários detalhes de integração que, na prática, fazem diferença para desenvolvimento e manutenção:

• Usa a WordPress HTTP API para pedidos externos.
• Centraliza chaves e credenciais numa área própria: um ecrã de “AI Credentials”.
• Trata de seleção de modelos sem obrigar plugins a “hard-code” (fixar no código) fornecedores específicos.
• A base foi desenhada para incentivar o ecossistema a construir sobre fundamentos como a Abilities API.

As próximas versões, de acordo com o que foi discutido, devem acrescentar:

• Suporte para a Abilities API.
• REST endpoints (endpoints REST) para integração programática.
• Um Prompt Builder no lado do cliente (client-side), para ajudar a compor prompts de forma estruturada.

Because the AI client is a great way to encourage the ecosystem to build around solid foundations (such as the Abilities API), the ideal home for this is Core itself. The combining of these related APIs will unlock so many possibilities for developers and site owners.

Notas do Core Committers Check-in (Make WordPress Core)

Limites e preocupações: manter o WordPress agnóstico (sempre)

Ao mesmo tempo, quem está a ponderar levar o AI Client para o core está consciente das restrições. As notas reforçam que o WordPress “will always remain agnostic”: incluir um modelo de IA específico, ou integrar apenas com um conjunto pequeno de serviços de terceiros, não é sustentável a longo prazo.

Também se abordou que algumas das possibilidades mais interessantes podem surgir com modelos que correm “mais perto” do utilizador – por exemplo, modelos baseados em máquina (local) ou ao nível do browser. Mas, nesta fase, não foi escolhida uma direção.

Antes de entrar no core, pedem-se casos de uso claros no “WordPress por defeito”

Antes de qualquer decisão, os contribuidores querem validar casos de uso concretos aplicáveis ao WordPress “out of the box” (sem depender de plugins). Foram citados exemplos como:

• Pesquisar a biblioteca de media por conteúdo/tema específico (por exemplo, encontrar imagens com determinado assunto).
• Gerar newsletters com base em conteúdo recente do site.

Redesign do admin: menos “revolução”, mais refrescar o que já existe

O redesign do admin voltou à conversa e trouxe um esclarecimento importante: o objetivo não é uma reformulação total. A indicação partilhada foi que se trata de dar um “fresh coat of paint” – ou seja, uma camada de atualização visual e de usabilidade, refrescando o que já existe em vez de reescrever tudo de raiz.

Isto encaixa na Phase 3: Collaboration do roadmap do Gutenberg. O trabalho nesta área começou em 2023, quando Matías Ventura (Lead Architect do Gutenberg) partilhou a visão para modernizar a experiência do admin e mais tarde demonstrou novos layouts no State of the Word de 2023.

Vale lembrar que já tinha sido discutido (na reunião trimestral de julho) testar este redesign como experiência no plugin Gutenberg ou mesmo num plugin separado ao estilo “MP7” – referência histórica ao MP6, o modelo “feature as a plugin” (funcionalidade como plugin) que acabou por moldar o redesign do admin no WordPress 3.8.

Havia um preview inicial do redesign previsto para acompanhar o WordPress 6.9, mas essa prévia foi retirada do plano em setembro, quando o roadmap foi atualizado indicando que já não estava previsto “based on the current state of work”.

E, por agora, continua a faltar uma peça crítica: não há timeline para quando este admin redesenhado chega ao core. O último grande refresh do admin aconteceu há mais de uma década, no WordPress 3.8.

Subir o PHP mínimo para 7.4: razões técnicas fortes, decisão em aberto

Outro tópico com impacto direto em desenvolvimento foi a discussão sobre subir a versão mínima de PHP suportada para PHP 7.4. O grupo falou em “compelling reasons” (razões fortes) para o fazer, mas não tomou decisão durante a reunião.

O argumento foi sobretudo prático e de sustentabilidade do core:

• Versões antigas de PHP obrigam o WordPress a manter compatibilidades que adicionam bloat (peso/código extra) e abrandam o desenvolvimento.
• Com PHP 7.4, o codebase pode caminhar para tipagem mais consistente, tornando o código mais fácil de entender tanto por developers como por sistemas de IA.
• Muitos SDKs de IA de terceiros já exigem versões mais recentes; manter o mínimo demasiado baixo impede o projeto de os usar.

Ao mesmo tempo, a conversa foi enquadrada como um equilíbrio entre avançar e manter os utilizadores a bordo, sem “deixar ninguém para trás”.

O que ficou como próximos passos (follow-ups) após o check-in

Nas notas publicadas, Jonathan Desrosiers listou um conjunto de itens a dar seguimento após a sessão:

• Propor formatos de reunião mais abertos e semiabertos.
• Publicar o calendário de releases de 2026.
• Confirmar as funcionalidades alvo para o WordPress 7.0 e possivelmente 7.1.
• Avaliar se é prático coordenar releases com eventos presenciais.

Porque isto interessa a quem desenvolve (plugins, temas e plataformas)

Para quem vive do ecossistema WordPress, há três sinais claros aqui. Primeiro: uma cadência de três major releases muda o ritmo de planeamento, testes e compatibilidade. Segundo: a entrada (ou não) do AI Client no core pode definir um padrão de integração de IA que evita fragmentação e reduz duplicação de esforço em plugins. Terceiro: uma subida do PHP mínimo, se avançar, desbloqueia modernização técnica – mas obriga a olhar com atenção para hosting e base instalada.

Nada disto está “fechado” ainda, mas o recado é que 2026 está a ser desenhado com ambição: WordPress 7.0 como marco, IA com fundações comuns e uma melhoria gradual do admin sem prometer uma revolução instantânea.