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.
Fase 3: colaboração, o que saiu e o que não saiu
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.
Fase 4: multilingue, ainda um nome numa lista
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_PThardcodado 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.
Data Liberation: cinco fases e as ferramentas que existem agora
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:
| Fase | Nome | Estado |
|---|---|---|
| 1 | Migration Guides | Em curso |
| 2 | Importing and Exporting Structured Data | Em curso |
| 3 | Liberating Data From Closed Platforms | Iniciada |
| 4 | Direct WordPress-to-WordPress Synchronization | Futuro |
| 5 | Content Creation Powerhouse | Futuro |
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 redesign do admin: o que o 7.1 realmente deu
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-themecom 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-themeque exporta um componente ReactThemeProviderde@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:
- A prop
__next40pxDefaultSizeterminou 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. wp_get_tooltip()ewp_get_toggletip()dão tooltips acessíveis como função do núcleo em vez de reimplementação por plugin.- O cabeçalho de linha da tabela de entradas passou da coluna da checkbox para a do título - 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 deve aprender
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.
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 - a escolha continua a ser uma decisão de arquitetura sua.
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.
