El 3 de junio de 2026 el equipo de WordPress abrió un programa de outreach para probar la edición colaborativa en tiempo real de cara a WordPress 7.1. Suena bien hasta que recuerdas que esa misma función era la estrella de WordPress 7.0 Armstrong y acabó fuera del plato final. Ahora te piden a ti —agencia, pyme, hoster— que la pruebes en producción mientras ellos apuntan al 19 de agosto para el release.
Yo llevo años montando webs en WordPress para clientes que no saben lo que es un commit. Cuando Armstrong llegó el 20 de mayo sin colaboración en vivo, no fue una sorpresa técnica: fue un patrón que ya habíamos visto con el Site Editor, con los content types y con mediales promesas que terminan en un experimento del plugin Gutenberg. Lo que me mosquea de esta segunda vuelta no es que fallen; es el reparto de riesgos.
Según el resumen de junio del blog de desarrolladores, la colaboración no entró en 7.0 pero el trabajo sigue activo para 7.1. El calendario provisional marca Beta 1 el 15 de julio, Release Candidate 1 el 5 de agosto y release final el 19 de agosto, justo en la ventana de WordCamp US. Nueve semanas para validar algo que ya arrastraba problemas de memoria y sincronización en ciclos anteriores. ¿Te suena realista si gestionas diez sitios con plugins de terceros?
El programa, descrito con detalle en The WP Clan, no se limita a empresas grandes. Buscan «early adopters» en ONGs, pequeños negocios, marketers, diseñadores y redacciones. Los hosts tienen su propia convocatoria para sacar a clientes a probar ediciones concurrentes. A cambio prometen badges del equipo de pruebas y créditos al final del ciclo. En mi experiencia, un badge no compensa una página corporativa bloqueada un martes a las once de la mañana.
La prueba se hace activando la opción en Ajustes > Escritura del plugin Gutenberg, no en core. Eso tiene sentido técnico —iterar sin atar el release entero— pero traslada otra vez la fricción al instalador: tienes que explicar a un cliente por qué necesita un plugin de desarrollo para algo que le vendieron como el futuro del CMS. Y aquí viene la parte que pocos comentan: en las conversaciones del equipo, varios contribuyentes señalaron que el build actual de Gutenberg ni siquiera incluye las tablas de base de datos que ya se probaron en el ciclo 7.0. Es decir, pruebas en un terreno que puede cambiar debajo de tus pies.
No digo que la función sea inútil. Al contrario: equipos de más de tres personas editando la misma landing sin pisarse los cambios es un dolor real. Gutenberg 23.3 ya mejoró la sincronización de notas a nivel de bloque sin refrescar la página, y eso demuestra que el núcleo avanza. Pero avanzar en el plugin y pedir validación masiva en hosting compartido son dos cosas distintas. En Plesk o en un VPS barato, con object cache a medias y un par de plugins de SEO que enganchan al editor, el escenario real dista mucho del Playground donde muchos contribuyentes hacen smoke tests.
El llamamiento de voluntarios para 7.1 deja claro que el squad de release aún se estaba formando a principios de junio. Eso, sumado al outreach público, me huele a cronograma optimista. Si tu negocio depende de publicar contenido sin downtime, participar como conejillo de indias en agosto —mes de vacaciones en España, por cierto— es una apuesta que solo tiene sentido si aislas entorno y tienes rollback en menos de cinco minutos.
Tampoco ayuda el contexto político del proyecto. Armstrong salió en medio de tensiones en la gobernanza que ya conoces si sigues el ecosistema. Cuando la confianza en el roadmap flaquea, pedir trabajo gratuito de QA a la comunidad se lee como externalizar costes de ingeniería. Los hosts que empujen la prueba a clientes pequeños sin SLA claro se exponen a tickets de soporte que WordPress.org no va a pagar.
¿Qué haría yo? Si tienes un staging clonado con el mismo stack de producción, activa la colaboración allí con un usuario de prueba y un flujo real: dos personas editando la home, un tercero subiendo imágenes pesadas, un cuarto con el clásico plugin de campos personalizados que inyecta metaboxes legacy. Documenta qué se rompe. Comparte feedback en el canal de Slack si te apetece contribuir. Pero no lo despliegues en la tienda WooCommerce que factura el 80% del trimestre solo porque te suena moderno editar «como en Google Docs».
WordPress necesita esta función para competir con herramientas que ya la dan por sentada. Lo entiendo. Lo que no me cuadra es el guion: prometer en 7.0, retrasar, y luego montar un coro de voces diversas para validar infraestructura que ni siquiera está cerrada. Si eres hoster, piensa si tu margen soporta el soporte extra. Si eres agencia, valora si puedes facturar «horas de laboratorio WordPress» o si te las comerás para quedar bien en la foto de la comunidad.
La colaboración en vivo llegará tarde o temprano. Cuando lo haga, querrás saber si tu stack la soporta, no si fuiste de los primeros en sangrar por ella. Mientras tanto, Armstrong ya está en la calle: revisa compatibilidad de plugins, bindings y cambios de accesibilidad antes de obsesionarte con un experimento que todavía vive en Gutenberg.
Si tu proveedor de hosting te ofreciera activar la beta de colaboración de WordPress 7.1 en tu tienda online a cambio de un 15% de descuento en la cuota mensual, ¿firmarías el consentimiento sabiendo que no hay SLA de rollback?