Actualización, . Gutenberg 24.3 ya está disponible (plugin con fecha 28 de octubre; entrada What’s new publicada el 2 de noviembre). Cambios editoriales que importan en un sitio en producción: formatear texto en una selección que abarca varios bloques, reacciones emoji en las notas (corazón, fiesta, ojos y unas cuantas más), Media inserter reconstruido sobre la cuadrícula DataViews con vistas previas de archivos que no son imágenes, y avisos de fallo de guardado/autosave con detalles, estado HTTP cuando está disponible, acción de copiar y cuenta atrás hasta el siguiente intento. La versión también incluye las correcciones de seguridad de WordPress 7.1.4, así que actualiza el plugin Gutenberg si lo tienes en producción. React 19 sigue activado por defecto como en 24.2; la checklist de pruebas de abajo sigue aplicando.
Gutenberg 24.2 salió el 14 de octubre de 2026. A los equipos editoriales les trae notas en el margen del editor, una sola búsqueda de enlaces en los menús y la ordenación de galerías. Para quienes desarrollan plugins y temas pesa más un cambio: el plugin Gutenberg carga ahora por defecto React 19 en lugar de React 18. Si en tu web tienes bloques propios o páginas de ajustes escritas en React, conviene revisarlos ahora, antes de que React 19 llegue al propio WordPress.
Este artículo se basa en la entrada oficial sobre la versión 24.2, la lista de cambios en el repositorio de Gutenberg, dos entradas de Make WordPress Core sobre React 19 y la guía de migración a React 19.
¿Qué hay de nuevo en Gutenberg 24.2?
La versión trae cinco cambios principales:
- notas trasladadas al margen junto al contenido,
- una sola búsqueda para todos los tipos de enlace en el bloque de navegación,
- ordenación y un filtro duotono común en el bloque de galería,
- más bloques con las mismas herramientas de diseño (unos 80 cambios en el código),
- React 19 activado por defecto y dos novedades en la Interactivity API.
A eso se suman más de 60 correcciones de errores y cambios de accesibilidad y rendimiento. Varios cambios menores importan en el trabajo diario. El control deslizante del número de columnas en el bloque de columnas ha desaparecido: una columna se añade con el botón más junto al botón del bloque en la barra de herramientas y se elimina como cualquier otro bloque. Después de recortar una imagen, el editor de imágenes permite volver al original sin pasar por la biblioteca de medios. El campo de autor de la entrada siempre tiene búsqueda y busca usuarios en el servidor, así que en webs con muchas cuentas la persona correcta aparece en la lista.
Gutenberg 24.2 también corrige las direcciones de las entradas nuevas. Hasta ahora, una entrada nueva podía publicarse con el slug auto-draft si alguien hacía clic en el campo del slug antes de publicar. En 24.2 eso ya no ocurre. Si en una web con el plugin Gutenberg has visto entradas con esa dirección, esa era la causa.
Los paneles que añaden los plugins se han trasladado, en el menú de opciones del editor, al submenú de paneles, junto a los nuevos submenús de apariencia y de notas. Los botones fijados de esos paneles en la barra de herramientas se quedan donde estaban. Si tu plugin tiene un panel lateral propio, comprueba si las instrucciones para los usuarios siguen indicando el lugar correcto.
¿React 19 ya está en WordPress?
No. WordPress 7.1 funciona con React 18.3. En julio de 2026, Jarda Snajdr explicó en Make WordPress Core por qué el paso a React 19 se quedó fuera de 7.1: tras activarlo brevemente en el plugin Gutenberg aparecieron incompatibilidades inesperadas entre la versión antigua y la nueva de React y en la forma en que los plugins usan React, y hubo que revertir el cambio.
«Necesitaremos un periodo de pruebas considerable en el que mejoremos y ajustemos la capa de compatibilidad que permite que los plugins existentes funcionen sin problemas.»
Fuente: Jarda Snajdr, Make WordPress Core, 24 de julio de 2026, traducción propia
Desde la versión 23.4, el plugin Gutenberg tenía un experimento de React 19 que había que activar a mano. Gutenberg 24.2 invierte ese ajuste: el experimento está activado por defecto. WordPress por sí solo, sin el plugin Gutenberg, sigue cargando React 18.3.
El plan de lanzamiento de WordPress 7.2 prevé la publicación a principios de diciembre de 2026. Sobre React 19 dice que los tipos, las dependencias y las correcciones de renderizado en Gutenberg están en su mayoría listos, pero que el paso completo en 7.2 es poco probable. Para los equipos que mantienen webs, esto significa que React 19 en el plugin Gutenberg es ahora un periodo de pruebas, no una fecha de llegada a WordPress. El contexto de la decisión de este verano está en el artículo sobre el plan de WordPress 7.1.
¿Cuándo deja Gutenberg 24.2 una web en React 18?
Según la entrada sobre la versión, las webs con el plugin cargan React 19 para los scripts react y react-dom, salvo que esté activo un tema o un plugin con problemas de compatibilidad conocidos. En ese caso la web se queda en React 18. La lista de esos temas y plugins empezó con problemas observados en WordPress.com y se amplió en esta versión (cambio #84607).
De aquí salen dos consecuencias prácticas. La primera: la misma versión de Gutenberg puede cargar versiones distintas de React en dos webs, según el conjunto de plugins. Al probar un bloque, comprueba qué versión ha recibido de verdad el editor. En la consola del navegador, en la pantalla del editor, basta con escribir React.version, porque WordPress expone React como variable global. La segunda: que no haya problemas en una web que ha entrado en la lista de excepciones no demuestra nada. En ese caso el bloque se ha probado con React 18.
La lista de excepciones es una solución provisional. Si tu plugin está en ella, el problema volverá el día en que React 19 entre en WordPress.
¿Cómo desactivar React 19 en Gutenberg?
El equipo de Gutenberg dice claramente qué hacer cuando algo deja de funcionar:
«Si mantienes un plugin o un tema que usa React, pruébalo con Gutenberg 24.2 e informa de cualquier problema que encuentres. Si algo deja de funcionar en una web, desactiva React 19 en Gutenberg > Experiments.»
Fuente: What’s new in Gutenberg 24.2, Make WordPress Core, 14 de octubre de 2026, traducción propia
En el escritorio de WordPress es el menú Gutenberg, la página de experimentos, la casilla de React 19. La entrada de julio sobre el experimento describía esa misma página como disponible en los ajustes de Gutenberg. La desactivación afecta a toda la web, así que es una salida de emergencia para producción, no una forma de arreglar el bloque. Un bloque que solo funciona con React 19 desactivado hay que corregirlo antes de que salga un WordPress con React 19.
La otra opción es no instalar el plugin Gutenberg en producción. Una web sin ese plugin recibe el React de WordPress, hoy el 18.3. El plugin Gutenberg se instala en producción cuando el cliente necesita funciones que todavía no están en WordPress. Si no las necesita, prueba React 19 en una copia de la web.
¿Qué API eliminó React 19 y qué rompe eso en los bloques de WordPress?
La entrada de julio en Make WordPress Core cita dos fuentes habituales de fallos en los plugins. La segunda son funciones antiguas de React, obsoletas desde hace al menos seis años y eliminadas en React 19. La capa de compatibilidad de Gutenberg suple algunas, pero no todas. La guía de migración a React 19 da la lista completa con la fecha desde la que cada API estaba obsoleta:
| API eliminada | Obsoleta desde | Sustituto |
|---|---|---|
propTypes en componentes de función | abril de 2017 (15.5.0) | TypeScript u otro sistema de tipos; las comprobaciones ahora se omiten sin aviso |
defaultProps en componentes de función | junto con propTypes | valores por defecto de los parámetros de la función |
String refs (ref="input") | marzo de 2018 (16.3.0) | refs como función o useRef |
Legacy context (contextTypes, getChildContext) | octubre de 2018 (16.6.0) | contextType y createContext |
ReactDOM.findDOMNode | octubre de 2018 (16.6.0) | refs a elementos del DOM |
| Fábricas al estilo module pattern | agosto de 2019 (16.9.0) | componentes normales |
React.createFactory | febrero de 2020 (16.13.0) | JSX |
ReactDOM.render y ReactDOM.hydrate | marzo de 2022 (18.0.0) | createRoot y hydrateRoot |
ReactDOM.unmountComponentAtNode | marzo de 2022 (18.0.0) | root.unmount() |
Los componentes de clase conservan defaultProps, porque para las clases no hay equivalente en la sintaxis de ES6. También se han eliminado react-dom/test-utils y react-test-renderer/shallow, lo que afecta a las pruebas unitarias, no al bloque en sí.
En el código de WordPress lo más frecuente es un render que monta una página de ajustes o un widget del escritorio. Los plugins antiguos lo importan de @wordpress/element, que por debajo llama a ReactDOM.render. Las versiones nuevas de ese paquete exportan createRoot, y es la que hay que usar:
import { createRoot } from '@wordpress/element';
const container = document.getElementById( 'my-plugin-settings' );
if ( container ) {
createRoot( container ).render( <SettingsPage /> );
}El segundo caso frecuente es defaultProps en un componente de función del editor de bloques. En React 19 los valores por defecto simplemente no se asignan, así que el componente recibe undefined y normalmente no lanza un error, sino que muestra un panel vacío o calcula mal un valor. Es un fallo fácil de pasar por alto, porque la consola no dice nada.
La guía ofrece un conjunto listo de correcciones automáticas: npx codemod@latest react/19/migration-recipe. Ejecútalo en una rama aparte y lee cada cambio, porque no conoce las particularidades de los paquetes @wordpress/*.
React 18.3, con el que funciona WordPress 7.1, es idéntico a 18.2 según el equipo de React, pero añade avisos sobre API obsoletas y otros cambios necesarios para React 19. Si en la consola del editor de un WordPress 7.1 normal ves avisos con el nombre de tu plugin, ahí tienes la lista de cosas que corregir.
¿Cómo comprobar si un plugin incluye su propia copia de React?
La primera fuente de fallos de la entrada de julio es más frecuente y más difícil de ver en el código fuente, porque solo aparece en el archivo JavaScript compilado.
«Si todo el mundo empaquetara su JavaScript correctamente, la mayoría de los problemas de compatibilidad no se producirían en absoluto.»
Fuente: Jarda Snajdr, Make WordPress Core, 24 de julio de 2026, traducción propia
Se trata del código de react/jsx-runtime incluido directamente en el archivo del plugin en lugar del script react-jsx-runtime que proporciona WordPress. En ese caso conviven en la web React 18, del paquete del plugin, y React 19, de WordPress, y las estructuras de datos creadas por la versión antigua llegan a la nueva. El componente parece correcto en el código, pero en el editor no se monta o lanza un error de elemento no válido.
La comprobación lleva unos minutos por plugin:
- Abre el archivo
*.asset.phpjunto al script compilado (por ejemplobuild/index.asset.php). Si el código usa JSX, en la lista de dependencias debería estarreact-jsx-runtime. - Busca en los archivos compilados código del propio React, por ejemplo con
grep -l "react.element" build/*.js. Una coincidencia en el archivo del plugin indica que parte de React va en el paquete. Es motivo para revisar la configuración, no una sentencia. - Comprueba que la configuración de compilación no se salta el mecanismo que sustituye las importaciones de
reacty@wordpress/*por los scripts de WordPress. Suele pasar con un webpack o un Vite propios en lugar de@wordpress/scripts. - Para plugins comprados a un proveedor externo, sin acceso al código fuente, queda la prueba en el editor de la siguiente sección y avisar al autor.
El equipo de Gutenberg trabaja en la detección automática de estos problemas en el plugin Plugin Check. Hasta que funcione, la comprobación corre a cargo del autor del plugin.
¿Cómo probar tus bloques con React 19 en una copia de la web?
La entrada de julio define la prueba de compatibilidad de forma sencilla: usar todas las partes del plugin que usan React, normalmente bloques, extensiones del editor y páginas propias del escritorio, y comprobar que la interfaz no está rota y que la consola del navegador no muestra errores. En una copia de pruebas de la web se hace así:
- Haz una copia de la web con la misma versión de PHP, WordPress y plugins que producción. Si la copia incluye datos de clientes de la tienda, anonimízalos antes de copiarlos.
- Instala Gutenberg en la versión de este lanzamiento:
wp plugin install gutenberg --version=24.2.0 --activate. - En el
wp-config.phpde la copia, pondefine( 'SCRIPT_DEBUG', true );. WordPress carga entonces las versiones sin comprimir de los scripts, incluida la versión de desarrollo de React, que muestra los avisos completos en lugar de códigos de error abreviados. - En el editor, escribe
React.versionen la consola y asegúrate de que es la 19. Si ves la 18, algún plugin activo está en la lista de excepciones y hay que repetir la prueba sin él. - Inserta cada bloque propio en una entrada nueva, cambia cada ajuste del panel del bloque, guarda, recarga el editor y comprueba que el bloque no muestra el aviso de contenido no válido.
- Abre cada página de ajustes del plugin y cada panel lateral que el plugin añade al editor. Desde la 24.2, esos paneles están en el submenú de paneles del menú de opciones.
- Por último, revisa las entradas guardadas en la web. Los bloques dinámicos los renderiza PHP, así que ahí React no influye, pero los bloques con Interactivity API y scripts en la página hay que probarlos a mano.
La lista del punto 5 debería incluir los bloques que el cliente usa de verdad, no solo los registrados. Si la web tiene una biblioteca de varias decenas de bloques, empieza por los de la página de inicio, la ficha de producto y los formularios. Las reglas generales para trabajar con una copia de pruebas están en nuestra guía para publicar cambios a través de una copia de la web, y para comprobar rápido un solo bloque en una instalación limpia basta con WordPress Playground.
Cada problema que encuentres, notifícalo con el número de versión de Gutenberg, la versión de React de la consola y el texto del error. El equipo pide los avisos en el repositorio de Gutenberg en GitHub y, para los plugins de terceros, a sus autores.
¿Cómo funcionan las notas en el margen del editor?
Hasta ahora, las notas flotantes y el panel de ajustes no podían estar abiertos a la vez, y la columna de notas quitaba espacio al contenido. En la 24.2, el editor reserva un margen junto a la zona de edición y muestra ahí las notas, así que siguen visibles al cambiar de bloque y de ajustes de la entrada.
Con una ventana más estrecha, cada hilo se pliega al avatar de su autor, y al hacer clic en el avatar se despliega de nuevo. El nuevo submenú de notas en el menú de opciones permite desplegarlas, minimizarlas u ocultarlas, y el editor recuerda la elección. Tres cambios reducen el riesgo de perder trabajo: la eliminación de una nota se puede deshacer, una nota o respuesta sin enviar no desaparece al seleccionar otro bloque, y las notas se desplazan junto con el contenido.
Para un equipo editorial que comenta los textos en el editor, esto significa cambiar menos de panel. Para quienes crean bloques hay una consecuencia práctica: la zona de edición tiene ahora menos espacio cuando las notas están visibles. Conviene revisar con las notas abiertas los bloques de ancho fijo o con un diseño propio en el editor.
El plan de WordPress 7.2 anuncia más cambios en las notas: un modo de sugerencias, en el que un cambio de texto propuesto se puede aceptar o rechazar, reacciones con emoji y un botón propio para añadir una nota en la barra de herramientas del bloque.
¿Qué ha cambiado en el bloque de navegación y en la galería?
Añadir al menú algo que no fuera una página exigía antes saber qué bloque usar, por ejemplo un enlace a categoría o un enlace a etiqueta, y solo entonces buscar dentro de él. Ahora el buscador de enlaces del bloque de navegación busca en todos los tipos de contenido a la vez y muestra el tipo de cada resultado. Un enlace existente se puede cambiar de categoría a página sin borrarlo y añadirlo de nuevo. El mismo buscador muestra también los bloques que admite el menú, así que al escribir Home aparece el bloque de enlace a la página de inicio.
Los resultados se ordenan ahora por tipo: entradas y páginas antes que categorías, etiquetas y medios. Este orden se aplica a todas las búsquedas de enlaces del editor, no solo en los menús. En webs grandes, las etiquetas y los adjuntos dejan de empujar fuera de la lista la entrada que buscas. Si tu plugin añade tipos de contenido propios al buscador de enlaces, es un buen motivo para comprobar dónde acaban sus resultados.
Global Styles puede ahora dar estilo a los estados de los enlaces de navegación (al pasar el ratón, foco, foco visible, activo), de momento solo en tipografía. Los temas que lo hacían con CSS propio pueden trasladar parte de las reglas a theme.json, pero antes conviene comprobar qué regla prevalece.
En el bloque de galería, la opción de ordenar funciona ahora también con galerías de imágenes elegidas a mano. La ordenación de más recientes a más antiguas, de más antiguas a más recientes y alfabética en ambos sentidos coloca las imágenes una vez, y después se pueden seguir arrastrando. La opción aleatoria está en el mismo sitio y mezcla las imágenes cada vez que se carga la página. En webs con caché de páginas completas esto importa: el orden aleatorio solo cambiará cuando se renueve la caché, no en cada visita.
La galería también admite duotono. Un solo filtro colorea todas las imágenes de la galería, fijado en el bloque o para todas las galerías de la web en Global Styles. El duotono fijado en una imagen concreta tiene prioridad sobre el ajuste de la galería. El duotono ha llegado además a los bloques de medios y texto y de vídeo. Con fotos de productos, comprueba que un filtro global no cambia los colores donde el cliente no lo quiere.
¿Qué hay de nuevo en la Interactivity API?
La nueva directiva data-wp-html muestra HTML a partir del estado, igual que data-wp-text muestra texto. Solo acepta valores marcados como de confianza con asDangerousHTML(). Ejemplo de la entrada sobre la versión:
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>El plan de 7.2 explica que la primera versión solo muestra valores marcados explícitamente como de confianza por el código de la aplicación, y que el soporte para cadenas normales saneadas llegará más adelante. No pases a asDangerousHTML() nada que venga del usuario o de los atributos del bloque sin sanearlo en PHP. En esta misma versión, la documentación de Gutenberg añadió una nota: los atributos de los bloques y los valores de Global Styles deben tratarse como no fiables en el momento de renderizar. Si haces una revisión de seguridad de un plugin, añade la búsqueda de asDangerousHTML a la lista de cosas que lee una persona.
El router expone ahora state.navigating y state.initiator, así que el bloque sabe que hay una navegación en curso en el lado del cliente y qué bloque la inició. Según el plan de 7.2, esto sustituye a la pareja obsoleta state.navigation.hasStarted y state.navigation.hasFinished. Los bloques con un indicador de carga propio durante la navegación conviene reescribirlos con los campos nuevos antes de que se eliminen los antiguos.
¿Las notas de Gutenberg ya son colaboración en tiempo real?
No. Las notas son comentarios a los bloques que se leen y se añaden en cualquier momento. La colaboración en tiempo real no está en el plan de WordPress 7.2. El plan dice que, como en 7.1, hace falta más tiempo para las decisiones de arquitectura, así que el tema se ha dejado fuera en lugar de incluirlo y retirarlo después.
El trabajo continúa en el plugin experimental gutenberg-sync-engines, descrito en la guía de motores de sincronización del 14 de octubre. Se están probando tres motores: yjs-server, DE-RTC e intent-log. El plugin requiere WordPress 7.0 o posterior y el plugin Presence API, y además incluye su propia copia de Gutenberg ligeramente modificada. Por eso no funcionará junto a un plugin Gutenberg activo: la prueba de React 19 y la de colaboración en tiempo real no se pueden hacer en la misma copia de la web.
Bajo la guía, el autor de la biblioteca Yjs, Kevin Jahns, señaló el coste en el servidor:
«La edición en tiempo real genera muchos mensajes pequeños. Si cada uno de ellos tiene que arrancar un proceso de PHP, cargar el documento compartido, verificarlo, fusionarlo y volver a escribirlo en la base de datos, eso supone una gran sobrecarga en comunicación, procesamiento y uso de la base de datos.»
Fuente: comentario de Kevin Jahns bajo la guía de motores de sincronización, 15 de octubre de 2026, traducción propia
Para quienes tienen su web en un alojamiento compartido barato, es una señal de que la colaboración en tiempo real quizá exija algún día otro alojamiento.
Actualización, . El plugin de funcionalidad Presence API llegó a la 0.20.0 el 1 de noviembre (listado en WordPress.org; unas 10 instalaciones activas). El resumen de la reunión del 26 de octubre, publicado el 1 de noviembre, dice que la checklist de merge sigue necesitando pruebas de usuarios externas y una auditoría de seguridad fuera del repositorio, y que el 3 de diciembre es la fecha más temprana para una propuesta inicial en Trac (ocho semanas sin cambio de API incompatible desde 0.17.0). Las versiones 0.18.4 a 0.20.0 añaden un arreglo de cierre de sesión para bloqueos de entradas, ganchos keepalive/roomChanged para relays push y wp_presence_admin_state(), para que un relay escriba las mismas filas que Heartbeat. Presence sigue siendo dependencia de gutenberg-sync-engines, no un sustituto de las notas en 24.2/24.3, y aún no trae coedición en tiempo real a WordPress 7.2.
¿Quién debería probar sus bloques antes de WordPress 7.2?
La prueba tiene sentido para cualquier web con bloques propios, extensiones del editor o páginas de ajustes en React, y para los autores de plugins y temas que los tienen. Una web construida solo con bloques de WordPress y plugins populares con soporte activo depende de que sus autores hagan la prueba. El equipo de Gutenberg lo pide justo ahora.
Si en tu equipo no hay nadie que revise los archivos compilados y pruebe los bloques en una copia de la web, un desarrollador WordPress lo hará en un solo encargo, y con un mantenimiento continuo de la web probar las nuevas versiones de Gutenberg antes de actualizar producción forma parte del trabajo. Por qué esa revisión necesita a una persona lo contamos también en el artículo sobre la contratación de desarrolladores que trabajan con IA.
En la solicitud indica la versión de WordPress y de PHP, la lista de plugins con bloques propios, si hay plugin Gutenberg en producción y si tienes una copia de pruebas de la web. El presupuesto es individual, según el alcance. El formulario está en la página de contacto.
