Gutenberg 24.2 e React 19: o que testar nos seus blocos custom

O Gutenberg 24.2 é um release de produto pequeno para redacções e um sinal de compatibilidade para autores de blocos. Notas na margem e uma única pesquisa na Navigation reduzem a fricção em content ops. O React 19 activado por predefinição no plugin Gutenberg desloca os testes dos próprios blocos para staging: uma regressão apanhada agora custa menos do que a mesma regressão depois desta linha entrar no core. Esperar pelo anúncio «React 19 no WordPress X.Y» deixa esse erro no site de produção do cliente.

O WordPress 7.1 deixou o React 19 fora do zip após problemas de compatibilidade. O 24.2 não anula essa decisão. O React 19 era, desde a 23.4, uma experiência a activar manualmente no plugin Gutenberg; o 24.2 activa-o por predefinição em todos os sites com o plugin.

Têm blocos próprios ou uma loja FSE e não querem arriscar update em produção? Descrevam o stack (PHP, WP, WooCommerce, lista de plugins do editor) em contacto. Recebem um plano de staging e aceitação, não só o changelog.

#O que há de novo no Gutenberg 24.2

#Notes no editor Gutenberg 24.2

As notes ficam ao lado do conteúdo, não só no painel lateral. Na revisão de um artigo ou landing, o editor comenta junto do bloco concreto. Menos saltos entre o painel e o canvas.

Para agências com content ops a várias pessoas, isso muda o ritmo:

• o copywriter deixa uma nota no H2, não num fio Slack sem contexto,
• o reviewer vê um monte de notas no bloco na segunda ronda,
• o programador de blocos vê que sítios da UI geram mais fricção editorial (muitas vezes blocos próprios com inspector confuso).

Alterações de código continuam a ir para o Linear/Jira. As notes substituem capturas com seta vermelha em PDF na revisão de conteúdo.

#Pesquisa de páginas e categorias no menu Navigation

Adicionar páginas, artigos, categorias e etiquetas à Navigation por um único campo de pesquisa. Ao reconstruir a IA do site (sobretudo multilingue), cai o número de cliques e de erros «adicionei a página errada da lista».

Teste prático de staging: construir um menu com mistura de page + category + custom link, guardar, actualizar o front, verificar o overlay mobile. Regressões na Navigation aparecem muitas vezes só no front, não no editor.

#Gallery no Gutenberg 24.2: ordenação e duotone

O controlo Order by passa a funcionar também em galerias de imagens escolhidas à mão (mais recentes, mais antigas, A a Z, Z a A ou aleatório a cada carregamento da página), e um único filtro duotone tinge todas as imagens de uma galeria, a partir do bloco ou para todo o site em Global Styles. Verifique:

• CSS custom que assume o markup antigo dos filtros,
• blocos filhos / variações Gallery no child theme,
• lazy load e CLS ao mudar a ordem das imagens,
• exportação para AMP ou headless (se servem blocos fora de um tema clássico).

O duotone parece cosmética até partir o contraste em fotos de produto. Em lojas, verifique o Gallery no cartão de produto, não só no blogue.

#React 19 no Gutenberg 24.2 (por predefinição)

Este é o sinal principal para o stack de desenvolvimento. Os sites com o plugin carregam agora o React 19 para os scripts react e react-dom, a menos que esteja activo um tema ou plugin com problemas de compatibilidade conhecidos; esses sites ficam no React 18. Se algo partir, o React 19 pode ser desligado em Gutenberg > Experiments. Para o atributo inert, o novo pacote @wordpress/react-inert-value funciona com o React 18 e com o 19 (artigo de lançamento do 24.2).

Plugins e temas com React no editor devem testar e reportar. Não esperem por uma data no core: o Roadmap to 7.2 considera pouco provável a entrada completa na 7.2, por isso as regressões aparecem primeiro no plugin.

Pontos típicos de ruptura após um upgrade de React:

• react/jsx-runtime empacotado no bundle do plugin em vez do script externo fornecido pelo WordPress (o React 18 e o 19 passam a correr lado a lado),
• APIs removidas no React 19: string refs, default props em componentes de função, legacy context,
• blocos próprios com @wordpress/scripts desactualizado / webpack antigo,
• slot fills e sidebars de plugin que assumem lifecycles antigos,
• peers de React 18 no package.json do plugin do cliente,
• testes E2E Playwright/Cypress ancorados em timings do 18.

Se mantêm uma biblioteca de blocos para vários clientes, um staging com 24.2 num projecto representativo sai mais barato do que cinco hotfixes depois do core.

#Gutenberg 24.2, WordPress 7.1 e React 19 no core

Na 7.1 o React 19 não entrou no core. A decisão foi correcta para a estabilidade do ecossistema e incómoda para equipas que já tinham preparado o upgrade. O Gutenberg 24.2 é o sítio oficial onde o ecossistema pode «sentir» o React 19 sem o forçar em todas as instalações sem o plugin Gutenberg.

Para agências, isso significa três vias:

1. Cliente sem plugin Gutenberg em produção - fica por agora no React do core (linha 7.1). Planeiem testes; não instalem o plugin Gutenberg «porque saiu o 24.2».
2. Cliente com plugin Gutenberg (early features) - o 24.2 é staging obrigatório antes da actualização.
3. Produtos próprios / blocos vendidos a muitos clientes - CI contra Gutenberg 24.2 + matriz PHP/WP.

Não misturem esta mensagem com o WordPress.com Agent: produto diferente, via diferente (Agent e MCP write). O Agent não testa os vossos blocos sob React 19.

#Checklist de testes Gutenberg 24.2 no staging

1. Instale o Gutenberg 24.2 numa cópia de produção (não no live do cliente). Em Gutenberg > Experiments, confirme que o React 19 está activo: com um plugin da lista de incompatíveis o site fica no React 18 e o teste nada diz sobre o 19.
2. Abra um artigo com os vossos blocos custom: insert, duplicate, move, save, preview, undo.
3. Verifique a Navigation: pesquise página e categoria, guarde o menu, actualize front e mobile.
4. Gallery com duotone: active o filtro, mude a ordem, guarde, verifique o front.
5. Notes: adicione uma nota no bloco, recarregue o editor, confirme persistência, apague.
6. Smoke WooCommerce (se for loja): produto, carrinho, checkout, e-mail.
7. Se algo falhar: reprodução mínima + versões PHP / WP / Gutenberg / plugin no issue tracker.

Extensão para biblioteca de blocos (2-4 horas):

• testes unitários/integração do pacote,
• build limpo de assets (npm ci + build),
• verificar peerDependencies de React,
• comparar bundle size antes/depois (a regressão costuma vir com React duplicado).

#O que evitar na actualização do Gutenberg 24.2

• Não activem o plugin Gutenberg numa loja WooCommerce em produção sem plano de rollback e janela de manutenção.
• Não prometam ao cliente «React 19 no core amanhã». O 24.2 é um plugin.
• Não tratem as Notes como sistema de tickets para programadores.
• Não actualizem dez clientes no mesmo dia «porque saiu o 24.2». Um staging representativo, depois a onda.

#Gutenberg 24.2 no retainer de manutenção

Um cliente em retainer «actualizações WordPress» deve receber no relatório mensal uma linha separada: teste Gutenberg 24.2 / via React 19. É uma sessão de compatibilidade de blocos, separada do bump normal do core.

Se o retainer não cobre testes do editor, adicionem change request antes de actualizar o Gutenberg em staging. Barato uma vez. Caro quando o editor cai no dia de publicação da campanha.

#Notes e pesquisa na Navigation no dia a dia editorial

Notes

• uma nota = uma decisão (copy / layout / legal),
• sem fios filosóficos na margem,
• após merge para final: apagar ou arquivar notes para o canvas não parecer graffiti.

Pesquisa na Navigation

• nomes de páginas no admin devem ser únicos e legíveis (duplicados «Oferta» em duas línguas sem prefixo de locale confundem a pesquisa),
• após reconstruir o menu: exportar a estrutura para um documento de IA (mesmo uma tabela Markdown) como fonte de verdade fora do WordPress.

#Testar Gutenberg 24.2 em WooCommerce e membership

Se o site é loja ou membership, não blogue, a checklist geral é curta demais. Acrescentem:

• edição do template Single Product no site editor (não só o produto clássico),
• blocos de carrinho / checkout (blocos Woo vs shortcode legacy),
• blocos de conteúdo restrito (membership, paywall),
• preview como utilizador autenticado vs visitante,
• guardar draft de produto com Gallery + duotone (se o front da loja herda o filtro nas miniaturas da grelha).

Uma regressão React no Inspector do produto pode bloquear uma campanha Black Friday mais do que uma regressão num post de blogue. Priorizem staging da loja antes do blogue da empresa.

#Gutenberg 24.2, child theme, FSE e theme.json

As agências costumam guardar «algumas linhas» em theme.json e style.css do child theme. Depois do 24.2 verifiquem:

• overrides de Gallery e duotone em theme.json,
• CSS a apontar a classes que as Notes ou a nova UI da Navigation possam ter alterado,
• patterns sincronizados que assumem markup antigo.

O FSE não dispensa testes. Pelo contrário: quanto mais UI em JSON e patterns, mais sítios onde o React 19 no editor pode mostrar painel vazio ou spinner infinito. Contexto sobre blocos, padrões e o editor do site: blocos Gutenberg e full site editing.

#Como reportar resultados de testes Gutenberg 24.2 ao cliente

Três parágrafos no e-mail após o teste de staging bastam:

1. O que testámos (lista de blocos + Navigation + Gallery + Notes).
2. O que encontrámos (concreto: «o Inspector do bloco X perde o focus», não «o editor anda estranho»).
3. Decisão: actualizar Gutenberg / esperar fix upstream / ficar no core sem plugin até à data Y.

Os clientes aceitam atraso na actualização quando vêem uma lista de testes. Não aceitam «partiu-se de alguma forma após a actualização» sem essa lista.

#Como reportar um bug no Gutenberg 24.2

Um issue no repositório do plugin ou no Gutenberg GitHub deve ter:

• versões: WP, PHP, Gutenberg, browser,
• passos de reprodução em cinco linhas,
• esperado vs real,
• se falha só com o vosso bloco, ou em Twenty Twenty-Five + blocos core.

«Não funciona connosco» sem reprodução fica no limbo. Uma boa reprodução num ambiente limpo acelera o fix mais do que dez comentários «+1».

#Matriz de testes React 19 para biblioteca de blocos

Um staging num cliente não chega se vendem blocos a várias marcas. Matriz mínima:

Automatização: um workflow CI que instala Gutenberg 24.2, faz build dos blocos, corre smoke Playwright em insert/save. Deixem Navigation, Gallery duotone e Notes manuais - E2E é frágil nas margens da UI.

O custo da matriz recupera-se no segundo cliente com a mesma biblioteca de blocos. Para um landing estático, basta a checklist de 15-30 minutos.

#Regressões típicas após React 19 no Gutenberg

De upgrades de React no ecossistema WordPress (não só 24.2) saem muitas vezes:

• cópia duplicada de React no bundle (sintoma: avisos estranhos na consola, state inconsistente),
• controlos do Inspector que «perdem» o focus a cada keystroke,
• blocos dinâmicos SSR vs client: hydrate mismatch após mudança de markup do Gallery,
• peers antigos de @wordpress/components incompatíveis com o novo React,
• E2E à espera de selectores que as Notes ou a nova pesquisa da Navigation moveram no DOM.

Registem cada regressão com a versão do Gutenberg no título do issue. «O editor está partido» sem número de versão é inútil para bisect.

#Gutenberg Notes e colaboração em tempo real

Na mesma semana, o Make WordPress Core publicou um guia dos motores de sincronização em avaliação para colaboração em tempo real. Num comentário a esse artigo, o autor do Yjs, Kevin Jahns, avisou que a edição em tempo real gera muitíssimas mensagens pequenas e que arrancar um worker PHP para cada uma acrescenta muita sobrecarga. Isto não é o changelog do 24.2, mas contexto para leads técnicos: a via de colaboração multi-pessoa e a via React 19 são riscos separados. As notas na margem resolvem review assíncrono. Não resolvem conflito de dois cursores no mesmo bloco.

Não vendam ao cliente «real-time collaboration» porque saiu o 24.2. Vendam review mais ágil e blocos testados.

#Quando implementar Gutenberg 24.2 em produção

1. Staging verde na checklist e no smoke WooCommerce.
2. Janela de manutenção acordada (não sexta depois das 16:00 numa loja).
3. Rollback: zip anterior do Gutenberg + backup da DB de antes da actualização.
4. Monitorização 24-48 h: erros JS no editor, tickets de publicação, falhas de checkout.

Se o cliente tem auto-update de plugins, desactivem o auto-update do Gutenberg até ao staging verde. O Gutenberg não é «mais um plugin de SEO».

#Release notes do plugin de blocos após Gutenberg 24.2

Se vendem blocos próprios como plugin:

• linha no changelog «tested with Gutenberg 24.2 (React 19 default)»,
• no readme: versão mínima de @wordpress/scripts / toolchain de build,
• no CI: job gutenberg-next ao lado de wordpress-stable,
• na policy de suporte: «relatos sem número de Gutenberg fecham-se com pedido de complemento».

Clientes enterprise lêem release notes. Uma linha sobre o 24.2 constrói mais confiança do que um vago «improved compatibility».

#Duotone da Gallery e design system da marca

O duotone no Gallery é conveniente para a redacção e perigoso para uma marca com design system rigoroso. Se o cliente tem filtros e tokens de cor definidos:

• desactivem duotone em patterns de produto,
• deixem-no no blogue / social proof,
• registem a regra nas Guidelines de conteúdo (não confundir com Guidelines do WordPress.com Agent).

Agent e Gutenberg são produtos separados, mas o mesmo problema: a ferramenta dá à redacção poder que o brand guide não previu. A ownership do design system fica na agência.

#Porque o WordPress 7.1 adiou o React 19

Factos do verão de 2026 (detalhe na roadmap 7.1): o upgrade do React 18 para o 19 saiu da 7.1 depois de um breve ensaio no Gutenberg ter revelado incompatibilidades inesperadas entre as duas versões do React e na forma como os plugins usam o React. No artigo do Make Core de 24 de Julho de 2026, Jarda Snajdr escreveu que é preciso um período de testes considerável para afinar a camada de compatibilidade. O 24.2 é a consequência dessa prudência: primeiro plugin Gutenberg, depois eventualmente o core.

Para leads: não a narrativa «a Automattic atrasa»; sim «têm uma janela de testes que têm de usar». Agências que em agosto adiaram a preparação «porque a 7.1 sem React 19» recebem em Outubro uma segunda oportunidade com o 24.2. Uma terceira janela conveniente antes do core pode não existir.

#Aceitar blocos de freelancers sob Gutenberg 24.2

Quando um autor freelancer de blocos diz «em mim funciona no core», perguntem:

• se testou o Gutenberg 24.2,
• se no package.json há peer React 19 ou ainda 18,
• se entrega reprodução num staging limpo.

Pagar um bloco sem esta checklist é comprar risco. No contrato B2B, acrescentem aceitação num ambiente com Gutenberg 24.2 como condição de entrega.

#Performance do editor após React 19 no Gutenberg

O React mais recente melhora muitas vezes concurrent features, mas em portáteis fracos da redacção ou num VPS com admin pesado podem ver:

• mais tempo até à interactividade do Inspector,
• jank no drag-and-drop de uma Gallery grande,
• maior uso de memória com muitas notes ao mesmo tempo.

Meçam subjectivamente no hardware do editor (não só no M-series do programador) e objectivamente: painel Performance do DevTools ao guardar um artigo com 40 blocos. Se o LCP do admin não importa para SEO, importa para a retenção da equipa de conteúdo. Um editor que espera 3 segundos por cada mudança no Inspector volta ao Classic Editor ou ao Google Docs.

#Acessibilidade de notas e navegação no Gutenberg 24.2

As notes na margem têm de ser alcançáveis por teclado e legíveis para leitores de ecrã. A pesquisa da Navigation tem de anunciar resultados para AT. Depois do 24.2:

• percorram por tab as notes e o fecho de uma nota,
• verifiquem focus trap em modais da Navigation,
• não assumam que «nova UI Automattic = WCAG automático».

Para clientes sob BFSG / EAA / lei de acessibilidade, isto não é teste opcional. É condição de aceitação do template.

#Quando ficar no WordPress core sem o plugin Gutenberg

Fiquem no core (sem plugin Gutenberg) quando:

• a loja gera tantas encomendas/dia que não há janela para regressão,
• dependem de plugins do editor sem maintainers,
• o cliente tem contrato «zero alterações de UI no admin no Q4».

Mesmo assim activem o 24.2 em staging para saber o que vem. Uma baseline de conhecimento é mais barata do que a surpresa no dia do upgrade do core.

#Formação da redacção em Notes no Gutenberg 24.2

O verde técnico é metade do sucesso. A outra metade: workshop de 30 minutos para editores.

Agenda:

1. Como adicionar uma note no bloco e como resolvê-la.
2. Quando note, quando ticket no tracker (mudança de código = ticket).
3. Como pesquisar na Navigation sem criar páginas duplicadas.
4. Quando não mexer no duotone em fotos de produto.

Sem workshop, as notes viram lixeira e a pesquisa na Navigation fonte de links maus. Registem o workshop no retainer como linha de implementação do 24.2.

#Riscos do Gutenberg 24.2 para leads técnicos

Uma tabela para o estado do projecto:

Para a direcção: o 24.2 é barato em staging e caro em produção sem checklist.

#Quando encomendar o teste Gutenberg 24.2 no exterior

Encomendem a revisão quando:

• mantêm uma biblioteca de blocos para várias marcas,
• a loja gera vendas e não têm janela para regressão no Inspector,
• um freelancer entregou blocos «a funcionar no core» sem teste 24.2,
• o retainer «actualizações» ainda não cobre a via React 19.

No pedido: URL de staging ou lista de plugins, versão WooCommerce, se o HPOS está activo, prazo da janela de manutenção. Basta para orçamentar smoke versus matriz completa.

#Gutenberg 24.2: staging antes da produção

Notes, pesquisa no menu e Gallery são ganho editorial. O React 19 no plugin é obrigação de staging para agências que vendem blocos e FSE. Actualização sem checklist transfere o risco para o cliente.

A via Agent / MCP write e a via Gutenberg ficam separadas: o Agent não testa React, e o React 19 no plugin não fecha o publish gate do MCP write.

Revisão de blocos ou retainer com a via Gutenberg: contacto. Desenvolvimento mais amplo: programador WordPress.