Colaboración en tiempo real WordPress

La colaboración en tiempo real recibió una segunda oportunidad en el núcleo de WordPress y volvió a fallar. Dos semanas antes de que WordPress 7.0 saliera, el equipo de contribuidores retiró lo que iba a ser la funcionalidad estrella de la versión. La razón que se dio entonces fueron problemas de rendimiento de la base de datos que el equipo no podía comprometerse a corregir dentro de la ventana de lanzamiento. Seis semanas después, esa misma funcionalidad volvió al plan de WordPress 7.1, con un programa de pruebas al estilo FSE y el 19 de agosto como ancla del calendario.

WordPress 7.1 Mary Lou salió el 19 de agosto de 2026 sin edición multiusuario en vivo. Son dos lanzamientos mayores consecutivos. El resto de este artículo es el ciclo tal como estaba, más lo que las agencias deben hacer ahora que el paquete no contiene la funcionalidad.

Para las agencias que gestionan flujos editoriales sobre WordPress, el fallo tiene consecuencias concretas. La edición multiautor seguiría siendo el mayor cambio de flujo introducido en el núcleo en más de una década. Cambiaría la superficie de conflicto en textos largos, redefiniría qué significa un bloqueo sobre una entrada y desplazaría para qué sirve realmente el editor de bloques. Nada de eso llegó en 7.1. No entrene a los clientes en un recambio del bloqueo de entrada que no está ahí.

La tensión es familiar para cualquiera que haya pasado por una redacción digital: en El País, en Clarín o en una agencia de medios mediana en América Latina, los flujos editoriales reales ponen a varias personas a tocar la misma pieza dentro del mismo cuarto de hora, y es ahí donde se ve si la funcionalidad aguanta.

#Qué se retiró de la 7.0 y por qué

La colaboración en tiempo real en el editor de bloques necesita tres cosas para funcionar a escala: un canal de presencia y cursor con baja latencia, una estrategia de fusión sin conflictos para los cambios de bloques y una capa de almacenamiento capaz de sostener el historial fusionado sin romper el modelo existente de wp_posts y wp_postmeta.

El canal de presencia y cursor se resolvió durante el ciclo 6.x, con una combinación de long-polling y un transporte WebSocket opcional para sitios dispuestos a mantener esa infraestructura. La estrategia de fusión sin conflictos aterrizó en el plugin Gutenberg a finales de 2025 con un enfoque basado en CRDT. La tercera pieza, la capa de almacenamiento, es donde la 7.0 se rompió.

La implementación de la 7.0 persistía el estado de colaboración en una nueva tabla ligada a las revisiones de la entrada. En instalaciones pequeñas, funcionaba. A la escala de un entorno de pruebas de Automattic con más de 50 000 ediciones concurrentes, las escrituras a la nueva tabla generaban un retraso de replicación y una contención de bloqueos lo suficientemente graves como para que el equipo lo marcara como bloqueante del lanzamiento. La decisión de retirar se tomó a mediados de abril, dos semanas antes de la fecha GA de la 7.0.

El anuncio de Anne McCarthy sobre el nuevo programa de pruebas reconoce que la arquitectura de base de datos sigue siendo la pregunta abierta: el equipo tiene hipótesis sobre cómo solucionarla, pero, al inicio del ciclo del 7.1, no hay una implementación comprometida. Eso es inusual para una funcionalidad apuntada a un lanzamiento.

#El problema del huevo y la gallina

Amy Kamala, co-representante del equipo de Hosting, resumió la situación en una frase: “Need testing to make decision, need decision to do testing.”

Las decisiones arquitectónicas para la capa de almacenamiento tienen perfiles de coste muy distintos en entornos de alojamiento distintos. Una solución que funciona bien en una instalación de un solo servidor puede no sobrevivir a un setup con balanceo de carga y réplicas de lectura. Una solución que encaja en un entorno single-tenant de hosting gestionado puede no funcionar en multisitio a la escala a la que opera WordPress.com.

El ciclo del 7.0 intentó tomar la decisión arquitectónica por anticipado y luego ponerla a prueba. Ese orden falló porque los resultados de las pruebas invalidaron la decisión y no hubo tiempo para corregir el rumbo. El ciclo del 7.1 intenta invertir el orden: elegir primero los escenarios de prueba, validar qué variantes arquitectónicas los sobreviven y dejar que la variante superviviente determine la implementación.

Es el mismo patrón que el equipo de edición completa del sitio utilizó en el ciclo del 5.8 al 6.0, cuando la brecha entre el entorno de contribuidores y los entornos reales de alojamiento producía regresiones repetidas. El programa de pruebas FSE creó una población reclutada de personas probadoras que operaban sitios reales con plugins reales, y el programa sacó a la luz errores que el equipo de contribuidores no habría detectado de forma aislada.

Aplicar el mismo patrón a la colaboración en tiempo real es el nuevo movimiento estructural. Es también la razón por la que se pide a las empresas de alojamiento que ayuden a reclutar testers de su base de clientes gestionados.

#La forma del programa de pruebas

El anuncio de Anne McCarthy posiciona la población de pruebas en tres capas:

1. Pruebas orientadas a personas desarrolladoras. El ciclo de pruebas existente. Plugins, temas, superficie de la REST API, regresiones de rendimiento. Conducido por contribuidores y sobre infraestructura de Automattic.
2. Pruebas empresariales y deterministas. Realizadas con socios de alojamiento sobre entornos de clientes gestionados con carga controlada. Pensadas para validar que la arquitectura de almacenamiento sobrevive a escenarios de contención de la base de datos.
3. Usuarios reales especialmente implicados. La capa nueva. Reclutada entre agencias, medios y equipos de contenido que operan sitios WordPress en producción con la colaboración editorial como requisito real del flujo de trabajo.

La tercera capa es de donde vendrá la mayor parte del nuevo volumen de pruebas. El programa pide explícitamente sitios donde la colaboración en tiempo real resuelva un problema real, no instalaciones de prueba sintéticas.

Lo que se pide a quienes hacen pruebas:

• Flujos editoriales activos con más de un autor trabajando en simultáneo sobre textos largos
• Disponibilidad para ejecutar una versión candidata contra entornos de prueba
• Ciclo de reporte: revisiones semanales con un formulario estructurado de comentarios
• Informes de errores que capturen tanto el comportamiento del editor como métricas a nivel de base de datos desde la capa de alojamiento

Lo que reciben quienes hacen pruebas:

• Línea directa con el equipo de contribuidores que construye la funcionalidad
• Visibilidad sobre las decisiones arquitectónicas a medida que se toman
• Reconocimiento de patrocinio para los sitios que mantengan ciclos de prueba prolongados
• La vista previa más temprana posible de lo que la colaboración en tiempo real significará para su proceso editorial

Para agencias con clientes de medios, es la forma más directa de estar en la sala cuando se finaliza la funcionalidad. El beneficio para la agencia no es el reconocimiento. Es la vista previa de ingeniería.

#La fecha del 19 de agosto y lo que realmente entregó

WordPress 7.1 Mary Lou salió el 19 de agosto en WordCamp US en Phoenix. La fecha se mantuvo. La colaboración en tiempo real no. El calendario de pruebas de abajo es el ciclo tal como se planificó en junio, y se queda aquí porque muestra lo poco de margen que un reinicio arquitectónico llegó a tener.

Trabajando hacia atrás desde el 19 de agosto:

• Finales de julio: primera versión candidata. Congelación de funcionalidades. RTC tiene que ser lo bastante estable para públicos de prueba amplios. La decisión arquitectónica de la base de datos tiene que estar cerrada.
• Mediados de julio: Beta 3. Última oportunidad para cambios de comportamiento. Los datos del programa de pruebas deberían informar decisiones, no iniciarlas.
• Principios de julio: Beta 2. Última oportunidad para cambios arquitectónicos no triviales. Los datos de pruebas de los socios de alojamiento deberían estar dentro.
• Finales de junio: Beta 1. Primera compilación ampliamente probada. La arquitectura de almacenamiento debería estar ya comprometida.
• Mediados de junio: arranque del programa de pruebas. Personas probadoras reclutadas ejecutando compilaciones en entornos de prueba. Primer ciclo de comentarios.
• Principios de junio: reclutamiento. Ese era el plan. Las empresas de alojamiento debían reclutar personas probadoras. La función, aun así, no entró en el zip.

Ocho semanas eran tiempo suficiente para una arquitectura cerrada. No eran tiempo suficiente para un reinicio arquitectónico. La decisión de arquitectura seguía abierta cuando arrancó el ciclo. La 7.1 salió sin la funcionalidad. La 7.2 está ahora apuntada al 9 de diciembre de 2026. Trátela como fecha de planificación, no como RTC.

#Qué cambia la colaboración en tiempo real en los flujos de las agencias

Deje a un lado la pregunta de la base de datos por un momento. ¿Qué aspecto tiene en la práctica WordPress con colaboración en tiempo real para una agencia?

Tres cambios concretos de flujo que llegan con la funcionalidad:

• Los bucles de revisión editorial se colapsan. El flujo editorial actual de WordPress es secuencial. El autor escribe. El editor revisa cuando el autor termina. El autor atiende los comentarios. El editor aprueba. Con colaboración en tiempo real, autor y editor pueden trabajar en paralelo. Para agencias que gestionan calendarios editoriales para clientes de contenido, esto reduce el tiempo de ciclo por artículo y cambia el aspecto de las horas facturables. En una agencia de medios en Madrid o Buenos Aires, donde el editor de sección suele leer en paralelo al redactor durante una hora-rotación, la funcionalidad recorta un traspaso que hoy a menudo consume media jornada.
• La compatibilidad de plugins pasa a ser un problema vivo. Muchos de los plugins editoriales más instalados asumen edición de un único autor. Los guardados de campos ACF, el análisis de Yoast SEO, las actualizaciones del metabox de Rank Math, los metaboxes personalizados de taxonomía y una larga cola de plugins desarrollados por agencias necesitan revisarse en cuanto a seguridad de escritura concurrente. El Plugin Review Team ha sido claro: la colaboración en tiempo real va a sacar a la luz plugins con patrones de escritura inseguros.
• La UX del post lock se sustituiría. El conocido modal “esta entrada está siendo editada por…” desde WordPress 3.6 cedería ante indicadores de presencia. En 7.1 eso no ocurrió. El modal antiguo sigue siendo lo que ve la persona usuaria.

No son casos de borde. Es el impacto visible al usuario el primer día si la funcionalidad llega a salir. No salió en 7.1, así que nada de esto es un ticket de soporte del 19 de agosto. Conserve la auditoría de plugins. No reescriba materiales de formación para una UX que no está en el núcleo.

#La pregunta sobre arquitectura de base de datos, simplificada

El reto técnico central es sencillo. WordPress guarda el contenido de cada entrada en wp_posts.post_content como un único blob. Las revisiones crean nuevas filas. La colaboración en tiempo real necesita fusionar ediciones concurrentes en ese blob sin perder datos y sin generar un crecimiento descontrolado de revisiones.

Las tres variantes arquitectónicas actualmente en discusión:

1. Log de operaciones append-only. Una nueva tabla almacena operaciones individuales (insertar, borrar, cambio de formato) con timestamps e IDs de autor. El blob post_content se reconstruye desde el log de operaciones al guardar. Pro: resolución de conflictos limpia. Contra: alto volumen de escritura sobre la nueva tabla.
2. Snapshot más deltas. Snapshots periódicos de post_content más registros delta entre snapshots. Pro: volumen de escritura acotado. Contra: la lógica de tiempos de los snapshots es compleja y la recuperación a partir de snapshots perdidos es delicada.
3. Fusión en memoria con persistencia periódica. Estado de colaboración mantenido en memoria en la capa de aplicación, persistido a post_content y a una única fila de revisión por intervalos o en un guardado explícito. Pro: bajo volumen de escritura a la base de datos. Contra: requiere sticky sessions o una capa de caché compartida.

Cada variante tiene implicaciones para el alojamiento. La variante 1 estresa la base de datos. La variante 2 estresa la capa de aplicación con la lógica de tiempos. La variante 3 estresa la infraestructura de caché y de sesión, en la práctica Redis o Memcached y unos pools de PHP-FPM bien dimensionados.

El programa de pruebas del 7.1 debía probar esas variantes contra configuraciones de alojamiento realistas. La decisión arquitectónica debía estar lista a finales de junio. No llegó a tiempo. La 7.1 salió sin RTC.

#Qué deben hacer las agencias ahora

Tres movimientos concretos después del fallo del 7.1.

1. No prometa a los clientes edición multiusuario en vivo en 7.1. No está ahí. El flujo editorial secuencial sigue siendo el producto.
2. Audite su pila editorial de plugins de todos modos. Cada plugin que se engancha a save_post, wp_insert_post_data o a los guardados de meta del editor de bloques es candidato a escritura concurrente cuando RTC vuelva. La lista sirve aunque la funcionalidad esté a un ciclo de distancia.
3. No reescriba la formación del post-lock para agosto. El modal “esta entrada está siendo editada por…” sigue siendo el comportamiento de 7.1. Guarde la explicación de una página hasta que una guía de campo diga que los indicadores de presencia han salido.

#El patrón más grande: la forma de la contribución está cambiando

Detrás del ciclo del 7.1 hay una historia estructural que va más allá de la funcionalidad.

Durante la mayor parte de su historia, el desarrollo del núcleo de WordPress se ha guiado por decisiones de contribuidores probadas sobre entornos de contribuidores. El programa de pruebas FSE en el ciclo del 5.8 al 6.0 fue el primer intento de incorporar formalmente la prueba en entorno real al bucle de decisión del núcleo. El programa de pruebas de colaboración en tiempo real para el 7.1 es el segundo.

El patrón es que el proyecto se está volviendo más dependiente del input desde entornos de producción y menos capaz de aterrizar funcionalidades estrella solo sobre entornos de contribuidores. Es el mismo desplazamiento por el que pasan los proyectos de software libre maduros a medida que su base instalada se diversifica. También cambia quién tiene influencia sobre la dirección. Las agencias que llevan sitios reales de clientes con flujos editoriales reales son cada vez más las personas cuyo feedback da forma al core. Es una silla legítima en la mesa que no existía un ciclo de lanzamiento o dos atrás. La comunidad hispana de WordPress, desde WordCamp Madrid hasta los grupos de Buenos Aires y Ciudad de México, lleva varios ciclos pidiendo precisamente este tipo de implicación.

Para las agencias españolas, latinoamericanas y europeas, las conversaciones de pasillo en la WCEU de Cracovia en junio fueron la oferta de alianza de pruebas. Esa oferta no produjo un lanzamiento en 7.1. La siguiente fecha en el calendario es la 7.2, ahora apuntada al 9 de diciembre de 2026 junto con State of the Word. Acuda a esas conversaciones con datos de producción, no con una diapositiva comercial que diga que RTC está en el núcleo.

#La conclusión

La colaboración en tiempo real no es una funcionalidad lanzada. Falló en 7.0 y falló en 7.1. La decisión sobre la arquitectura de la base de datos no se cerró a tiempo. El programa de pruebas no pasó la funcionalidad de la línea.

Lo que sí está decidido: 7.1 Mary Lou salió el 19 de agosto sin edición multiusuario en vivo. El flujo editorial secuencial sigue siendo lo que se ejecuta. Siga Make WordPress Core para lo que la 7.2 liste de verdad. No trate un objetivo de diciembre como fecha de lanzamiento.

Los hilos en make.wordpress.org/core siguen siendo la fuente principal. La cobertura de lo que 7.1 sí entregó está en la nota del plan 7.1.

Última actualización: 2026-06-06.