Hace una semana parecía que todo el lanzamiento de WordPress 7.0 iba por un buen camino, pero parece que tras el lanzamiento de las versiones candidatas se han replanteado algunas situaciones.
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.
Transcripción del programa
Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.
En este episodio encontrarás la información del 30 de marzo al 5 de abril de 2026.
WordPress 7.0 no saldrá el 9 de abril como estaba previsto. El 31 de marzo se publicó un anuncio que pocas veces se ha visto en el historial del proyecto: el lanzamiento se retrasa después de haber entrado ya en fase de Release Candidate. Es una decisión inusual, y merece explicarse con detalle.
La raíz del problema es la base de datos de la colaboración en tiempo real.
La colaboración en tiempo real es una de las funciones más ambiciosas de WordPress 7.0. Para que varios usuarios puedan editar el mismo post simultáneamente, el sistema necesita almacenar dos tipos de información: los cambios en el contenido del documento, y los datos de presencia, es decir, quién está editando y dónde tiene el cursor cada persona.
Desde el principio del ciclo se debatió si era necesaria una tabla específica en la base de datos para gestionar esta información. La propuesta existía, pero se pausó antes de que llegara la fase RC por falta de tiempo y porque el diseño no estaba suficientemente maduro. En su lugar se optó por una solución provisional: guardar los cambios en postmeta y la información de presencia en transients, con un manejo especial para evitar invalidaciones de caché excesivas.
Esa solución funcionaba técnicamente, pero Matt Mullenweg expresó su preferencia por tomarse el tiempo necesario para diseñar bien la tabla personalizada desde el principio, en lugar de lanzar con una solución de compromiso que luego sería difícil de cambiar. Su argumento es que la arquitectura de datos de una función tan central como la colaboración en tiempo real tiene que aguantar el paso del tiempo, y que merece más reflexión de la que hubo.
Además, en las últimas semanas surgió una consideración adicional: más allá de la colaboración entre usuarios humanos, el sistema de sincronización podría necesitar dar soporte a casos de uso más amplios, como la sincronización entre un agente de IA y el editor, o entre distintos contextos de edición. Eso amplía el alcance del problema y refuerza la necesidad de diseñar bien las primitivas desde el principio.
El equipo de lanzamiento publicó una nueva entrada explicando las implicaciones concretas de la pausa, con algunos puntos a destacar.
La rama de desarrollo para la versión 7.1 de WordPress queda cerrada a nuevos commits hasta nuevo aviso, para evitar conflictos durante el trabajo en la rama 7.0. Cualquier cambio que se aplique a la rama 7.0 requiere la aprobación de dos committers distintos, con un proceso más riguroso que el habitual. Las únicas excepciones permitidas son correcciones de errores introducidos en el ciclo actual, mejoras en las herramientas de construcción y tests, y cambios específicos relacionados con la estabilidad de la colaboración en tiempo real y la pantalla de Conectores de IA.
Las nuevas versiones de prerelease quedan en pausa hasta el 17 de abril. El nuevo calendario completo se publicará a más tardar el 22 de abril. En términos de versiones, el equipo ha decidido que las próximas versiones se llamarán RC3, RC4, etcétera, aunque técnicamente el proyecto esté en una fase más parecida a una beta. Cambiar a betas crearía problemas con la función version_compare de PHP, que no reconocería la beta 7 como más reciente que la release candidate 2, lo que podría romper las actualizaciones automáticas.
Durante la pausa, el equipo recomienda usar las versiones nocturnas generadas desde la rama 7.0 para seguir probando.
Además, también se anunció un tema que afectará a muchos desarrolladores de plugins durante el período de transición. Los plugins que usan meta boxes clásicos, aquellos que envían datos al guardar el post mediante el hook save_post, no son compatibles con la colaboración en tiempo real. Cuando WordPress detecta meta boxes en un post, desactiva la colaboración para ese post completo.
La razón es que los meta boxes funcionan fuera del sistema de datos de Gutenberg, por lo que no pueden participar en la sincronización de cambios entre colaboradores. El período de 7.0 es una ventana de tiempo para que los desarrolladores de esos plugins migren a APIs más modernas del editor de bloques.
Así que el retraso de WordPress 7.0 es una decisión deliberada y fundamentada para no comprometer la arquitectura de una función que tiene el potencial de cambiar de forma sustancial cómo se trabaja en WordPress a nivel profesional. Pero no sabremos nada hasta el 22 de abril.
El equipo de Core ha lanzado documentación para los que quieran ir más allá de la configuración por defecto de la colaboración en tiempo real en WordPress 7.0.
Por defecto, la sincronización entre colaboradores funciona mediante sondeo HTTP: el editor consulta al servidor cada cierto tiempo para ver si hay cambios. Es una solución que funciona en cualquier instalación de WordPress sin requerir infraestructura adicional, pero tiene sus limitaciones en latencia y carga del servidor cuando hay muchos colaboradores activos.
WordPress 7.0 permite sustituir ese mecanismo por uno propio mediante el filtro sync.providers en el lado del cliente. Esto abre la puerta a usar WebSockets u otros transportes de tiempo real que ofrezcan actualizaciones instantáneas y solo consuman recursos cuando hay cambios reales.
El equipo de Formación ha lanzado el Programa de Formación de Facilitadores, una iniciativa gratuita y abierta para preparar a personas que quieran enseñar WordPress a otros. No hay proceso de solicitud ni credenciales previas requeridas. Está pensado para educadores universitarios, organizadores de comunidades, freelancers, desarrolladores o cualquier persona que conozca WordPress y quiera compartir ese conocimiento de forma estructurada.
El programa tiene tres componentes: cursos autoguiados en Learn WordPress, guías de facilitación con agendas detalladas para talleres de dos o tres días, y un manual general que orienta a los facilitadores sobre cómo aprovechar el programa. El primer curso ya está disponible y cubre los programas educativos de WordPress: WordPress Credits, Campus Connect y los Student Clubs, con 9 módulos y 41 lecciones.
La idea detrás del programa es crear una red distribuida de facilitadores que puedan llevar la formación en WordPress a sus comunidades de forma independiente, sin depender de un equipo central. A medida que el ecosistema de credenciales de WordPress crezca, los facilitadores que completen los cursos relevantes podrán acreditar esa experiencia de forma reconocida profesionalmente.
El equipo de Comunidad ha publicado una propuesta para explorar la organización de un nuevo Community Summit en 2027 o 2028, aprovechando una de las WordCamp principales. El último que se celebró fue en 2023 en Estados Unidos, y la idea es que el próximo tenga lugar en Asia o Europa para dar más representación a esas regiones.
El Community Summit es un espacio de trabajo más íntimo y enfocado, donde contribuidores de diferentes equipos se reúnen para debatir en profundidad los temas que afectan al proyecto, tomar decisiones y alinear esfuerzos. Las ediciones anteriores de 2012, 2014, 2017 y 2023 demuestran que este tipo de encuentro tiene un impacto real en la dirección del proyecto.
Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.
Un abrazo, y hasta el próximo programa.
Deja una respuesta