Poderte conectar de forma remota a WordPress desde tu herramienta de inteligencia artificial ya se puede hacer de forma nativa con el plugin MCP Adapter.
Recuerda que puedes escuchar este programa desde:
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 5 al 11 de octubre de 2026.
Quinta tanda de seguridad en la versión 7.1 en apenas dos meses: WordPress 7.1.3 corrige siete vulnerabilidades y cuatro errores, con recomendación de actualizar de inmediato. Ninguna parece de la gravedad de la ejecución remota de código de la 7.1.2, pero la lista es variada: un XSS almacenado en la pantalla de comentarios de administración, explotable mediante comentarios pendientes; una denegación de servicio en make_absolute_url; una inyección SQL de segundo orden en la exportación WXR; y un fallo que permitía a un autor destacar entradas. Se suman una divulgación sin autenticar de comentarios de entradas privadas o sin publicar, un XSS en los embeds de Imgur y una colisión de nombres de acción en un hook. Los parches se están retroportando hasta la rama 4.7, y todo esto encaja con lo que contaba la Core Security Initiative sobre el aluvión de informes alimentado por herramientas de IA.
Mientras tanto, ya hay calendario de release parties para la 7.2, prevista para el 8 de diciembre. La beta 1 llega el 20 de octubre; después, tres release candidates a partir del 17 de noviembre, y un ensayo general con congelación de código de 24 horas el 7 de diciembre.
Tres cambios de fondo en el Core de WordPress 7.2: saneamiento de HTML, SQL y estándares CSS.
El más importante es la reescritura de la función kses, que lleva toda la vida de WordPress limpiando el HTML de entradas no fiables. La implementación original es anterior al HTML5 y a un mundo donde la gente escribía HTML a mano, y hoy su función casi exclusiva es eliminar riesgos de seguridad, así que la nueva versión se apoya en la API de HTML de WordPress en lugar de en expresiones regulares y cadenas de funciones. No cambia la interfaz ni exige modificar plugins o temas, pero sí el comportamiento con entradas raras: el HTML se normaliza (etiquetas en minúsculas, atributos entre comillas, referencias de caracteres reescritas), los <script> y <style> no permitidos se eliminan con su contenido en lugar de dejar el código suelto en pantalla, y los fragmentos incompletos se recortan antes del punto ambiguo.
En la base de datos, WordPress 7.2 añade NO_BACKSLASH_ESCAPES a la lista de modos SQL no soportados. Con ese modo activo, MySQL trata la barra invertida como un carácter normal y las consultas con valores escapados pueden fallar o devolver datos equivocados, algo que algunos hostings activan y que provocaba problemas muy difíciles de rastrear. A partir de ahora, al conectarse, WordPress lo retira solo de la sesión, sin tocar la configuración global del servidor, y la mayoría de sitios no notará nada.
El tercero es más pequeño: hay una propuesta de actualizar los estándares CSS del núcleo para poder integrar Stylelint, que ya se usa en Gutenberg, y hacer que se cumplan de forma automática. Los cambios relevantes son dos: una sola línea en blanco entre secciones y bloques, porque no distingue entre ambos casos, y evitar la propiedad order y los valores reverse.
Ya está disponible el plugin AI 1.4.0. La novedad más llamativa es el experimento de feeds en Markdown: con él activado, el sitio ofrece una versión en Markdown de su contenido en /feed/markdown/, y cualquier entrada o página se puede pedir también en ese formato, pensado para agentes de IA y herramientas que trabajan mejor con Markdown que con HTML renderizado. La moderación de comentarios incorpora una puntuación de valor, de 0 a 1, que mide cuánto aporta un comentario a la entrada donde se publica, como señal adicional a la toxicidad y el sentimiento: un comentario puede ser perfectamente educado y no decir nada. Además, la traducción de contenido añade nueve idiomas de destino y permite reintentar una traducción fallida sin reiniciar el flujo, y la generación de texto alternativo respeta ya la casilla de imagen decorativa del bloque Imagen.
De cara a la 1.5.0 se anuncian texto a voz, sugerencias de enlaces internos, integración con el editor de medios de Gutenberg, control de acceso por rol y usuario y trazabilidad de contenido con C2PA, además de abilities de escritura para contenido, usuarios, términos y medios, en línea con el patrón CRUD que se comentó para la 7.2.
El MCP Adapter, la pieza que traduce las Abilities de WordPress al protocolo MCP para que asistentes como Claude o ChatGPT puedan descubrirlas y usarlas, llega por fin al directorio de plugins de WordPress.org con su versión 0.7.0.
Hasta ahora había que descargarlo de GitHub o empaquetarlo como dependencia de Composer, lo que lo dejaba fuera del alcance de la mayoría de usuarios y obligaba a cada plugin a gestionar sus propias copias y conflictos. Instalado, ofrece un servidor MCP por defecto, con tres herramientas básicas, que expone automáticamente cualquier Ability pública del sitio, y permite a los desarrolladores crear servidores propios con herramientas, recursos y prompts a medida. Eso sí, solo aporta la infraestructura de servidor: no incluye cliente MCP ni una interfaz para un flujo agéntico completo de principio a fin.
La parte más reveladora es el razonamiento sobre por qué esto sigue siendo un plugin y no entra en el núcleo: la especificación MCP todavía cambia, con una actualización mayor que rompió compatibilidad hace menos de tres meses, y eso casa mal con el calendario de distribución masiva y la promesa de retrocompatibilidad de WordPress. Como plugin canónico, puede avanzar al ritmo del protocolo, y otros plugins pueden depender de él sin copias duplicadas ni desfasadas gracias a las dependencias de plugins y a la instalación automática. La 0.7.0 añade soporte para la nueva especificación sin estado de julio de 2026, manteniendo la conexión de clientes con versiones anteriores. El propio equipo lo sigue calificando de experimental, con la meta de llegar a una 1.0 estable según el feedback de desarrolladores.
El equipo de Accesibilidad ha dado un giro de guion en el pulso con los temas accessibility-ready que veníamos siguiendo. Se ha anunciado que el trabajo para hacer la etiqueta condicional en el directorio de temas está casi terminado. Lo importante para quien publique temas es que ya no se retirará ningún tema del directorio por no cumplir los requisitos, que no habrá retrasos en la aprobación por pedir la etiqueta, y que solicitarla pasa a tratarse como una solicitud para entrar en el listado correspondiente. Falta aún algo de trabajo de configuración, así que la aplicación de los cambios sobre qué temas aparecen bajo la etiqueta se retrasa un poco.
Es una salida bastante distinta de la amenaza del 1 de octubre que planteaba el equipo en julio, y encaja con la solución ya esbozada en los comentarios de aquel post: que la etiqueta dependa de una aprobación registrada en el directorio y no solo del style.css del tema, de modo que el equipo pueda quitarla directamente sin tener que retirar el tema entero. El propio equipo lo vende como una ganancia de confianza: como podrán retirar la etiqueta a quien no cumpla, su valor como señal de fiabilidad sube bastante.
Desde el equipo de Comunidad se plantea un problema cotidiano: cuando termina un evento, su web se queda congelada, con una agenda de fechas pasadas, un botón de comprar entrada que ya no sirve y una cuenta atrás clavada en cero, justo cuando más gente puede acercarse a buscar información. La propuesta, válida para WordCamps, Campus Connect o cualquier evento de WordPress, es convertir la web en una página de cierre sin rehacerla desde cero, reorganizando el contenido para pasar de anunciar el evento a contar lo que pasó e invitar a seguir participando.
El planteamiento tiene cuatro piezas: fotos con enlace a la galería completa, con crédito a cada fotógrafo y la licencia de reutilización; charlas con título, ponente, diapositivas en PDF y enlace a WordPress.tv, publicando primero las diapositivas y añadiendo los vídeos cuando estén listos; una llamada a la acción bien visible para unirse al meetup local, quizá de las partes más importantes porque quien visita la web después del evento ya ha demostrado interés; y un apartado con crónicas, testimonios y artículos escritos sobre el evento.
Se está poniendo en práctica con la web de WordCamp Costa Rica 2026, celebrada el 18 y 19 de septiembre y todavía en transformación, y proponen añadir esta tarea a la lista de comprobación posterior al evento, con beneficios que van desde mantener la web útil durante meses y dar reconocimiento a ponentes, fotógrafos y voluntarios, hasta crear un archivo para el siguiente equipo organizador y enseñar a futuros patrocinadores lo que logró el evento.
Por otro lado, se propone dar un marco estable a algo que ya ha funcionado tres veces: que estudiantes tengan presencia en los grandes WordCamp. Empezó como experimento en WordCamp US 2025, ganó fuerza en WordCamp Asia 2026 y alcanzó su hito en WordCamp Europe 2026, donde estudiantes de dos universidades y un instituto de Cracovia subieron al escenario a presentar las webs que habían construido durante el año. Allí se estrenó además un nivel de patrocinio para que graduados de WPCredits pudieran asistir, y su impacto fue más allá de la sala: hicieron de voluntarios, participaron en el Contributor Day, contaron su experiencia en una sesión y se quedaron con ganas de más. El argumento de fondo es de embudo: cada estudiante que construye un sitio o presenta su trabajo es un futuro colaborador, organizador o autor de plugins.
La propuesta es un marco ligero y repetible, a pilotar en 2027 empezando por WordCamp Asia, con cuatro piezas: una o dos personas de cada equipo organizador que hagan de enlace con Educación; entre uno y tres huecos reservados en el programa, sin formato fijo, desde escenario hasta taller o Contributor Day; vías de patrocinio o ayuda de viaje, porque llegar sigue siendo la gran barrera para estudiantes de otros países; y flexibilidad en los plazos, ya que los calendarios académicos no cuadran con los de una convocatoria de ponentes.
También se proponen unas pocas métricas comunes, como número de estudiantes, participación en Contributor Day y cuántos siguen implicados a los tres o seis meses. También se pide que lo adopten los WordCamp locales, que suelen ser la primera puerta de entrada.
BuddyPress 15.0 se retrasa hasta el 19 de enero de 2027. La versión ha tardado más de lo previsto y se habían movido fechas antes: WordPress 7.2 está previsto para el 8-10 de diciembre, y así hay margen para probar BuddyPress contra su versión estable sin que el lanzamiento final caiga en plenas vacaciones. El plan es una beta el 15 de diciembre, con congelación de funciones, y una release candidate el 5 de enero, con congelación de cadenas de texto, dejando tres semanas entre ambas por las fiestas. Es el punto de partida, no un límite: si las pruebas lo piden, habrá otra beta u otra RC, y las fechas son objetivos, no garantías.
La pieza más importante de esta versión es la API REST versión 2, y el equipo quiere que quien desarrolle tenga tiempo de entender los cambios antes de probar la beta: la idea es publicar una semana antes, el 8 de diciembre, la introducción a la API, el aviso de funciones obsoletas y una guía para quien use el plugin independiente BP REST API. Eso sí, avisan de que la documentación sin terminar no bloqueará el lanzamiento. También se revisará la compatibilidad de WP-CLI y otras integraciones del equipo antes de la versión final.
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