O roteiro do WordPress 7.1

#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 foi 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 daquele lançamento. Regressou 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 saiu mesmo a 19 de agosto, e uma história de colaboração que ainda está a ser discutida em aberto.

Atualização, 20 de agosto de 2026: o WordPress 7.1 Mary Lou saiu a 19 de agosto, na data. A atualização de React 18 para React 19, o e-mail em Unicode, o Guidelines / wp_knowledge, a colaboração em tempo real e a descontinuação do bloco Classic saíram todos do lançamento. O que entrou foi a estilização responsiva, os media do lado do cliente, uma barra de administração persistente, o editor de artigos sempre em iframe, Playlist e Tabs, e um Notes mais rico. A nota de 28 de julho sobre a Beta 3 continua a valer para os dois itens que saíram primeiro.

#Em resumo

• A Anne McCarthy liderou o 7.1 pela primeira vez. O WordPress 7.1 Mary Lou saiu a 19 de agosto de 2026, o dia de encerramento da WordCamp US em Phoenix.
• O lançamento estava estruturado em torno da colaboração, mas a colaboração em tempo real (RTC) foi adiada outra vez depois de ter sido cortada do 7.0.
• O que realmente entrou: estilização responsiva, media do lado do cliente, barra de administração persistente, editor de artigos sempre em iframe, Playlist e Tabs. O Guidelines e a descontinuação do bloco Classic não saíram. O React 19 escorregou para lá do 7.1.
• O suporte para endereços de e-mail em Unicode foi retirado do lançamento por decisão de Matt Mullenweg, por questões de segurança, seis semanas depois de ter sido integrado no núcleo.
• 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.
• A janela curta de estabilização fez o que sempre faz: a lista de junho era intenção. O zip de 19 de agosto é a entrega.

#O que saiu 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.

O padrão é claro. O que entrou é infraestrutural ou voltado para construtores. A história da colaboração, aquela que dá nome ao lançamento, ficou na faixa média a baixa e fora do zip.

Quem fechou o meio dessa tabela foi o Gutenberg 23.6, o último lançamento de funcionalidades antes do 7.1. Promove os blocos Playlist e Tabs de experimentais a estáveis, acrescenta notas em linha na seleção de texto com preenchimento automático de @menções, uma variação Dynamic Gallery que mostra todos os media anexados a um artigo, uma API de registo de ícones para plugins e temas, e larguras de viewport configuráveis no theme.json, ou seja, a estilização responsiva deixa de estar presa a três breakpoints escolhidos por outra pessoa.

#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 7.1 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. Os autores de temas definem os próprios breakpoints no theme.json. A Beta 4 acrescentou uma opção de exclusão depois de queixas de UX, por isso isto não é forçado em todos os sites.

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 escorrega, o bloco Classic fica: por dentro

Dois itens do roteiro são invisíveis para os utilizadores finais e importantes para os programadores. Um deles saiu do lançamento. A atualização do editor de React 18 para React 19 não entra no 7.1: os problemas de compatibilidade com plugins revelaram-se mais teimosos do que o esperado, e o contribuidor patrocinado pela Automattic Jarda Snajdr disse que a atualização precisa de “um período de testes considerável” antes de poder sair.

É a decisão certa e desconfortável ao mesmo tempo. O React 19 era um dos poucos itens deste roteiro com confiança alta e, ao mesmo tempo, o item com maior probabilidade de partir código de terceiros. Empurrá-lo torna o 7.1 um lançamento mais pequeno do que o roteiro anunciava e atira o trabalho de compatibilidade para um ciclo posterior. Para os programadores o efeito prático é um adiamento, não um cancelamento: a atualização continua a caminho, por isso testar blocos personalizados e interfaces de editor com o React 19 no plugin Gutenberg continua a valer a pena, só que sem um prazo de agosto em cima.

O bloco Classic é o caso mais interessante, porque o plano mudou a meio do ciclo. A ideia original era ocultá-lo do inseridor de blocos no 7.1 e retirá-lo gradualmente, porque transporta o TinyMCE, um editor pesado. A reação da comunidade foi imediata: alguns, como Seth Rubenstein (Pew Research Center), despacharam-na com um lacónico “bom”, enquanto bloggers veteranos como Jeff Chandler viam a perturbação a chegar: “Santo Deus. Não vi isto a caminho. Sei o que isto vai fazer.”

Atualização: esse plano de o ocultar do inseridor foi revertido. O bloco Classic continua a aparecer no inseridor no 7.1 exatamente como no 7.0, e o diretor de engenharia da Automattic Marin Atanasov observou que a abordagem original “tinha as coisas em grande medida ao contrário” e que forçar os utilizadores a abandoná-lo sem uma alternativa melhor só piora a experiência sem qualquer ganho direto. O ângulo do desempenho mantém-se, porque carregar o TinyMCE de forma diferida em páginas que nunca o usam é um ganho real para lojas WooCommerce onde cada kilobyte de peso do editor é medido, mas o relógio de migração que alguns já tinham posto a andar nunca arrancou. Quem mantém conteúdo em bloco Classic não é forçado a nada no 7.1.

Atualização: o suporte para endereços de e-mail em Unicode também está fora do 7.1. Tinha sido integrado no núcleo seis semanas antes, ao fim de onze anos de desenvolvimento, e Matt Mullenweg decidiu retirá-lo por questões de segurança. Onze anos até à integração e seis semanas até à reversão é um resultado duro para os contribuidores envolvidos, e convém lê-lo ao lado do debate do canary mais abaixo: uma alteração que passa a revisão, é integrada e depois retirada tarde por uma avaliação de segurança é exatamente a falha no ciclo de feedback que os committers tentam nomear. Se contava com endereços de e-mail fora do ASCII no 7.1, planeie com o comportamento atual.

Duas mudanças com impacto para os programadores surgiram como propostas de merge depois do roteiro e vale a pena segui-las. O theming do sistema de design introduz uma folha de estilos wp-theme registada no núcleo mais um ThemeProvider de React, a base do tão prometido redesenho do painel de administração, com os esquemas de cor do utilizador aplicados no editor do site como primeiro resultado visível. E a Abilities API ganhou três abilities só de leitura propostas (core/read-settings, core/read-content, core/read-users) que permitem a agentes e ferramentas de IA ler dados básicos do site após verificações de permissões, ainda que um mantenedor de Abilities já tenha objetado que não estão prontas para o núcleo. Ambas são o tipo de canalização que decide se a história da IA e do painel sai limpa ou escorrega para o 7.2.

#Guidelines e IA: a aposta no fluxo de trabalho

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 funcionalidade deu um passo concreto quando o core committer patrocinado pela Automattic, Greg Ziółkowski, publicou uma proposta formal de merge para trazer o novo custom post type wp_knowledge e as AI Guidelines para o núcleo. A receção, no entanto, foi altamente polarizada:

• George Stephanis (Bethink Studios) acolheu a funcionalidade, notando que resolve os desafios de diretrizes editoriais que os plugins passaram anos a contornar.
• Aaron Jorbin (core committer independente) observou que estabelece uma boa fundação, mas permanece incompleta no seu estado atual.
• Jon Brown (9seeds) argumentou abertamente que “deveria ser desenvolvida como um plugin do núcleo durante um ano ou dois, e depois talvez nunca ser integrada no núcleo.”
• O Search Engine Journal destacou a resistência dos programadores, relatando que muitos sentem que a funcionalidade está desfasada das necessidades reais dos utilizadores.

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. Não saiu. Matt Mullenweg vetou a integração em julho, dizendo que as funcionalidades de IA precisam de adoção real com crescimento impressionante de semana para semana antes de entrarem no núcleo. A experiência fica no Gutenberg e na Automattic. Trate-a como proposta, não como capacidade do 7.1. Cobrimos o debate da integração em WordPress 7.1: diretrizes de IA e o novo tipo de conteúdo wp_knowledge.

#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 enquadrou-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 colaboração em tempo real no WordPress 7.1, e o roteiro não resolveu tanto as questões aí levantadas como voltou 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. Essa divisão manteve-se neste ciclo. O 7.1 não entregou nem a canalização nem a funcionalidade visível. A colaboração como fio condutor ficou aspiração. O 7.2 está neste momento apontado para 9 de dezembro de 2026. Não venda a um cliente edição multiutilizador ao vivo nessa data também, até um field guide dizer que saiu.

#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 foi a 15 de julho, o lançamento a 19 de agosto, e a Beta 3 trouxe 71 correções. São menos de quatro semanas para fechar um roteiro tão grande. McCarthy herdou uma lista ambiciosa e pouco tempo para a executar, e o resultado realista sempre foi 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. O React 19 e o e-mail em Unicode caíram antes da Beta 3. Guidelines, RTC e a descontinuação do bloco Classic caíram à volta dela. O zip que saiu é a lista mais curta.

Para os proprietários de sites, a lição prática não mudou: tratar o roteiro como intenção, não como garantia. Planeie em torno do que realmente saiu, estilização responsiva, media do lado do cliente, Playlist e Tabs, e o editor em iframe. Não prometa a um cliente uma funcionalidade que ainda carregava “big, open strategy questions” (grandes questões estratégicas em aberto) seis semanas antes do lançamento, e não confunda uma funcionalidade integrada com uma funcionalidade lançada. O e-mail em Unicode foi integrado e depois retirado. É a mesma lição.

#O atraso de 24 horas nas atualizações: segurança vs. velocidade

Paralelamente aos debates sobre o lançamento do núcleo, a equipa de plugins do WordPress.org implementou uma alteração significativa na infraestrutura: um período de arrefecimento (cooldown) de 24 horas para todas as atualizações de plugins e temas. Embora o anúncio tenha enquadrado esta medida em torno das atualizações automáticas para evitar ataques à cadeia de abastecimento, verificou-se que o atraso se aplica a todas as vias de atualização, incluindo instalações manuais a partir do painel de administração.

Isto gerou uma forte contestação por parte de programadores e agências:

• Miriam Schwab (Elementor) apontou que isto cria uma perigosa “janela de vulnerabilidade”. No momento em que uma versão de segurança é submetida, o código da correção torna-se público e os bots podem analisá-lo para criar exploits, mas os administradores dos sites ficam impedidos de aplicar a atualização durante 24 horas.
• Pavel Ciorici (programador de temas) alertou que, se um programador lançar uma correção rápida de bugs durante o cooldown, o temporizador de 24 horas reinicia, agravando o atraso.
• Steve Burge (PublishPress) ofereceu um contraponto, destacando que o processo detetou com sucesso pequenos problemas de segurança na sua primeira semana e considerou-o um bom passo em frente.
• Francisco Torres (co-representante da equipa de plugins) reconheceu a fricção, confirmando que a equipa está a analisar ativamente os comentários e que é provável que existam alterações a esta regra.

Para agências e sites WordPress focados no desempenho, esta mudança de infraestrutura altera o ritmo dos lançamentos e da aplicação de correções de segurança, reforçando a necessidade de utilizar implementações externas ao repositório ou testar atualizações em ambientes de testes (staging) antes da distribuição pública.

#O que fazer agora

• Programadores: o editor de artigos está sempre em iframe. Blocos em API v2 ou inferior precisam de uma passagem para v3. Os pormenores estão na nota sobre o editor de artigos em iframe. O React 19 continua fora do núcleo. Continuem a testá-lo no plugin Gutenberg.
• Sites com WP Rocket: um erro de tipo no módulo de compatibilidade com a Cloudflare está a pôr sites offline no 7.1 (wp-media/wp-rocket#8596). Staging primeiro, depois produção. Se mantém lojas, isto é uma verificação de desempenho e fiabilidade WooCommerce, não uma passagem cosmética.
• Sites legados: o bloco Classic continua no inseridor. Não há migração forçada no 7.1. Faça a auditoria quando for mexer no conteúdo de qualquer forma, não porque este lançamento tenha posto um relógio a andar.
• Equipas editoriais: o Guidelines não saiu. Não redesenhem o fluxo de trabalho em torno de uma experiência do Gutenberg.
• Todos: as atualizações automáticas para o 7.1 já estão a rolar. Testem em staging, sobretudo se correm object cache, um plugin de cache de páginas, ou JavaScript próprio no editor.

#Conclusão

O WordPress 7.1 Mary Lou é um lançamento de plataforma útil com um nome ligeiramente enganador. O enquadramento da colaboração era intenção verdadeira. A funcionalidade de colaboração não saiu, pelo segundo ciclo consecutivo. Retire o enquadramento e o que recebeu a 19 de agosto é mais pequeno e ainda vale a pena: estilização responsiva que remove atrito diário, media do lado do cliente que deixa de rebentar o limite de memória PHP nos envios HEIC, Playlist e Tabs como blocos estáveis, uma barra de administração persistente, e o editor de artigos sempre em iframe. O Guidelines não entrou. A descontinuação do bloco Classic não entrou. O React 19 e o e-mail em Unicode ficaram de fora. A distância entre o roteiro de junho e o zip de agosto está agora medida, não prevista.

A história mais profunda continua a ser 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, a mesma inquietação que alimenta o debate recorrente sobre se o WordPress está a perder quota de mercado. Acompanhe essa conversa, porque vai moldar lançamentos muito depois deste. Planeie em torno do que saiu. Teste o staging. Trate o próximo roteiro da mesma forma que este merecia ser tratado: intenção, até o zip existir.

Última atualização: 20 de agosto de 2026.