Colaboração em tempo real WordPress

A colaboração em tempo real teve uma segunda oportunidade no núcleo do WordPress e falhou outra vez. 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 voltou ao plano do WordPress 7.1, com um programa de testes ao estilo FSE e 19 de agosto a ancorar o calendário.

O WordPress 7.1 Mary Lou saiu a 19 de agosto de 2026 sem edição multiutilizador em direto. São dois lançamentos principais consecutivos. O resto deste artigo é o ciclo tal como estava, mais o que as agências devem fazer agora que o pacote não contém a funcionalidade.

Para as agências que gerem fluxos editoriais em WordPress, a falha tem consequências concretas. A edição multiautor continuaria a ser a maior mudança de fluxo no núcleo há mais de uma década. Alteraria a superfície de conflito em textos longos, redefiniria o que significa um bloqueio sobre um artigo e deslocaria aquilo para que o editor de blocos serve. Nada disto chegou no 7.1. Não treine clientes para um substituto do bloqueio de artigo que não está lá.

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.

#Porque a colaboração em tempo real saiu do WordPress 7.0

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 testes 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.

#Porque a escolha da base de dados do RTC depende de testes de alojamento

Amy Kamala, co-representante da equipa de Hosting, resumiu a situação numa frase: “É preciso testar para decidir, é preciso decidir para testar.” (tradução própria)

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 edição completa do site 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 testes FSE criou uma população recrutada de testadores a operar sites reais com plugins reais, e o programa trouxe à superfície erros 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.

#Como funciona o programa de testes do RTC no WordPress 7.1

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. Utilizadores reais especialmente envolvidos. 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 programa 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 versão candidata contra ambientes de teste
• Ciclo de reporte: revisões semanais com um formulário estruturado de comentários
• Relatórios de erros 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.

#Data de lançamento do WordPress 7.1 e o que trouxe

O WordPress 7.1 Mary Lou saiu a 19 de agosto na WordCamp US em Phoenix. A data manteve-se. A colaboração em tempo real não. O calendário de testes abaixo é o ciclo tal como foi planeado em junho, mantido aqui porque mostra quão pouco espaço um recomeço arquitetural alguma vez teve.

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

• Final de julho: primeira versão candidata. Congelamento de funcionalidades. 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 testes 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 compilação amplamente testada. A arquitetura de armazenamento deve estar assumida nesta altura.
• Meio de junho: arranque do programa de testes. Testadores recrutados a executar compilações em ambientes de teste. Primeiro ciclo de comentários.
• Início de junho: recrutamento. Esse era o plano. Os alojamentos deviam recrutar testadores. A funcionalidade mesmo assim não entrou no zip.

Oito semanas eram tempo suficiente para uma arquitetura fechada. Não eram tempo suficiente para um recomeço arquitetural. A decisão de arquitetura ainda estava aberta quando o ciclo arrancou. O 7.1 saiu sem a funcionalidade. O 7.2 está neste momento apontado para 9 de dezembro de 2026. Trate isso como data de planeamento, não como RTC.

#Como a colaboração em tempo real muda o fluxo editorial 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 seria substituída. O conhecido modal “este artigo está a ser editado por…” desde o WordPress 3.6 cederia a indicadores de presença. No 7.1 isso não aconteceu. O modal antigo continua a ser o que o utilizador vê.

Estes não são casos de fronteira. É o impacto visível para o utilizador no primeiro dia, se a funcionalidade alguma vez sair. Não saiu no 7.1, portanto nada disto é um ticket de suporte de 19 de agosto. Mantenha a auditoria de plugins. Não reescreva materiais de formação para uma UX que não está no núcleo.

#Opções de base de dados para colaboração em tempo real

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 testes do 7.1 devia testar essas variantes contra configurações de alojamento realistas. A decisão de arquitetura devia estar fechada até ao final de junho. Não chegou a tempo. O 7.1 saiu sem RTC.

#O que as agências devem fazer depois do WordPress 7.1

Três movimentos concretos depois da falha do 7.1.

1. Não prometa aos clientes edição multiutilizador em direto no 7.1. Não está lá. O fluxo editorial sequencial continua a ser o produto.
2. Faça auditoria à sua pilha editorial de plugins na mesma. 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 quando o RTC voltar. A lista é útil mesmo que a funcionalidade esteja um ciclo à frente.
3. Não reescreva a formação do post-lock para agosto. O modal “este artigo está a ser editado por…” continua a ser o comportamento do 7.1. Guarde a explicação de uma página até um guia de campo dizer que os indicadores de presença saíram.

#Como as agências influenciam o WordPress com testes em produção

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 núcleo do WordPress foi guiado por decisões de contribuidores testadas em ambientes de contribuidores. O programa de testes 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 núcleo. O programa de testes 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, as conversas de corredor na WCEU em Cracóvia em junho foram o convite a parcerias de teste. Esse convite não produziu um lançamento no 7.1. A próxima data no calendário é o 7.2, neste momento apontado para 9 de dezembro de 2026 a par do State of the Word. Apareçam nessas conversas com dados de produção, não com um diapositivo de vendas a dizer que o RTC está no núcleo.

#Conclusão

A colaboração em tempo real não é uma funcionalidade entregue. Falhou o 7.0 e falhou o 7.1. A decisão sobre a arquitetura de base de dados não foi fechada a tempo. O programa de testes não passou a funcionalidade da linha.

O que está decidido: o 7.1 Mary Lou saiu a 19 de agosto sem edição multiutilizador em direto. O fluxo editorial sequencial continua a ser o que corre. Acompanhe o Make WordPress Core para o que o 7.2 realmente listar. Não trate um objetivo de dezembro como data de lançamento.

Os tópicos em make.wordpress.org/core continuam a ser a fonte principal. A cobertura do que o 7.1 realmente entregou está na nota do plano 7.1.

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