WordPress16/09/2026Redação de Tecnologia e Desenvolvimento7 min de lecturaActualizado el 23/09/2026

Gutenberg 24.0: qué cambió en el editor y qué anticipa sobre WordPress 7.2

La versión 24.0 amplía las revisiones visuales, mejora Galería y Título del sitio y actualiza APIs y herramientas. Vea qué ya se puede probar y qué todavía depende del Core de WordPress 7.2.

Notebook aberto com interface de editor de blocos, livros com referências a Gutenberg 24.0 e WordPress 7.2, planta e caneca sobre mesa de trabalho.

Gutenberg 24.0 llegó el 16 de septiembre de 2026 con cambios que ya conviene incorporar a la rutina de pruebas de quienes desarrollan temas, plugins o proyectos basados en el editor de bloques. La versión amplía las revisiones visuales, hace que el bloque Galería sea más flexible en diferentes anchos de pantalla, añade ajuste automático de texto al bloque Título del sitio e incorpora una larga lista de cambios menores en componentes, APIs, accesibilidad y herramientas de desarrollo.

Eso no significa que todo lo incluido en Gutenberg 24.0 ya esté confirmado para WordPress 7.2. El próximo ciclo mayor del Core sigue en fase alpha. La página oficial de la versión indica que se considerarán nuevas funciones cuando estén razonablemente listas, con Beta 1 prevista entre el 20 y el 22 de octubre y la ventana de lanzamiento final entre el 8 y el 10 de diciembre de 2026. Para los equipos técnicos, el valor de 24.0 está en probar con anticipación y separar tres cosas: lo que ya funciona en el plugin Gutenberg, lo que puede afectar la compatibilidad de temas y plugins y lo que todavía depende de integración y estabilización en el Core.

Los cambios más visibles de Gutenberg 24.0

La publicación oficial del lanzamiento destaca tres cambios principales en el editor.

  • Las revisiones visuales también incluyen el título de la entrada: el título pasa a formar parte de las diferencias entre revisiones, lo que permite ver cuándo ocurrió un cambio de nombre en el mismo contexto que las modificaciones del contenido.
  • Galería incorpora una variación Grid y controles por breakpoint: el bloque Galería puede usar una cuadrícula personalizable. La cantidad de columnas y el recorte de imágenes también pueden variar según el estado del viewport, reduciendo la necesidad de CSS propio en algunos diseños responsivos.
  • Título del sitio incorpora fit-text: el bloque puede escalar el texto para ocupar el ancho disponible en lugar de depender solo de un tamaño fijo y del salto de línea.

El changelog también registra casi 100 iconos redibujados con un lenguaje visual coherente basado en trazos, sangría y reducción de sangría en listas con Tab y Shift+Tab, imágenes de fondo definidas por URL y visualización de espacios de no separación durante la edición. La lista completa está en la publicación oficial de Gutenberg 24.0 en Make WordPress Core.

Qué puede afectar a temas y plugins

No todos los cambios de 24.0 son puramente visuales. Hay varios puntos que merecen atención de quienes mantienen extensiones del editor o dependen de APIs y componentes de Gutenberg.

ÁreaCambio en 24.0Qué probar
Galería y layoutsVariación Grid y propiedades responsivas por viewportCSS del tema, estilos de bloque, espaciados, comportamiento en tablet y pantallas pequeñas
Título del sitioSoporte para fit-textConflictos con tipografía, ancho máximo, cabeceras y estilos globales
API FetchPosibilidad de eliminar middleware registrado, exposición del handler predeterminado y retorno null en una respuesta 200 sin cuerpoPlugins que interceptan solicitudes, tratan respuestas vacías o sustituyen el flujo predeterminado
Editor de entradasDeprecación de la propiedad as en componentes de elementos de menú de pluginsExtensiones que añaden elementos al menú del editor usando esa propiedad
Build y paquetesAjustes de compatibilidad en el paquete de build y cambios de publicación de paquetesPipelines, dependencias, pruebas Vitest y builds que consumen paquetes de Gutenberg directamente
Site Editor v2Más pantallas consumen configuración de vista desde un endpointIntegraciones que dependen de la estructura de listas de páginas, patrones, plantillas y partes de plantilla

También hay correcciones en Theme JSON, el editor de medios, DataViews, accesibilidad y rendimiento. Para mantenimiento preventivo, lo más importante no es probar cada línea del changelog de forma aislada, sino identificar dónde el producto amplía el editor, sobrescribe estilos, depende de componentes experimentales o consume paquetes JavaScript del proyecto Gutenberg.

Qué vale la pena probar ahora

Los equipos con entornos de staging pueden instalar o actualizar el plugin Gutenberg y concentrarse en los flujos con mayor probabilidad de exponer regresiones.

  • Editar una entrada existente, cambiar título y contenido y comparar revisiones.
  • Crear galerías con distintas cantidades de columnas y revisar los estados de viewport.
  • Aplicar estilos propios del tema a Galería y Título del sitio y comprobar que el resultado siga siendo predecible.
  • Probar bloques de lista solo con teclado, incluidos Tab y Shift+Tab.
  • Validar extensiones que usan API Fetch, componentes del editor, DataViews o menús de plugins.
  • Ejecutar la suite de pruebas de temas y plugins en un entorno separado, sin tratar Gutenberg 24.0 como reemplazo de una instalación estable del Core.

Este tipo de pruebas genera señales útiles antes de la beta. Si un plugin depende de una propiedad deprecada o el CSS de un tema supone una estructura rígida de la Galería, es mejor detectarlo en desarrollo que durante la ventana de release candidate.

Qué anticipa Gutenberg 24.0 sobre WordPress 7.2

La versión 24.0 ayuda a ver la dirección del trabajo del editor durante el ciclo de WordPress 7.2, sobre todo en tres frentes: edición responsiva más controlable, revisiones más completas y consolidación continua de componentes e infraestructura del editor. También sigue el trabajo en Site Editor v2, DataViews y la biblioteca de componentes de interfaz.

Pero anticipar una dirección no equivale a confirmar inclusión en el Core. A 16 de septiembre, la página oficial de WordPress 7.2 todavía describe la versión como un ciclo en desarrollo y afirma que se considerarán nuevas funciones cuando estén razonablemente listas. Esto es especialmente importante para funcionalidades experimentales y cambios que todavía pueden recibir ajustes antes de Beta 1.

En la práctica, Gutenberg funciona como campo de desarrollo y pruebas para funciones del editor, mientras que el Core adopta versiones y funcionalidades mediante su propio proceso de integración, revisión y estabilización. Por eso, el changelog del plugin no debe convertirse en una lista definitiva de funciones de WordPress 7.2.

Qué todavía no debe tratarse como función confirmada del Core

Hay tres grupos que exigen cautela.

  • Experimentos: el propio changelog de Gutenberg separa elementos experimentales. Pueden cambiar, eliminarse o no llegar al Core en el mismo ciclo.
  • Refactorizaciones internas: cambios en componentes, DataViews, paquetes, endpoints y herramientas pueden preparar experiencias futuras sin aparecer para el usuario final exactamente como se ven en el plugin.
  • Funciones cerca del freeze: el calendario de 7.2 sitúa Beta 1 entre el 20 y el 22 de octubre. Hasta entonces, las decisiones de inclusión y estabilización pueden cambiar según el grado de preparación, las pruebas y la revisión del equipo de lanzamiento.

Para documentación pública, changelogs de producto y planificación de soporte, el enfoque más seguro es marcar las funciones como “disponibles en Gutenberg 24.0” hasta que exista una confirmación equivalente en las Dev Notes, el Field Guide o la documentación oficial de WordPress 7.2.

Calendario de WordPress 7.2 para seguir

El calendario oficial actual sitúa el ciclo en alpha durante septiembre de 2026. Las principales ventanas siguientes son:

  • Beta 1: 20 a 22 de octubre de 2026.
  • Beta 2: 27 a 29 de octubre.
  • Beta 3: 3 a 5 de noviembre.
  • Beta 4: 10 a 12 de noviembre.
  • Release Candidate 1: 17 a 19 de noviembre.
  • Lanzamiento final: 8 a 10 de diciembre de 2026.

Estas fechas ofrecen un ritmo práctico de pruebas. Antes de Beta 1, conviene explorar funciones nuevas y reportar problemas. Durante las betas, la atención suele desplazarse hacia correcciones y compatibilidad. Cerca de los release candidates, los equipos de temas y plugins deberían priorizar pruebas de regresión, lectura de Dev Notes y validación de las integraciones que realmente hayan llegado al Core.

Checklist para equipos de desarrollo

  • Actualizar Gutenberg solo en un entorno de pruebas.
  • Mapear extensiones que dependan de componentes, paquetes o APIs del editor.
  • Revisar el CSS aplicado a Galería, Título del sitio y layouts responsivos.
  • Probar revisiones, medios, listas y navegación por teclado.
  • Registrar diferencias entre el comportamiento del plugin Gutenberg y el comportamiento del Core.
  • Repetir las pruebas cuando se publique WordPress 7.2 Beta 1.
  • Usar las Dev Notes y el Field Guide de 7.2 como referencia final de compatibilidad.

Gutenberg 24.0 ya ofrece material concreto para homologación, pero la lectura más útil para desarrolladores es tratar la versión como una señal temprana del ciclo de WordPress 7.2 y no como una especificación final. Esa separación permite probar antes sin convertir funciones todavía en integración en promesas sobre el próximo Core.

Temas de este artículodesenvolvimento WordPresseditor de blocosGutenbergtemas e pluginsWordPress 7.2