WordPress 7.1 colaboración en tiempo real: el segundo intento, el programa de outreach al estilo FSE y el plazo de ocho semanas

La colaboración en tiempo real recibe una segunda oportunidad en el core de WordPress. 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 regresa al roadmap de WordPress 7.1, con un programa de outreach al estilo FSE arrancando y una fecha de lanzamiento, el 19 de agosto, anclando el calendario.

Para las agencias que gestionan flujos editoriales sobre WordPress, esto tiene consecuencias concretas. La edición multiautor es el mayor cambio de flujo introducido en el core en más de una década. Cambia la superficie de conflicto en textos largos, redefine qué significa un “lock” sobre una entrada y desplaza para qué sirve realmente el editor de bloques. El intento del 7.1 también señala cómo está cambiando la forma de la contribución a WordPress: un programa de outreach para algo que, en el fondo, es una pregunta de arquitectura de base de datos es un formato nuevo para el proyecto.

Hemos seguido el anuncio, leído los hilos en make.wordpress.org/core y participado en dos de las primeras conversaciones de outreach. A continuación, lo que las agencias deberían saber al inicio del ciclo del 7.1. 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 outreach 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 Full-Site Editing 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 outreach FSE creó una población reclutada de testers que operaban sitios reales con plugins reales, y el programa sacó a la luz bugs 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 outreach

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. Passionate real-world early adopters. 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 outreach 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 correr una build de release candidate contra entornos de staging
• Ciclo de reporte: check-ins semanales con un formulario estructurado de feedback
• Reportes de bugs 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 por qué importa

WordPress 7.1 está programado para el 19 de agosto. La fecha no es arbitraria. Coincide con WordCamp US en Phoenix, donde el lanzamiento se celebrará como parte del programa de la conferencia. La fecha de lanzamiento ancla también todo el calendario de pruebas del 7.1.

Trabajando hacia atrás desde el 19 de agosto:

• Finales de julio: Release Candidate 1. Feature freeze. 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 outreach 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 build ampliamente probada. La arquitectura de almacenamiento debería estar ya comprometida.
• Mediados de junio: arranque del programa de outreach. Testers reclutados ejecutando builds en staging. Primer ciclo de feedback.
• Ahora (principios de junio): reclutamiento. Las empresas de alojamiento reclutan testers, el equipo de contribuidores estructura el material de outreach.

Ocho semanas son tiempo suficiente. No son tiempo suficiente para un reinicio arquitectónico. La implicación para las agencias que siguen esto: dé por hecho que la decisión arquitectónica se tomará para finales de junio. Si tiene una opinión sólida o datos de producción que deberían informarla, hágalos llegar al equipo de contribuidores en las próximas tres semanas.

#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 sustituye. El conocido modal “esta entrada está siendo editada por…” que existe desde WordPress 3.6 se está descontinuando en favor de indicadores de presencia. Las personas usuarias que llevan una década entrenadas en el comportamiento antiguo tendrán que aprender el nuevo patrón. Las comunicaciones internas y los materiales de formación deben actualizarse.

No son casos de borde. Es el impacto visible al usuario el primer día tras el lanzamiento de la funcionalidad.

#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 outreach del 7.1 se está diseñando para probar las tres variantes contra configuraciones de alojamiento realistas. Qué variante sobreviva es la decisión arquitectónica que el equipo necesita tomar para finales de junio.

#Qué deben hacer las agencias este mes

Tres movimientos concretos para agencias que llevan WordPress para clientes editoriales o de medios.

1. Audite su stack editorial de plugins. 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. Liste los plugins, anote a sus autores y compruebe si existen declaraciones públicas sobre compatibilidad con RTC. Los que no tienen declaraciones son los que hay que planificar alrededor.
2. Presente a un cliente editorial al programa de outreach. Si tiene un cliente con dos o más editores trabajando sobre la misma superficie de contenido, ese es exactamente el flujo que el equipo de outreach quiere. Inscribirlo coloca a su cliente en la población de prueba y a usted en la sala de la conversación arquitectónica. La inscripción se hace a través del artículo en make.wordpress.org/core enlazado desde el anuncio de McCarthy.
3. Prepare formación interna para el cambio de UX del post-lock. Aunque sus clientes no usen activamente la colaboración en tiempo real, el cambio visible al comportamiento de “esta entrada está bloqueada” generará tickets de soporte en agosto. Tenga una explicación de una página lista.

#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 core de WordPress se ha guiado por decisiones de contribuidores probadas sobre entornos de contribuidores. El programa de outreach 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 core. El outreach 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, la implicación es directa: la WCEU en Cracovia esta semana va a acoger conversaciones sobre alianzas de prueba de RTC en los pasillos, entre las pausas patrocinadas y junto al café. Hay que estar allí.

#La conclusión

La colaboración en tiempo real todavía no es una funcionalidad lanzada. La decisión sobre la arquitectura de la base de datos todavía no se ha tomado. El programa de outreach sigue reclutando. Nada de esto está cerrado.

Lo que sí está decidido: la funcionalidad ha vuelto al roadmap, la fecha de lanzamiento del 19 de agosto es el ancla de trabajo, la estrategia de pruebas se ha ampliado más allá de los entornos empresariales y de contribuidores, y se pide a las empresas de alojamiento que ayuden a reclutar testers en producción. Si la decisión arquitectónica aterriza para finales de junio y los datos de outreach la validan, WordPress 7.1 entrega la funcionalidad en WordCamp US.

Para las agencias con clientes editoriales, este es el ciclo de lanzamiento en el que conviene participar. La forma de la edición multiautor en WordPress para el resto de la década se está definiendo en las próximas ocho semanas.

El anuncio en make.wordpress.org/core y los detalles del programa de outreach están en Make WordPress Core. La cobertura continúa en The Repository y en el blog de WPPoland a lo largo de todo el ciclo del 7.1.

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