WordPress Pódcast (español)

[Noticias] Nada listo para WordPress 7.0

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 [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], 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 [https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/] 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 [https://make.wordpress.org/core/2026/04/02/the-path-forward-for-wordpress-7-0/] 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 [https://make.wordpress.org/core/2026/04/01/building-a-custom-sync-provider-for-real-time-collaboration/] 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 [https://make.wordpress.org/community/2026/04/03/introducing-the-wordpress-facilitator-training-program/], 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 [https://make.wordpress.org/community/2026/04/02/community-summit-alongside-a-flagship-event-for-2027-or-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 [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.

[Magazine] Soporte humano

¿Cuántas veces te has enfrentado a una máquina en un contacto de soporte? Quizá debas apagar y volver a encender… Recuerda que puedes escuchar este programa desde Pocket Casts [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. NOTAS DEL PROGRAMA NOTICIAS * Rethinking Left Navigation [https://make.wordpress.org/core/2026/03/24/rethinking-left-navigation/] * Extending the 7.0 Cycle [https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/]

[Noticias] Todo listo para WordPress 7.0

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 [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], 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 [https://make.wordpress.org/core/2026/03/24/rethinking-left-navigation/]. 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 [https://make.wordpress.org/core/2026/03/25/wordpress-6-9-2-retrospective/] 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 [https://make.wordpress.org/core/2026/03/25/wordpress-7-0-release-candidate-phase/], 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 [https://make.wordpress.org/core/2026/03/27/wordpress-7-0-release-candidate-phase-pt-2/] 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 [https://wordpress.org/news/2026/03/wordpress-7-0-release-candidate-1/] 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 [https://wordpress.org/news/2026/03/wordpress-7-0-release-candidate-2/], 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 [https://make.wordpress.org/core/2026/03/24/introducing-the-ai-client-in-wordpress-7-0/] 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 [https://make.wordpress.org/core/2026/03/24/client-side-abilities-api-in-wordpress-7-0/], 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 [https://make.wordpress.org/ai/2026/03/24/whats-new-in-ai-0-6-0/], 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 [https://make.wordpress.org/ai/2026/03/23/guidelines-lands-in-gutenberg-22-7/] 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 [https://make.wordpress.org/community/2026/03/23/getting-local-with-wordcamp-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 [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.

[Noticias] 7.0 Beta 6

WordPress 7.0 sigue en su fase beta, aunque tendría que haber lanzado la primera versión candidata, para validar el tamaño de la instalación y el uso por defecto del sistema de tiempo real. Recuerda que puedes escuchar este programa desde Pocket Casts [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 16 al 22 de marzo de 2026. El ciclo de lanzamiento de WordPress 7.0 ha tenido esta semana un pequeño reajuste. El Release Candidate 1, que estaba previsto para el jueves 19 de marzo, se ha retrasado hasta el martes 24 [https://make.wordpress.org/core/2026/03/19/wordpress-7-0-release-candidate-1-delayed/]. La razón son tres preocupaciones detectadas en el último momento: el rendimiento de la colaboración en tiempo real, la optimización de imágenes en el cliente web, y el tamaño del paquete de instalación. Con la Beta 6, que incluye más de 130 correcciones, vienen cambios relevantes respecto a la Beta 5 [https://make.wordpress.org/core/2026/03/20/wordpress-7-0-beta-6/]. La función de procesamiento de imágenes en el cliente web ha sido revertida temporalmente para resolver los problemas detectados. La colaboración en tiempo real pasa a ser opcional por defecto, con una constante de configuración para quienes quieran controlarla a nivel de servidor, usando la constante WP_ALLOW_COLLABORATION. Además, los intervalos de sincronización de la colaboración en tiempo real se han multiplicado por cuatro, pasando de 250 milisegundos a 1 segundo, para reducir el número de peticiones HTTP y el impacto en el servidor. La fecha de lanzamiento final de WordPress 7.0 se mantiene para el 9 de abril, así que el margen sigue siendo suficiente si estos días se lanza la primera versión candidata. WordPress 7.0 trae un buen paquete de novedades en el editor de bloques, y se han publicado varias notas de desarrollo que las detallan. Son las siguientes: Sangría de texto [https://make.wordpress.org/core/2026/03/15/new-block-support-text-indent-textindent/]. El bloque de párrafo incorpora ahora un control de sangría en las opciones de tipografía, una de las peticiones más antiguas de la comunidad. Se puede configurar para que afecte solo a los párrafos que siguen a otro párrafo, como es habitual en publicaciones en inglés, o a todos los párrafos, como es más común en otros idiomas. CSS personalizado por bloque [https://make.wordpress.org/core/2026/03/15/custom-css-for-individual-block-instances-in-wordpress-7-0/]. Ahora es posible añadir CSS propio a cualquier bloque individual directamente desde el panel de opciones avanzadas del editor, sin necesidad de ir al editor de sitio ni añadir clases manualmente. Los cambios se reflejan en tiempo real mientras se edita. Solo los usuarios con permisos para editar CSS tienen acceso a esta opción. Ancho y alto de bloques [https://make.wordpress.org/core/2026/03/15/dimensions-support-enhancements-in-wordpress-7-0/]. Los controles de ancho y alto pasan a ser opciones estándar del panel de dimensiones, igual que ya lo son el margen y el relleno. Los temas también pueden definir tamaños predefinidos para que los usuarios elijan entre opciones concretas en lugar de introducir valores manualmente. Visibilidad por dispositivo [https://make.wordpress.org/core/2026/03/15/block-visibility-in-wordpress-7-0/]. Ahora se puede mostrar u ocultar cualquier bloque según el tipo de dispositivo, eligiendo entre escritorio, tableta y móvil, sin que esto afecte a los demás. Los controles están disponibles en la barra de herramientas, en el panel lateral y en la paleta de comandos. En la vista de lista del editor aparecen iconos que indican en qué dispositivos está oculto cada bloque. Edición de patrones mejorada [https://make.wordpress.org/core/2026/03/15/pattern-editing-in-wordpress-7-0/]. Los patrones no sincronizados y las partes de plantilla ahora muestran por defecto un modo de edición centrado en el contenido, que oculta la estructura de bloques y los controles de diseño para que el usuario se centre en el texto y los medios. Para hacer cambios de diseño se puede acceder al modo de edición completo con un clic adicional. Sobreescrituras de patrones para bloques personalizados [https://make.wordpress.org/core/2026/03/16/pattern-overrides-in-wp-7-0-support-for-custom-blocks/]. Las sobreescrituras de patrones sincronizados, que permiten personalizar el contenido de cada instancia de un patrón sin alterar el diseño original, ahora son compatibles con cualquier bloque personalizado, no solo con los bloques de núcleo como antes. API de Conectores [https://make.wordpress.org/core/2026/03/18/introducing-the-connectors-api-in-wordpress-7-0/]. WordPress 7.0 introduce la nueva pantalla en Ajustes, llamada Conectores, que centraliza la gestión de conexiones a servicios externos. De momento se centra en proveedores de IA, con soporte integrado para Anthropic, Google y OpenAI. Desde esta pantalla se pueden instalar los plugins de proveedor correspondientes, introducir las claves de API y ver el estado de cada conexión. La arquitectura está pensada para ampliarse en el futuro a otros tipos de servicios. El directorio de Plugins ha recibido su servidor MCP [https://make.wordpress.org/meta/2026/03/20/plugin-directory-mcp-server/], lo que significa que asistentes de IA como Claude, Cursor o VS Code con capacidades de IA pueden conectarse directamente al directorio para ayudar a los desarrolladores a preparar y enviar sus plugins. Las herramientas disponibles son tres: validar el archivo readme.txt antes de enviar el plugin, consultar el estado de una solicitud en revisión junto con el feedback del revisor, y enviar un plugin nuevo o actualizar uno que ya esté en proceso de revisión. Además, el agente de IA tiene acceso a documentos de referencia como las directrices del directorio, las preguntas frecuentes para desarrolladores o la lista de slugs reservados, lo que le permite dar orientación precisa y actualizada mientras se trabaja. Y, para acabar, este pódcast se distribuye con licencia Creative Commons [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.

[Magazine] Hackathon

Las hackathones son una herramienta esencial para que proyectos de código abierto avancen con la participación de la comunidad y su equipo. Recuerda que puedes escuchar este programa desde Pocket Casts [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. NOTAS DEL PROGRAMA NOTICIAS * WordPress Launches Playground-Powered Personal Workspace, but Reception Is Mixed [https://www.therepository.email/wordpress-launches-playground-powered-personal-workspace-but-reception-is-mixed] * AI optimization is replaying early SEO, just faster [https://joost.blog/ai-optimization-is-replaying-early-seo-just-faster/] * WordPress 7.0’s Real-Time Collaboration Heads Into RC1 With Key Questions Still Open [https://www.therepository.email/wordpress-7-0s-real-time-collaboration-heads-into-rc1-with-key-questions-still-open]