WordPress 7.0 llega a su recta final de lanzamiento, con todo ya definido y con foco en arreglar los pequeños detalles.
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 23 al 29 de marzo de 2026.
Matt Mullenweg ha abierto un debate en Make Core sobre el menú lateral izquierdo del escritorio. El problema es conocido: cualquier plugin puede añadir entradas donde quiera, sin ningún orden establecido, lo que provoca que en sitios con varios plugins activos el menú acabe siendo un caos difícil de navegar.
La propuesta de Matt es establecer una jerarquía: primero los elementos del núcleo de WordPress, y al final una sección específica para plugins, donde cada plugin con mucho peso, como WooCommerce o un LMS, tendría su propio elemento de primer nivel con todo su universo dentro. Para evitar que los plugins importantes queden enterrados al final, plantea permitir fijar elementos o mostrar automáticamente arriba los tres plugins usados más recientemente.
Lo que juega a favor de este cambio es que el menú lateral actual no tiene ninguna lógica estructural, y la experiencia en instalaciones con muchos plugins es objetivamente mala. Establecer una jerarquía clara facilitaría también la navegación para agentes de IA y herramientas de automatización, que cada vez interactúan más con el escritorio de WordPress. Es un problema real que lleva años sin solución oficial.
Lo que genera dudas en la comunidad tiene que ver con la memoria muscular. La navegación lateral de WordPress lleva décadas con una estructura que los usuarios conocen, y cambiarla supone reaprendizaje. En varios comentarios señalan que las listas «de uso reciente» pueden ser especialmente contraproducentes en ese sentido, porque el menú cambia de posición según el comportamiento del usuario, lo que impide construir hábitos estables. Hay quien preferiría dar al usuario el control para ordenar el menú a su gusto, como ya hacen plugins como Admin Menu Editor, en lugar de imponer una nueva estructura desde el núcleo. También se plantea si no sería más efectivo empezar por crear una guía de buenas prácticas para desarrolladores de plugins, sin necesidad de cambios en el código.
Es una conversación abierta, sin decisiones tomadas todavía, pero es significativo que la haya iniciado el propio Matt en el blog de Core.
Ha sido un mes de lanzamientos intenso, así que vale la pena hacer un repaso ordenado de todo lo que ha salido y lo que está por llegar.
Comenzamos con las versiones de seguridad de 6.9. A principios de marzo se publicaron hasta tres versiones de mantenimiento en menos de 48 horas. WordPress 6.9.2 corregía diez vulnerabilidades de seguridad, pero pocas horas después provocó que algunos sitios con temas clásicos mostrasen la web en blanco. La respuesta fue 6.9.3, publicada el mismo día. Al día siguiente se descubrió que tres de los parches de seguridad de 6.9.2 no habían llegado correctamente al paquete, lo que obligó a publicar 6.9.4. El equipo de seguridad hizo después una retrospectiva pública en la que reconoció el fallo de proceso, identificó las causas, y comprometió mejoras concretas en la lista de verificación de lanzamientos y en la automatización de los backports a versiones antiguas.
En paralelo las betas de WordPress 7.0. El ciclo de betas fue más largo de lo habitual. Además de las cinco betas inicialmente previstas, hubo que añadir una Beta 4 de urgencia para incluir los parches de seguridad de 6.9.2, y una Beta 6 porque se detectaron problemas de rendimiento en la colaboración en tiempo real, el tamaño del paquete de instalación y la optimización de imágenes en el lado cliente. Esta última función quedó temporalmente revertida, la colaboración en tiempo real pasó a ser opcional por defecto, y los intervalos de sincronización se multiplicaron por cuatro para reducir la carga en el servidor.
La primera versión candidata llegó con 134 correcciones adicionales respecto a la Beta 5. Además de los arreglos habituales, incorporó la pantalla de Conectores de IA y la paleta de comandos en la barra de administración como novedades añadidas fuera del ciclo de betas inicial, al ser consideradas parte esencial de las funcionalidades principales de la versión.
La segunda versión candidata, publicada apenas dos días después, cierra el periodo de congelación de cadenas de traducción, lo que permite al equipo de Polyglots preparar las traducciones para el lanzamiento final.
WordPress 7.0 saldrá el 9 de abril de 2026, coincidiendo con el Contributor Day de la WordCamp Asia en Mumbai. Si tienes plugins o temas, es el momento de actualizar el campo «Tested up to» a 7.0 en el readme.txt.
El equipo de Core ha anunciado dos notas técnicas de WordPress 7.0 orientadas a desarrolladores, pero con implicaciones importantes para entender hacia dónde va la plataforma.
El cliente de IA nativo de WordPress 7.0 se integra en el núcleo, lo que significa que cualquier plugin puede enviar prompts a modelos de IA sin tener que gestionar credenciales ni preocuparse de qué proveedor tiene configurado el sitio. La función de entrada es wp_ai_client_prompt, que devuelve un objeto con el que se puede construir el prompt de forma encadenada: texto, temperatura, tokens máximos, instrucciones de sistema, formato de respuesta y mucho más.
Soporta generación de texto, imágenes, audio y vídeo, dependiendo del proveedor disponible. Lo más importante para los desarrolladores de plugins es que el cliente abstrae completamente al proveedor: el plugin describe qué necesita y WordPress se encarga de enrutarlo al modelo disponible en ese sitio concreto.
La API de Habilidades llegó a WordPress 6.9 en el servidor, permitiendo que agentes de IA y herramientas de automatización descubran y ejecuten funciones de WordPress de forma estructurada. En WordPress 7.0 llega su contrapartida en JavaScript, con dos paquetes: uno genérico para gestión de estado que puede usarse en cualquier proyecto, y otro específico de WordPress que carga automáticamente todas las habilidades registradas en el servidor a través de la API REST. Los plugins pueden registrar sus propias habilidades en el navegador, con esquemas de entrada y salida, comprobaciones de permisos y anotaciones sobre su comportamiento. La relevancia práctica de esto es que abre la puerta a que agentes de IA interactúen con WordPress directamente desde el navegador, sin necesidad de hacer llamadas al servidor para cada acción.
Ambas APIs están pensadas para trabajar juntas: el cliente de IA gestiona las conversaciones con los modelos, y la API de Habilidades expone qué puede hacer WordPress para que esos modelos puedan actuar sobre el sitio de forma estructurada y segura.
El equipo de IA ha tenido una semana con dos novedades destacadas, muy relacionadas entre sí.
La primera es el lanzamiento de la versión 0.6 del plugin de IA, que además de novedades funcionales trae un cambio de nombre importante. El plugin deja de llamarse AI Experiments para llamarse simplemente AI, un cambio que refleja su creciente madurez como herramienta central de las funciones de inteligencia artificial en WordPress. La novedad más visible de esta versión es la edición de imágenes con IA directamente desde la Biblioteca de Medios: los usuarios pueden refinar imágenes generadas mediante prompts iterativos, editar imágenes existentes, y aplicar acciones predefinidas como expandir o eliminar fondos y sustituir elementos dentro de la imagen. Internamente, la estructura del plugin también ha evolucionado: los experimentos ahora se tratan como un tipo de funcionalidad más, lo que prepara el camino para que los más maduros asciendan a la categoría de características estables en futuras versiones.
La segunda novedad es la llegada de Guidelines a Gutenberg 22.7, una funcionalidad experimental que permite definir estándares editoriales para todo el sitio desde una nueva pantalla bajo el menú de Ajustes. La idea es tener un lugar centralizado donde documentar el tono de voz, las preferencias de imagen, las normas por tipo de bloque y cualquier otra directriz editorial, de forma que tanto los editores humanos como las herramientas de IA trabajen desde la misma fuente de verdad. La funcionalidad incluye importación y exportación en formato JSON e historial de revisiones. Por ahora es un experimento que hay que activar manualmente en las opciones de Gutenberg, pero el equipo ya está pensando en proponerlo para WordPress 7.1 como funcionalidad de núcleo.
El equipo de Comunidad está probando una nueva estrategia de marketing para aumentar la asistencia a las principales WordCamp. La idea es identificar usuarios de WordPress con presencia local relevante, como fotógrafos, artistas, escritores, creadores de contenido o negocios, que ya usan WordPress pero nunca han participado en eventos de la comunidad, e invitarles personalmente.
El criterio de selección busca personas con más de 10.000 seguidores en redes sociales, o con una inversión significativa en su presencia online, que vivan cerca del lugar donde se celebra el evento. El acercamiento es directo y personalizado, sin métodos masivos. A quienes acepten participar se les puede integrar en el programa del evento como ponentes o panelistas, o simplemente darles visibilidad a través de entrevistas y contenido previo al evento.
El equipo ya ha compartido listas de sitios WordPress locales con los organizadores de los tres WordCamps principales de 2026, WordCamp Asia, WordCamp Europe y WordCamp US. La ejecución concreta quedará en manos de cada equipo organizador local.
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