O futuro do WordPress: roteiro 2026-2030 e além

Em 2015, a conversa WordPress girava em torno da REST API. Em setembro de 2026, com o 7.1.1 como versão estável, gira em torno de quem pode editar a mesma entrada ao mesmo tempo, o que um agente de IA pode invocar e se consegue tirar o conteúdo de um construtor fechado sem o copiar à mão.

Dois números enquadram o resto. A W3Techs mediu o WordPress em 40,2% de todos os websites e 58,8% dos sites com CMS conhecido a 20 de setembro de 2026, abaixo dos 43,2% de todos os websites em dezembro de 2025. O roteiro responde a essa descida, não a celebra. O lançamento do EmDash CMS da Cloudflare é uma peça visível da mesma pressão: em propostas portuguesas e brasileiras (pt-BR em briefings, pt-PT no site) a pergunta «há alternativa mais moderna?» já aparece em RFPs de e-commerce.

O que se segue é o roteiro confrontado com o núcleo, versão a versão. Onde a funcionalidade é real, tem o nome da função. Onde ainda é discussão, diz-se.

#O WordPress tem colaboração em tempo real em 2026

O roteiro em wordpress.org nomeia quatro fases Gutenberg: Easier Editing, Customization, Collaboration, Multilingual. A fase 3 é a ativa e está parcialmente entregue.

Notes saíram. Comentários ao nível do bloco chegaram no WordPress 6.9 a 2 de dezembro de 2025, após um percurso experimental no plugin Gutenberg. Renomeados de «block comments» para Notes para os distinguir de wp_comments dos leitores. A primeira versão cobre adicionar, encadear, resolver e apagar notas no bloco inteiro, não numa seleção dentro dele. Ver ou criar exige a capability edit_post, porque as notas só existem no editor de entradas.

O WordPress 7.1 alargou-as em vez de as substituir: notificações por e-mail para menções em Notes, ligações partilháveis a revisões e uma correção para Notes deixarem de vazar para queries de feeds de comentários. Esse detalhe vale a pena conhecer antes de abrir um ticket: um feed de comentários à medida construído em 6.9 podia ver registos de notas que ninguém pediu.

A colaboração em tempo real não saiu. Chegou ao núcleo como beta e foi retirada. O pedido de testes de 11 de março de 2026 pedia para instalar WordPress 7.0 Beta 1 num servidor alcançável por outra pessoa, ativar «Enable real-time collaboration» em Definições > Escrita e abrir a mesma entrada com duas contas. A 8 de maio de 2026 saiu do 7.0; as razões são a parte útil: superfície de funcionalidade, race conditions, carga de servidor, eficiência de memória e bugs que o fuzz testing continuava a revelar. Também não está ativa no 7.1. A camada de sync baseia-se em Yjs; core/freeform (Classic) está listado como incompatível. A vista versão a versão está no roteiro WordPress 7.1.

A parte que toca no seu código. Os blocos sincronizam pelos atributos, por isso a maioria apoia colaboração por omissão; os que partem são os que guardam estado do editor noutro sítio. Declare o campo em block.json com tipo, leia de attributes, escreva com setAttributes na alteração, em vez de o estacionar num React useState dentro de edit() até ao blur. Isso já compensa em undo, revisões e autosave e decide se o bloco sobrevive se a colaboração voltar.

#Quando terá o WordPress multilingue no núcleo

O roteiro descreve a fase 4 numa linha: implementação no núcleo para sites multilingues. Não há esquema, API, dev note nem data. O Advanced Administration Handbook continua a documentar WordPress multilingue como algo resolvido com plugin.

A sequência é a parte interessante e está dita abertamente nas atualizações da fase 3: a infraestrutura de colaboração tem de estar assentada antes de se desenhar o multilingue, porque ambos precisam da mesma resposta a como um conteúdo lógico mapeia para várias versões guardadas. Fazer o contrário seria resolver isso duas vezes. A fase 4 não está bloqueada por falta de interesse, está bloqueada porque a fase 3 está um ciclo de release atrás da própria beta.

Em projetos pt-PT / en (e por vezes es) com WPML ou Polylang, o que faz sentido enquanto se espera:

• Manter a identidade de tradução em post meta ou taxonomia, não embutida na lógica do template.
• Não guardar uma string de locale dentro de atributos de bloco. Um bloco com pt_PT hardcodado torna-se conteúdo inválido no dia em que a camada de tradução se mover.
• Tratar WPML e Polylang como dependências de longo prazo, não como provisórios. Vão sobreviver a este item do roteiro.

#O Data Liberation consegue migrar um site para WordPress

A página do projeto em wordpress.org/data-liberation foi publicada a 6 de dezembro de 2023 e nomeia cinco fases de forma explícita:

As fases 4 e 5, as que as pessoas querem dizer com «migração num clique», não começaram.

O que existe é mais estreito e mais útil do que o slogan. O plugin data liberation agent, open source da Studio by WordPress.com, traz extratores para plataformas nomeadas: GoDaddy Websites and Marketing, Hostinger Website Builder, HubSpot, Shopify, Squarespace, Webflow, Weebly e Wix. São scrapers para construtores concretos, não um formato universal. Em paralelo, a equipa Playground constrói novos importadores PHP como parsers em streaming, e o passo de blueprint importWxr pode agora passar pelo importador Data Liberation em vez do legado.

Leitura prática para agências: nas oito plataformas da lista há ferramenta real a testar antes de orçamentar migração manual de conteúdo. Em tudo o resto, o formato de exportação do núcleo continua a ser WXR, e o WXR continua a não transportar ficheiros multimédia, definições de plugins nem a biblioteca de padrões de blocos. Orçamente em conformidade quando uma loja portuguesa sai do Shopify ou do Wix.

#O que mudou no admin do WordPress 7.1

Primeiro, uma correção que circula muito. O MP6 não chegou em 2012. Foi um feature plugin proposto em outubro de 2013 e integrado no WordPress 3.8, lançado a 12 de dezembro de 2013. E o admin não ficou congelado: o 7.1 alterou-o.

O que saiu no WordPress 7.1 a 19 de agosto de 2026 é a base de um sistema de design, descrita na dev note do core de 31 de julho de 2026. Dois recursos ficam registados por omissão:

• Uma folha de estilos wp-theme com tokens de design semânticos como CSS custom properties, no padrão --wpds-color-background-surface-neutral-strong, --wpds-border-radius-lg, --wpds-dimension-padding-2xl.
• Um handle de script wp-theme que exporta um componente React ThemeProvider de @wordpress/theme.

O ThemeProvider aceita cinco props: color.primary e color.background como cores seed, cursor.control, cornerRadius com os presets none, subtle, moderate e pronounced, e isRoot para theming na raiz do documento.

Três outras alterações de admin no 7.1 que aparecem no tracker antes de aparecerem num post:

1. A prop __next40pxDefaultSize terminou a viagem: a partir do 7.1 é um no-op, ainda aceite e ignorada em vez de removida. Os controlos de formulário renderizam a 40px de qualquer forma, por isso ecrãs de admin afinados ao default antigo deslocam-se.
2. wp_get_tooltip() e wp_get_toggletip() dão tooltips acessíveis como função do núcleo em vez de reimplementação por plugin.
3. O cabeçalho de linha da tabela de entradas passou da coluna da checkbox para a do título, uma correção de acessibilidade que muda o que o leitor de ecrã anuncia por linha.

O que o 7.1 não é: substituto do wp-admin, dashboard de cliente ou entrega white-label. Tokens e um provider são a abertura, não o redesign acabado. Planeie o admin voltado ao cliente assumindo que essa camada continua a ser sua.

#O que um programador WordPress deve aprender em 2026

Três coisas são concretas o suficiente para justificar tempo de estudo; uma afirmação comum não é.

Abilities API, desde o 6.9. O registo que permite a plugins, núcleo e agentes externos descobrir o que um site consegue fazer. Hook wp_abilities_api_init, chamada a wp_register_ability() com um nome namespaced como my-plugin/my-ability, callback de execução e de permissão com esquemas tipados de entrada e saída. As abilities são privadas por omissão: show_in_rest é false até o definir. O WordPress 7.0 acrescentou o correspondente do lado do cliente. O núcleo regista três abilities só de leitura em wp-includes/abilities.php: core/get-site-info, core/get-user-info e core/get-environment-info. Confirme os nomes no trunk antes de codificar contra eles.

AI Client, integrado no 7.0. Infraestrutura agnóstica de provider: PHP prompt builder, abstração de provider e modelo, armazenamento partilhado de credenciais, REST e API JavaScript. O SDK fica em wp-includes/php-ai-client/; a cola WordPress em wp-includes/ai-client/. O ecrã Connectors: wp-admin/options-connectors.php. Consequência prática: deixa de empacotar chave de API e cliente HTTP em cada plugin que quer um modelo. O que o núcleo não inclui é geração de páginas a partir de uma descrição, otimização de conteúdo ou atualizações preditivas. Isso continua a ser território de plugins.

React, em especial a camada de dados do editor. JSX é a metade fácil. A metade que decide se o seu bloco sobrevive à colaboração e ao novo admin é @wordpress/data, esquemas de atributos em block.json, e agora @wordpress/ui e @wordpress/theme para superfícies de admin que seguem os tokens do núcleo.

E a afirmação a largar: não existe uma «API canónica» que torne o headless WordPress fácil. Existe a REST API, o WPGraphQL como plugin e agora a Abilities API para chamadas voltadas a agentes. Três contratos diferentes com três histórias de manutenção, e a escolha continua a ser uma decisão de arquitetura sua.

#Como o roteiro WordPress afeta os plugins

O roteiro não toca só no núcleo, muda também a forma como os plugins se apoiam na plataforma. Convém separar o que já exige ação do que continua condicional.

#É preciso adaptar os plugins à colaboração em tempo real

Enquanto a edição simultânea não voltar ao núcleo, nada o obriga a refazer um plugin. O que pode fazer hoje, porque compensa também sem colaboração, é pôr editores de tabelas, construtores de formulários e ferramentas de SEO a guardar o estado nos atributos do bloco e não em estado local de React. É o mesmo requisito que o pedido de testes do 7.0 Beta 1 fixou, e é também o que faz o anular e as revisões funcionarem bem.

#É preciso adaptar os plugins ao multilingue do núcleo

Aqui não há nada a preparar contra uma API, porque não há API. O único passo concreto é não se amarrar: mantenha a identidade de tradução em meta ou numa taxonomia e não ponha strings de idioma dentro dos atributos dos blocos. Qualquer lista de APIs de tradução normalizadas do núcleo é, por agora, invenção.

#O que aconteceu à colaboração em tempo real depois do WordPress 7.0

A remoção não acabou com o trabalho, tirou-o do ramo da versão. A 3 de junho de 2026 a equipa do núcleo anunciou um programa de testes de edição colaborativa para o 7.1: os utilizadores pioneiros correm a versão mais recente do plugin Gutenberg, ativam a colaboração em Definições > Escrita e reportam no canal de Slack #collaborative-editing-outreach durante o ciclo do 7.1, pelo menos até 18 de agosto de 2026. A publicação da equipa de Hosting do mesmo dia pediu aos fornecedores de alojamento que convidassem os seus próprios clientes, para a funcionalidade ser testada em muitas configurações de servidor e não numa só. Isso bate certo com as razões da remoção: a carga de servidor e a eficiência de memória dependem do alojamento.

Dois repositórios mostram para onde foi a engenharia a seguir. O Gutenberg Sync Engines, criado a 10 de agosto de 2026, descreve-se como uma comparação de possíveis motores de sincronização e transportes para a colaboração em tempo real do Gutenberg. O feature plugin Presence API, listado em wordpress.org desde 21 de julho de 2026 e que exige o WordPress 7.0, regista que utilizadores têm sessão iniciada, em que ecrã do admin estão e que entradas estão a editar. Os dados passam pela Heartbeat API para uma tabela própria, wp_presence, com um TTL de 150 segundos, e os bloqueios de entrada ficam lá em vez de em post meta, pelo que manter um bloqueio deixa de tornar obsoletas as queries de entradas em cache. A versão 0.18.1 saiu a 13 de outubro de 2026.

O resumo da reunião da Presence API de 12 de outubro de 2026 fixa a fasquia para uma proposta ao núcleo: três projetos externos a usar a API e oito semanas sem uma alteração incompatível, contadas a partir da versão 0.17.0, o que dá 3 de dezembro como data mais cedo. Os bloqueios de entrada são o primeiro consumidor e o Gutenberg Sync Engines o primeiro projeto externo. Nenhuma versão do WordPress é indicada como alvo. Se o seu plugin lê ou escreve o post meta _edit_lock, é este o trabalho a acompanhar, porque os bloqueios de entrada são exatamente o que o plugin transfere.

#Quando sai o WordPress 7.2

O apelo a voluntários de 12 de agosto de 2026, publicado por Jeffrey Paul, propõe 9 de dezembro de 2026 como data de lançamento final e diz que é flexível. O desenvolvimento alfa começou a 10 de agosto de 2026. Os marcos propostos avançam semana a semana:

A página do roteiro, modificada pela última vez a 20 de agosto de 2026, indica 10 de dezembro de 2026 para o 7.2 e avisa que as datas projetadas servem apenas para planeamento aproximado. Diz também que as funcionalidades novas ficam congeladas um mês antes de cada versão. O apelo enumera funções (release lead, coordenação da versão, tech leads, triage lead, test lead), mas nenhuma funcionalidade. A meio de outubro não há âmbito publicado para o 7.2, por isso tudo o que for apresentado como novidade do 7.2 antes da Beta 1 é palpite. Para planear numa agência, as datas úteis são as release candidates: teste os sites de clientes e os blocos próprios contra a RC1 na semana de 17 de novembro, não no dia do lançamento.

#Como preparar plugins e blocos para o WordPress 7.1

Sem adivinhar o futuro, isto é o que pode fazer com o que já foi publicado:

1. Declare os atributos de bloco em block.json com tipo e escreva-os com setAttributes. É a condição que o próprio pedido de testes fixou para um bloco sincronizar.
2. Registe as suas capacidades com a Abilities API em vez de inventar um endpoint REST próprio para um agente chamar, e deixe show_in_rest em false até saber quem consome essa ability.
3. Use os tokens --wpds- nos seus ecrãs de admin, em vez de fixar à mão cores e raios que vão desalinhar na versão seguinte.
4. Reveja o espaçamento dos seus ecrãs de admin face aos controlos de 40px, porque __next40pxDefaultSize já não altera nada.

O WordPress não abranda, mas também não sprinta: uma funcionalidade de colaboração entregue, uma adiada, redesign do admin na fase dos tokens e uma fase multilingue que ainda não começou. Se quiser essa leitura aplicada a um stack concreto, fazemos exatamente este tipo de auditoria como programadores WordPress.