Gutenberg 24.2 y React 19: qué probar en tus bloques personalizados

Gutenberg 24.2 es un release de producto pequeño para redacciones y una señal de compatibilidad para autores de bloques. Las notas al margen y una sola búsqueda en Navigation reducen la fricción en content ops. React 19 activado por defecto en el plugin Gutenberg traslada las pruebas de vuestros bloques a staging: una regresión detectada ahora cuesta menos que la misma regresión cuando esta línea entre en el core. Esperar el anuncio «React 19 en WordPress X.Y» deja ese error en producción del cliente.

WordPress 7.1 dejó React 19 fuera del zip tras problemas de compatibilidad. 24.2 no anula esa decisión. React 19 era, desde la 23.4, un experimento que había que activar a mano en el plugin Gutenberg; 24.2 lo activa por defecto en todos los sitios con el plugin.

¿Tenéis bloques propios o una tienda FSE y no queréis arriesgar un update en producción? Describid el stack (PHP, WP, WooCommerce, lista de plugins del editor) en contacto. Recibís un plan de staging y aceptación, no solo el changelog.

#Qué hay de nuevo en Gutenberg 24.2

#Notes en el editor Gutenberg 24.2

Las notes se sitúan junto al contenido, no solo en la barra lateral. En la revisión de un artículo o landing, el editor comenta junto al bloque concreto. Menos saltos entre el panel y el canvas.

Para agencias con content ops de varias personas, eso cambia el ritmo:

• el copywriter deja una nota en el H2, no en un hilo de Slack sin contexto,
• el reviewer ve un montón de notas en el bloque en la segunda ronda,
• el desarrollador de bloques ve qué puntos de la UI generan más fricción editorial (a menudo bloques propios con inspector confuso).

Los cambios de código siguen yendo a Linear/Jira. Las notes sustituyen capturas con flecha roja en PDF durante la revisión de contenido.

#Buscar páginas y categorías en el menú Navigation

Añadir páginas, entradas, categorías y etiquetas a Navigation con un único campo de búsqueda. Al reconstruir la IA del sitio (sobre todo multilingüe), bajan los clics y los errores «añadí la página equivocada de la lista».

Prueba práctica de staging: construir un menú con mezcla de page + category + custom link, guardar, refrescar el front, comprobar el overlay móvil. Las regresiones de Navigation suelen salir primero en el front, no en el editor.

#Gallery en Gutenberg 24.2: ordenación y duotone

El control Order by ahora también funciona en galerías de imágenes elegidas a mano (más recientes, más antiguas, A a Z, Z a A o aleatorio en cada carga de página), y un solo filtro duotone tiñe todas las imágenes de una galería, desde el bloque o para todo el sitio en Global Styles. Comprueba:

• CSS custom que asume el markup antiguo de filtros,
• bloques hijos / variaciones de Gallery en el child theme,
• lazy load y CLS al cambiar el orden de las imágenes,
• exportación a AMP o headless (si servís bloques fuera de un tema clásico).

El duotone parece cosmética hasta que rompe el contraste en fotos de producto. En tiendas, comprobad Gallery en la ficha de producto, no solo en el blog.

#React 19 en Gutenberg 24.2 (por defecto)

Esta es la señal principal para el stack de desarrollo. Los sitios con el plugin cargan ahora React 19 para los scripts react y react-dom, salvo que esté activo un tema o plugin con problemas de compatibilidad conocidos; esos sitios se quedan en React 18. Si algo se rompe, React 19 se puede desactivar en Gutenberg > Experiments. Para el atributo inert, el nuevo paquete @wordpress/react-inert-value funciona con React 18 y con 19 (artículo de lanzamiento de 24.2).

Plugins y temas con React en el editor deben probar y reportar. No esperéis una fecha en el core: el Roadmap to 7.2 considera poco probable la llegada completa en 7.2, así que las regresiones aparecen primero en el plugin.

Puntos típicos de rotura tras un upgrade de React:

• react/jsx-runtime empaquetado en el bundle del plugin en lugar del script externo que proporciona WordPress (React 18 y 19 acaban funcionando a la vez),
• APIs eliminadas en React 19: string refs, default props en componentes de función, legacy context,
• bloques propios con @wordpress/scripts desactualizado / webpack antiguo,
• slot fills y sidebars de plugin que asumen lifecycles antiguos,
• peers de React 18 en el package.json del plugin del cliente,
• tests E2E Playwright/Cypress anclados a timings de 18.

Si mantenéis una biblioteca de bloques para varios clientes, un staging con 24.2 en un proyecto representativo sale más barato que cinco hotfixes después del core.

#Gutenberg 24.2, WordPress 7.1 y React 19 en core

En 7.1 React 19 no entró en el core. La decisión fue correcta para la estabilidad del ecosistema e incómoda para equipos que ya habían preparado el upgrade. Gutenberg 24.2 es el lugar oficial donde el ecosistema puede «sentir» React 19 sin forzarlo en cada instalación sin el plugin Gutenberg.

Para agencias, eso significa tres vías:

1. Cliente sin plugin Gutenberg en producción - se queda por ahora en React del core (línea 7.1). Planificad pruebas; no instaléis el plugin Gutenberg «porque salió 24.2».
2. Cliente con plugin Gutenberg (early features) - 24.2 es staging obligatorio antes de la actualización.
3. Productos propios / bloques vendidos a muchos clientes - CI contra Gutenberg 24.2 + matriz PHP/WP.

No mezcléis este mensaje con el WordPress.com Agent: producto distinto, vía distinta (Agent y MCP write). El Agent no prueba vuestros bloques bajo React 19.

#Checklist de pruebas Gutenberg 24.2 en staging

1. Instala Gutenberg 24.2 en una copia de producción (no en el live del cliente). En Gutenberg > Experiments, confirma que React 19 está activo: con un plugin de la lista de incompatibles el sitio se queda en React 18 y la prueba no dice nada sobre 19.
2. Abre una entrada con vuestros bloques custom: insert, duplicate, move, save, preview, undo.
3. Comprueba Navigation: busca página y categoría, guarda el menú, refresca front y móvil.
4. Gallery con duotone: activa el filtro, cambia el orden, guarda, comprueba el front.
5. Notes: añade una nota en el bloque, recarga el editor, confirma persistencia, bórrala.
6. Smoke WooCommerce (si es tienda): producto, carrito, checkout, email.
7. Si algo falla: reproducción mínima + versiones PHP / WP / Gutenberg / plugin en el issue tracker.

Extensión para biblioteca de bloques (2-4 horas):

• tests unitarios/integración del paquete,
• build limpio de assets (npm ci + build),
• comprobar peerDependencies de React,
• comparar bundle size antes/después (la regresión suele ir con React duplicado).

#Qué evitar al actualizar Gutenberg 24.2

• No activéis el plugin Gutenberg en una tienda WooCommerce en producción sin plan de rollback y ventana de mantenimiento.
• No prometáis al cliente «React 19 en el core mañana». 24.2 es un plugin.
• No tratéis Notes como sistema de tickets para desarrolladores.
• No actualicéis diez clientes el mismo día «porque salió 24.2». Un staging representativo, luego la oleada.

#Gutenberg 24.2 en el retainer de mantenimiento

Un cliente en retainer «actualizaciones WordPress» debería recibir en el informe mensual una línea aparte: prueba Gutenberg 24.2 / vía React 19. Es una sesión de compatibilidad de bloques, separada del bump normal del core.

Si el retainer no cubre pruebas del editor, añadid change request antes de actualizar Gutenberg en staging. Barato una vez. Caro cuando el editor cae el día de publicación de la campaña.

#Notes y búsqueda en Navigation en el día a día editorial

Notes

• una nota = una decisión (copy / layout / legal),
• sin hilos filosóficos en el margen,
• tras merge a final: borrar o archivar notes para que el canvas no parezca graffiti.

Búsqueda en Navigation

• los nombres de páginas en el admin deben ser únicos y legibles (duplicados «Oferta» en dos idiomas sin prefijo de locale confunden la búsqueda),
• tras reconstruir el menú: exportar la estructura a un documento de IA (aunque sea una tabla Markdown) como fuente de verdad fuera de WordPress.

#Probar Gutenberg 24.2 en WooCommerce y membership

Si el sitio es tienda o membership, no blog, la checklist general se queda corta. Añadid:

• edición de la plantilla Single Product en el site editor (no solo el producto clásico),
• bloques de carrito / checkout (bloques Woo vs shortcode legacy),
• bloques de contenido restringido (membership, paywall),
• preview como usuario autenticado vs visitante,
• guardar draft de producto con Gallery + duotone (si el front de la tienda hereda el filtro en miniaturas de la rejilla).

Una regresión React en el Inspector del producto puede bloquear una campaña Black Friday más que una regresión en un post de blog. Priorizad staging de la tienda antes que el blog de la empresa.

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

Las agencias suelen guardar «unas líneas» en theme.json y style.css del child theme. Tras 24.2 comprobad:

• overrides de Gallery y duotone en theme.json,
• CSS que apunta a clases que Notes o la nueva UI de Navigation pueden haber cambiado,
• patterns sincronizados que asumen markup antiguo.

FSE no libera de pruebas. Al contrario: cuanto más UI vive en JSON y patterns, más sitios donde React 19 en el editor puede mostrar un panel vacío o un spinner infinito. Contexto sobre bloques, patrones y el editor del sitio: bloques Gutenberg y full site editing.

#Cómo informar al cliente del resultado de las pruebas Gutenberg 24.2

Tres párrafos en el correo tras la prueba de staging bastan:

1. Qué probamos (lista de bloques + Navigation + Gallery + Notes).
2. Qué encontramos (concreto: «el Inspector del bloque X pierde el focus», no «el editor se comporta raro»).
3. Decisión: actualizar Gutenberg / esperar fix upstream / quedarnos en core sin plugin hasta la fecha Y.

Los clientes aceptan un retraso en la actualización cuando ven una lista de pruebas. No aceptan «se rompió de alguna forma tras la actualización» sin esa lista.

#Cómo reportar un bug en Gutenberg 24.2

Un issue en el repo del plugin o en Gutenberg GitHub debería tener:

• versiones: WP, PHP, Gutenberg, navegador,
• pasos de reproducción en cinco líneas,
• esperado vs real,
• si falla solo con vuestro bloque, o en Twenty Twenty-Five + bloques core.

«No funciona en nuestro caso» sin reproducción aterriza en limbo. Una buena reproducción en entorno limpio acelera el fix más que diez comentarios «+1».

#Matriz de pruebas React 19 para una biblioteca de bloques

Un staging en un cliente no basta si vendéis bloques a muchas marcas. Matriz mínima:

Automatización: un workflow CI que instala Gutenberg 24.2, construye bloques, lanza smoke Playwright en insert/save. Dejad Navigation, Gallery duotone y Notes en manual: el E2E es frágil en los márgenes de la UI.

El coste de la matriz se recupera en el segundo cliente con la misma biblioteca de bloques. Para un landing estático basta la checklist de 15-30 minutos.

#Regresiones típicas tras React 19 en Gutenberg

De upgrades de React en el ecosistema WordPress (no solo 24.2) salen a menudo:

• copia duplicada de React en el bundle (síntoma: avisos raros en consola, state inconsistente),
• controles del Inspector que «pierden» el focus en cada keystroke,
• bloques dinámicos SSR vs client: hydrate mismatch tras cambio de markup de Gallery,
• peers antiguos de @wordpress/components incompatibles con el nuevo React,
• E2E esperando selectores que Notes o la nueva búsqueda de Navigation movieron en el DOM.

Registrad cada regresión con la versión de Gutenberg en el título del issue. «El editor está roto» sin número de versión es inútil para bisect.

#Gutenberg Notes y colaboración en tiempo real

En la misma semana, Make WordPress Core publicó una guía de los motores de sincronización en evaluación para la colaboración en tiempo real. En un comentario a ese artículo, el autor de Yjs, Kevin Jahns, advirtió que la edición en tiempo real genera muchísimos mensajes pequeños y que arrancar un worker de PHP para cada uno añade mucha sobrecarga. Eso no es el changelog de 24.2, pero es contexto para leads técnicos: la vía de colaboración multipersona y la vía React 19 son riesgos separados. Las notas al margen resuelven la revisión asíncrona. No resuelven el conflicto de dos cursores en el mismo bloque.

No vendáis al cliente «real-time collaboration» porque salió 24.2. Vended revisión más ágil y bloques probados.

#Cuándo desplegar Gutenberg 24.2 en producción

1. Staging en verde en la checklist y en el smoke de WooCommerce.
2. Ventana de mantenimiento acordada (no viernes después de las 16:00 en una tienda).
3. Rollback: zip anterior de Gutenberg + backup de DB de antes de la actualización.
4. Monitorización 24-48 h: errores JS en el editor, tickets de publicación, fallos de checkout.

Si el cliente tiene auto-update de plugins, desactivad el auto-update de Gutenberg hasta el staging en verde. Gutenberg no es «otro plugin de SEO».

#Release notes del plugin de bloques tras Gutenberg 24.2

Si vendéis bloques propios como plugin:

• línea en el changelog «tested with Gutenberg 24.2 (React 19 default)»,
• en el readme: versión mínima de @wordpress/scripts / toolchain de build,
• en CI: job gutenberg-next junto a wordpress-stable,
• en la policy de soporte: «los reportes sin número de Gutenberg se cierran con petición de completar».

Los clientes enterprise leen release notes. Una línea sobre 24.2 construye más confianza que un vago «improved compatibility».

#Duotone de Gallery y design system de marca

El duotone en Gallery es cómodo para la redacción y peligroso para una marca con design system estricto. Si el cliente tiene filtros y tokens de color definidos:

• desactivad duotone en patterns de producto,
• dejadlo en el blog / social proof,
• registrad la regla en las Guidelines de contenido (no confundir con las Guidelines del WordPress.com Agent).

Agent y Gutenberg son productos separados, pero el mismo problema: la herramienta da a la redacción poder que la guía de marca no previó. La ownership del design system se queda en la agencia.

#Por qué WordPress 7.1 aplazó React 19

Hechos del verano de 2026 (detalle en la roadmap 7.1): el upgrade de React 18 a 19 salió de 7.1 después de que una breve prueba en Gutenberg revelara incompatibilidades inesperadas entre las dos versiones de React y en la forma en que los plugins usan React. En el artículo de Make Core del 24 de julio de 2026, Jarda Snajdr escribió que hace falta un periodo de pruebas considerable para afinar la capa de compatibilidad. 24.2 es la consecuencia de esa prudencia: primero plugin Gutenberg, luego eventualmente el core.

Para leads: no la narración «Automattic llega tarde»; sí «tenéis una ventana de pruebas que debéis usar». Las agencias que en agosto aparcaron la preparación «porque 7.1 sin React 19» reciben en octubre una segunda oportunidad con 24.2. Una tercera ventana cómoda antes del core puede no existir.

#Aceptar bloques de freelancers bajo Gutenberg 24.2

Cuando un autor freelance de bloques dice «en mi caso funciona en core», preguntad:

• si probó Gutenberg 24.2,
• si en package.json hay peer React 19 o sigue siendo 18,
• si entrega reproducción en un staging limpio.

Pagar un bloque sin esa checklist es comprar riesgo. En el contrato B2B, añadid aceptación en un entorno con Gutenberg 24.2 como condición de entrega.

#Rendimiento del editor tras React 19 en Gutenberg

El React más reciente suele mejorar concurrent features, pero en portátiles débiles de la redacción o en un VPS con admin pesado podéis ver:

• más tiempo hasta la interactividad del Inspector,
• jank al arrastrar una Gallery grande,
• mayor uso de memoria con muchas notes a la vez.

Medid de forma subjetiva en el hardware del editor (no solo en el M-series del desarrollador) y de forma objetiva: panel Performance de DevTools al guardar una entrada con 40 bloques. Si el LCP del admin no importa para SEO, importa para la retención del equipo de contenido. Un editor que espera 3 segundos por cada cambio en el Inspector vuelve al Classic Editor o a Google Docs.

#Accesibilidad de notas y navegación en Gutenberg 24.2

Las notes al margen deben ser alcanzables por teclado y legibles para lectores de pantalla. La búsqueda de Navigation debe anunciar resultados para AT. Tras 24.2:

• recorred por tab las notes y el cierre de una nota,
• comprobad el focus trap en modales de Navigation,
• no asumáis que «nueva UI Automattic = WCAG automático».

Para clientes bajo BFSG / EAA / ley de accesibilidad, esto no es una prueba opcional. Es condición de aceptación de la plantilla.

#Cuándo quedarse en WordPress core sin el plugin Gutenberg

Quedaos en core (sin plugin Gutenberg) cuando:

• la tienda genera tantos pedidos/día que no hay ventana para una regresión,
• dependéis de plugins del editor sin maintainers,
• el cliente tiene contrato «cero cambios de UI en el admin en Q4».

Aun así activad 24.2 en staging para saber qué viene. Una baseline de conocimiento es más barata que la sorpresa el día del upgrade del core.

#Formación de la redacción en Notes en Gutenberg 24.2

El verde técnico es la mitad del éxito. La otra mitad: un taller de 30 minutos para editores.

Agenda:

1. Cómo añadir una note en el bloque y cómo resolverla.
2. Cuándo note, cuándo ticket en el tracker (cambio de código = ticket).
3. Cómo buscar en Navigation sin crear páginas duplicadas.
4. Cuándo no tocar duotone en fotos de producto.

Sin taller, las notes se convierten en basura y la búsqueda de Navigation en fuente de enlaces malos. Registrad el taller en el retainer como línea de implementación de 24.2.

#Riesgos de Gutenberg 24.2 para leads técnicos

Una tabla para el estado del proyecto:

Para la dirección: 24.2 es barato en staging y caro en producción sin checklist.

#Cuándo encargar el test de Gutenberg 24.2 fuera

Encargad la revisión cuando:

• mantenéis una biblioteca de bloques para varias marcas,
• la tienda genera ventas y no tenéis ventana para una regresión del Inspector,
• un freelancer entregó bloques «que funcionan en core» sin test 24.2,
• el retainer «actualizaciones» aún no cubre la vía React 19.

En la consulta: URL de staging o lista de plugins, versión de WooCommerce, si HPOS está activo, plazo de la ventana de mantenimiento. Basta para presupuestar smoke frente a matriz completa.

#Gutenberg 24.2: staging antes de producción

Notes, búsqueda en el menú y Gallery son ganancia editorial. React 19 en el plugin es obligación de staging para agencias que venden bloques y FSE. Una actualización sin checklist traslada el riesgo al cliente.

La vía Agent / MCP write y la vía Gutenberg se quedan separadas: el Agent no prueba React, y React 19 en el plugin no cierra el publish gate de MCP write.

Revisión de bloques o retainer con la vía Gutenberg: contacto. Desarrollo más amplio: desarrollador WordPress.