Introdução
A 19 de junho de 2026, Anne McCarthy, da Automattic, publicou o roteiro do WordPress 7.1 no blogue Make WordPress Core, o seu primeiro ciclo como líder de lançamento. O seu enquadramento no LinkedIn foi caracteristicamente caloroso: “I am so excited about what’s taking shape.” (Estou tão entusiasmada com o que está a ganhar forma.) O roteiro está genuinamente recheado, e a palavra de destaque é colaboração, apresentada como o fio condutor que mantém o lançamento coeso.
Há uma tensão que vale a pena nomear logo à partida. O lançamento é apresentado em torno da colaboração, mas a funcionalidade de colaboração de maior destaque, a colaboração em tempo real, é justamente a que continua a ser adiada. Foi retirada do WordPress 7.0 cerca de duas semanas antes desse lançamento. Regressa no roteiro do 7.1 envolta em “big, open strategy questions” (grandes questões estratégicas em aberto) em vez de uma data de lançamento. E na WordCamp Europe 2026, os core committers questionaram abertamente se a funcionalidade completa pertence sequer ao núcleo. Assim, a leitura honesta do 7.1 são dois lançamentos num só: um conjunto sólido de melhorias de estilização, media e plataforma que vai mesmo sair a 19 de agosto, e uma história de colaboração que ainda está a ser discutida em aberto.
Em resumo
- A Anne McCarthy lidera o 7.1 pela primeira vez, com lançamento marcado para 19 de agosto de 2026, o dia de encerramento da WordCamp US em Phoenix, e a Beta 1 a 15 de julho.
- O lançamento está estruturado em torno da colaboração, mas a colaboração em tempo real (RTC) continua por resolver depois de ter sido cortada do 7.0.
- Os ganhos genuinamente confirmados são a estilização responsiva, o React 19, a descontinuação do bloco Classic, e as funcionalidades de fluxo de trabalho Guidelines e IA.
- Os core committers lançaram um modelo de canary deployment ao estilo do Chrome, um sinal de que consideram que o próprio processo de teste e feedback precisa de ser repensado.
- Com menos de quatro semanas da Beta 1 ao lançamento, é de esperar que alguns itens do roteiro escorreguem ou saiam por trás de flags.
O que sai mesmo, ordenado por quem afeta
O roteiro lista muita coisa. Para um proprietário de site ou uma agência, a pergunta útil não é “o que está na lista”, mas “o que muda o meu trabalho”. Eis a divisão.
| Funcionalidade | O que é | A quem afeta | Confiança |
|---|---|---|---|
| Estilização responsiva | Definir estilos de bloco por tamanho de ecrã no editor | Construtores de sites, agências | Alta |
| React 18 para 19 | Atualização interna da biblioteca do editor | Programadores de blocos e plugins | Alta |
| Descontinuação do bloco Classic | Eliminar gradualmente o bloco Classic, carregar o TinyMCE de forma diferida | Sites legados, desempenho | Alta |
| Guidelines | Regras editoriais e voz da marca, ligadas às ferramentas de IA | Equipas editoriais | Média |
| Melhorias no Notes | Reações em emoji, modo de sugestão, texto rico | Revisores, equipas | Média |
| Media do lado do cliente | HEIC, Ultra HDR, GIF-para-video, recorte livre | Editores de conteúdo | Média |
| Novos blocos | Playlist, Table of Contents, Tabs | Todos os utilizadores | Média |
| Colaboração em tempo real | Edição multiutilizador ao vivo | Equipas, eventualmente | Baixa para o 7.1 |
O padrão é claro. Os itens de alta confiança são infraestruturais ou voltados para construtores. A história da colaboração, aquela que dá nome ao lançamento, situa-se na faixa média a baixa.
Estilização responsiva: o destaque silencioso
Se constrói sites para clientes, o mais útil no 7.1 não é a colaboração, é a estilização responsiva. Até agora, controlar como um bloco aparece em diferentes tamanhos de ecrã significava CSS personalizado, um plugin, ou uma luta com o editor. O roteiro traz a estilização de blocos por breakpoint para o próprio editor, a par da estilização de estados interativos para hover, foco e ativo, e de uma vista “display inherited styles” (mostrar estilos herdados) para que possa ver de onde um estilo realmente vem.
Isto é pouco glamoroso e importa mais do que a maioria dos itens mais vistosos. O controlo responsivo é um ponto de atrito diário no trabalho real com clientes, e movê-lo para o núcleo reduz o número de plugins e o CSS personalizado que todos os sites de outra forma acumulam. É o tipo de maturidade de plataforma que não dá manchetes, mas que elimina silenciosamente toda uma categoria de pedidos de suporte.
React 19 e descontinuação do bloco Classic: por dentro
Dois itens do roteiro são invisíveis para os utilizadores finais e importantes para os programadores. O WordPress está a atualizar o editor de React 18 para React 19, aterrando primeiro no plugin Gutenberg antes de um eventual caminho para o núcleo. Para a maioria dos sites isto não muda nada de visível. Para quem mantém blocos personalizados ou interfaces de editor, é uma razão para testar com o React 19 antes de agosto e não depois.
A descontinuação do bloco Classic é a mais interessante, porque é uma decisão de desempenho disfarçada de arrumação. O bloco Classic transporta o TinyMCE, um editor pesado, e o plano é carregá-lo de forma diferida e eliminar o bloco gradualmente. O conteúdo existente não deixa de funcionar, mas os sites que ainda se apoiam no editor Classic ou no bloco Classic devem encarar isto como o arranque formal da contagem decrescente para migrar. Para builds sensíveis ao desempenho, sobretudo lojas WooCommerce onde cada kilobyte de peso do editor e do front-end é medido, livrar-se do TinyMCE em páginas que nunca precisaram dele é um ganho real.
Guidelines e IA: a aposta no fluxo de trabalho
O roteiro aposta na IA, mas de forma mais disciplinada do que “adicionar uma caixa de chat”. O destaque é o Guidelines, uma funcionalidade que permite a um site definir regras editoriais e voz da marca num só lugar, alimentando depois as ferramentas de IA do editor para que o conteúdo gerado siga essas regras. Há também uma iteração do AI Client que adiciona streaming de geração e embeddings, e uma iteração dos Connectors que leva a autenticação para além das simples chaves de API.
Esta é a forma certa para a IA num CMS. O risco da assistência de escrita por IA é um resultado uniforme e fora da marca, exatamente o problema de slop contra o qual todas as equipas de conteúdo lutam agora. Uma camada Guidelines que limita a geração aos padrões de um site é uma proteção contra isso, partindo do princípio de que sai num estado utilizável. É classificada aqui como de confiança média justamente porque a ambição da funcionalidade e uma janela de estabilização de quatro semanas nem sempre se conciliam.
A saga da RTC, e porque continua a emperrar
A colaboração em tempo real é a funcionalidade que o WordPress está sempre quase a lançar. Foi cortada do 7.0 duas semanas antes. No roteiro do 7.1, McCarthy enquadra-a com honestidade, com “big, open strategy questions” (grandes questões estratégicas em aberto) ainda por resolver: o que efetivamente lançar e que mecanismo de armazenamento usar. Abordámos os pormenores desta segunda tentativa no nosso artigo sobre WordPress 7.1 real-time collaboration, e o roteiro não resolve tanto as questões aí levantadas como volta a enunciá-las.
O desenvolvimento mais revelador veio dos core committers. No seu encontro na WordCamp Europe 2026, surgiu uma “strong opinion, loosely held” (opinião forte, mantida de forma livre) de que o conjunto completo de funcionalidades da RTC não devia viver de todo no núcleo, apenas a arquitetura subjacente, deixando a camada rica de funcionalidades para plugins ou alojamentos. É uma divisão significativa. Se se mantiver, o 7.1 poderá entregar as fundações técnicas da colaboração sem a funcionalidade visível, o que tornaria o enquadramento da “colaboração como fio condutor” mais aspiração do que entrega neste ciclo.
O debate do canary: um problema de processo disfarçado
O mais interessante que os committers discutiram na WordCamp Europe nem sequer foi uma funcionalidade. Lançaram a ideia de mover o WordPress para um modelo de canary deployment ao estilo do Chrome com feature flags, uma forma fundamentalmente diferente de construir, testar e lançar o núcleo. O próprio grupo reconheceu que era provavelmente “a technical solution to a communications problem” (uma solução técnica para um problema de comunicação), e levantou perguntas óbvias, como em que os builds canary se distinguiriam do que o plugin Gutenberg já oferece, e se até deveria continuar a existir um plugin Gutenberg.
Está longe de acontecer. Mas o facto de os committers o levantarem diz algo sobre onde acham que o modelo atual fica aquém, sobretudo em torno de testes e feedback. Os falhanços à tangente da RTC são o sintoma: uma funcionalidade importante chegar a duas semanas do lançamento antes de ser retirada é uma falha no ciclo de feedback, não apenas uma funcionalidade que não estava pronta. A ideia do canary é uma tentativa de apanhar isso mais cedo. Quer venha a vingar ou não, o facto de estar em cima da mesa é a admissão mais honesta de todo o ciclo de que o processo de construção, e não o backlog de funcionalidades, é a verdadeira limitação.
O problema do calendário
Eis o número duro. A Beta 1 está prevista para 15 de julho, e o lançamento é a 19 de agosto. São menos de quatro semanas para fechar um roteiro tão grande. McCarthy herda uma lista ambiciosa e pouco tempo para a executar, e o resultado realista é que alguns itens saem, alguns escorregam para o 7.2, e alguns chegam por trás de feature flags num estado parcial. Isto não é uma crítica à líder de lançamento, é a realidade estrutural de uma data fixa marcada para coincidir com a WordCamp US.
Para os proprietários de sites, a lição prática é tratar o roteiro como intenção, não como garantia. Planeie em torno dos itens de alta confiança, estilização responsiva, React 19, a contagem decrescente do bloco Classic, e acompanhe os de confiança média em vez de assentar planos neles. Não prometa a um cliente uma funcionalidade que ainda carrega “big, open strategy questions” (grandes questões estratégicas em aberto) seis semanas antes do lançamento.
O que fazer antes de 19 de agosto
- Programadores: testem blocos personalizados e extensões de editor com o React 19 já agora, usando o plugin Gutenberg, e não depois do lançamento do núcleo.
- Sites legados: auditem onde ainda dependem do bloco ou editor Classic e iniciem um plano de migração, porque a contagem decrescente da descontinuação já arrancou formalmente.
- Projetos sensíveis ao desempenho: a mudança para o carregamento diferido do TinyMCE é desempenho gratuito assim que deixar o bloco Classic, vale a pena tomar em conta numa revisão de desempenho WooCommerce.
- Equipas editoriais: acompanhem o Guidelines e as ferramentas de IA, mas não redesenhem o vosso fluxo de trabalho em torno de uma funcionalidade de confiança média até que ela saia mesmo.
- Todos: testem com a Beta 1 a partir de 15 de julho. Uma janela de estabilização curta significa que os testes da comunidade contam mais do que o habitual neste ciclo.
Conclusão
O WordPress 7.1 é um lançamento forte com um nome ligeiramente enganador. O enquadramento da colaboração é intenção verdadeira, mas a funcionalidade de colaboração continua por resolver, e os committers debatem abertamente se pertence ao núcleo e se todo o processo de construção precisa de ser repensado. Retire o enquadramento e o que tem a 19 de agosto é um lançamento de plataforma genuinamente útil: estilização responsiva que remove atrito diário, uma modernização para React 19, uma descontinuação do bloco Classic que ajuda o desempenho, e um primeiro passo disciplinado na IA através do Guidelines.
A história mais profunda é o debate do canary. Um projeto disposto a questionar publicamente o seu próprio modelo de deployment é um projeto que sabe que os seus ciclos de feedback estão a ficar sob tensão. Acompanhe essa conversa, porque vai moldar os lançamentos do WordPress muito depois de o 7.1 sair. Por agora, planeie em torno do que está confirmado, teste cedo, e trate o resto do roteiro como uma declaração de intenções e não como uma promessa de entrega.
Última atualização: 20 de junho de 2026.
