WordPress Pódcast (español)

El equipo de WordPress Photos ha creado PhotoFetch, un plugin que permite buscar e incorporar fotografías libres de derechos en tu sitio web de forma fácil y rápida.

Recuerda que puedes escuchar este programa desde:

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 19 al 25 de octubre de 2026.

WordPress 7.2 ya está en fase de pruebas: la beta 1 salió el 20 de octubre y, como siempre, es solo para entornos de prueba, nunca para sitios en producción.

La fecha prevista de lanzamiento es el 8 de diciembre, que es la que recogen el anuncio y el calendario de release parties; la guía de pruebas del equipo de Test habla del 9, una discrepancia a tener en cuenta. Es la última versión grande de 2026 y llega con el nuevo tema por defecto, Ipsum.

Para quien edita contenido, lo más visible es una tanda de mejoras en el editor. El estilado adaptativo que llegó en la 7.1 se amplía, sobre todo en la Galería, donde se podrán fijar columnas, recorte y proporción de imagen por tipo de pantalla. En Estilos Globales llega un filtro «Personalizado» para ver solo los bloques con estilos modificados y, de vuelta tras haberse aplazado en la 7.1, los valores heredados se muestran en los controles del inspector del bloque; se suman sombras de texto con controles propios y estilado de elementos de formulario sin tocar código. Las Notas ganan reacciones con emoji, un icono propio en la barra de herramientas y un modo minimizado, y pasan al margen del lienzo, de modo que se pueden tener abiertas a la vez que la barra de ajustes del bloque. También hay gestión de enlaces de navegación desde la barra lateral del Editor del Sitio, mensajes de error más claros, y un inspector de la entrada reconstruido con el sistema DataForm.

En medios y administración hay varios cambios útiles. El procesamiento de imágenes en el navegador llega a la Biblioteca de medios, y por fin resuelve una limitación de hace doce años: las miniaturas de GIF y WebP animados mantienen la animación. El insertador de medios se rediseña para bibliotecas muy grandes y los recortes quedan vinculados a su imagen original, para no llenar la biblioteca de duplicados sueltos. El escritorio estrena el widget «Un día como hoy», cambia los Dashicons de la barra de administración y del menú por iconos SVG y añade una opción para desactivar el reordenamiento de metaboxes, pensada para pantallas táctiles. Para quien trabaja en hosting, merece atención un cambio de rendimiento: WordPress deja de combinar scripts y hojas de estilo en archivos grandes, los carga por separado para aprovechar mejor la caché del navegador y adelanta la carga de la pantalla de administración que probablemente se visite a continuación.

Para desarrolladores, la novedad grande es la Secrets API, una forma estándar de guardar claves de API y tokens con cifrado, rotación de credenciales y proveedores de almacenamiento personalizables, con soporte de WP-CLI y comprobaciones en Salud del sitio, a partir de la propuesta de estas últimas semanas. Llegan también redirecciones a contenido aleatorio, nuevas capacidades en la Abilities API, la directiva data-wp-html de la Interactivity API y más endurecimiento de la API de HTML. El equipo de Test pide ayuda con una guía detallada que explica qué probar en cada función, y quien encuentre fallos puede avisar en el foro, en Trac o en el repositorio de Gutenberg, indicando versiones de WordPress y PHP, tema, plugins y pasos para reproducirlo.

La tecnología de WordPress Playground ya sirve para ejecutar otro gestor de contenidos en el navegador: Herman Peeren, colaborador de Joomla, ha creado Joomla Playground, un proyecto comunitario todavía en fase temprana que abre Joomla en una pestaña, con su administración y su web pública, sin servidor PHP ni base de datos locales. Se apoya en dos piezas del ecosistema WordPress: los paquetes wasm, que ejecutan PHP como WebAssembly en el navegador, y mysql-on-sqlite, la librería que permite lanzar consultas MySQL contra SQLite, a la que ha conectado un adaptador propio de Joomla. Funciona en navegadores basados en Chromium, documenta Joomla 6.2 y 5.4 con PHP 8.3 a 8.5, y permite guardar el sitio en el navegador, importar y exportar ZIP e inspeccionar el correo sin enviarlo.

Lo interesante para el lado WordPress es lo que Joomla aporta de vuelta, porque su uso expone casos que WordPress por sí solo no ejercita. En compatibilidad SQL, por ejemplo, los identificadores de sesión guardados como valores binarios no coincidían con las comparaciones de texto que usa Joomla y rompían el inicio de sesión, un caso que podría pasar a ser una prueba de regresión de la librería compartida. Guardar miles de archivos sueltos en el almacenamiento del navegador era lento, así que Peeren pasó a un ZIP base compartido más una instantánea de los archivos modificados, apoyándose en el registro de cambios del sistema de archivos de Playground, y en sus mediciones el guardado bajó de 13 segundos a unos 0,3. Y al compartir un único proceso PHP, una conexión de red caída bloqueaba las peticiones siguientes durante minutos, y la indexación de búsqueda en segundo plano se colaba delante de la navegación; habilitar la red mediante fetch del navegador y trocear la indexación para que ceda el turno redujo a la mitad, aproximadamente, el tiempo hasta poder usar la demo.

El WordPress Contributor Toolkit, la aplicación de escritorio que permite contribuir a Core y a Gutenberg, llega a la versión 2.0 con interfaz rediseñada y traducida a diez idiomas. Los flujos de trabajo de Core y Gutenberg que vimos en la versión anterior siguen igual. La ventana entera está construida sobre el sistema de diseño de WordPress, así que botones, avisos y diálogos resultarán familiares a quien use el editor de bloques, y la lista de sitios muestra ahora el estado del servidor de cada uno. Llega además un diálogo de ajustes con tres grupos, general, sitios y cuenta, con tema claro, oscuro, el del sistema o uno personalizado a partir de un fondo y un color principal, y opciones como la versión de PHP de cada sitio o si lo que estaba en marcha al cerrar vuelve a arrancar.

La otra novedad de fondo es el idioma. Todas las cadenas de la interfaz son traducibles en translate.wordpress.org, y la 2.0 incluye checo, neerlandés, inglés de Canadá y del Reino Unido, gallego, húngaro, lao, polaco, serbio y turco. Un idioma entra en la aplicación cuando está traducido al menos al 80%, así que la lista crecerá con cada versión, y el propio equipo propone traducirla como una primera contribución en sí misma. Por defecto la aplicación sigue el idioma del sistema operativo.

También hay mejoras pensadas para el día a día de un Contributor Day. Tras aplicar un parche o una pull request, los detalles del sitio muestran los archivos cambiados en forma de árbol, separando los del parche y los propios, con un botón para revertir solo uno sin perder lo que se está probando. Los datos leídos de Trac, como resumen, estado o componente, se conservan al cerrar y reabrir la aplicación, con un botón para refrescarlos. Y la instalación pesa unos 350 MB menos, algo que se nota cuando todo el mundo descarga a la vez en la misma red.

Emre Erkan, Locale Manager del equipo turco, ha medido cuántas personas con rol de gestión en Polyglots siguen activas, y el resultado es bastante desalentador. Revisó los perfiles públicos de las 870 personas que son Locale Managers o editores generales de traducción en los 203 idiomas: solo el 31% ha traducido algo en los últimos 90 días, un 15% lo hizo entre tres meses y un año atrás, un 36% hace más de un año y un 17% no tiene actividad registrada desde mediados de 2022. Visto por idiomas, en 95 de ellos, casi la mitad, ningún gestor ni editor general ha estado activo en el último trimestre, y en 74 ni siquiera en el último año. Importa porque son quienes abren la puerta a los demás: sin ellos nadie concede el rol de editor de proyecto, y quien espera se acaba marchando en silencio. El proceso de idiomas inactivos del manual solo salta cuando una traducción va dos versiones mayores por detrás, así que un idioma puede estar al día gracias a dos o tres personas mientras casi todos sus responsables llevan años desaparecidos.

En los comentarios, Emre añadió un segundo análisis con las solicitudes de editor publicadas desde 2022: 4.601 entradas y 6.640 peticiones por idioma, de las cuales la mitad las respondió un gestor o editor del propio idioma, con una mediana de nueve horas, pero un 39% no recibió respuesta nunca de su equipo, y en 1.901 de esos casos la única persona que se ocupó fue Tor-Björn Fjellner. Lo más llamativo es el ritmo: entre enero y octubre de 2026 ya van 2.821 peticiones, 2,4 veces las de todo 2025, algo que enlaza con la avalancha de traducciones automáticas que contamos. Y Tobi lo confirma: la mayoría de idiomas depende de uno o dos editores activos, y la presión de los desarrolladores que envían miles de cadenas a idiomas que no hablan está agotando a la gente. Se añade que los editores de proyecto se vuelven inactivos porque solo atienden el proyecto que les interesa y no reciben avisos después, y se recuerda que las importaciones como «actuales» no quedan registradas en los perfiles, así que las cifras sesgan hacia la inactividad.

Sobre las soluciones hay bastante acuerdo, ya que se lleva tiempo proponiendo un estatus honorífico o emérito, con razones de seguridad, porque conviene limitar los permisos de quien ya no contribuye, sobre todo sin autenticación en dos pasos, y para que los nuevos se sientan necesarios.

WordPress Credits, el programa que conecta a estudiantes de instituciones asociadas con trabajo real de contribución al proyecto, abre niveles de patrocinio para 2027. Empezó con ocho instituciones, en su primer año ha trabajado en 17 países y ha llegado a más de 900 estudiantes, cifras que se pueden seguir en el panel público del programa. Ese crecimiento es el motivo del cambio: currículo, traducción, herramientas e incorporación de nuevas instituciones necesitan financiación estable, y el sistema actual de patrocinio no se diseñó para eso. Será un piloto, y el equipo promete publicar lo aprendido y retirar lo que no funcione. Los patrocinadores actuales han costeado mentores y aportado productos que los estudiantes usan, y los niveles se construyen sobre lo que ellos hicieron posible.

Hay cinco niveles: Friend, en especie a través de Five for the Future, para empresas que ya patrocinan mentores; Supporter, con 5.000 dólares al año; Backer, con 10.000; Champion, con 15.000; y Partner, desde 30.000. Todos aparecen en la página de socios y se mencionan en el reportaje sobre mentores. Desde Supporter se suma logo, insignia para la web propia e informe anual; desde Backer, que se nombre la parte concreta del programa que se financia, con informe de ese coste y un artículo educativo sobre el producto patrocinado; y Champion añade otro artículo con información factual y neutral sobre más productos, invitación a la sesión anual de socios educativos y un seminario web o evento conjunto. Los artículos los redacta la empresa pero se publican en wordpresseducation.org tras la revisión del equipo, para que lo publicado sea útil primero a los estudiantes. Aparte de los niveles, cualquier patrocinador puede donar acceso gratuito a sus productos, que la Fundación reparte, sin pedir tarjeta y con forma de exportar el trabajo para que nadie quede atado.

El nivel que más quieren que se mire es Partner, que financia un programa completo y con nombre propio, algo que hasta ahora no han podido construir por ir limitados al presupuesto disponible. El patrocinador sería socio exclusivo de ese programa, aparecería en su lanzamiento y recibiría un informe específico, y el equipo prefiere diseñarlo con quien patrocine antes que ofrecer una lista cerrada; entre las ideas, estudiantes traduciendo WordPress a idiomas con poca cobertura, trabajando en accesibilidad o creando webs para ONG que no podrían encargarlas. Un gestor del programa contactará con cada patrocinador actual para ajustar el nivel. Los eventos de Campus Connect quedan fuera de estos niveles.

Ya hay un plugin para usar el directorio de Photos sin salir del escritorio: se llama PhotoFetch, está publicado en el directorio de plugins de WordPress.org y permite buscar fotos e importarlas directamente a la Biblioteca de medios. Tiene su propia pantalla bajo el menú de la Biblioteca de medios para buscar e importar, pero también se integra en el selector de medios del editor, como una pestaña junto a la de la Biblioteca. El directorio de fotos reúne imágenes aportadas por el público bajo licencia CC0, es decir, libres de derechos, así que el plugin ahorra el paso de descargar la foto y volver a subirla a mano.

Lo curioso es de dónde sale. Lo construyó un equipo de siete personas en el Contributor Day de WordCamp US 2026. A partir de la idea y de la investigación para ver su viabilidad, el resto del día se fue en funciones, documentación y pruebas. Es un buen ejemplo de lo que puede dar un día de contribución bien aprovechado.

El equipo de BuddyPress ha publicado las versiones de seguridad 14.5.3, 12.7.3 y 11.6.3, con parches para las tres ramas que siguen recibiendo soporte. El día siguiente llegó también una 14.5.4, pero no te confundas: según las notas de esa versión, no trae arreglos nuevos, es solo un cambio de número añadido a la rama principal para que los sitios se actualicen. Todas las correcciones están en la 14.5.3, y como la versión de base de datos no cambia, no hay migración que hacer.

Los seis fallos corregidos son de peso. Hay dos inyecciones SQL, una a ciegas en la gestión de campos de perfil y otra por un argumento sin enlazar. Se bloquea además un abuso de la función maybe_unserialize, y se impide que usuarios sin permisos de administrador se asignen a sí mismos tipos de miembro. Los otros dos tienen que ver con grupos: ya no se puede comentar en actividades de grupos de los que no se es miembro, y la API REST deja de revelar detalles de grupos ocultos.

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.

Conseguir buenas traducciones de la interfaz de WordPress es más difícil que nunca, y la culpa es de la IA.

Recuerda que puedes escuchar este programa desde:

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 12 al 18 de octubre de 2026.

Conseguir buenas traducciones de la interfaz de WordPress es más difícil que nunca, y la culpa es de la IA.

La traducción automática lleva veinte años ayudando, pero ahora muchos desarrolladores usan modelos como ChatGPT o Claude para traducir en bloque sus plugins y temas a idiomas que no hablan, y esperan que los voluntarios revisen el resultado, algo que cuesta mucho más que generarlo. Los equipos de cada idioma acumulan miles de cadenas pendientes cada semana, y la salida habitual es revisar por muestreo y aprobar o rechazar en bloque, con herramientas que solo manejan una pantalla cada vez.

A la vez, las solicitudes del rol de editor de traducción de proyecto se han disparado: en los últimos seis meses se ha pasado de recibir más por día que antes por semana, y los desarrolladores no las piden para uno o dos idiomas, sino para diez o veinte.

Las líneas de trabajo son tres. Adaptar las guías de estilo de cada idioma para que los modelos puedan usarlas, en inglés y en Markdown; crear un rol de traductor automático que pueda aportar traducciones pero no aprobar ni editar las de otros, y evitar que lo no verificado entre en la memoria de traducción; y cambiar la misión del equipo, que además de formar traductores tendrá que enseñar a los desarrolladores a usar la traducción automática con cabeza y a internacionalizar bien su código.

En los comentarios de la conversación se añaden matices. Por ejemplo, se propone limitar las importaciones a cien cadenas hasta que un editor lo apruebe; también se pide que solo los editores puedan importar y sacar las solicitudes del blog; se señala que muchos desarrolladores creen que necesitan el rol para que se aprueben sus traducciones; o recuerdan que el verdadero incentivo es el posicionamiento en el directorio, y que un glosario automático es difícil en alemán por sus compuestos.

La propuesta más elaborada es la de no prohibir nada, sino hacer visible lo automático. El autor declararía al importar que usó IA y aceptaría que las cadenas se marquen como sin revisar; los editores podrían liberarlas en bloque o rechazarlas con una sola acción; no entrarían en la memoria de traducción; y los usuarios verían el aviso antes de instalar, con la opción de elegir inglés o desactivar las traducciones automáticas. Desde Japón, cuentan que su equipo revisa solo las primeras cadenas y deja peticiones de cambio, y que su guía de estilo funciona porque mucha gente ya se la da a las herramientas automáticas, con un formulario de solicitud limitado a tres idiomas como idea.

Ya está disponible Gutenberg 24.2, con las Notas como gran protagonista. Ahora viven en un margen junto al lienzo, así que se ven mientras se cambian bloques o ajustes, se pueden minimizar u ocultar, se puede deshacer el borrado de una nota y no se pierde lo que se está escribiendo al cambiar de bloque.

El bloque de Navegación gana una búsqueda única que recorre páginas, entradas, categorías y etiquetas a la vez, y la Galería puede ordenar sus imágenes y aplicarles un duotono común. Las herramientas de diseño siguen extendiéndose por decenas de bloques: ancho y alto mínimos, sombras, duotono y fondos con imagen o degradado.

Para quien desarrolle, lo más importante es que React 19 pasa a estar activado por defecto, salvo en sitios con un tema o plugin conocido por tener problemas, que se quedan en React 18. Es un giro respecto a WordPress 7.1, donde se aplazó, y el equipo pide probar plugins y temas que usen React; se puede desactivar en la zona de Experimentos.

Feature Notifications, el proyecto para crear un sistema de notificaciones unificado en WordPress, vuelve a la vida tras más de tres años parado: su última versión, la 0.2.0, es de abril de 2023. Jonathan Bossenger, que tuvo que apartarse en 2023 y ha retomado el proyecto, ha auditado el código y publicado un plan para llegar a una 0.3.0, que sería la primera versión realmente funcional, capaz de crear, guardar, mostrar y descartar notificaciones, con el objetivo de lanzarla el 1 de diciembre, junto a la última release candidate de WordPress 7.2. Los cimientos son sólidos, con modelos de datos, registro de canales, esquema de base de datos y la interfaz del centro de notificaciones en la barra de administración, pero el sistema no está conectado de principio a fin. La capa de persistencia son todavía piezas sin implementar, la API REST devuelve respuestas vacías, descartar una notificación no guarda nada y las pruebas de los controladores REST están desactivadas.

El plan se reparte en fases que pueden avanzar en paralelo: ordenar las pull requests abiertas, construir el producto mínimo con migración de esquema, repositorios, una API en PHP para emitir notificaciones, endpoints REST con modelo de permisos, descarte persistente y un comando de WP-CLI para generar notificaciones de prueba. Después vienen los arreglos de seguridad y corrección. Se publicará como versión de GitHub y plugin en el directorio.

En general se ha celebrado el regreso, porque las notificaciones del escritorio son una de las peores partes de la experiencia y empeoran cuantos más plugins hay.

Continuando con el giro hacia una colaboración «consciente del servidor», el equipo de Core ha publicado una guía para probar los tres motores de sincronización candidatos, todos en un plugin experimental llamado Gutenberg Sync Engines.

Yjs es el más cercano a Google Docs, con cursores en vivo y actualizaciones muy rápidas, pero esconde los conflictos, porque uno de los dos cambios simultáneos gana sin avisar, y exige mantener dos implementaciones, en JavaScript y en PHP.

DE-RTC es el más parecido al WordPress de siempre: solo comparte al guardar, por defecto cada diez segundos, y aparta los conflictos reales para que alguien los revise. No es tiempo real, pero es barato para hostings modestos y deja que plugins, scripts o WP-CLI participen casi como una persona.

Intent-log envía descripciones de lo que hizo cada persona, como «dividir este bloque», lo que da contexto al servidor y un historial legible, aunque procesa una actualización cada vez por entrada y su lógica de fusión sigue sin estar madura.

El debate de fondo toca de cerca al hosting. Hay cinco transportes posibles, desde sondeo simple, que funciona en cualquier sitio, hasta WebSockets, que necesita un proceso aparte, y se advierte de que la mayoría de hostings compartidos no admiten conexiones largas, así que el sitio típico acabará en sondeo, gane el motor que gane.

Nueva versión de bbPress, y otra vez de seguridad y mantenimiento, así que toca actualizar de nuevo si se administran foros. Refuerza la validación de las contraseñas de temas y respuestas y hace que los shortcodes se queden como texto literal cuando aparecen en bucles de contenido normales de WordPress. La novedad funcional es un ajuste de estado del foro para todo el sitio, con tres modos, abierto, cerrado y congelado; los sitios existentes siguen abiertos salvo que se cambie.

El resto es mantenimiento, sobre todo en la integración con BuddyPress: acciones del perfil, rutas de temas de grupo, visibilidad de la actividad y acceso a foros de grupo. También se recupera la compatibilidad con los enlaces de suscripción de paquetes de temas de terceros, se conservan los formularios de moderación tras un error de validación, y se corrigen notificaciones, conversores, widgets, perfiles, administración de temas y respuestas, y visibilidad de contenido restringido.

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.

Tenemos hoy a Ana Gavilán, que ha estado en el WP Agency Forum, y nos cuenta su experiencia liderando el equipo de marketing de WordPress España.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Continuamos con la historia de WordPress tras casi un mes sin preparar el magazine, que Javier ha estado entretenido con sus cosas…

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

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:

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 

Vuelve a aparecer un problema histórico en WordPress: la lista de usuarios se puede ordenar siempre por nombre, pero no por apellidos.

Recuerda que puedes escuchar este programa desde:

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 28 de septiembre al 4 de octubre de 2026.

Gutenberg 24.1 es, ante todo, una versión de consistencia en las herramientas de diseño: unas 140 de sus contribuciones se dedican a que casi todos los bloques de core tengan las mismas opciones de fondo, color, sombra y tipografía. Imagen de fondo, tamaño y degradado, sombras, bordes y colores de enlaces, encabezados y botones llegan ya a bloques como Acordeón, Tabs, Comentarios o los de entrada, y los bloques Grupo, Biografía del autor y Lista de términos ganan además soporte de columnas de texto. La sombra de texto que se estrenó hace unas versiones tiene ahora panel propio en Estilos Globales y está disponible en Párrafo y Encabezado, y los bloques Cover y Media y Texto estrenan una sección de selección de medios en el inspector, igual que ya tenían Imagen y Logo del sitio.

El plugin de la Presence API, la pieza que muestra quién está trabajando y dónde dentro del escritorio de WordPress y que se anunció en abril, llega a la versión 0.14.0 con varias novedades de calado. La más relevante es el soporte multisitio: el administrador de red puede ver ahora quién está conectado en todos los sitios a la vez, activado por defecto en redes que no sean grandes. También cambia cómo se gestionan los bloqueos de edición de entradas, que pasan de guardarse como metadatos de la entrada a vivir en la tabla propia de presencia; así, renovar un bloqueo ya no invalida la caché de consultas de entradas en sitios con caché de objetos persistente, un problema de rendimiento real. La presencia funciona además con cualquier tipo de contenido con editor, incluido lo que alguien tenga abierto en el Editor del Sitio, y con roles que solo editan páginas o tipos personalizados.

Dos aspectos destacan por encima del resto. En privacidad, el registro está activado por defecto, pero se puede desactivar por sitio o para toda la red, y hay sección en la política de privacidad y herramientas de exportación y borrado de datos; además, saber dónde está cada persona queda reservado por defecto a quien pueda listar usuarios, mientras que el resto solo ve quién está conectado. Y en el apartado de IA, los agentes que editan por la API REST o por MCP no envían el pulso de actividad habitual, así que desde la 0.13 cada guardado registra una presencia temporal que aparece con una etiqueta de «Agente» en la barra de administración y en la columna de editores. El plugin no decide quién es un agente: lo consulta al plugin Agent Users o a cualquier otro que responda por el filtro previsto. Entre los pulidos, mejor rendimiento con una sola pestaña que consulta y comparte resultados con las demás, Site Health que avisa si Heartbeat no mantiene la presencia al día, y un depurador en la barra de administración solo para desarrollo.

Se ha reabierto un viejo problema de WordPress: en la pantalla de perfil el nombre siempre va antes que el apellido y ningún idioma puede cambiarlo. En japonés, húngaro, chino, coreano o vietnamita se escribe primero el apellido, y WordPress ya lo admite a la hora de mostrar el nombre públicamente, pero no al introducirlo. El ticket de Trac más antiguo es de 2008, y desde entonces el asunto ha ido de aplazamiento en aplazamiento, a la espera de una solución global con un único campo de nombre completo que nunca ha llegado, mientras los usuarios de Japón o Malasia recurren a trucos como meter el apellido en el campo del nombre o invertir los campos con CSS.

La propuesta es partir el problema en dos. Primero, un cambio pequeño: que cada idioma pueda reordenar los campos del perfil mediante una cadena traducible y un filtro, sin alterar el significado de los datos, de modo que no hay problemas de compatibilidad. Después, y más adelante, un ajuste a nivel de sitio con tres opciones: nombre primero, apellido primero o campo único de nombre completo. Fumiki reconoce el sesgo de la muestra: quienes participan en Slack o en Trac ya se han acostumbrado al orden inglés y responden que no les molesta, pero la persona más afectada, como el dueño de un pequeño café que monta su web en su idioma, casi nunca aparece por ahí. Pide a los equipos de cada idioma que cuenten cómo se escriben los nombres en documentos oficiales, qué hacen hoy en WordPress y si el cambio les serviría.

Los primeros comentarios ya aportan matices: en ruso lo formal es apellido primero, pero el orden actual de WordPress no resulta extraño porque nombre, patronímico y apellido también es natural, y lo habitual es omitir el patronímico si no hay campo, antes que mezclarlo con el nombre o el apellido. Tor-Björn Fjellner, mentor de Polyglots, defiende que lo más razonable es un único campo, porque es imposible adivinar dónde va cada parte, y sugiere un segundo campo con el valor de ordenación. Fumiki lo ve coherente con las recomendaciones de internacionalización del W3C, y añade que lo que más le interesa es saber cómo escribe la gente de verdad su nombre en cada región, no la teoría.

Se ha detectado una contradicción en el manual de Comunidad sobre quién puede organizar un evento de meetup. Una página del manual, titulada «Any Member Can Organize an Event», dice que cualquier miembro puede hacerlo sin filtros, mientras que las Cinco Reglas de Buena Fe hablan de miembros «fiables y de confianza». La autora de la propuesta se encontró en medio cuando alguien que nunca había ido a un meetup le pidió organizar uno y le sugirió asistir primero a uno existente; un miembro le preguntó entonces si cualquiera puede organizar o no, y no supo dar una respuesta clara. Su hipótesis es que, al dividir el contenido en páginas separadas en 2023, el texto se copió pero se perdió el contexto: en la versión de 2016 la frase hablaba de una casilla concreta en las herramientas del grupo, y el título de la página actual la convierte en un principio general.

La respuesta del equipo, que le llegó por mensaje privado y no está escrita en ningún sitio, es que cualquier miembro puede organizar un evento sin ser co-organizador, pero debe coordinarse con los co-organizadores, que confirman que es de fiar y que cumple las reglas. Por eso se propone confirmar esa interpretación, retirar la página «Any Member Can Organize an Event» y repartir su contenido entre la documentación de gestión del grupo, las reglas y el registro del caso en la auditoría de manuales.

En el equipo de Fotos han detectado que la norma contra las imágenes generadas por IA existe, pero solo de forma oral. Se han repasado los hilos del canal de Slack desde 2023 y se ha dicho en varias ocasiones que una imagen generada no es una fotografía y no se acepta, y los moderadores piden que se envíen solo fotos reales. Sin embargo, ni las directrices, ni la lista de comprobación previa a la subida, ni el correo de rechazo, ni las preguntas frecuentes mencionan la IA, así que quien envía una imagen no se entera hasta que se la rechazan. Tampoco hay documentado cómo recurrir un rechazo, lo que ha dejado sin respuesta a contribuyentes que decían haber subido fotos reales, con la dificultad añadida de que la imagen se borra al rechazarla.

La propuesta son cuatro cambios sencillos: añadir «imágenes generadas por IA» a la frase de las directrices que ya excluye capturas de pantalla y arte digital, hacer lo mismo en la casilla de la lista de comprobación, ampliar el motivo de rechazo «No es una foto» o crear uno propio para la IA, y añadir a las preguntas frecuentes que quien crea que ha sido un error puede responder al correo de rechazo adjuntando la foto. Se limita a imágenes totalmente generadas, y deja para otro debate la edición con IA, como el escalado o el relleno generativo.

bbPress 2.6.19 es una nueva versión de seguridad que aplica las contraseñas heredadas de los foros a las respuestas de la API REST y a la actividad de BuddyPress, y refuerza las comprobaciones de acceso al contenido restringido en feeds, foros de grupo y otras vistas indirectas. También endurece los permisos de moderación y de roles de foro, protege las credenciales del importador y la gestión de cuentas, y mejora el escapado en perfiles y administración.

Entre los arreglos de mantenimiento hay correcciones en las asociaciones y notificaciones de foros de grupo de BuddyPress, en la limpieza del conversor, en las contraseñas de bases de datos importadas, en los correos de suscripción y en la posición de las respuestas.

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.

Si quieres contribuir en WordPress mediante una IA, ya puedes conectar el servidor MCP del Trac para encontrar tickets, cambios y todo lo necesario para rebuscar entre todo el trabajo pendiente.

Recuerda que puedes escuchar este programa desde:

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 21 al 27 de septiembre de 2026.

Cuarta versión de seguridad de la serie en apenas mes y medio, y esta vez con severidad crítica: WordPress 7.1.2 corrige una vulnerabilidad reportada de forma responsable que permite a un atacante sin autenticar hacer que la resolución de plantillas de página incluya un archivo PHP local arbitrario, siempre que sea legible, situado fuera de los directorios del tema activo. Si se dan ciertas condiciones previas tanto en el entorno del servidor como en el tema activo, esto puede derivar en ejecución remota de código. Tiene CVE propio, el CVE-2026-87902.

Actualización recomendada de forma inmediata, sin excusas esta vez: los parches ya se han retroportado a todas las ramas con soporte de seguridad, desde la 4.7 hasta la 7.0, así que toca comprobar versión y actualizar cuanto antes.

Consecuencia directa del episodio que ya contamos sobre el lanzamiento de WordPress 7.1 en el escenario de WordCamp US: Anne McCarthy anuncia que WordPress abandona el formato de lanzamiento en directo sobre un escenario. Tras dos rondas del experimento, como el State of the Word 2025 y la propia 7.1 en WordCamp US, el equipo reconoce que atar el lanzamiento a un evento físico trae más problemas que ventajas: logística compleja, límites de cuánta gente del release squad puede desplazarse al evento, y el propio squad reportando que ejecutar un proceso que no estaba pensado para hacerse sobre un escenario añade estrés real de más.

La alternativa, propuesta por Matt tras hablarlo con Anne, es pasar a un formato de seminario web por Zoom en streaming, sin fecha de evento fija: quienes forman parte del release squad y de la propia versión pueden compartir la sesión en directo, mientras el resto observa y pregunta, permitiendo que participe más gente del equipo según su zona horaria, sin el coste de desplazarse a un evento. Este nuevo formato arranca ya con WordPress 7.2, prevista para principios de diciembre, con más detalles sobre cómo unirse a medida que se acerque la fecha.

Gutenberg ha completado la migración de sus tests unitarios y de integración en JavaScript, dejando atrás Jest en favor de Vitest. El motivo son dos ventajas de peso: mejor soporte nativo de módulos modernos de JavaScript, que con Jest exigía mantener configuración especial cada vez que una dependencia adoptaba ese formato; y la posibilidad de ejecutar tests de componentes en un navegador real en lugar de simularlo, para comprobar cosas como estilos calculados, tamaños, scroll o interacción por teclado sin depender de imitaciones. Los propios tests en Vitest terminaron antes que el grupo más lento de los que corren en Node, así que la nueva cobertura en navegador no ha alargado el tiempo total de ejecución.

Para los que contribuyen en el núcleo de WordPress, ya hay servidor MCP público y gratuito para consultar Trac desde cualquier asistente de IA, sin cuenta ni clave de API. Funciona con Claude, ChatGPT o cualquier otro cliente compatible con MCP, y permite preguntar cosas como qué queda pendiente en un ticket concreto y qué pull requests siguen abiertos, o pedir un resumen de un changeset y su diff, con herramientas específicas para buscar tickets, leer un ticket con su discusión y adjuntos, consultar un changeset, o revisar el timeline. Por defecto conecta con el Trac de Core, pero funciona igual con el resto de Tracs de WordPress.org, como Meta, Themes, Plugins, bbPress, BuddyPress o GlotPress, cambiando el endpoint.

El WordPress Contributor Toolkit llega a la 1.2 con una novedad de peso: soporte completo para contribuir también a Gutenberg, no solo al núcleo. El flujo es paralelo al de Core: al crear un sitio se elige si se contribuye a WordPress Core o a Gutenberg, una decisión que ya no se puede cambiar después y que determina qué repositorio clona y cómo lo construye. Para Gutenberg, en lugar de vincular un ticket de Trac se vincula un issue de GitHub, que trae consigo sus propias pull requests con un botón «Apply…» para probarlas directamente, y al terminar el trabajo se puede abrir la pull request en el repositorio correspondiente sin salir de la aplicación, con autenticación por device flow que vive solo en memoria mientras la aplicación está abierta.

El Dev Tools Dock de WordPress Playground suma una herramienta más: un panel de correo electrónico que captura y muestra los correos que genera el sitio, sin montar servidor de correo ni revisar una bandeja de entrada real. Cuando WordPress envía un mensaje por su vía habitual, PHP lo escribe hacia un programa compatible con sendmail, y Playground intercepta ese mensaje en el navegador en lugar de entregarlo de verdad, mostrándolo con su asunto, remitente, destinatario y cuerpo, con vista previa en HTML si el mensaje lo lleva. Es útil para casi cualquier plugin que envíe correos por el camino normal de WordPress: formularios de contacto, mensajes de bienvenida o aprobación en membresías, confirmaciones de pedidos o reservas, o simplemente para comparar cómo queda una plantilla de correo entre distintos temas o versiones de WordPress.

Tercera versión de bbPress en poco más de un mes, aunque esta vez sin sobresaltos de seguridad: la 2.6.18 es una versión de mantenimiento centrada en importación de foros antiguos y en la actualización de contraseñas en el primer inicio de sesión. Los usuarios importados desde formatos de foro antiguos pueden ahora actualizar su contraseña al iniciar sesión por primera vez, incluso en casos donde ya no existe la base de datos original del foro; también se corrigen los estados de tema, el recuento de respuestas y las fechas de foro al importar desde PHPWind, y se restaura el enlace de edición de Super Moderador en las pantallas de usuario del frontend.

El equipo de Comunidad da novedades sobre la migración de los grupos de meetup de WordPress desde Meetup.com hacia events.WordPress.org, la alternativa basada en GatherPress. Tras la llamada a pruebas de finales de agosto, que dejó bastante feedback útil, el plan para los cerca de 700 grupos afectados avanza en tres fases: ahora mismo se está trabajando sobre ese feedback; el siguiente paso es que grupos reales organicen eventos reales en la plataforma para ver qué funciona y qué se rompe, incluyendo probar la herramienta de migración que importa datos desde Meetup.com; y solo cuando la plataforma y esa vía de migración hayan aguantado el uso real, se abrirá al resto de grupos.

Hay ya varias cosas decididas: la herramienta de migración importará eventos próximos y sedes como borradores para que el organizador los revise antes de publicar, pero no copiará la lista de miembros, ya que cada persona tendrá que unirse por su cuenta con una cuenta de WordPress.org, y de momento la ejecutará alguien del propio equipo en lugar del organizador del grupo, con los eventos pasados fuera de esta primera ronda. Precisamente por eso el equipo insiste en que quien organice un grupo empiece ya a animar a sus miembros a crearse una cuenta de WordPress.org, porque va a ser un requisito ineludible para poder seguir en el grupo tras la migración.

Quedan dos preguntas abiertas relevantes: si será posible migrar miembros en bloque emparejando cuentas de Meetup con cuentas de WordPress.org, algo que depende de una decisión pendiente sobre gestión de datos de usuarios; y qué pasará finalmente con la página de Meetup.com de cada grupo, que durante el piloto se mantendrá activa pero redirigiendo a la nueva plataforma en lugar de llevar su propia lista de asistencia paralela.

Mary Hubbard, directora ejecutiva del Proyecto WordPress, asume la presidencia de la Open Website Alliance, el organismo que agrupa a las organizaciones detrás de Drupal, Joomla!, TYPO3 y WordPress para defender el software libre de forma conjunta. El cargo es rotatorio entre los miembros de la Alianza, así que le toca el turno a WordPress.

La Alianza nació en 2024 a partir del trabajo conjunto de estos cuatro proyectos respondiendo a la Cyber Resilience Act de la Unión Europea, defendiendo ante los legisladores que sus gestores de contenido no son solo infraestructura digital de base, sino la maquinaria con la que negocios reales llegan a sus clientes y venden productos, y que cualquier requisito de seguridad debería tener en cuenta ese papel económico sin ahogar cómo trabajan las comunidades de desarrolladores, traductores y colaboradores que mantienen el software.

Hubbard enmarca el nombramiento en la misma línea que la reciente firma de WordPress de la carta sobre modelos de IA de peso abierto: la idea de que cualquiera debería tener libertad para usar, modificar y compartir las herramientas de las que depende.

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.

Ya sabemos el roadmap para WordPress 7.2, lo que se plantea que llegue en esta versión, y lo que no debería llegar.

Recuerda que puedes escuchar este programa desde:

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 14 al 20 de septiembre de 2026.

WordPress 7.2 está previsto para principios de diciembre de 2026, y el equipo ya ha publicado el roadmap oficial del ciclo. Como en cada roadmap, el propio equipo avisa de que todo lo que aparece aquí está en desarrollo activo, pero nada garantiza que llegue tal cual a la versión final: es la hoja de ruta de intenciones, no una lista cerrada de compromisos.

La novedad que más titulares se ha llevado esta semana es el propio tema por defecto: se llama Ipsum, y con él WordPress rompe una tradición de más de una década de bautizar sus temas con el año de lanzamiento. A partir de ahora, cada tema por defecto tendrá su propio nombre y cambiará cuando el diseño lo pida, no cuando lo marque el calendario. La historia detrás es interesante: el equipo llevaba meses trabajando en un tema mucho más ambicioso y expresivo, con nombre en clave Mētis, pensado para lucir todo lo que Gutenberg ya permite hacer. Tras revisar la dirección con Matt, el criterio cambió: el tema que se empaqueta con WordPress debe ser el punto de partida más simple posible, dejando que el diseño más elaborado exista aparte. Mētis sigue viva como proyecto independiente, pero no se incluirá en esta versión.

Ipsum, cuyo nombre viene del clásico «lorem ipsum», el texto de relleno que ocupa la página hasta que llega el contenido real, es un lienzo en blanco pensado para blogs, con líneas discontinuas simulando el trazo de un lápiz de editor, un puñado de combinaciones tipográficas y variaciones de estilo que retiñen toda la página, imágenes incluidas. Todas las combinaciones cumplen WCAG AA. Ya está disponible para descargar y probar desde GitHub, con la ventana de feedback muy ajustada antes del lanzamiento de la 7.2.

Las Notas, el sistema de comentarios internos del editor, dan el salto más ambicioso hasta la fecha: llega el modo de sugerencias, donde en lugar de simplemente comentar sobre un bloque se puede proponer directamente un cambio de texto concreto para que otra persona lo acepte o lo rechace, un paso de gigante hacia una colaboración mucho más directa entre quienes editan un mismo contenido. Se suman también reacciones con emoji sobre las propias notas y un atajo dedicado en la barra de herramientas del bloque para añadir una nota sin salir del flujo de escritura.

El apartado de seguridad trae tres piezas de peso. La más llamativa conceptualmente es el llamado «modo sudo»: una función en fase muy inicial que plantea exigir una reautenticación puntual para acciones administrativas especialmente sensibles, aunque ya haya sesión iniciada, algo habitual en sistemas operativos pero nuevo en WordPress; de momento solo se ha anunciado la intención, con propuesta detallada pendiente de publicarse. La segunda es la Secrets API ya comentada en su propuesta inicial: sigue avanzando camino de la 7.2, con soporte desde el primer día para WP-CLI y la interfaz de administración pospuesta a una versión posterior. La tercera es una ronda de mejoras y endurecimiento para Application Passwords, con mejor detección de entornos locales frente a HTTPS, notificaciones por correo cuando se añade una nueva contraseña de aplicación, y una gestión más segura del rol por defecto que se les asigna. A esto se suma trabajo continuado de refuerzo sobre la API de procesamiento de HTML, para que WordPress interprete el marcado de forma más segura y fiable en todo el núcleo.

El mensaje del equipo sobre la IA es muy claro y, siendo justos, un poco frenazo: el ciclo de la 7.1 dejó constancia de que las funciones de IA necesitan demostrar primero adopción real y valor práctico antes de plantearse su entrada en el núcleo, así que todo el trabajo de este apartado se sigue haciendo en el plugin de IA, sin ninguna garantía de aterrizar en la 7.2. Entre lo que se está cocinando: más abilities de WordPress, incluyendo las primeras de escritura y no solo de lectura; una actualización del adaptador MCP a la especificación más reciente, con planes de publicarlo como plugin normal en el directorio; activación de MCP con configuración mínima directamente desde el propio plugin de IA; experimentación con WebMCP en flujos de trabajo de agentes dentro del propio navegador; un modelo de identidad y delegación para que los agentes tengan una identidad auditable y permisos gestionables de forma independiente a las cuentas humanas; contexto de sitio y directrices editoriales reutilizables entre distintas funciones de IA; soporte de embeddings compartido para búsqueda semántica; y streaming de respuestas de IA en el cliente PHP.

El roadmap destaca cuatro frentes concretos de alto esfuerzo sobre accesibilidad: que los avisos del escritorio de administración se anuncien correctamente a tecnología de asistencia y sean más fáciles de descartar por teclado; introducir tests automatizados con axe-core para prevenir regresiones; permitir desactivar por completo el reordenamiento de metaboxes, que llevaba tiempo dando problemas de complejidad visual y cambios accidentales en móvil; y eliminar el modo de accesibilidad de widgets, para reducir el número de modos de gestión distintos que hay que mantener.

Llega un nuevo bloque de Lista de Descripción, formado por tres bloques estáticos que serializan a las etiquetas HTML 

Uno de los cambios de fondo más importantes del ciclo: el Editor del Sitio extensible avanza hacia una base nueva, construida sobre el paquete de enrutado wordpress/boot, ya cerca de tener paridad de funciones con el editor actual. Lo relevante no es solo el rediseño técnico, sino que por primera vez se abre a terceros: un endpoint de configuración de vistas en el servidor permitirá que autores de plugins registren sus propias pantallas y ajustes dentro del propio Editor del Sitio, en lugar de tener que construirse su propia API desde cero cada vez. Otros proyectos en marcha, como la edición de navegación, ya se están apoyando en esta base en lugar de duplicar trabajo.

El sistema de DataViews y DataForms sigue puliendo su extensibilidad, con configuración de vistas y formularios registrada en el servidor y campos y acciones también registrables ahí; como parte de esto, el propio inspector de la publicación, es decir, la imagen destacada, extracto, estado, fecha, autor o plantilla, se está migrando a un DataForm, y ya se pide ayuda para probar esa pieza en concreto. La omnibar, que llegó en la 7.1, sigue iterando con la sustitución de dashicons por iconos SVG, mejoras al command palette y revisión continuada de accesibilidad. Y hay una nueva tanda de mejoras a los mensajes de error: más claros, más diagnosticables, y con un botón de copiar para poder buscarlos o compartirlos fácilmente, siguiendo los principios de diseño defensivo que planteó Matt hace unas semanas. Se retoma también el widget «Un día como hoy», que ya se había intentado meter en la 7.1 sin éxito.

Por fin se podrá estilar de forma consistente elementos de formulario, como botones, campos de texto, desplegables y la etiqueta que faltaba, directamente desde Estilos Globales, sin tocar theme.json a mano. El estilado responsivo que llegó en la 7.1 se amplía a más controles, con una API pública para que bloques de terceros con controles personalizados también puedan aprovecharlo. Se puede definir un estado personalizado «activo» para bloques interactivos, como el elemento de menú actual en una navegación, empezando por el bloque de Enlace de Navegación y el bloque Tabs. Y retorna, esta vez con más peso, el proyecto de mostrar los estilos heredados de Estilos Globales directamente en el inspector del bloque, la función que se aparcó en la 7.1 tras varios intentos fallidos de diseño; ahora se suma la incógnita de si mostrar de forma visible cuándo un valor global ha sido sobrescrito localmente y cómo ofrecer una forma clara de revertir ese cambio.

El procesamiento de medios en el cliente, que debutó en la 7.1, se centra ahora en madurar el sistema: reforzar el proceso de subida, ampliar formatos soportados y cerrar trabajo de rendimiento pendiente. El insertor de medios se rediseña pensando en bibliotecas de medios muy grandes, con más fuentes para la galería dinámica y opciones de ordenación para la galería estática. El modal de edición de medios de la 7.1 se centra en el seguimiento de la relación entre una imagen original y sus recortes, resolviendo un problema real: cada recorte crea hoy un adjunto independiente sin ningún vínculo registrado con el original, lo que puede acabar llenando la biblioteca de medios de duplicados sueltos. En rendimiento, el foco está en eliminar la concatenación de scripts y estilos a favor de precarga, y en imágenes responsivas mejoradas, con el plugin Enhanced Responsive Images del equipo de Performance disponible para quien quiera ayudar a probar. Y las revisiones visuales, que llegaron en la 7.0, siguen puliéndose para que comparar y restaurar cambios resulte más fluido.

Una ausencia deliberada y con razón: la edición colaborativa en tiempo real no está en el roadmap de la 7.2, aunque el trabajo sigue en paralelo al ciclo de la versión. El equipo reconoce que aún faltan decisiones arquitectónicas importantes por resolver, y en lugar de listarla aquí para tener que retirarla después, como pasó en ciclos anteriores, prefieren dejarla fuera del todo por ahora.

Mientras esperamos la llegada de la 7.2, ya está aquí WordPress 7.1.1, la primera versión de mantenimiento de la 7.1. Trae 17 correcciones en core, 19 en el editor de bloques, y once fallos de seguridad, así que es actualización recomendada de forma inmediata: el propio anuncio insiste en ello, como toca en cualquier versión de seguridad.

Entre los fallos corregidos destacan un XSS almacenado en wpautop() explotable por un visitante sin cuenta, con el comentario pendiente de aprobación; un problema en la HTML API que permitía escapar de un comentario HTML mediante secuencias de cierre abrupto; un XSS almacenado en temas con soporte de cabeceras personalizadas; URLs especialmente manipuladas que permitían instalar y previsualizar automáticamente un tema inactivo desde WordPress.org; y una travesía de rutas autenticada en el controlador REST de plantillas, reportada de nuevo por Anthropic.

La lista sigue con más fallos de peso: un administrador de sitio podía activar en red un plugin pensado solo para red que estuviera instalado sin estarlo; XML-RPC permitía publicar cambios de personalización saltándose la comprobación de permiso para editar CSS; una sobrescritura arbitraria de posts por parte de un Contributor, también reportada por Anthropic; una comprobación de permisos ausente que filtraba el título de un post padre privado a través de los metadatos del adjunto; una divulgación del slug de un post en borrador o pendiente por parte de un Contributor sin la autorización adecuada; y un fallo que permitía a cualquier usuario autenticado reasignar el padre de un comentario, notas incluidas. Como viene siendo costumbre, los parches se están retroportando a todas las ramas con soporte, desde la 4.7 hasta la 7.0.

Ya está disponible Gutenberg 24.0. La novedad más práctica es que las revisiones visuales por fin incluyen el título del artículo, que hasta ahora quedaba fuera: ver los cambios de título junto a los del cuerpo del texto evita tener que adivinar cuándo se renombró algo. La Galería estrena una variación de cuadrícula totalmente personalizable que sustituye al layout flexible no editable de siempre, y tanto el número de columnas como el recorte de imágenes se pueden configurar de forma distinta según el dispositivo, así que una galería puede mostrar cuatro columnas en escritorio y dos en tableta sin tocar una línea de CSS.

El Título del Sitio gana la opción «fit-text», que hace que el texto escale para ocupar todo el ancho disponible en lugar de quedarse fijo en un tamaño de punto y tener que saltar de línea o quedarse corto. Entre el resto de novedades destaca un rediseño de casi cien iconos hacia un lenguaje visual unificado basado en trazos, la posibilidad de indentar y desindentar con Tab un elemento de lista completo o varios seleccionados a la vez, imágenes de fondo que ya aceptan directamente una URL sin tener que pasar por la Biblioteca de medios, y que los espacios de no separación se vuelvan visibles mientras se edita, en lugar de quedar invisibles y cambiar el salto de línea sin que nadie se entere.

El equipo de Core que trabaja en la edición colaborativa en tiempo real ha explicado por qué la función sigue fuera del roadmap. El diseño actual mezcla los cambios solo en el navegador, sin que el servidor intervenga hasta que alguien guarda, y eso deja tres huecos serios: no sabe quién escribió cada cambio dentro de una sesión, lo que permitiría colar HTML no autorizado bajo los permisos de otra persona; no puede participar cuando la actualización llega por la API REST o WP-CLI; y no puede mediar si dos personas se dessincronizan, con riesgo real de perder trabajo.

La solución propuesta es que la colaboración pase a ser «consciente del servidor»: en lugar de intercambiar cambios directamente entre sí, cada persona se los envía a WordPress, que comprueba permisos, fusiona los cambios de todos y resuelve los conflictos, en vez de dejarlo todo en manos del navegador. El coste es más carga en el servidor, así que habrá que cuidar el rendimiento, sobre todo en hostings más modestos.

Hay tres motores de sincronización en fase de prueba, disponibles como plugin para quien quiera probar y dar feedback: uno basado en la biblioteca Yjs, otro con fusión a tres bandas que sincroniza solo al guardar, y un tercero que registra descripciones breves de cada cambio en lugar del contenido completo.

Ya está disponible en Learn WordPress el curso «AI-Powered WordPress», pensado para explicar de forma progresiva todo lo que ha ido llegando con el plugin canónico de IA desde la 7.0. Se estructura en cuatro módulos: los tres primeros van dirigidos a cualquiera que gestione o publique en un sitio WordPress, como propietarios, redactores, editores o administradores, sin necesidad de saber programar, y cubren desde conectar el primer proveedor de IA desde la pantalla de Connectors, hasta usar las herramientas editoriales para redactar, resumir y clasificar contenido, generar texto alternativo accesible de forma automática, moderar comentarios con análisis de sentimiento y toxicidad, y controlar qué está haciendo la IA en el sitio con el registro de peticiones y las aprobaciones de conectores.

El cuarto módulo da un salto hacia el desarrollo, sin asumir experiencia previa en PHP aunque ayuda haber tocado antes archivos de tema o plugin: cubre cómo conectar asistentes como Claude o ChatGPT a un sitio mediante el adaptador MCP, cómo registrar una Ability de WordPress para que las herramientas de IA descubran las funciones de un plugin propio, y cómo usar el WordPress AI Client para lanzar prompts desde plugins y temas propios. El curso completo se estima en unas nueve horas, requiere un sitio con WordPress 7.0 o superior y acceso de administrador, y cierra con un bloque sobre buenas prácticas responsables a la hora de publicar y construir con IA dentro de WordPress.

Anécdota curiosa: bbPress ya va por la 2.6.17, saltándose la 2.6.16, porque el propio John James Jacoby encontró un fallo de SQL justo después de etiquetar esa versión y prefirió sacar el arreglo sin esperar. Es otra actualización de seguridad y mantenimiento. Refuerza la visibilidad heredada de foros privados y ocultos, los límites de los foros de grupo de BuddyPress, las comprobaciones de acceso para suscriptores, la edición de perfil, las peticiones a la API REST y XML-RPC, los resultados de búsqueda, las redirecciones canónicas, las etiquetas de tema, mover respuestas, dividir temas, y el escapado de salida en general.

La otra pieza importante es una revisión a fondo de las herramientas de mantenimiento y reparación de contadores, como temas, respuestas, foros, subforos, participación, voces y contribuciones de usuario, que ahora se comportan mejor durante moderación, movimientos, fusiones, divisiones, borrado, restauración, reasignación y peticiones simultáneas. Además, los temas de bloques reciben ya soporte de primera clase mientras bbPress sigue usando sus propias plantillas PHP.

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.

ha sido una semana sin noticias, pero con una notica que ha dado mucho que hablar por lo ocurrido en tan sólo 33 horas.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

hoy vamos a hablar de Mateo Carlos… en concreto, de Matthew Charles Mullenweg, al que, si me permitís, a partir de ahora llamaremos Matt.

Matt nació el 11 de enero de 1984 en Houston, Texas, hijo de un programador que trabajaba para una gran ingeniería y que puso ordenadores en casa desde muy pronto. La informática, en su caso, fue ambiente familiar antes que vocación.

Pero antes que el código llegó la música. Estudió saxofón jazz en la High School for the Performing and Visual Arts, y esa manera de entender el trabajo, con el improvisar, tocar en grupo, sacar cosas a menudo aunque no estén perfectas, se le quedó pegada para siempre. Y por eso no es casualidad que cada versión de WordPress lleve el nombre de un músico de jazz. La otra afición que le viene de esa época es la fotografía, que sigue practicando y que, curiosamente, ha acabado apareciendo en esta historia.

Aunque ya hemos hecho un poco de historia de WordPress, y nos queda un poco más, la historia empieza en 2003. Matt tenía 19 años, estudiaba Ciencias Políticas en la Universidad de Houston y usaba un pequeño sistema de blogs llamado b2/cafelog, que se había quedado huérfano cuando su desarrollador, el francés Michel Valdrighi, dejó de mantenerlo.

En enero escribió en su blog que alguien debería coger ese código y seguir adelante. Le respondió un desarrollador británico, Mike Little, y entre los dos hicieron el fork. El 27 de mayo de 2003 salió WordPress 0.7, nombre sugerido por su amiga Christine Selleck.

Y aquí hay un detalle que parece menor y no lo es: b2/cafelog estaba bajo licencia GPL, así que WordPress heredó la GPL desde el minuto uno. Esa herencia es la que explica toda la cultura de plugins y temas libres del ecosistema, y también es la que marca la frontera de lo que se puede y no se puede controlar. Porque el código es libre; la marca, no. Ahí está el germen del conflicto de los últimos dos años.

Ese mismo año, un cambio de licencias en Movable Type, que era el sistema de blogs más importante de la época, pero de pago, empujó a media blogosfera a buscar alternativa, y WordPress estaba ahí en el momento justo y el lugar exacto.

En 2004 dejó la universidad para irse a San Francisco a trabajar en CNET, con el acuerdo de poder dedicar parte de su tiempo a WordPress. Duró poco: en 2005 se marchó y fundó Automattic, cuyo nombre esconde su propio nombre dentro.

Automattic nació con una idea rara para la época: una empresa totalmente distribuida, sin oficinas, con gente trabajando desde cualquier parte del mundo. De hecho, llegó a cerrar su oficina de San Francisco porque casi nadie iba. Sus primeros productos fueron WordPress.com, el alojamiento gestionado, y Akismet, el antispam que todavía hoy tiene medio Internet instalado. Y en 2006 se celebró la primera WordCamp, también en San Francisco, el embrión de la red de eventos que hoy sostiene la comunidad en todo el mundo.

La jugada estratégica clave llegó en 2010, cuando se creó la WordPress Foundation y Automattic le cedió la marca registrada. Sobre el papel, la marca queda en manos de una fundación sin ánimo de lucro. En la práctica, el dominio wordpress.org sigue siendo propiedad personal de Mullenweg, y esa distinción, que durante quince años pareció un tecnicismo, es exactamente el nudo de todo lo que ha pasado desde 2024.

Luego está Audrey Capital, que mucha gente confunde con una empresa del grupo y no lo es. Es su vehículo personal de inversión ángel e investigación, fundado a finales de la década de 2000 y bautizado, según se cuenta, con el nombre de su gata.

Desde entonces ha participado en más de cien operaciones en startups de software libre, internet de consumo, inteligencia artificial y salud. Audrey también ha pagado el sueldo de contribuidores que trabajan en el proyecto WordPress, lo cual añade otra capa a un organigrama que ya de por sí no está nada claro.

En la parte de negocio, Automattic es una empresa privada, distribuida, sin oficinas centrales de verdad, valorada en 7.500 millones de dólares en su última ronda de 2021 y con casi mil millones levantados en total.

El dinero viene sobre todo de suscripciones: alojamiento en WordPress.com, Jetpack, WooCommerce y WordPress VIP para grandes clientes. A eso se suma una colección de compras muy variada: Akismet, Gravatar, WooCommerce en 2015, Tumblr en 2019, Day One, Pocket Casts, Texts.com y Beeper. La plantilla llegó a superar las dos mil personas y se redujo con fuerza tras el recorte del 16% de abril de 2025.

Y hay un dato que conviene retener para entender el final de esta historia: pese a todo ese capital levantado, Mullenweg nunca perdió la mayoría. Automattic es una empresa privada donde el fundador mantiene el control efectivo. No es un CEO contratado, es el dueño.

Y ahí está la tensión que lo explica casi todo: Matt es a la vez CEO de una empresa privada con inversores que esperan retorno, líder vitalicio del proyecto de software libre que sostiene el negocio, director de la fundación que guarda la marca y propietario personal de la infraestructura donde vive la comunidad.

Su iniciativa Five for the Future, de 2014, pedía a las empresas del ecosistema dedicar el 5% de sus recursos al proyecto. Diez años después, esa idea razonable se convirtió en la vara de medir con la que exigió a WP Engine un 8% de sus ingresos brutos, y de ahí salió el litigio que sigue vivo.

Y llegamos a hoy, o mejor dicho la última semana, donde comienza «el culebrón de las 33 horas»

El pasado miércoles 9 de septiembre, el consejo de administración de Automattic votó poner a Mullenweg en excedencia remunerada en contra de su voluntad.

Lo contó él mismo en el canal de anuncios de Slack, acusando al director financiero Mark Davies de haber conspirado con los consejeros Ann Dunwoody, Toni Schneider y Sue Decker.

Según su mensaje, recibió la resolución cincuenta minutos antes de la reunión y le negaron tiempo para que un abogado externo la revisara. La empresa confirmó por escrito la excedencia y el nombramiento de Davies como CEO interino, con la fórmula habitual de plena confianza en su liderazgo.

Nadie explicó los motivos. Y a día de hoy, siguen sin explicarse.

Desde WordPress.org, Mary Hubbard, que es la directora ejecutiva del proyecto y a la vez trabajadora de Automattic, salió rápido a tranquilizar a la comunidad: el cambio en la empresa comercial no afecta al proyecto de código abierto, Mullenweg sigue siendo su líder y los equipos continúan con lo previsto.

Que hiciera falta decirlo en voz alta ya dice bastante sobre lo entrelazadas que están las dos cosas.

Y entonces, giro de guion. Porque Mullenweg no se fue.

Lo interesante del caso es que no recuperó el puesto mediante una votación formal del consejo. Simplemente se negó a marcharse y se quedó con las llaves de casa. Echó del Slack corporativo al resto de administradores, la cuenta de Mark Davies apareció desactivada y empezó a publicar mensajes diciendo que todo estaba resuelto.

Abrió uno de ellos con un «Don’t call it a comeback», enlazó el vídeo de «Mama Said Knock You Out» de LL Cool J y se cambió el avatar por uno con sombrero y parche de pirata. También escribió que ahora era un pirata, con alguna palabrota incluida, algo llamativo en alguien conocido por no decir tacos jamás. Y añadió: si esto es un problema de recursos humanos, que alguien me controle, porque mis controladores habituales están con Mark Davies.

En X apuntó además que esta era probablemente la quinta vez que se enfrentaba a un golpe interno. Y cuando le preguntaron si todo aquello era trolleo, respondió que no era un troll, sino un pirata, obviamente. Prometió también un artículo explicando su vuelta; el artículo llegó, pero iba sobre el barco-casa que se había comprado.

El sábado 12, Automattic confirma el regreso

El sábado por la noche llegó por fin el comunicado oficial. Un portavoz declaró a TechCrunch que Mullenweg es presidente y consejero delegado de Automattic, con el apoyo total del consejo, y añadió que basta con mirar internet para ver a directivos y trabajadores respaldándolo, en referencia aparente a los mensajes de apoyo que él mismo llevaba días republicando en X.

El dato exacto lo dio después la propia empresa: estuvo apartado 33 horas y 20 minutos. Poco más de un día.

El 14 de septiembre, la junta entera, estaba de patitas en la calle.

Y aquí es donde el desenlace se vuelve realmente inusual. Los tres consejeros que votaron apartarlo ya no están.

Toni Schneider, primer CEO de Automattic y hoy al frente de Bluesky, renunció a su asiento, y llegó a borrar de su web personal el párrafo donde mencionaba su papel en la compañía. Sue Decker también dimitió: su perfil de LinkedIn indica ahora que estuvo en el consejo desde marzo de 2020 hasta septiembre de 2026. Y a la generala Ann Dunwoody la retiró directamente Mullenweg.

Preguntada por los cambios, Automattic declinó dar detalles, aunque reconoció que ha habido salidas. Todavía no se sabe quién compone el nuevo consejo.

El 16 de septiembre llega el día de los los paracaídas dorados

Porque entonces TechCrunch publicó los documentos que explican qué pasó durante esas 33 horas. Es la parte más surrealista de todo el asunto.

Mark Davies, el director financiero convertido en CEO interino, y Andy Missan, el director jurídico, firmaron cada uno el acuerdo de indemnización del otro, con fecha efectiva del 10 de septiembre. Es decir: se firmaron mutuamente el paracaídas mientras el fundador estaba apartado.

Cada acuerdo incluía doce meses de salario base en un pago único, vesting acelerado de sus acciones, la posibilidad de ejercer las opciones ya consolidadas y un año más de cobertura médica. Entre los dos, el paquete suma 8,15 millones de dólares que Automattic debería ahora, porque Mullenweg los despidió nada más volver.

El departamento legal está decidiendo si paga o impugna la validez de esos acuerdos. Hay otro detalle que ha alimentado las sospechas: según un documento de recursos humanos, Davies no tenía ya acciones de Automattic cuando salió, porque las habría vendido meses atrás, aunque sí conservaba un buen paquete de opciones ejercitables. Jordan Hinkes, el asesor jurídico general, también tiene la cuenta desactivada, aunque Mullenweg ha dicho en X que su salida estaba planeada desde hacía semanas porque se va a una startup de inteligencia artificial.

El 15 de septiembre llegó la artillería pesada legal

Y es que en paralelo, Automattic ha cambiado de bufete. Deja a Gibson Dunn y ficha a Stephen Shackelford y Shawn J. Rabin, de Susman Godfrey.

Y el fichaje es un mensaje en sí mismo. Shackelford fue co-director de la demanda de Dominion Voting Systems contra Fox News, la que acabó con un acuerdo de 787 millones y medio de dólares. Rabin es especialista en antimonopolio y litigios comerciales complejos, con un arbitraje reciente de 987 millones contra Walgreens a sus espaldas.

El anuncio lo hicieron en X con una frase que no deja lugar a dudas sobre el tono: dicen estar deseando trabajar juntos para luchar por la libertad y el open source. Contra quién exactamente, no lo especifican. Puede ser WP Engine, pueden ser sus propios exconsejeros, o puede ser la ofensiva contra las otras diez empresas de hosting que WP Engine reveló en su demanda de febrero.

Y aquí es donde quedan las dos lecturas posibles

TechCrunch plantea dos interpretaciones, y ninguna está confirmada.

La primera: el consejo actuó para proteger a la empresa. En julio, WP Engine acusó a Mullenweg de destruir pruebas, en concreto mensajes en Signal, WhatsApp y Telegram. Si los consejeros consideraban que aquello se había convertido en un riesgo corporativo serio, apartarlo y cambiar la dirección podía servir para demostrar al tribunal que se tomaban el asunto en serio, y de paso reducir sanciones o mejorar las condiciones de un acuerdo. Que Davies y Missan se blindaran a toda prisa encaja con quien sabe que, si la jugada sale mal, se va a la calle. Y salió mal.

La segunda es la que sospecha el propio Mullenweg: que el consejo buscaba crear una ventana de control temporal para alguna operación estratégica. Él mismo admite que nunca le dieron un motivo, así que está especulando igual que el resto; la falta de explicación y la venta de acciones del director financiero alimentaron sus sospechas y pesaron en su decisión de retomar el mando y barrer al consejo.

También está el factor propiedad, y el factor valoración

Porque nada de esto se entiende sin volver al principio: Mullenweg levantó mucho capital, pero mantuvo la mayoría. Un consejo puede votar lo que quiera; si el fundador controla las acciones, el pulso lo gana él. Y lo ha ganado.

Ahora bien, hay un contrapunto incómodo a dia de hoy. BlackRock, que entró en la ronda de 2021, lleva desde 2024 rebajando el valor que asigna a su participación. Y, según recogía Scripting News a partir de la última presentación del fondo ante la SEC, la marca habría caído hasta los 14,33 dólares por acción, frente a los 85 que pagó en su día, lo que implicaría una valoración de la compañía en torno a los 1.200 millones en lugar de los 7.500. Automattic no ha confirmado esas cifras, y conviene tomarlas como lo que son: la valoración contable de un inversor, no un precio de mercado. Pero la tendencia lleva dos años apuntando en la misma dirección.

Así que, como resumen

En cuestión de una semana, el consejo intentó apartar al fundador, el fundador se negó a irse, tomó el control de las comunicaciones internas, la empresa acabó confirmando su regreso, los tres consejeros que votaron en contra han desaparecido, dos directivos han sido despedidos con ocho millones largos en indemnizaciones en el aire, y de paso se ha contratado a uno de los bufetes más temidos de Estados Unidos.

Es un desenlace muy poco habitual en gobernanza corporativa: el fundador con control mayoritario le ha ganado el pulso a su propia junta directiva, y ha salido de la crisis con más poder del que tenía antes de empezar.

Lo que sigue sin saberse es lo esencial: por qué votaron apartarlo, quién forma el nuevo consejo, si esos 8,15 millones se pagan o se pelean en los tribunales, y si todo esto tiene conexión real con el caso WP Engine, porque oficialmente nadie la ha establecido.

Aunque, hay que dejar una cosa muy clara, y es importante: para quien tiene su web o su negocio montado sobre WordPress, el mensaje práctico es que el proyecto sigue funcionando igual y que las actualizaciones van a seguir llegando. El problema de fondo es otro: la gobernanza de la plataforma que mueve más del 40% de la web ha quedado retratada como algo que se decide, y se deshace, en un Slack privado, en poco más de treinta horas.

Aunque WebMCP todavía es un proyecto para ser un estándar de Internet, ya se ha integrado en WordPress Playground para ser usado con ChatGPT de escritorio, que le da soporte.

Recuerda que puedes escuchar este programa desde:

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 7 al 13 de septiembre de 2026.

Ya está formado el Release Squad de WordPress 7.2, con Matt Mullenweg de vuelta como Release Lead, tras la convocatoria de voluntarios. David Baumwald coordina la versión, George Mamadashvili y Peter Wilson son los Tech Leads, y el equipo se completa con los responsables de triage y testing, más los leads de diseño y desarrollo del nuevo tema por defecto, Twenty Twenty-Seven, encabezados por Henrique Iamarino en diseño y Maggie Cabrera y Carolina Nymark en desarrollo.

Como viene siendo norma desde la 6.7, la 7.2 mantiene el modelo de squad reducido, apoyándose mucho en los representantes de cada equipo Make para coordinar el trabajo desde dentro de sus propios equipos en lugar de centralizarlo todo en el squad de la versión. El número de voluntarios superó con creces las plazas disponibles, así que quien no haya sido seleccionado esta vez puede seguir aportando en testing, bug scrubs, triage o documentación durante todo el ciclo, que es donde de verdad se nota el volumen de trabajo de cada versión.

WordPress Playground incorpora soporte de WebMCP, un estándar todavía en fase de borrador que permite a una página web exponer directamente acciones como herramientas que un agente de IA puede descubrir y usar sin salir del navegador. Es una vía distinta a MCP, que conecta con un servidor local o remoto: WebMCP funciona dentro de la propia página web abierta, sin intermediario. OpenAI ya ha añadido soporte para esto en el navegador integrado de la aplicación de escritorio de ChatGPT, bajo el nombre «Site tools», así que ahora también se puede trabajar con Playground pidiéndole en lenguaje natural que construya una página de inicio o prepare una demostración reproducible de un plugin.

El reto técnico interesante es que WordPress corre dentro de un iframe anidado en la página de Playground, y un agente que solo mira la página principal no ve las herramientas que un plugin registre dentro de ese WordPress. La solución es un proxy de WebMCP que expone hacia fuera las herramientas registradas dentro del sitio y reenvía las llamadas hacia dentro, de forma que un plugin que ofrezca, por ejemplo, la acción de crear un borrador de evento, se vuelve descubrible y usable por el agente sin montar ningún servidor aparte.

El equipo ya ha probado varios flujos de trabajo reales: construir una página de inicio completa de turismo a partir de una sola instrucción, montar un panel de seguimiento de compatibilidad entre versiones de WordPress con tarjetas editables, o convertir las funciones de un plugin en demostraciones interactivas que cualquier visitante puede probar sin instalar nada.

El equipo de Plugins ha activado una revisión de seguridad automatizada para cada nueva versión de cualquier plugin del directorio, antes de que llegue a distribuirse por la API de actualizaciones. Hasta ahora los plugins nuevos se revisaban antes de entrar al directorio, pero las actualizaciones posteriores no pasaban ningún filtro sistemático, y un plugin seguro hoy podía introducir una vulnerabilidad o código malicioso en cualquier versión futura sin que nadie se enterase a tiempo. El detonante concreto fue un incidente real: el 28 de julio se coló un backdoor en una actualización de un plugin con unas 20.000 instalaciones activas, que la revisión automática detectó y puntuó como alto riesgo, bloqueando su distribución antes de que llegara a ningún sitio, con el plugin cerrado del todo 26 minutos después.

El mecanismo se apoya en el periodo de cuarentena de seis horas que ya existe desde junio para toda actualización de plugins y temas: durante esa ventana, varios modelos de IA analizan los cambios de cada versión, cruzan resultados entre sí para reducir falsos positivos, y asignan una puntuación de riesgo. Si supera el umbral de alto riesgo, la distribución se bloquea automáticamente sin depender de que haya alguien del equipo disponible en ese momento, y se avisa por correo a todos los autores del plugin con los hallazgos concretos; una puntuación alta no implica intención maliciosa, ya que una vulnerabilidad introducida sin querer puede puntuar igual de alto que un ataque deliberado.

El equipo de Comunidad ha propuesto crear un fondo de patrocinio educativo conjunto para estudiantes de WPCredits y de WordPress Campus Connect, pensado como paquete estándar en la convocatoria de patrocinadores de los tres WordCamps insignia: Asia, Europa y US. Hasta ahora esto se ha resuelto caso por caso: en WordCamp US 2025 asistieron dos estudiantes de Campus Connect, y en WordCamp Europe 2026 cinco estudiantes de WPCredits, con valoraciones de 8 a 10 sobre 10 en el informe de impacto posterior. La propuesta busca convertir ese esfuerzo puntual en un proceso repetible, con un formulario de recomendación que rellenan organizadores o mentores, y criterios de selección centrados en trayectoria de contribución sostenida y calidad del perfil en WordPress.

El plan es lanzarlo primero como piloto en WordCamp Asia 2027, con una cohorte de ocho estudiantes, un objetivo de financiación de 30.000 dólares y una aportación mínima de patrocinador de 3.000, antes de extenderlo a Europa y Estados Unidos si funciona bien. Quedan muchas dudas sobre cómo estructurar el patrocinio en franjas de precio por plaza, dónde alojar de forma centralizada el enlace de interés para patrocinadores durante todo el año en lugar de repetir el proceso por cada evento, qué pasa si se recauda solo para la mitad de las plazas previstas, y la logística de confirmar los fondos con tiempo suficiente para que los estudiantes puedan tramitar vuelos y visados.

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.