Finalmente, el trabajo del Real Time Collaboration vendrá en WordPress 7.1 y no en 7.0, teniendo en cuenta los problemas de rendimiento y los cambios que se necesitan para su nueva implementación.
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 4 al 10 de mayo de 2026.
La gran noticia de esta semana en torno a WordPress 7.0 es que la colaboración en tiempo real no estará en la versión final. Matt Mullenweg tomó la decisión de retirarla citando problemas de superficie de ataque, condiciones de carrera, carga en servidor, eficiencia de memoria y bugs recurrentes detectados en pruebas de fuzz. Es una decisión difícil dado el trabajo invertido, pero se toma en beneficio de lanzar una versión estable. La característica se reevaluará durante el ciclo de WordPress 7.1, y mientras tanto sigue disponible a través del plugin de Gutenberg para quien quiera seguir probándola.
Los datos técnicos detrás de esa decisión también se han publicado. Ocho entornos de hosting distintos, incluyendo configuraciones con y sin caché de objetos persistente, participaron en las pruebas de rendimiento. El análisis muestra con bastante claridad que la estrategia de almacenamiento con una tabla dedicada combinada con caché de objetos para la detección de presencia de usuarios es la ganadora: aproximadamente un 52% más rápida que la implementación actual, y la única que escala bien tanto con caché como sin ella. Esta información guiará el trabajo en la siguiente iteración de la característica.
Con todo eso sobre la mesa, el 8 de mayo se publicó la Release Candidate 3 de WordPress 7.0, que ya incorpora la retirada de la colaboración en tiempo real y resuelve más de 143 incidencias adicionales desde el RC2. La fecha de lanzamiento final sigue siendo el 20 de mayo. Si tienes plugins o temas, es el momento de probarlos contra este RC3 y actualizar el campo Tested up to a 7.0.
Ha llegado Gutenberg 23.1 con una buena cantidad de novedades, aunque muchas todavía en modo experimental. Lo más llamativo para el día a día es la mejora en la subida de imágenes: las miniaturas ahora se generan en paralelo en lugar de secuencialmente, lo que se nota especialmente al subir imágenes en bloque a través del bloque de galería o en conexiones lentas.
En el apartado experimental hay cosas interesantes. La gestión de taxonomías personalizadas desde el administrador sin escribir PHP es una de las más esperadas: con el experimento activado aparece una pantalla de Taxonomías en Ajustes donde se pueden crear, editar y eliminar taxonomías desde la interfaz.
También hay un nuevo editor de medios con recortador de imagen de forma libre para los bloques de imagen y logotipo del sitio. Y el experimento para deshabilitar TinyMCE ha evolucionado: en lugar de eliminarlo todo, ahora simplemente oculta el bloque Clásico, dejando funcionar las instancias existentes, lo que es bastante más razonable.
El plugin de IA sigue su cadencia de versiones cada dos semanas: la 0.9.0 acaba de salir con redimensionado de contenido, moderación y correcciones varias, y el objetivo es llegar a la versión 1.0.0 coincidiendo con WordPress 7.0. En paralelo, el adaptador MCP, que permite a asistentes como Claude o ChatGPT interactuar con WordPress, está terminando los últimos detalles para publicarse como plugin independiente en el repositorio.
Uno de los debates más interesantes gira en torno a la seguridad de las claves de API. El equipo está valorando un mecanismo de aprobación de conectores que permitiría a los administradores controlar qué plugins pueden acceder a las conexiones configuradas con proveedores como OpenAI, Anthropic o Google. Varios contribuidores advierten de que resolver esto solo desde un plugin puede dar una falsa sensación de seguridad, y que lo que WordPress necesita en el fondo es una API de gestión de secretos en core. La idea es que este experimento sirva de primer paso y empuje esa conversación hacia WordPress 7.1.
El equipo también ha empezado a definir qué viene después de haber completado las bases técnicas de la IA en WordPress. Las conversaciones apuntan a educación, buenas prácticas, apoyo a otros equipos de contribuidores con herramientas de IA, y posicionamiento estratégico a largo plazo.
En el Blog de Desarrolladores se ha publicado una guía práctica para empezar a escribir tests end-to-end para WordPress usando Playwright. El artículo parte de la base de que los tests unitarios cubren una capa, pero los tests E2E cubren otra distinta: simulan lo que haría un usuario real en el navegador, comprobando cómo funciona el conjunto del sistema, no componentes aislados. Gutenberg los lleva usando desde el principio, y desde hace unos años también forman parte de WordPress Core.
El grueso del artículo está orientado a desarrolladores de plugins y temas, con ejemplos concretos sobre un proyecto de reseñas de libros. Para quien nunca ha tocado Playwright en el contexto de WordPress, la guía es un buen punto de entrada: la curva de arranque es razonable, los ejemplos son reales y el código completo está disponible en un repositorio público.
El equipo de Accesibilidad ha actualizado los requisitos para obtener la etiqueta «accessibility-ready» en los temas del directorio oficial. Los criterios anteriores databan de 2011 y 2012, antes de que existieran Web Content Accessibility Guidelines 2.1, 2.2, HTML 5 o ARIA con soporte generalizado, así que la actualización era más que necesaria. El cambio más importante en la estructura es que se han eliminado las «recomendaciones»: ahora todo lo que aparece en la lista son requisitos, algunos que antes eran opcionales han pasado a ser obligatorios, y otros se han descartado directamente por considerarse buenas prácticas que no deberían bloquear la aprobación.
Además, cada requisito sigue ahora un formato estándar con tres secciones: el principio básico, las instrucciones de prueba paso a paso con criterios claros de éxito o fallo, y enlaces a la documentación correspondiente. Para los autores de temas que ya tienen la etiqueta, la fecha límite para adaptarse a los nuevos requisitos es el 30 de junio de 2026. Pasada esa fecha, los temas que no cumplan los nuevos criterios perderán la etiqueta.
El Slack de WordPress, el chat donde se comunica toda la comunidad, da un paso importante hacia la internacionalización: las comunidades locales de todo el mundo podrán integrarse en el mismo espacio que ya usan los equipos de contribuidores del proyecto, sin tener que elegir entre su comunidad local y la visibilidad global. La iniciativa parte de una realidad que muchos ya conocían: gran parte de la colaboración ocurría en instancias de Slack separadas, lo que dificultaba el descubrimiento mutuo entre comunidades y la conexión con los equipos de Make WordPress. Además, muchos de esos workspaces locales funcionaban con el plan gratuito de Slack, con historial de mensajes limitado y menos herramientas disponibles.
El objetivo no es sustituir el trabajo que las comunidades locales ya hacen, sino crear mejores puentes. En la práctica, esto significa que comunidades de meetups, WordCamps regionales y eventos de referencia como WordCamp Europe, WordCamp US y WordCamp Asia tendrán espacio propio dentro del Slack global. Algunos de estos movimientos ya están en marcha: WordCamp Asia y WordCamp US están ya activos dentro de Make Slack, la comunidad japonesa está en proceso de transición, y WordCamp Europe planea unirse para la edición de 2027.
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