Si llevas un proyecto serio encima con WordPress probablemente ya has visto pasar el rumor de la colaboración en tiempo real y las capturas chulas del editor compartido. Yo también me ilusioné en su día. Pero llega mayo de 2026 y el mensaje oficial es otro: esa pieza no entrará en WordPress 7.0. No es un retraso menor; es un frenazo explícito ante problemas de superficie expuesta, condiciones de carrera, carga en servidor y eficiencia de memoria, tal y como resumen en Make Core. A mi me suena a decisión sensata a nivel de proyecto, pero muy incómoda si vendías a tu cliente un roadmap imaginario.
En paralelo el blog de desarrolladores publica el repaso de mayo como si fuera un sprint interminable: sistema de content types tomando forma (todavía experimental), paquete nuevo @wordpress/grid, cambios en REST de plantillas, tirones de CSS por capacidades y un montón de mejoras de bloques. Es decir: el núcleo sigue acelerando en el laboratorio mientras muchas pymes siguen en hosting compartido rezando para que el último plugin «de formularios bonitos» no les deje el sitio en ventana de mantenimiento. Esa tensión no la arregla ningún changelog.
Del experimento de content types me quedo con una lectura que no siempre se dice en voz alta: esto es trabajo de horizonte largo, pegado a un issue abierto en Gutenberg que vale la pena guardar en favoritos pero no firmar en un presupuesto cerrado. Representa la dirección donde parece que quiere ir WordPress para ordenar tipos de contenido más allá del CPT clásico que cargamos a paladas desde hace años. Bien. Pero si tú vives de entregar en ocho semanas ya sabes que «experimental en trunk» no paga facturas, ademas el cliente no lee GitHub: lee la web y el precio final.
La retirada de la colaboración en vivo del 7.0 debería servirte como aviso de método. El calendario oficial ya movió fechas para dar aire a trabajo arquitectónico y ahora tenemos Release Candidate 3 sobre la mesa con el aviso de rigor: prueba temas y plugins contra 7.0 ya, no el martes anterior al go-live. Yo he visto suficientes staging «casi iguales» a producción como para no fiarme de un «en principio no rompe nada». Si tu negocio depende de Woo, de un page builder o de un stack de membership, el coste real no es pulsar Actualizar sino tener un plan cuando algo asume una API que cambia más rápido que tu documentación interna.
Y aquí viene lo que menos me gusta del discurso aggregator-friendly: las listas mensuales de novedades suenan a progreso lineal cuando en la práctica estás navegando tres velocidades distintas. La primera es la del core en modo trunk con experimentos. La segunda es la de temas compatibles pero aún amortizando deuda de bloques legacy. La tercera es la del usuario final que solo quiere titular, imagen y botón sin que se le desmorone el spacing. Meter a todo el mundo en la misma narrativa «WordPress avanza» es cómodo pero te impide comunicar riesgos. Si omites ese matiz cuando vendes un rediseño te estás buscando un ticket de soporte envenenado.
No estoy pidiendo parar el desarrollo; estoy pidiendo honestidad operativa. Si Core decide posponer una feature tan visible como la colaboración en vivo es señal de que el coste de mantener promesas públicas es altísimo. Debería servirte de espejo con tus propias hojas de ruta: menos teatro de demo, más pruebas de carga, menos dependencia de un único maestro-builder que nadie más sabe retocar cuando el proyecto crece dos años.
Yo que tú usaría estos días antes del 20 de mayo como una ventana táctica: revisar backups, crear entorno RC, documentar overrides de CSS por rol (por si alguien sin edit_css esperaba comportamientos antiguos) y tener un comunicado tipo «qué esperar / qué no» para el equipo de contenido. Eso marca diferencia profesional porque separa gestión tecnológica de postureo en redes.
Para cerrar voy al grano. WordPress puede seguir siendo una plataforma excelente para proyectos web con sentido pero solo si empiezas a mirar cada «gran hito» con el mismo cinismo útil que aplicas cuando un cliente te dice que necesita MVP «para dentro de tres días». El ecosistema te da herramientas potentes si no confundimos novelty con readiness.
Si después de todo esto siguen saliendo lanzamientos oficiales, documentación abierta en Make y avisos de RC con tiempo, lo mínimo es leerlos y traducirlos al idioma que entienden quien manda en el proyecto: riesgos, fechas duras y horas humanas necesarias.
Y la pregunta que me resumo después de seguir estos hilos tan oficiales: si tu cliente insistiera mañana en que el lanzamiento debe incluir edición colaborativa en vivo porque «lo han visto en un vídeo», le explicas con papel y lápiz por qué 7.0 no lo lleva ya o prefieres asumir tú mismo el riesgo y callar esperando magia?
Fuentes
- What’s new for developers? (May 2026) – WordPress Developer Blog
- Real-time collaboration will not ship in WordPress 7.0 – Make WordPress Core
- WordPress 7.0 Release Party: Updated Schedule – Make WordPress Core
- WordPress 7.0 Release Candidate 3 – WordPress News
- Tracking issue: Content Types experiment – GitHub WordPress/Gutenberg (#77600)