Gutenberg 23.0: revisiones en plantillas y el panel de identidad: ¿te quitas dolores o solo sumas capas?

Cuando leo las notas de cada salida de Gutenberg ya sé más o menos qué va a pasar: un número redondo de PRs cerradas, nombres de contribuidores que ni pronuncio bien y tres pantallas nuevas que prometen ordenar el caos del Site Editor. En la 23.0, publicada el 22 de abril de 2026 según el equipo de Core, lo que más me ha llamado la atención no es la lista entera sino dos piezas que sí cambian cómo gestionas el sitio desde el editor: un panel de revisiones también para plantillas, partes de plantilla y patrones (experimental) y la incorporación de título y lema del sitio junto al logo y el icono en Design › Identity.

No voy a venderte que eso sea «revolucionario» en mayúsculas. Lo que veo es otro paso hacia que el editor se coma poco a poco los sitios donde antes ibas a Ajustes › Generales o al historial de revisiones solo cuando tocaba posts y páginas. Si mantienes proyectos serios en WordPress sabes que ahí está la fricción real: el cliente que rompe una cabecera sin querer, la plantilla que alguien sobreescribe sin backup claro, el hosting que no siempre te da diff útil fuera del contenido.

Revisiones donde antes solo había miedo

Según la entrada oficial en Make WordPress Core, al editar una plantilla, una parte o un patrón con revisiones disponibles aparece una fila Revisions en la barra lateral, con el mismo comportamiento que ya tenías para tipos de contenido «normales»: revisar versiones y restaurar. Está ligado al experimento del inspector unificado (Editor Inspector: Use DataForm) y hay que activarlo desde Gutenberg › Experiments si quieres probarlo en el Site Editor o editando una plantilla desde el editor de entradas.

Aquí es donde yo me pregunto si esto te salva el día o te mete en debates más largos. Por un lado, tener historial explícito en entidades que antes vivían en una zona más «fría» ayuda a que agencias y freelancers puedan decir al cliente «mira, aquí está lo que había antes». Por otro, cada cosa experimental es una etiqueta de «pendiente de estabilizar»: si tu política interna es no tocar experimentos en producción igual sigues exportando JSON y rezando.

Identidad en un solo sitio (literalmente)

Título y lema del sitio pasan al panel Design › Identity, que ya reunía logo e icono desde la 22.8. La idea, explícita en la misma nota del lanzamiento, es que los cuatro ajustes queden como un formulario coherente y que los cambios se reflejen en el lienzo al escribir porque escriben sobre la misma entidad root/site que consumen los bloques correspondientes.

Para ti que montas tiendas o webs corporativas suena a detalle de UX; para quien lleva marcas white‑label es menos horas explicando por qué el lema no coincide entre sitio y vista previa. Lo que no desaparece es la responsabilidad de quién puede entrar ahí: democratizar controles no sustituye políticas ni capacitación.

Colaboración en tiempo real y plugins viejos

La nota dedica espacio a que la colaboración en tiempo real avanza en compatibilidad con meta boxes antiguos: los autores pueden marcar meta boxes como compatibles con un flag nuevo y los administradores pueden intervenir vía el hook filter_block_editor_meta_boxes. También menciona mejoras de fiabilidad en sincronización y que el hook de activación de Gutenberg respeta la constante WP_ALLOW_COLLABORATION, cosa que los hosts pueden usar como interruptor.

Yo lo leo así: el núcleo está empujando un modelo de trabajo simultáneo que choca con buena parte del ecosistema real de plugins que aún arrastra PHP en meta boxes. Que exista una vía técnica no significa que tu stack favorito ya esté listo; solo que la culpa deja de ser siempre «desactivamos colaboración entera».

Pequeños grandes líos: Guidelines renombrado

Si tenías activado el experimento Guidelines en releases anteriores, la 23.0 renombra identificadores internos y el propio aviso dice que el flag puede aparecer desactivado tras actualizar: hay que volver a activarlo en Experiments y reintroducir datos. Es el tipo de fricción invisible que en proyectos multicliente te puede pillar un martes cualquiera cuando «solo» actualizaste el plugin.

En paralelo, el blog para desarrolladores de abril de 2026 resume líneas de trabajo del mes vinculadas al editor y paquetes WP; no sustituye la lectura de Core pero sirve para ubicar el ritmo de cambios si llevas dependencias que asumen una versión concreta.

¿Qué me llevo con todo esto? Que Gutenberg sigue sumando piezas de gobierno del sitio dentro del editor —revisiones e identidad— mientras la colaboración en tiempo real fuerza a reconciliar el pasado en forma de meta boxes. Si tu hosting no da margen o tus plugins no están al día igual solo ves más superficie de configuración.

Si mañana tu cliente pudiera tocar título, lema y plantillas con revisiones visibles pero tu hosting desactivara la colaboración en vivo por estabilidad, ¿preferirías bloquear esos controles avanzados por política o priorizar la experiencia «moderna» y asumir más soporte cuando algo experimental pete?

Fuentes

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Scroll al inicio