El 17 de junio salió Gutenberg 23.4 y, como casi siempre, el titular suena a alivio inmediato: subidas resilientes, reintentos con backoff exponencial, cola que aguanta cuando se cae la red. Si gestionas webs con clientes que suben fotos desde el móvil en un parking con cobertura regular, te entiendo. He visto demasiadas veces la barra de progreso congelada y el mensaje genérico de error que no dice nada útil.
La nota oficial en Make WordPress lo resume bien: el editor distingue ahora entre un fallo del servidor y una caída de red, retiene la cola si el dispositivo se queda offline y reanuda cuando vuelve la conexión. También añade snackbars con el progreso por lotes, para que sepas cuántas imágenes van y cuántas quedan en espera. Suena a producto maduro. Y en parte lo es.
Pero antes de celebrarlo como la solución definitiva, conviene leer el análisis que ha circulado en foros y blogs técnicos en inglés estos días. The WP Clan lo encuadra dentro de la iteración Client Side Media de WordPress 7.1, con 23 de 33 tareas completadas. O sea: estamos en mitad del camino, no en la meta. Y eso cambia mucho cómo lo vendes a un cliente que cree que «actualizar el plugin» le quita dolores de cabeza para siempre.
Lo que sí mejora de verdad
La pieza más sólida es el retry con backoff exponencial. Antes, una subida interrumpida en 4G te obligaba a volver a elegir el archivo. Ahora el editor reintenta con intervalos crecientes en lugar de martillear el servidor cada dos segundos con el mismo JPEG de 8 MB. Para redacciones con varios autores en remoto, eso reduce fricción real.
Otra mejora relevante es el techo al procesamiento de imágenes en el cliente. WordPress 7.0 metió compresión con WebAssembly en el navegador, y eso funciona hasta que alguien intenta subir un HEIC de 60 megapíxeles y el tab se convierte en un ventilador. Gutenberg 23.4 limita qué tamaños procesa el pipeline WASM y delega al servidor lo que se le va de las manos. Bien pensado. En mi experiencia, el cuello de botella no era solo la red: era el propio navegador ahogándose antes de que la petición llegara al hosting.
También entran detalles menores pero útiles: soporte UltraHDR, transformaciones de Columns y Gallery a layouts Grid, y un experimento para probar React 19 antes de que llegue al core. Cosas de desarrollador, sí, pero con impacto en compatibilidad de temas y plugins que mucha gente ignora hasta que algo petar.
Lo que no te cuentan en el changelog
El roadmap de WordPress 7.1, publicado el 19 de junio, insiste otra vez en colaboración en tiempo real, Notes con sugerencias, Guidelines para IA editorial… Un ecosistema cada vez más complejo. Gutenberg 23.4 mete parches de fiabilidad en RTC —persistencia de documentos, overlays que se re-renderizan cuando cambia el árbol de bloques— pero la colaboración en vivo sigue sin estar en el core estable. Ya pasó con Armstrong: la función estrella se quedó fuera por estabilidad. ¿Cuántas veces vamos a probar betas rotas antes de que llegue algo que aguante un lunes de producción?
Y aquí está mi principal crítica: las subidas resilientes enmascaran problemas de infraestructura que deberías haber resuelto antes. Si tu hosting tarda 40 segundos en aceptar un PNG de 2 MB, reintentar con backoff no arregla el servidor lento: solo alarga la agonía con más paciencia. Si el límite de subida en PHP sigue en 2M porque nadie tocó el php.ini, el editor puede ser tan listo como quieras; la petición morirá igual.
En el blog para desarrolladores de WordPress de junio recalcan que hay que probar plugins y temas contra 7.0 y activar Gutenberg en su última versión para validar cambios. Traducción al mundo real: otra tarea más en la lista del freelance que ya va justo de horas. No es culpa del equipo de Gutenberg; es la realidad de un CMS que avanza más rápido que la capacidad de mantenimiento de la mayoría de sitios en producción.
El contraste incómodo: seguridad en junio
Mientras el editor gana resiliencia en subidas, el reporte de Wordfence de la primera semana de junio sigue contando decenas de vulnerabilidades nuevas en plugins —tres críticas, algunas explotadas como zero-day antes del parche. Kirki Freeform Page Builder, ARMember Premium, Hippoo Mobile App… nombres que suenan a nicho hasta que miras los cientos de miles de instalaciones activas. Actualizar Gutenberg no te protege de eso. De hecho, cada capa nueva —IA nativa, procesamiento WASM, conectores— amplía la superficie de ataque si no tienes un proceso de revisión antes de pulsar «Actualizar todo».
Me parece un desajuste tipico del ecosistema WordPress: el marketing habla de experiencia de autor impecable y el día a día del administrador sigue siendo parchear plugins revisar logs y rezar para que la copia de seguridad de ayer sirva.
Qué haría yo antes de vender esto a un cliente
Primero, medir tiempos reales de subida en el entorno de producción, no en localhost. Segundo, revisar límites de PHP, memoria y timeout del hosting antes de confiar en la cola inteligente del editor. Tercero, probar Gutenberg 23.4 en staging con los mismos temas y plugins del cliente —sobre todo si usan bloques personalizados o integraciones de medios. Cuarto, no prometer colaboración en tiempo real hasta que salga estable en core; el roadmap de 7.1 apunta a agosto, pero ya sabemos cómo acabó Armstrong.
Gutenberg 23.4 es un paso técnico sensato. No es la revolución que algunos titulares insinúan. Arregla fricciones reales del editor, sobre todo en móvil y en redes inestables, pero no sustituye un hosting bien dimensionado ni un mantenimiento serio del stack.
Si mañana un cliente te pide «activar lo nuevo de WordPress para que las fotos no fallen», ¿le explicas que primero hay que revisar su plan de hosting compartido de 3 euros, o le instalas Gutenberg 23.4 y cruzas los dedos?