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.

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

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

#A forma do programa de testes

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.

#A data de 19 de agosto e o que realmente entregou

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.

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

#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 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 agora

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.

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

#A 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.