Atualização, . O Gutenberg 24.3 já está disponível (plugin datado de 28 de outubro; artigo What’s new publicado a 2 de novembro). Mudanças editoriais que importam num site em produção: formatar texto numa seleção que atravessa vários blocos, reações emoji nas notas (coração, festa, olhos e mais algumas), Media inserter reconstruído na grelha DataViews com pré-visualizações de ficheiros que não são imagens, e avisos de falha de gravação/autosave com detalhes, estado HTTP quando existe, ação de copiar e contagem decrescente até à próxima tentativa. A versão inclui também as correções de segurança do WordPress 7.1.4, por isso atualize o plugin Gutenberg se o tiver em produção. O React 19 continua ligado por predefinição como no 24.2; a checklist de testes abaixo mantém-se.
O Gutenberg 24.2 saiu a 14 de outubro de 2026. Para as redações traz notas na margem do editor, uma única pesquisa de ligações nos menus e ordenação de galerias. Para os autores de plugins e temas há uma mudança mais importante: o plugin Gutenberg carrega agora por predefinição o React 19 em vez do React 18. Quem tem no site blocos próprios ou páginas de definições escritas em React deve verificá-los agora, antes de o React 19 chegar ao próprio WordPress.
Este texto baseia-se no artigo oficial sobre a versão 24.2, na lista de alterações no repositório do Gutenberg, em dois artigos do Make WordPress Core sobre o React 19 e no guia de migração para o React 19.
O que há de novo no Gutenberg 24.2?
A versão tem cinco alterações principais:
- notas levadas para a margem ao lado do conteúdo,
- uma só pesquisa para todos os tipos de ligação no bloco de navegação,
- ordenação e um filtro duotone comum no bloco de galeria,
- mais blocos com as mesmas ferramentas de design (cerca de 80 alterações no código),
- React 19 ativado por predefinição e dois acréscimos na Interactivity API.
A isto juntam-se mais de 60 correções de erros e alterações de acessibilidade e desempenho. Algumas mudanças menores contam no trabalho do dia a dia. O controlo deslizante do número de colunas no bloco de colunas desapareceu: uma coluna acrescenta-se com o botão mais ao lado do botão do bloco na barra de ferramentas e remove-se como qualquer outro bloco. Depois de recortar uma imagem, o editor de imagens permite voltar ao original sem entrar na biblioteca multimédia. O campo de autor do artigo tem sempre pesquisa e procura utilizadores do lado do servidor, por isso em sites com muitas contas a pessoa certa aparece na lista.
O Gutenberg 24.2 corrige também os endereços dos artigos novos. Até agora, um artigo novo podia ser publicado com o slug auto-draft se alguém clicasse no campo do slug antes da publicação. Na 24.2 isso já não acontece. Se num site com o plugin Gutenberg viu artigos com esse endereço, era esta a causa.
Os painéis acrescentados por plugins passaram, no menu de opções do editor, para um submenu de painéis, ao lado dos novos submenus de aspeto e de notas. Os botões fixados desses painéis na barra de ferramentas ficam onde estavam. Os autores de plugins com painel lateral próprio devem confirmar se as instruções para os utilizadores ainda indicam o sítio certo.
O React 19 já está no WordPress?
Não. O WordPress 7.1 funciona com o React 18.3. Em julho de 2026, Jarda Snajdr explicou no Make WordPress Core porque é que a passagem para o React 19 saiu da 7.1: depois de uma curta ativação no plugin Gutenberg surgiram incompatibilidades inesperadas entre a versão antiga e a nova do React e na forma como os plugins usam o React, e a mudança teve de ser revertida.
«Vai ser preciso um período de testes mais longo, em que corrigimos e afinamos a camada de compatibilidade que permite aos plugins existentes funcionar sem problemas.»
Fonte: Jarda Snajdr, Make WordPress Core, 24 de julho de 2026, tradução própria
Desde a versão 23.4, o plugin Gutenberg tinha uma experiência React 19 que era preciso ativar à mão. O Gutenberg 24.2 inverte essa definição: a experiência vem ativada por predefinição. O WordPress sozinho, sem o plugin Gutenberg, continua a carregar o React 18.3.
O plano de lançamento do WordPress 7.2 aponta a saída para o início de dezembro de 2026. Sobre o React 19 diz que os tipos, as dependências e as correções de renderização no Gutenberg estão na maioria prontos, mas que a passagem completa na 7.2 é pouco provável. Para as equipas que mantêm sites, isto quer dizer que o React 19 no plugin Gutenberg é agora um período de testes, e não uma data de entrada no WordPress. O contexto da decisão do verão está no artigo sobre o plano do WordPress 7.1.
Quando é que o Gutenberg 24.2 deixa o site no React 18?
Segundo o artigo sobre a versão, os sites com o plugin carregam o React 19 para os scripts react e react-dom, a menos que esteja ativo um tema ou plugin conhecido por problemas de compatibilidade. Nesse caso o site fica no React 18. A lista desses temas e plugins começou com problemas observados no WordPress.com e foi alargada nesta versão (alteração #84607).
Daqui resultam duas coisas práticas. Primeiro, a mesma versão do Gutenberg pode carregar versões diferentes do React em dois sites, conforme o conjunto de plugins. Ao testar um bloco, verifique que versão o editor recebeu de facto. Na consola do navegador, no ecrã do editor, basta escrever React.version, porque o WordPress disponibiliza o React como variável global. Segundo, a ausência de problemas num site que ficou na lista de exceções não prova nada. Nesse caso o bloco foi testado com o React 18.
A lista de exceções é uma solução transitória. Se o seu plugin está nela, o problema volta no dia em que o React 19 entrar no WordPress.
Como desativar o React 19 no Gutenberg?
A equipa do Gutenberg diz claramente o que fazer quando algo deixa de funcionar:
«Se mantém um plugin ou tema que usa React, teste-o com o Gutenberg 24.2 e comunique qualquer problema que encontre. Se algo deixar de funcionar no site, desative o React 19 em Gutenberg > Experiments.»
Fonte: What’s new in Gutenberg 24.2, Make WordPress Core, 14 de outubro de 2026, tradução própria
No painel do WordPress é o menu Gutenberg, a página de experiências, a caixa de verificação junto ao React 19. O artigo de julho sobre a experiência descrevia a mesma página como disponível nas definições do Gutenberg. A desativação aplica-se ao site inteiro, por isso é uma solução de emergência para a produção, e não uma forma de corrigir o bloco. Um bloco que só funciona com o React 19 desativado tem de ser corrigido antes da versão do WordPress com o React 19.
A segunda possibilidade é não instalar o plugin Gutenberg em produção. Um site sem este plugin recebe o React do WordPress, ou seja, hoje o 18.3. O plugin Gutenberg instala-se em produção quando o cliente precisa de funções que ainda não existem no WordPress. Se não precisa, teste o React 19 numa cópia do site.
Que API removeu o React 19 e o que é que isso estraga nos blocos WordPress?
O artigo de julho no Make WordPress Core aponta duas fontes típicas de avarias em plugins. A segunda são funções antigas do React, obsoletas há pelo menos seis anos e removidas no React 19. A camada de compatibilidade do Gutenberg repõe algumas, mas não todas. O guia de migração para o React 19 dá a lista completa, com a data a partir da qual cada API ficou obsoleta:
| API removida | Obsoleta desde | Substituição |
|---|---|---|
propTypes em componentes funcionais | abril de 2017 (15.5.0) | TypeScript ou outro sistema de tipos; as verificações são agora ignoradas em silêncio |
defaultProps em componentes funcionais | juntamente com propTypes | valores predefinidos dos parâmetros da função |
String refs (ref="input") | março de 2018 (16.3.0) | refs como função ou useRef |
Legacy context (contextTypes, getChildContext) | outubro de 2018 (16.6.0) | contextType e createContext |
ReactDOM.findDOMNode | outubro de 2018 (16.6.0) | refs para elementos DOM |
| Fábricas no estilo module pattern | agosto de 2019 (16.9.0) | componentes normais |
React.createFactory | fevereiro de 2020 (16.13.0) | JSX |
ReactDOM.render e ReactDOM.hydrate | março de 2022 (18.0.0) | createRoot e hydrateRoot |
ReactDOM.unmountComponentAtNode | março de 2022 (18.0.0) | root.unmount() |
Os componentes de classe mantêm defaultProps, porque para as classes não há equivalente na sintaxe ES6. Foram também removidos react-dom/test-utils e react-test-renderer/shallow, o que afeta os testes unitários, e não o bloco em si.
No código WordPress, o caso mais comum é um render que monta uma página de definições ou um widget do painel de administração. Plugins mais antigos importam-no de @wordpress/element, que por baixo chama ReactDOM.render. As versões mais recentes deste pacote exportam createRoot, e é essa função que deve ser usada:
import { createRoot } from '@wordpress/element';
const container = document.getElementById( 'my-plugin-settings' );
if ( container ) {
createRoot( container ).render( <SettingsPage /> );
}O segundo caso frequente são os defaultProps num componente funcional do editor de blocos. No React 19 os valores predefinidos simplesmente não são definidos, por isso o componente recebe undefined e normalmente não lança erro: mostra um painel vazio ou calcula mal um valor. Este erro passa facilmente despercebido, porque a consola fica calada.
O guia indica um conjunto pronto de correções automáticas: npx codemod@latest react/19/migration-recipe. Corra-o num ramo à parte e leia cada alteração, porque não conhece as particularidades dos pacotes @wordpress/*.
O React 18.3, com que funciona o WordPress 7.1, é segundo a equipa do React idêntico ao 18.2, mas acrescenta avisos sobre API obsoletas e outras alterações necessárias no React 19. Se na consola do editor de um WordPress 7.1 normal vê avisos com o nome do seu plugin, aí tem uma lista pronta do que corrigir.
Como verificar se um plugin inclui a sua própria cópia do React?
A primeira fonte de avarias do artigo de julho é mais frequente e mais difícil de ver no código-fonte, porque só aparece no ficheiro JavaScript compilado.
«Se toda a gente compilasse corretamente o seu JavaScript, a maior parte dos problemas de compatibilidade nem sequer existiria.»
Fonte: Jarda Snajdr, Make WordPress Core, 24 de julho de 2026, tradução própria
Trata-se do código de react/jsx-runtime incluído diretamente no ficheiro do plugin em vez do script react-jsx-runtime que o WordPress fornece. Nesse caso funcionam lado a lado no site o React 18 do pacote do plugin e o React 19 do WordPress, e as estruturas de dados criadas pela versão antiga chegam à nova. O componente parece correto no código, mas no editor não monta ou lança um erro de elemento inválido.
A verificação leva alguns minutos por plugin:
- Abra o ficheiro
*.asset.phpao lado do script compilado (por exemplobuild/index.asset.php). Se o código usa JSX,react-jsx-runtimedeve constar da lista de dependências. - Procure nos ficheiros compilados código do próprio React, por exemplo
grep -l "react.element" build/*.js. Um resultado no ficheiro do plugin é sinal de que parte do React está no pacote. É motivo para verificar a configuração, não uma sentença. - Verifique se a configuração de compilação não contorna o mecanismo que substitui as importações de
reacte@wordpress/*pelos scripts do WordPress. Isto acontece sobretudo com um webpack próprio ou com Vite em vez de@wordpress/scripts. - Para plugins comprados a um fornecedor externo, sem acesso ao código-fonte, resta o teste no editor da secção seguinte e um aviso ao autor.
A equipa do Gutenberg está a trabalhar na deteção automática destes problemas no plugin Plugin Check. Até isso funcionar, a verificação fica a cargo do autor do plugin.
Como testar os blocos próprios com o React 19 numa cópia do site?
O artigo de julho define o teste de compatibilidade de forma simples: usar todas as partes do plugin que recorrem ao React, ou seja, normalmente blocos, extensões do editor e páginas próprias no painel de administração, e confirmar que a interface não está estragada e que a consola do navegador não mostra erros. Numa cópia de testes do site faz-se assim:
- Faça uma cópia do site com a mesma versão de PHP, WordPress e plugins da produção. Se a cópia contém dados de clientes da loja, anonimize-os antes de copiar.
- Instale o Gutenberg na versão do lançamento:
wp plugin install gutenberg --version=24.2.0 --activate. - No
wp-config.phpda cópia definadefine( 'SCRIPT_DEBUG', true );. O WordPress carrega então as versões não comprimidas dos scripts, incluindo a versão de desenvolvimento do React, que mostra avisos completos em vez de códigos de erro abreviados. - No editor, escreva
React.versionna consola e confirme que é a 19. Se aparece 18, algum plugin ativo está na lista de exceções e o teste tem de ser repetido sem ele. - Insira cada bloco próprio num artigo novo, mude cada definição no painel do bloco, grave, recarregue o editor e verifique se o bloco não mostra a mensagem de conteúdo inválido.
- Abra cada página de definições do plugin e cada painel lateral que o plugin acrescenta ao editor. Depois da 24.2 estes painéis estão no submenu de painéis do menu de opções.
- Por fim, veja os artigos gravados no site. Os blocos dinâmicos são renderizados pelo PHP, por isso aí o React não conta, mas os blocos com Interactivity API e scripts na página têm de ser experimentados um a um.
A lista do ponto 5 deve incluir os blocos que o cliente usa de facto, e não só os que estão registados. Se o site tem uma biblioteca de várias dezenas de blocos, comece pelos da página inicial, da ficha de produto e dos formulários. As regras gerais do trabalho numa cópia de testes estão no nosso guia sobre publicar alterações através de uma cópia do site, e para verificar depressa um bloco numa instalação limpa basta o WordPress Playground.
Cada problema encontrado deve ser comunicado com o número da versão do Gutenberg, a versão do React indicada na consola e o texto do erro. A equipa pede os relatórios no repositório do Gutenberg no GitHub e, para plugins externos, junto dos respetivos autores.
Como funcionam as notas na margem do editor?
Até agora, as notas flutuantes e o painel de definições não podiam estar abertos ao mesmo tempo, e a coluna de notas tirava espaço ao conteúdo. Na 24.2 o editor reserva uma margem ao lado da área de edição e mostra lá as notas, que assim continuam visíveis quando se muda de bloco e de definições do artigo.
Com uma janela mais estreita, cada conversa recolhe-se ao avatar do autor, e um clique no avatar volta a abri-la. O novo submenu de notas no menu de opções permite expandi-las, minimizá-las ou ocultá-las, e o editor memoriza a escolha. Três alterações reduzem o risco de perder trabalho: a eliminação de uma nota pode ser anulada, uma nota ou resposta por enviar não desaparece quando se seleciona outro bloco, e as notas deslocam-se juntamente com o conteúdo.
Para uma redação que discute os textos no editor, isto significa menos troca de painéis. Para os autores de blocos há uma consequência prática: a área de edição tem agora menos espaço quando as notas estão visíveis. Vale a pena ver com as notas abertas os blocos com largura fixa ou com disposição própria no editor.
O plano do WordPress 7.2 anuncia mais mudanças nas notas: um modo de sugestões, em que uma alteração de texto proposta pode ser aceite ou rejeitada, reações com emoji e um botão próprio para acrescentar notas na barra de ferramentas do bloco.
O que mudou no bloco de navegação e na galeria?
Acrescentar ao menu algo que não fosse uma página exigia saber que bloco usar, por exemplo a ligação para uma categoria ou para uma etiqueta, e só depois pesquisar dentro dele. Agora a pesquisa de ligações no bloco de navegação procura todos os tipos de conteúdo ao mesmo tempo e mostra o tipo de cada resultado. Uma ligação existente pode passar de categoria para página sem a apagar e voltar a criar. A mesma pesquisa mostra também os blocos que o menu aceita, por isso escrever Home encontra o bloco de ligação para a página inicial.
Os resultados são agora ordenados por tipo: artigos e páginas antes de categorias, etiquetas e multimédia. Esta ordem vale em todas as pesquisas de ligações no editor, não só nos menus. Em sites grandes, as etiquetas e os anexos deixam de empurrar o artigo procurado para fora da lista de resultados. Para os autores de plugins que acrescentam tipos de conteúdo próprios à pesquisa de ligações, é motivo para verificar onde vão parar os seus resultados.
O Global Styles pode agora estilizar os estados das ligações da navegação (passar o cursor, foco, foco visível, ativo), por enquanto só na tipografia. Os temas que faziam isto com CSS próprio podem passar parte das regras para o theme.json, mas convém primeiro verificar qual das regras prevalece.
No bloco de galeria, a opção de ordenação funciona agora também em galerias com imagens escolhidas à mão. A ordenação das mais recentes, das mais antigas e alfabética nos dois sentidos organiza as imagens uma vez, e depois continua a ser possível arrastá-las. A opção aleatória está no mesmo sítio e baralha as imagens a cada carregamento da página. Para sites com cache de páginas inteiras isto é importante: a ordem aleatória só muda quando a cache é renovada, não a cada visita.
A galeria passou também a suportar duotone. Um único filtro dá cor a todas as imagens da galeria, definido no bloco ou, para todas as galerias do site, no Global Styles. O duotone definido numa imagem individual tem prioridade sobre a definição da galeria. O duotone chegou também aos blocos de multimédia e texto e de vídeo. Nas fotografias de produtos, verifique se um filtro definido globalmente não altera as cores onde o cliente não as quer alteradas.
O que há de novo na Interactivity API?
A nova diretiva data-wp-html mostra HTML a partir do estado, tal como data-wp-text mostra texto. Só aceita valores marcados como fiáveis com asDangerousHTML(). Exemplo do artigo sobre a versão:
import { asDangerousHTML, store } from '@wordpress/interactivity';
store( 'myPlugin', {
state: {
get description() {
return asDangerousHTML(
'<p>A <strong>formatted</strong> description.</p>'
);
},
},
} );<div data-wp-interactive="myPlugin">
<article data-wp-html="state.description">
<p>Loading description.</p>
</article>
</div>O plano da 7.2 explica que a primeira versão só mostra valores marcados explicitamente como fiáveis pelo código da aplicação, e que o suporte a texto simples limpo chega mais tarde. Não passe para asDangerousHTML() nada que venha do utilizador ou de atributos de bloco sem limpeza do lado do PHP. Na mesma versão, a documentação do Gutenberg ganhou a nota de que os atributos dos blocos e os valores do Global Styles devem ser tratados como não fiáveis no momento da renderização. Se faz uma revisão de segurança de um plugin, acrescente a pesquisa por asDangerousHTML à lista de coisas que uma pessoa lê.
O router disponibiliza agora state.navigating e state.initiator, por isso o bloco sabe que há uma navegação do lado do cliente em curso e que bloco a iniciou. Segundo o plano da 7.2, isto substitui o par obsoleto state.navigation.hasStarted e state.navigation.hasFinished. Vale a pena reescrever os blocos com indicador de carregamento próprio na navegação para os novos campos, antes de os antigos serem removidos.
As notas do Gutenberg já são colaboração em tempo real?
Não. As notas são comentários a blocos, lidos e acrescentados a qualquer momento. A colaboração em tempo real não está no plano do WordPress 7.2. O plano diz que, como na 7.1, é preciso mais tempo para as decisões de arquitetura, por isso o tema ficou de fora, em vez de o incluir e depois o retirar.
O trabalho continua no plugin experimental gutenberg-sync-engines, descrito no guia sobre motores de sincronização de 14 de outubro. Estão a ser testados três motores: yjs-server, DE-RTC e intent-log. O plugin exige o WordPress 7.0 ou mais recente e o plugin Presence API, e inclui a sua própria cópia ligeiramente alterada do Gutenberg. Por isso não funciona ao lado do plugin Gutenberg ativo, ou seja, o teste do React 19 e o teste da colaboração ao vivo não podem ser feitos na mesma cópia do site.
Debaixo do guia, o autor da biblioteca Yjs, Kevin Jahns, chamou a atenção para o custo do servidor:
«A edição em tempo real gera imensas mensagens pequenas. Se cada uma delas tiver de iniciar um processo PHP, carregar o documento partilhado, validá-lo, fundi-lo e gravá-lo de volta na base de dados, isso representa uma grande sobrecarga de comunicação, processamento e base de dados.»
Fonte: comentário de Kevin Jahns ao guia sobre motores de sincronização, 15 de outubro de 2026, tradução própria
Para os donos de sites em alojamento partilhado barato, é um sinal de que a colaboração ao vivo pode um dia exigir outro alojamento.
Atualização, . O plugin de funcionalidade Presence API chegou à 0.20.0 a 1 de novembro (listagem no WordPress.org; cerca de 10 instalações ativas). O resumo da reunião de 26 de outubro, publicado a 1 de novembro, diz que a checklist de merge ainda precisa de testes de utilizadores externos e de uma auditoria de segurança fora do repositório, e que 3 de dezembro é a data mais cedo para uma proposta inicial no Trac (oito semanas sem alteração de API incompatível desde a 0.17.0). As versões 0.18.4 a 0.20.0 acrescentam uma correção de logout para bloqueios de artigos, ganchos keepalive/roomChanged para relays push e wp_presence_admin_state(), para um relay escrever as mesmas linhas que o Heartbeat. O Presence continua a ser dependência do gutenberg-sync-engines, não um substituto das notas em 24.2/24.3, e ainda não traz coedição em tempo real no WordPress 7.2.
Quem deve testar os blocos antes do WordPress 7.2?
O teste faz sentido para qualquer site com blocos próprios, extensões do editor ou páginas de definições em React, e para os autores de plugins e temas que têm esses elementos. Um site feito só com blocos do WordPress e plugins populares com suporte ativo depende de os respetivos autores fazerem o teste. A equipa do Gutenberg pede-o precisamente agora.
Se não tem na equipa alguém que reveja os ficheiros compilados e experimente os blocos numa cópia do site, um programador WordPress faz isso numa única encomenda, e na manutenção contínua do site o teste das novas versões do Gutenberg antes de atualizar a produção faz parte do trabalho. Porque é que esta revisão exige uma pessoa, explicamos também no artigo sobre o recrutamento de programadores que trabalham com IA.
No pedido, indique a versão do WordPress e do PHP, a lista de plugins com blocos próprios, se há o plugin Gutenberg em produção e se tem uma cópia de testes do site. O orçamento é individual, depois de definido o âmbito. O formulário está na página de contacto.
