WordPress 7.1 colaboração em tempo real: a segunda tentativa, o programa de outreach ao estilo FSE e o prazo de oito semanas

A colaboração em tempo real está a ter uma segunda oportunidade no core do WordPress. Duas semanas antes de o WordPress 7.0 sair, a equipa de contribuidores retirou aquilo que deveria ser a funcionalidade central do lançamento. A razão apresentada na altura foram problemas de desempenho da base de dados que a equipa não conseguia comprometer-se a corrigir dentro da janela de lançamento. Seis semanas depois, a mesma funcionalidade volta ao roadmap do WordPress 7.1, com um programa de outreach ao estilo FSE em arranque e uma data de lançamento, 19 de agosto, a ancorar o calendário.

Para as agências que gerem fluxos editoriais em WordPress, isto tem consequências concretas. A edição multiautor é a maior mudança de fluxo no core há mais de uma década. Altera a superfície de conflito em textos longos, redefine o que significa um “lock” sobre um artigo e desloca aquilo para que o editor de blocos serve. A tentativa do 7.1 sinaliza também como a forma da contribuição para o WordPress está a mudar: um programa de outreach para algo que, no fundo, é uma questão de arquitetura de base de dados, é uma forma nova para o projeto.

Acompanhámos o anúncio, lemos as threads em make.wordpress.org/core e participámos em duas das primeiras conversas de outreach. Eis o que as agências devem saber no arranque do ciclo do 7.1. Em Portugal, esta tensão é familiar: redações como as do Público ou da RTP fazem fluxos digitais com vários jornalistas e editores a trabalhar no mesmo texto, e é precisamente aí que se decide se a funcionalidade aguenta a escala.

#O que foi retirado do 7.0 e porquê

A colaboração em tempo real no editor de blocos precisa de três coisas para funcionar à escala: um canal de presença e cursores com baixa latência, uma estratégia de fusão sem conflitos para alterações de blocos e uma camada de armazenamento que consiga manter o histórico fundido sem partir o modelo existente de wp_posts e wp_postmeta.

O canal de presença e cursores foi resolvido no ciclo 6.x, com uma combinação de long-polling e um transporte WebSocket opcional para sites dispostos a manter essa infraestrutura. A estratégia de fusão sem conflitos chegou ao plugin Gutenberg no final de 2025 com uma abordagem baseada em CRDT. A terceira peça, a camada de armazenamento, foi onde o 7.0 falhou.

A implementação do 7.0 persistia o estado de colaboração numa nova tabela ligada às revisões do artigo. Em instalações mais pequenas, isso funcionava. À escala de um ambiente de teste da Automattic com mais de 50 000 edições concorrentes, as escritas para a nova tabela criavam atraso de replicação e contenção de bloqueios suficientemente graves para a equipa marcar o problema como bloqueador de lançamento. A decisão de retirar foi tomada a meio de abril, duas semanas antes da data de GA do 7.0.

O anúncio de Anne McCarthy sobre o novo programa de outreach reconhece que a arquitetura da base de dados continua a ser a questão em aberto: a equipa tem hipóteses sobre como a resolver, mas, no arranque do ciclo do 7.1, ainda não há uma implementação assumida. Isso é invulgar para uma funcionalidade pensada para um lançamento.

#O problema do ovo e da galinha

Amy Kamala, co-representante da equipa de Hosting, resumiu a situação numa frase: “Need testing to make decision, need decision to do testing.”

As opções arquiteturais para a camada de armazenamento têm perfis de custo muito diferentes para os vários ambientes de alojamento. Uma solução que funciona bem numa instalação single-server pode não sobreviver a um setup com balanceamento de carga e réplicas de leitura. Uma solução adequada a um ambiente single-tenant de alojamento gerido pode não funcionar em multisite à escala em que o WordPress.com opera.

O ciclo do 7.0 tentou tomar a decisão arquitetural à partida e testá-la depois. Essa ordem falhou, porque os resultados dos testes invalidaram a decisão e não havia tempo para corrigir o rumo. O ciclo do 7.1 está a tentar inverter a ordem: escolher primeiro os cenários de teste, validar quais as variantes arquiteturais que os sobrevivem e deixar que a variante sobrevivente determine a implementação.

Este é o mesmo padrão que a equipa de Full-Site Editing usou no ciclo do 5.8 ao 6.0, quando o fosso entre os ambientes dos contribuidores e os ambientes reais de alojamento produziu regressões repetidas. O programa de outreach FSE criou uma população recrutada de testadores a operar sites reais com plugins reais, e o programa veio à superfície bugs que a equipa de contribuidores não teria apanhado isoladamente.

Aplicar o mesmo padrão à colaboração em tempo real é a nova jogada estrutural. É também a razão pela qual se pede aos alojamentos que ajudem a recrutar testadores da sua base de clientes geridos.

#A forma do programa de outreach

O anúncio de Anne McCarthy posiciona a população de testes em três camadas:

1. Testes orientados a programadores. O ciclo de testes existente. Plugins, temas, superfície da REST API, regressões de desempenho. Conduzido pelos contribuidores e em infraestrutura da Automattic.
2. Testes empresariais e determinísticos. Realizados com parceiros de alojamento em ambientes de clientes geridos com carga controlada. Pensados para validar que a arquitetura de armazenamento sobrevive a cenários de contenção de base de dados.
3. Passionate real-world early adopters. A camada nova. Recrutada entre agências, editores e equipas de conteúdos que operam sites WordPress em produção com a colaboração editorial como requisito real de fluxo de trabalho.

A terceira camada é de onde virá a maior parte do novo débito de testes. O outreach pede explicitamente sites onde a colaboração em tempo real resolve um problema real, e não instalações de teste sintéticas.

O que se pede aos testadores:

• Fluxos editoriais ativos com mais do que um autor a trabalhar em simultâneo em conteúdos longos
• Disponibilidade para executar uma build de release candidate contra ambientes de staging
• Ciclo de reporte: check-ins semanais com um formulário de feedback estruturado
• Relatórios de bugs que captem tanto o comportamento do editor como métricas ao nível da base de dados a partir da camada de alojamento

O que os testadores recebem:

• Linha direta com a equipa de contribuidores que está a construir a funcionalidade
• Visibilidade sobre as decisões arquiteturais à medida que vão sendo tomadas
• Reconhecimento de patrocínio para os sites que façam ciclos de teste prolongados
• A pré-visualização mais antecipada possível daquilo que a colaboração em tempo real vai significar para o seu processo editorial

Para agências com clientes editoriais, é a forma mais direta de estar na sala quando a funcionalidade é finalizada. O benefício para a agência não é o reconhecimento. É a pré-visualização de engenharia.

#A data de 19 de agosto e por que importa

O WordPress 7.1 está agendado para 19 de agosto. A data não é arbitrária. Coincide com a WordCamp US em Phoenix, onde o lançamento será celebrado como parte do programa da conferência. A data de lançamento ancora também todo o calendário de testes do 7.1.

Contando para trás a partir de 19 de agosto:

• Final de julho: Release Candidate 1. Feature freeze. O RTC tem de estar suficientemente estável para públicos de teste mais amplos. A decisão arquitetural da base de dados tem de estar fechada.
• Meio de julho: Beta 3. Última oportunidade para alterações de comportamento. Os dados do programa de outreach devem informar decisões, não iniciá-las.
• Início de julho: Beta 2. Última oportunidade para alterações arquiteturais não triviais. Os dados de teste dos parceiros de alojamento devem estar dentro.
• Final de junho: Beta 1. Primeira build amplamente testada. A arquitetura de armazenamento deve estar assumida nesta altura.
• Meio de junho: arranque do programa de outreach. Testadores recrutados a executar builds em staging. Primeiro ciclo de feedback.
• Agora (início de junho): recrutamento. Os alojamentos recrutam testadores, a equipa de contribuidores prepara o material de outreach.

Oito semanas são tempo suficiente. Não são tempo suficiente para um recomeço arquitetural. A implicação para as agências que acompanham isto: assuma que a decisão arquitetural será tomada até ao final de junho. Se tem uma opinião forte ou dados de produção que devam informá-la, leve isso à equipa de contribuidores nas próximas três semanas.

#O que a colaboração em tempo real muda nos fluxos das agências

Ponha de lado a questão da base de dados por um momento. Como é, na prática, o WordPress com colaboração em tempo real para uma agência?

Três mudanças concretas de fluxo que chegam com a funcionalidade:

• Os ciclos de revisão editorial encolhem. O fluxo editorial atual do WordPress é sequencial. O autor escreve. O editor revê depois de o autor terminar. O autor responde aos comentários. O editor aprova. Com colaboração em tempo real, autor e editor podem trabalhar em simultâneo. Para agências que gerem calendários editoriais para clientes de conteúdo, isto reduz o tempo de ciclo por artigo e altera o aspeto das horas faturáveis. Em redações portuguesas em que o editor de secção trabalha em paralelo com o jornalista durante uma hora-rolo, a funcionalidade corta uma passagem de testemunho que hoje muitas vezes ocupa metade do turno.
• A compatibilidade dos plugins passa a ser um problema vivo. Muitos dos plugins editoriais mais instalados pressupõem edição por um único autor. As gravações de campos ACF, a análise do Yoast SEO, as atualizações da metabox do Rank Math, as metaboxes personalizadas de taxonomia e uma cauda longa de plugins desenvolvidos por agências precisam todos de ser revistos em termos de segurança em escrita concorrente. A equipa de revisão de plugins foi clara: a colaboração em tempo real vai pôr a descoberto plugins com padrões de escrita inseguros.
• A UX do “post lock” é substituída. O conhecido modal “este artigo está a ser editado por…” que existe desde o WordPress 3.6 está a ser descontinuado em favor de indicadores de presença. Utilizadores treinados durante uma década no comportamento antigo vão precisar de aprender o novo padrão. As comunicações internas e os materiais de formação têm de ser atualizados.

Estes não são casos de fronteira. É o impacto visível para o utilizador no dia em que a funcionalidade sair.

#A questão da arquitetura de base de dados, simplificada

O desafio técnico central é simples. O WordPress guarda o conteúdo de cada artigo em wp_posts.post_content como um único blob. As revisões criam novas linhas. A colaboração em tempo real precisa de fundir edições concorrentes nesse blob sem perder dados e sem criar um crescimento descontrolado de revisões.

As três variantes arquiteturais atualmente em discussão:

1. Log de operações append-only. Uma nova tabela guarda operações individuais (inserir, apagar, alteração de formatação) com timestamps e IDs de autor. O blob post_content é reconstruído a partir do log de operações na gravação. Pró: resolução de conflitos limpa. Contra: volume de escrita elevado para a nova tabela.
2. Snapshot mais deltas. Snapshots periódicos de post_content mais registos delta entre snapshots. Pró: volume de escrita limitado. Contra: a lógica de temporização dos snapshots é complexa e a recuperação a partir de snapshots em falta é difícil.
3. Fusão em memória com persistência periódica. O estado de colaboração mantido em memória ao nível da camada aplicacional, persistido em post_content e numa única linha de revisão por intervalos ou em gravação explícita. Pró: baixo volume de escrita na base de dados. Contra: exige sticky sessions ou uma camada de cache partilhada.

Cada variante tem implicações para o alojamento. A variante 1 sobrecarrega a base de dados. A variante 2 sobrecarrega a camada aplicacional com lógica de temporização. A variante 3 sobrecarrega a infraestrutura de cache e de sessão, normalmente Redis ou Memcached e pools de PHP-FPM bem dimensionados.

O programa de outreach do 7.1 está a ser desenhado para testar as três variantes contra configurações de alojamento realistas. Qual a variante que sobrevive é a decisão arquitetural que a equipa precisa de tomar até ao final de junho.

#O que as agências devem fazer este mês

Três movimentos concretos para agências que gerem WordPress para clientes editoriais ou de imprensa.

1. Faça auditoria à sua stack editorial de plugins. Cada plugin que se prende a save_post, wp_insert_post_data ou às gravações de meta do editor de blocos é candidato a escrita concorrente. Liste os plugins, anote os autores e verifique se os autores têm declarações públicas sobre compatibilidade com RTC. Os que não têm declarações são aqueles em torno dos quais é preciso planear.
2. Inscreva um cliente editorial no programa de outreach. Se tem um cliente com dois ou mais editores a trabalhar na mesma superfície de conteúdos, é exatamente esse fluxo que a equipa de outreach quer. Inscrever coloca o seu cliente na população de teste e coloca-o a si na sala da conversa arquitetural. A inscrição faz-se através do artigo em make.wordpress.org/core ligado no anúncio de McCarthy.
3. Prepare formação interna para a mudança de UX do post-lock. Mesmo que os seus clientes não usem ativamente a colaboração em tempo real, a alteração visível ao comportamento de “artigo bloqueado” vai gerar tickets de suporte em agosto. Tenha uma explicação de uma página pronta.

#O padrão maior: a forma da contribuição está a mudar

Por trás do ciclo do 7.1 há uma história estrutural que vai além da funcionalidade.

Durante a maior parte da sua história, o desenvolvimento do core do WordPress foi guiado por decisões de contribuidores testadas em ambientes de contribuidores. O programa de outreach FSE no ciclo do 5.8 ao 6.0 foi a primeira tentativa de incorporar formalmente os testes do mundo real no ciclo de decisão do core. O outreach da colaboração em tempo real para o 7.1 é o segundo.

O padrão é que o projeto se está a tornar mais dependente do input vinda de ambientes de produção e menos capaz de fazer aterrar funcionalidades centrais apenas em ambientes de contribuidores. É o mesmo deslocamento por que passam os projetos open source maduros à medida que a sua base instalada se diversifica. Também altera quem tem influência sobre a direção. As agências que gerem sites reais de clientes com fluxos editoriais reais são, cada vez mais, as pessoas cujo feedback molda o core. É um lugar legítimo à mesa que não existia um ciclo de lançamento ou dois antes. Em Portugal, a comunidade WordPress organizada em torno do WP Lisboa e do WordCamp Lisboa tem vindo, há vários ciclos, a pedir exatamente este tipo de envolvimento.

Para as agências portuguesas e europeias, a implicação é direta: a WCEU em Cracóvia esta semana vai acolher conversas sobre parcerias de teste de RTC nos corredores, entre as pausas patrocinadas e ao café. Apareçam por lá.

#A conclusão

A colaboração em tempo real ainda não é uma funcionalidade entregue. A decisão sobre a arquitetura de base de dados ainda não foi tomada. O programa de outreach ainda está a recrutar. Nada disto está fechado.

O que está decidido: a funcionalidade voltou ao roadmap, a data de lançamento a 19 de agosto é a âncora de trabalho, a estratégia de testes foi alargada para lá dos ambientes empresariais e de contribuidores, e os alojamentos estão a ser convidados a ajudar a recrutar testadores em produção. Se a decisão arquitetural chegar até ao final de junho e os dados do outreach a validarem, o WordPress 7.1 entrega a funcionalidade na WordCamp US.

Para as agências com clientes editoriais, este é o ciclo de lançamento em que vale a pena participar. A forma da edição multiautor no WordPress para o resto da década está a ser definida nas próximas oito semanas.

O anúncio em make.wordpress.org/core e os detalhes do programa de outreach estão em Make WordPress Core. A cobertura continua na The Repository e no blogue da WPPoland ao longo de todo o ciclo do 7.1.

Última atualização: 2026-06-06.