[Noticias] WordPress 7.0.3: segunda tanda de parches de seguridad en un mes

[Noticias] Temas accesibles ¿para qué?

Nueva polémica estos días con respecto a los temas accesibles, en los que la comunidad WordPress ha tomado una posición muy clara. Recuerda que puedes escuchar este programa desde: [https://www.wppodcast.org/wp-content/uploads/sites/3/2020/07/apple.png]https://www.wppodcast.es/apple/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2020/07/spotify.png]https://www.wppodcast.es/spotify/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2023/10/pocketcasts.png]https://www.wppodcast.es/pocketcasts/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2026/07/feed.png]https://www.wppodcast.es/feed/podcast/ TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 10 al 16 de agosto de 2026. El equipo de Accesibilidad llevaba dos años actualizando, por primera vez en catorce años, los criterios de la etiqueta accessibility-ready para los temas del repositorio de WordPress, pasando de WCAG 2.0 a WCAG 2.1 nivel AA y revisando más de un centenar de temas del repositorio [https://make.wordpress.org/accessibility/2026/07/23/accessibility-ready-theme-reviews-extending-the-deadline/]. El trabajo estaba previsto consolidarse antes del 30 de septiembre hasta que Matt Mullenweg intervino directamente para declarar la iniciativa «permanentemente aplazada» y añadió que cualquier committer puede anular las sugerencias del equipo de Accesibilidad. La respuesta de Joe Dolson, líder del equipo, fue inmediata: el programa es voluntario y seguirá adelante hasta la fecha prevista. Amber Hinds, que había liderado la reescritura, pidió a Mullenweg que aclarase si la intención es que cualquier tema pueda usar la etiqueta sin revisión, algo que ya ocurre técnicamente, precisamente por el problema que el equipo llevaba años intentando resolver. La pregunta sigue sin respuesta. La ambigüedad de Mullenweg no es solo un asunto interno. La Directiva europea 2016/2102 obliga a las webs del sector público a cumplir WCAG 2.1 nivel AA, y WordPress alimenta una proporción enorme de esas webs en Europa. Si la etiqueta accessibility-ready deja de tener verificación, quien instale un tema marcado como tal en una web pública podría estar incumpliendo la legislación de su país. Ryan Boren, excommitter de peso, lo definió como una forma de zanjar una discusión sin argumentar. Eric Eggert, experto en accesibilidad con experiencia en la transposición de directivas europeas, cuestionó directamente el estilo de liderazgo y el trato a colaboradores voluntarios. Elena Brescacin, usuaria ciega y ponente habitual de WordCamp, recordó que la accesibilidad no es solo para personas con discapacidad permanente: cualquiera puede necesitar acceso por teclado, contraste alto o navegación por voz en cualquier momento de su vida. El resultado es un impasse inhabitual: Dolson dice que el equipo continúa, Mullenweg dice que se acabó, y qué pasará el 1 de octubre con los temas que no hayan solicitado revisión sigue sin resolverse. En paralelo, Anne McCarthy, release lead de la 7.1, propuso crear un plugin canónico de «Accessibility Labs», siguiendo el modelo de Performance Labs, como espacio para probar funcionalidades de accesibilidad antes de integrarlas en core. Dolson se ha mostrado favorable, con una condición: que exista un camino real hacia core. Sin esa garantía, el plugin podría convertirse en un almacén de funcionalidades que nunca se integran, que es precisamente lo que ha pasado con otras iniciativas de accesibilidad a lo largo de los años. Ya está aquí la primera versión del WordPress Contributor Toolkit [https://wordpress.github.io/contributor-toolkit/], la app de escritorio que nació en abril como el «Core Dev Environment Toolkit» y que resuelve el mayor obstáculo para dar el primer paso en el desarrollo de core: montar un entorno completo de wordpress-develop sin tener que instalar Git, Node ni Docker a mano. Disponible para Windows, macOS con Apple Silicon y Linux, esta versión da un salto respecto a la anterior: ya no solo deja el entorno listo, sino que acompaña durante toda la contribución [https://make.wordpress.org/core/2026/08/14/wordpress-contributor-toolkit-1-0-a-smoother-workflow-for-your-first-core-contribution/], desde vincular un ticket de Trac hasta enviar el trabajo final. Otra novedad práctica es que un mismo sitio ya puede albergar trabajo de varios tickets a la vez, cada uno en su propia rama, sin tener que repetir la instalación completa cada vez, y hay un botón para actualizar a la última versión de desarrollo sin perder el trabajo en curso. Esta versión llega justo a tiempo para el Contributor Day de WordCamp US, pensada explícitamente para que tanto quien contribuye por primera vez como quien facilita esas sesiones pueda centrarse en el ticket en sí y no en pelearse con la configuración del entorno. Tercera ronda de parches de seguridad en poco más de un mes: WordPress 7.0.4 corrige una vulnerabilidad de ejecución remota de código [https://wordpress.org/news/2026/08/wordpress-7-0-4-release/] para usuarios autenticados con rol de Author o superior, a través de una subida de archivo maliciosa en sitios que usan Imagick y Ghostscript para procesar imágenes. El fallo lo ha reportado, de nuevo, el equipo de pwn.ai, y tiene el CVE-2026-65640. Como viene siendo costumbre, los parches se están retroportando hasta la rama 4.7, y la RC3 de WordPress 7.1, publicada el mismo día, ya los incorpora. Precisamente sobre esa RC3 [https://make.wordpress.org/core/2026/08/12/wordpress-7-1-release-candidate-3/]: la beta de la 7.1 sigue avanzando según calendario, con más de 90 correcciones desde la RC1, con 37 en el editor y 57 en core, y coincide con un hito importante del ciclo: la congelación total de cadenas de texto, así que a partir de ahora Polyglots ya puede traducir la versión final sin miedo a que cambien los textos. La fecha de lanzamiento sigue siendo el 19 de agosto. Con la vista puesta más allá, arranca oficialmente la planificación de WordPress 7.2 [https://make.wordpress.org/core/2026/08/12/wordpress-7-2-call-for-volunteers/], con fecha propuesta de lanzamiento entre el 8 y el 10 de diciembre, coincidiendo con el State of the Word. El equipo de Core busca voluntarios para el Release Squad: Release Lead, coordinación, Tech Leads, Triage Lead y Test Lead, con plazo para presentarse hasta el 28 de agosto. El equipo de Formación ha anunciado que ya están disponibles en Learn WordPress los kits de actividades prácticas [https://learn.wordpress.org/activity-library/]: paquetes completos y listos para usar, pensados para cualquiera que quiera organizar una sesión formativa sobre WordPress sin preparar materiales desde cero. Cada kit incluye una guía para quien facilita la sesión y una presentación de diapositivas, todo pensado para funcionar sobre WordPress Playground sin necesidad de instalar nada ni crear cuentas, con una duración de entre 60 y 90 minutos y un resultado tangible al final de la sesión. Hay once kits disponibles [https://make.wordpress.org/community/2026/08/12/hands-on-activity-kits-now-live-on-learn-wordpress/], con temas muy variados: desde primeros pasos para contribuir al proyecto o creación de contenido con bloques, hasta sesiones más técnicas como depuración para desarrolladores con herramientas como Query Monitor y Xdebug, o comercio electrónico con WooCommerce. Hay también dos kits centrados en inteligencia artificial, uno para gestionar un sitio local con Claude Desktop mediante lenguaje natural a través del adaptador MCP, y otro para usar el plugin de IA de WordPress directamente desde el escritorio, además de kits de accesibilidad, SEO, seguridad y el propio Playground. WordPress Credits, el programa que lleva un año conectando estudiantes de todo el mundo con contribuciones reales a WordPress, estrena panel público [https://wordpress.github.io/WPCredits/], con datos que se actualizan semanalmente [https://make.wordpress.org/community/2026/08/13/wpcredits-dashboard/]: estudiantes inscritos, instituciones participantes, contribuciones que van entrando al proyecto, sitios construidos y testimonios de quienes lo viven en primera persona. En paralelo también se ha lanzado una propuesta para resolver un vacío evidente del programa [https://make.wordpress.org/community/2026/08/14/what-comes-after-wordpress-credits/]: ahora mismo, cuando un estudiante se gradúa, no hay ningún paso siguiente definido, y todo el impulso construido se corta justo en el momento en que esa persona está más capacitada para seguir aportando. La propuesta plantea convertir WordPress Credits en el primer escalón de un recorrido más largo, con un itinerario claro hacia la certificación oficial de desarrollador de WordPress y hacia WordPress Jobs, además de proyectos de contribución concretos pensados específicamente para graduados que quieran volver, en colaboración con los propios equipos Make. La pieza más interesante a nivel de ecosistema es un modelo que ya están explorando con empresas: que financien las plazas del examen de certificación para graduados, desbloqueables cuando el estudiante complete una contribución verificable tras graduarse, a cambio de acceso preferente a ese talento. El plan se ejecuta en tres fases: infraestructura básica primero, un piloto centrado en la vía de desarrollo después, y expansión a otras vías más adelante, con un objetivo de retención del 25% para ese piloto. Ya está disponible la extensión oficial de navegador de WordPress, para Chrome y navegadores basados en Chromium a través de la Chrome Web Store [https://chromewebstore.google.com/detail/wordpress-browser-extensi/apaakgfongbkeecchhhjocpgjchbdenl], y para Safari en macOS desde la Mac App Store [https://apps.apple.com/app/id6794460913]. Es un proyecto de código abierto que resuelve un problema muy conocido [https://wordpress.org/news/2026/08/browser-extension/]: la barra de administración de WordPress, siempre visible arriba de la pantalla cuando tienes sesión iniciada, estorba en sitios con cabeceras fijas o efectos de scroll, y desactivarla desde el perfil te hace perder también sus accesos rápidos. La extensión oculta esa barra pero mantiene los atajos más usados a un clic, en el propio icono de la barra del navegador, con la barra completa de vuelta en solo dos clics si la necesitas. El icono de la extensión avisa, mientras se navega, si el sitio en el que se está corre WordPress y si hay sesión iniciada, sin resultar intrusivo. En un sitio que se administre, lleva directamente al escritorio o al editor de esa página, entrada, taxonomía o plantilla concreta que se está viendo, incluidas las plantillas de block themes, que abren directamente en el Editor del Sitio. Guarda localmente la lista de sitios en los que se tiene sesión, así que están disponibles aunque se esté navegando por otra web completamente distinta. Y, para acabar, este pódcast se distribuye con licencia Creative Commons [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.

[Noticias] WordPress 7.0.3: segunda tanda de parches de seguridad en un mes

Tras el lanzamiento de emergencia de WordPress 7.0.2 por el wp2shell, ahora llega una versión 7.0.3 de mantenimiento de seguridad con 12 parches de seguridad con gran afectación a la pantalla de acceso. Recuerda que puedes escuchar este programa desde: [https://www.wppodcast.org/wp-content/uploads/sites/3/2020/07/apple.png]https://www.wppodcast.es/apple/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2020/07/spotify.png]https://www.wppodcast.es/spotify/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2023/10/pocketcasts.png]https://www.wppodcast.es/pocketcasts/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2026/07/feed.png]https://www.wppodcast.es/feed/podcast/ TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 3 al 9 de agosto de 2026. Matt Mullenweg ha publicado una reflexión breve pero con mucho recorrido sobre cómo diseñar WordPress de cara a un futuro con más agentes de IA [https://make.wordpress.org/core/2026/08/04/defensive-data-design/] operando sobre el sitio, planteando una serie de principios de diseño «defensivo» de datos: que enviar algo a la papelera sea fácil pero borrarlo de verdad sea difícil, que publicar un borrador al mundo cueste más que crearlo, que los cambios sean reversibles y visibles siempre que se pueda, y que los mensajes de error expliquen el porqué, no solo el qué, con un botón de copiar para poder pegarlos directamente en un buscador o una IA. También pide asumir que todo lo que llega de fuera, ya sea red, formato o estructura, no es solo poco fiable, sino potencialmente hostil, y apostar por lenguaje llano y directo en vez de jerga técnica. El post ha generado bastante debate en los comentarios, con gente del equipo de Gutenberg confirmando que ya se están actualizando las guías de estilo y los documentos para agentes de IA con estos principios, y varias mejoras concretas ya fusionadas en los mensajes de error al guardar contenido. Entre las propuestas que más han calado destaca la de un «2FA humano»: que ciertas tareas queden marcadas como sensibles y solo puedan completarse si una persona las aprueba explícitamente, con un agente intermedio que explique en lenguaje sencillo qué es lo que se va a hacer antes de pedir el visto bueno. Otro comentario apunta a que este principio de «publicar es difícil» encaja con la vieja propuesta de un estado de revisión programada, donde un agente de IA que edite contenido ya publicado cree por defecto un borrador futuro pendiente de revisión, en lugar de publicar el cambio directamente. Apenas unas semanas después del lanzamiento de emergencia de la 7.0.2 por la cadena de explotación «wp2shell», WordPress vuelve a publicar una actualización de seguridad, la 7.0.3 [https://wordpress.org/news/2026/08/wordpress-7-0-3-release/], con doce vulnerabilidades corregidas de golpe. La más destacada, y la única con CVE público CVE-2026-64638 [https://cve.wpvulnerability.com/cve/CVE-2026-64638], es un XSS reflejado en la pantalla de inicio de sesión que no requiere autenticación y que, en determinadas circunstancias, podría derivar en ejecución de código PHP. El resto de fallos, aunque sin CVE propio aún, no son menores: varios XSS almacenados que necesitan al menos rol de Contributor (en los ajustes de emojis, en el bloque de Contenido del post, en Quick Edit en sitios con muchos usuarios y en el bloque de Fecha del post), una escalada de privilegios en redes multisitio con registro abierto que permitía crear un sitio nuevo, un SSRF en la validación de URLs, un bypass del filtro de CSS seguro para usuarios Author o superior, reportado curiosamente por Anthropic, y varios problemas de filtrado de información: comentarios de posts protegidos por contraseña expuestos vía el bloque de Comentarios recientes, notas filtradas en los feeds de comentarios, y enumeración de slugs de posts. A diferencia de la 7.0.2, que fue un lanzamiento de urgencia fuera de calendario por la gravedad de la cadena de ejecución remota de código, esta 7.0.3 tiene un perfil más de mantenimiento rutinario de seguridad, aunque el consejo es el mismo de siempre: actualizar cuanto antes. Lo que sí llama la atención es el alcance del retroporteo: la ficha técnica en HelpHub [https://wordpress.org/documentation/wordpress-version/version-7-0-3/] confirma que se han publicado 24 versiones distintas de golpe, desde la propia 7.0.3 hasta la 4.7.34, cada una con el subconjunto de fallos que le aplicaba (la 6.9 recibe 11 de los 12, y el resto de ramas activas hasta la 4.7 reciben entre 7 y 8, según a cuántos eran vulnerables). A nivel de código, el parche se concentra en ficheros muy concretos: wp-login y wp-signup por el XSS de inicio de sesión y el bypass de confirmación de correo electrónico, kses por el filtro de CSS que reportó Anthropic, canonical por la enumeración de slugs, http por el SSRF, y los ficheros de gestión de usuarios y Quick Edit por la escalada de privilegios y el XSS correspondiente. La RC2 de WordPress 7.1, publicada el mismo día, ya incorpora todas estas correcciones, así que quien esté probando la 7.1 no tiene que hacer nada adicional. Toca, una vez más, comprobar versión y actualizar cuanto antes en cualquier sitio. WordPress 7.1 ha entrado oficialmente en fase de versión candidata [https://make.wordpress.org/core/2026/08/05/wordpress-7-1-release-candidate-phase/], con la RC2 ya publicada, lo que activa una serie de normas internas del equipo de Core hasta el lanzamiento final. La más relevante es que, mientras no se cree la rama específica de la 7.1, retrasada unos días por trabajo en curso sobre GitHub Actions, cualquier cambio en el desarrollo principal necesita el visto bueno de dos committers distintos en lugar de uno solo, para minimizar el riesgo de introducir regresiones en un momento tan delicado del ciclo. La primera versión candidata [https://wordpress.org/news/2026/08/wordpress-7-1-release-candidate-1/] marca además la congelación de cadenas de texto: a partir de ahora no se permiten textos nuevos salvo excepciones muy puntuales y marcadas expresamente, lo que da vía libre al equipo de Polyglots para empezar a traducir la versión a los distintos idiomas en cuanto esa rama esté lista. En cuanto a qué puede seguir tocándose antes del lanzamiento, solo se aceptan dos tipos de tickets: regresiones introducidas durante este ciclo de desarrollo, y ampliaciones del conjunto de tests, que pueden añadirse en cualquier momento sin restricciones. El equipo de Accesibilidad ha hecho balance de un año de trabajo reorganizando toda su documentación [https://make.wordpress.org/accessibility/2026/08/06/one-year-of-working-on-documentation-about-accessibility-for-wordpress/], un proyecto que arrancó tras detectar en WordCamp Europe Torino que la información sobre accesibilidad estaba dispersa, duplicada e incompleta. El resultado es la nueva WP Accessibility Knowledge Base [https://wpaccessibility.org/], convertida en la única fuente de referencia: cubre desde una introducción a las WCAG y el programa de temas accessibility-ready, hasta estándares de contenido, imágenes, formularios y código frontend, pasando por guías de testing manual y con lector de pantalla. El manual del equipo en Make WordPress, por su parte, se ha reducido a lo estrictamente relacionado con el propio equipo y cómo contribuir, dejando toda la parte técnica en la nueva base de conocimiento. Y, para acabar, este pódcast se distribuye con licencia Creative Commons [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.

[Noticias] WordPress 7.1: repaso completo antes de la versión candidata

WordPress 7.1 está a punto de entrar en fase de release candidate, y el calendario sigue apuntando al 19 de agosto para la versión final. Con la mayoría de novedades ya confirmadas, toca hacer repaso completo de esta versión, que es de las cargadas. Recuerda que puedes escuchar este programa desde: [https://www.wppodcast.org/wp-content/uploads/sites/3/2020/07/apple.png]https://www.wppodcast.es/apple/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2020/07/spotify.png]https://www.wppodcast.es/spotify/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2023/10/pocketcasts.png]https://www.wppodcast.es/pocketcasts/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2026/07/feed.png]https://www.wppodcast.es/feed/podcast/ TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 27 de julio al 2 de agosto de 2026. WordPress 7.1 está a punto de entrar en fase de release candidate, y el calendario sigue apuntando al 19 de agosto para la versión final. Con la mayoría de novedades ya confirmadas, toca hacer repaso completo de esta versión, que es de las cargadas. La gran novedad de esta versión es el sistema de estilos adaptativos de bloques. Por primera vez se puede definir cómo se ve un bloque en escritorio, tableta y móvil directamente desde el editor, sin escribir una sola línea de CSS. Funciona en entradas, páginas, plantillas, patrones y menús de navegación, con un planteamiento en el que los estilos van adaptándose de pantallas grandes a pequeñas hasta que tú los personalizas. Destaca especialmente para los bloques de Imagen, Imagen destacada y Cover, donde ahora se puede elegir un recorte distinto según el dispositivo. Los temas también pueden definir sus propios puntos de corte entre tamaños de pantalla, para ajustarse mejor a su propio diseño. Junto a esto llega la posibilidad de definir cómo se ve un botón o un enlace de menú al pasar el ratón por encima, al hacer clic o al tener el foco, todo desde el propio editor y sin necesidad de programar nada. El nuevo modal de edición de imágenes junta en un solo sitio el recorte libre, el recorte por proporción, el volteo, la rotación fina y la edición de metadatos. Para el bloque Cover, tras recortar la imagen de fondo, el propio bloque recalcula el color de la superposición para que el texto siga siendo legible aunque cambie el brillo de la zona recortada. Esto se suma al procesamiento de imágenes en el navegador que ya comentamos hace unas semanas: todo el trabajo de generar los distintos tamaños de imagen se hace ahora en el propio ordenador en lugar de en el servidor, lo que agiliza notablemente las subidas y reduce mucho la carga en el hosting. También trae soporte ampliado para fotos de iPhone en formato HEIC, imágenes con HDR, AVIF, y conversión automática de GIF a vídeo para aligerar el peso de las páginas. Los iconos SVG, que en la versión anterior eran un conjunto cerrado, se convierten en un sistema abierto: cualquier plugin o tema puede añadir sus propios iconos y agruparlos en colecciones, que aparecen organizadas por pestañas en el selector de iconos del editor, junto a los de WordPress. Un cambio a tener en cuenta: los iconos ahora heredan por defecto el color del texto que los rodea, así que si alguna vez se tocó el color de un icono con CSS personalizado, puede que haya que revisarlo. La barra de administración de siempre, la que aparece arriba del todo, se muestra ahora también dentro del editor por defecto, así que nunca se pierde el acceso rápido al resto del escritorio de WordPress mientras se edita. El bloque Playlist crea listas de reproducción de audio con forma de onda visual, ideal para mostrar episodios de podcast o pistas de música directamente en una página, sin depender de servicios externos. El bloque Tabs organiza contenido en pestañas que el visitante puede ir abriendo, perfecto para preguntas frecuentes o para presentar varias opciones sin abrumar con un muro de texto. Al cambiar el estilo de un bloque, ahora se ve una vista previa en vivo antes de aplicarlo. Convertir un bloque en otro se ha simplificado bastante: por ejemplo, un grupo puede convertirse directamente en fila o columna sin pasos intermedios, y pegar un enlace de vídeo antiguo (por shortcode) genera automáticamente el bloque de inserción moderno, algo muy útil para quien mantenga contenido antiguo. Seis bloques, entre ellos Grupo, Cita y Contenido de la entrada, ganan la posibilidad de combinar un degradado de color con una imagen de fondo a la vez, algo que antes solo se conseguía con CSS personalizado. El bloque Cover permite ahora restringir qué servicios de vídeo se pueden embeber. La Galería estrena un botón para poblarla automáticamente con todas las imágenes que ya se han subido a ese mismo artículo, sin tener que ir seleccionándolas una a una. Y el bloque Imagen añade una casilla para marcar una imagen como puramente decorativa, de forma que los lectores de pantalla la ignoren sin necesidad de dejar el texto alternativo en blanco por convención. Las Notas, el sistema de comentarios internos del editor, siguen madurando. La novedad más visible son las notas ancladas a un trozo concreto de texto en lugar de a todo el bloque, que se pueden formatear con negrita, cursiva o enlaces, mencionar a compañeros con una arroba, y organizar en varios hilos de conversación distintos dentro de un mismo bloque, con un apartado separado para las ya resueltas. Una nueva pantalla en Apariencia > Editor > Identidad reúne en un solo sitio el logo, favicon, título y eslogan del sitio, con edición directa ahí mismo. Y la opción de aplicar un cambio de estilo local a todo el sitio (con «Apply Globally») deja de ser una acción de todo o nada: ahora se abre un panel donde se elige exactamente qué cambios concretos se quieren aplicar globalmente y cuáles se prefiere dejar solo en ese bloque. No todo lo planeado llega a tiempo. Anne McCarthy ha contado en su blog personal el proceso detrás de aparcar una función muy esperada que iba a mostrar en el editor qué estilos de un bloque vienen heredados del diseño general del sitio [https://nomad.blog/2026/07/28/behind-the-scenes-of-a-punted-feature-of-7-1/]. Se probaron varios diseños visuales y ninguno convenció del todo por problemas de accesibilidad o de exceso de elementos en pantalla, así que el equipo prefirió aparcarla para hacerla bien en la próxima versión antes que lanzar algo a medias. La paleta de comandos organiza mejor sus resultados y recuerda lo que se usa más a menudo. Se puede corregir el hilo de un comentario mal ubicado desde su pantalla de edición. Los artículos sin título muestran ahora un fragmento del contenido en el listado, para poder distinguirlos de un vistazo. Y aparece un nuevo widget de escritorio, «Un día como hoy», que recuerda qué se publicó en la misma fecha de años anteriores. El cambio técnico más relevante es que el editor de entradas se ejecuta ahora siempre de forma aislada (dentro de un iframe), lo mismo que ya hacía el editor del sitio; esto es principalmente relevante para quien desarrolle bloques personalizados. En el terreno de estilos del tema, el theme.json, hay bastante movimiento: soporte para sombras de texto, más bloques con alineación de texto estandarizada, la posibilidad de que un tema desactive por completo la visibilidad de bloques por pantalla, y una nueva opción de anchura mínima para que un bloque no se encoja demasiado en pantallas estrechas. Aparece también la primera pieza del futuro sistema de diseño de WordPress, que de momento no cambia nada visible pero es la base técnica que ya permite que el editor del sitio respete el esquema de color elegido en el perfil de administración, en lugar de mostrar siempre fondo oscuro. La API de conexiones con servicios externos (como proveedores de IA) admite ya usuario y contraseña de aplicación como alternativa a las claves de API. Y la Abilities API, pensada para que herramientas de IA interactúen con WordPress de forma estructurada, gana varios puntos de control adicionales para desarrolladores que necesiten interceptar, limitar o modificar esas ejecuciones. Para cerrar, dos cambios de mantenimiento a tener en cuenta para quienes administren servidores: jQuery UI se actualiza a la última versión estable, lo que retira definitivamente el soporte de Internet Explorer y Edge Legacy, así que si se mantiene algún sitio con dependencias muy antiguas, es buen momento para revisarlas. La responsable de WPCredits para Latinoamérica ha compartido los dos primeros proyectos piloto [https://make.wordpress.org/community/2026/07/31/exploring-new-ways-to-contribute-to-wordpress-through-wpcredits/] de un esfuerzo por facilitar que centros educativos se sumen de forma sostenible a la comunidad de WordPress, sin inventar nuevas áreas de contribución sino documentando metodologías reutilizables. El primer piloto nació de una oportunidad puntual en Costa Rica: tres estudiantes de WPCredits de la Universidad Fidélitas diseñaron e impartieron un taller completo de WordPress con Gutenberg para 40 estudiantes de secundaria dentro del campamento internacional Patrones Hermosos, organizado por el Tecnológico de Monterrey y el MIT. Cada participante acabó creando y presentando su propia web, con un cien por ciento de satisfacción, y todo el proceso, metodología, roles, materiales y checklists, se ha convertido en una guía replicable en PDF para que cualquier universidad o comunidad local pueda montar algo parecido sin partir de cero. El segundo piloto va un paso más allá y busca documentar todo el recorrido que sigue un centro educativo desde que decide participar en WPCredits hasta que sus estudiantes hacen contribuciones reales a WordPress, usando como terreno de pruebas el equipo de Polyglots. El proyecto es una colaboración con el equipo de Polyglots de español de Costa Rica para traducir WordPress.org al español costarricense (es_CR), y el primer centro en sumarse es el Liceo Experimental Bilingüe José Figueres Ferrer, el primer instituto de América en unirse al programa WPCredits: trece estudiantes participan como parte de su programa de servicio comunitario, aprovechando su bilingüismo para contribuir directamente a la localización de WordPress. Si el modelo funciona, la idea es adaptarlo después a otras áreas de contribución más allá de Polyglots. El equipo de BuddyPress ha publicado tres versiones a la vez [https://codex.buddypress.org/releases/version-14-5-2/], la 14.5.2, la 12.7.2 y la 11.6.2, todas ellas de seguridad y mantenimiento, así que toca actualizar cuanto antes. La corrección principal refuerza la seguridad de los gestores AJAX de actividad, comprobando que quien pide un elemento de actividad tenga realmente permiso para verlo antes de devolvérselo. Junto a esa corrección de seguridad, la versión trae dos mejoras menores: Nouveau ahora exige contraseñas de nivel «fuerte», y se han limpiado varios avisos de obsolescencia de cara a PHP 8.4. Y, para acabar, este pódcast se distribuye con licencia Creative Commons [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.

[Noticias] Bloques de Playlist y Tabs

WordPress 7.1 incluirá dos nuevos bloques: Playlist, una ampliación de una lista de medios, y Tabs, que tras varias iteraciones consigue alcanzar la madurez suficiente para ser lanzado. Recuerda que puedes escuchar este programa desde: [https://www.wppodcast.org/wp-content/uploads/sites/3/2020/07/apple.png]https://www.wppodcast.es/apple/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2020/07/spotify.png]https://www.wppodcast.es/spotify/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2023/10/pocketcasts.png]https://www.wppodcast.es/pocketcasts/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2026/07/feed.png]https://www.wppodcast.es/feed/podcast/ TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 20 al 26 julio de 2026. Ya está la beta 3 de WordPress 7.1 [https://wordpress.org/news/2026/07/wordpress-7-1-beta-3/], con más de 71 tickets resueltos desde la beta 1. La novedad de estilos más visible es que aplicar cambios globalmente deja de ser todo o nada: la opción «Apply globally» del inspector de bloques ahora abre un paso de revisión donde se elige qué propiedades concretas se aplican de forma global, dejando el resto como anulaciones locales. También se corrigen varios problemas de subida de medios [https://make.wordpress.org/core/2026/07/22/client-side-media-processing-in-wordpress-7-1/]: los GIF animados largos ya no se quedan colgados, las imágenes rotadas por metadatos EXIF se procesan correctamente, y subir una sola imagen HEIC en Safari deja de crear dos entradas duplicadas. Atención a un recorte importante: el soporte de direcciones de correo con Unicode que se venía anunciando finalmente no entra en la 7.1, y su desarrollo continúa como plugin de comunidad aparte. Esta beta trae, además, una tanda de notas con bastante base técnica. La estrella es el procesamiento de medios en el cliente: WordPress 7.1 mueve la compresión, redimensionado, conversión de formato, rotación y generación de miniaturas de imágenes al navegador, en lugar de depender de GD o Imagick en el servidor. Solo funciona en navegadores Chromium; por ahora en Firefox y Safari cae automáticamente al procesado en servidor de toda la vida, sin que el usuario note diferencia. En el terreno de estilos, llega el soporte de sombra de texto para los estilos globales [https://make.wordpress.org/core/2026/07/23/text-shadow-support-in-global-styles/]: por ahora solo como valor de estilo, sin interfaz gráfica, que llegará en la siguiente versión. También cambia el comportamiento por defecto de la Biblioteca de Medios: el scroll infinito [https://make.wordpress.org/core/2026/07/23/media-library-infinite-scrolling-is-now-enabled-by-default-with-a-per-user-opt-out/], que llevaba desactivado por defecto desde WordPress 5.8 por motivos de accesibilidad, pasa a estar activado por defecto. El bloque de HTML personalizado gana la posibilidad de mezclar marcado estático con bloques editables [https://make.wordpress.org/core/2026/07/23/editable-blocks-inside-the-custom-html-block/] reales dentro del mismo bloque, bloqueados para que no se puedan mover ni eliminar, algo pensado explícitamente para que las herramientas de IA generen estructuras seguras de editar sin necesidad de crear un bloque personalizado. Dos noticias más de calado: la actualización a React 19 no llega a la 7.1 [https://make.wordpress.org/core/2026/07/24/react-19-punted-beyond-wordpress-7-1-experiment-in-gutenberg/] después de detectar incompatibilidades inesperadas entre plugins y las dos versiones de React conviviendo; sigue como experimento activable en el plugin de Gutenberg para que los desarrolladores puedan ir probando la compatibilidad de sus plugins. Los iconos SVG, que en la 7.0 eran un conjunto cerrado, se convierten en una API pública completa [https://make.wordpress.org/core/2026/07/24/registering-and-rendering-svg-icons-in-wordpress-7-1/]: cualquier plugin o tema puede registrar su propia colección de iconos, renderizarlos en PHP y consultarlos por REST, con el selector de iconos del bloque Icon ya organizado por pestañas de colección. Ya está aquí Gutenberg 23.6 [https://make.wordpress.org/core/2026/07/22/whats-new-in-gutenberg-23-6-july-22-2026/], y trae dos bloques que llevaban tiempo escondidos tras un experimento y que por fin pasan a la biblioteca estable, sin necesidad de activar nada: el bloque Playlist, con reproducción de pistas de audio, metadatos, carátula y forma de onda configurables, y la familia de bloques Tabs, que organiza contenido en pestañas siguiendo el patrón de accesibilidad recomendado por el W3C ARIA, con controles propios de color, tipografía y bordes para los botones de navegación. Las Notas siguen ganando músculo camino de convertirse en un sistema de comentarios completo, con dos añadidos importantes: las notas en línea, que se anclan a una selección concreta de texto dentro de un bloque en lugar de al bloque entero, y el autocompletado con arroba para mencionar a alguien. La Galería también estrena una variación dinámica que muestra automáticamente todos los medios adjuntos al post, tanto en el editor como en el frontend, sin dejar de ser la misma Galería de siempre. Otra novedad son las colecciones de iconos: ahora plugins y temas pueden registrar sus propios conjuntos de iconos como colecciones completas. Ya tenemos el plugin AI 1.2.0 [https://make.wordpress.org/ai/2026/07/21/whats-new-in-ai-1-2-0/]. La novedad más vistosa es el experimento Suggest Reply para moderación de comentarios: desde la pantalla de comentarios o desde el widget de actividad, quien modera puede generar una respuesta contextual que tiene en cuenta el propio comentario, el post al que pertenece y unas directrices editoriales opcionales. La sugerencia se inserta directamente en el formulario de respuesta en línea, pero siempre queda como propuesta. También llega la generación de resúmenes de contenido en bloque, es decir, poder seleccionar varios posts o páginas desde el listado y lanzar la acción «Generate Summary» para todos a la vez, sin tener que entrar uno por uno en el editor. El equipo de Accesibilidad tiene una propuesta para reorganizar la página de Get Involved [https://make.wordpress.org/accessibility/2026/07/21/accessibility-team-meeting-notes-july-16-2026/], sustituyendo los antiguos grupos de trabajo por tres áreas de enfoque más claras: WordPress Core y el editor de bloques, el programa Accessibility-ready, y la documentación sobre accesibilidad web en general. En paralelo, el manual del equipo se está migrando a GitHub y se simplifica para centrarse en la información del propio equipo y el onboarding de nuevos colaboradores, dejando la guía técnica de accesibilidad en wpaccessibility.org. Con las betas de WordPress 7.1 ya publicadas, el foco del equipo ha pasado a corregir errores y a probar de cara a la RC. Piden ayuda revisando en detalle funciones recién llegadas como las Notas, el procesamiento de medios en el cliente, los subtítulos del lightbox, los bloques Tabs y Playlist, el panel de identidad o las actualizaciones del Command Palette. Otro elemento importante tiene que ver con el programa de temas accessibility-ready. Cuando se anunciaron los nuevos requisitos en mayo, el equipo se marcó como plazo el 30 de junio para completar las revisiones y exigir acción a los autores de temas; esa fecha ya pasó hace semanas sin que se haya retirado ningún tema del directorio [https://make.wordpress.org/accessibility/2026/07/23/accessibility-ready-theme-reviews-extending-the-deadline/], así que el plazo se amplía hasta el 30 de septiembre de 2026. Mientras tanto, basta con que el autor de un tema haya rellenado el formulario de solicitud de revisión y esté trabajando en adaptarlo para que no se le retire del listado; a partir del 1 de octubre, cualquier tema etiquetado como accessibility-ready que no haya pedido esa revisión sí quedará fuera del directorio de búsquedas, aunque las instalaciones existentes seguirán recibiendo actualizaciones con normalidad. Atención, además, a un matiz importante: cumplir los requisitos antiguos no garantiza cumplir los nuevos, así que se espera que prácticamente todos los autores tengan que hacer cambios en sus temas. El equipo de Comunidad está replanteándose cómo funcionan sus reuniones mensuales. Su conclusión es contundente: si una reunión se puede sustituir del todo por un post en el blog, ya no es realmente una reunión. La propuesta es partir esa reunión única en dos cosas separadas [https://make.wordpress.org/community/2026/07/23/rethinking-our-monthly-team-meetings/]. Por un lado, mantener una actualización mensual escrita, publicada a principio de cada mes, recogiendo cambios de políticas, WordCamps, meetups, resúmenes de Campus Connect y programas de educación; deja de ser «la agenda de una reunión» para convertirse en un formato propio. Por otro lado, proponen sesiones de coworking: bloques de una o dos horas donde un grupo trabaja junto, en tiempo real, en una tarea concreta del equipo. La idea de fondo es que la gente no se conecte por información que puede leer en otro sitio, sino cuando hay algo que hacer juntos o alguien a quien preguntar en el momento. En paralelo llega otra propuesta relacionada: recuperar la newsletter de organizadores de meetups [https://make.wordpress.org/community/2026/07/24/proposal-bringing-back-the-meetup-organizer-newsletter/], que lleva parada desde julio de 2025. Esta primera versión plantea mantenerse simple, un post mensual con eventos próximos y recientes de meetups, WordCamps, Campus Connect y los formatos «next gen», poniendo el foco en lo que están haciendo realmente los organizadores. Para que no vuelva a apagarse por sobrecarga de trabajo manual, como le pasó a la anterior, quiere apoyarse en Slackbot, la IA integrada de Slack, para rastrear los canales de eventos y sacar un primer borrador en minutos, dejando el toque humano para pulir, verificar datos y elegir fotos. Y, para acabar, este pódcast se distribuye con licencia Creative Commons [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.

[Noticias] Actualización urgente para 6.8, 6.9 y 7.0

Una versión de seguridad se ha lanzado para las versiones 6.8, 6.9, 7.0 y 7.1-beta que corrige 2 problemas de seguridad graves del núcleo de WordPress. Recuerda que puedes escuchar este programa desde: [https://www.wppodcast.org/wp-content/uploads/sites/3/2020/07/apple.png]https://www.wppodcast.es/apple/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2020/07/spotify.png]https://www.wppodcast.es/spotify/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2023/10/pocketcasts.png]https://www.wppodcast.es/pocketcasts/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2026/07/feed.png]https://www.wppodcast.es/feed/podcast/ TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 13 al 19 julio de 2026. La noticia importante de esta semana es de seguridad, y va en serio. WordPress ha publicado la versión 7.0.2 [https://wordpress.org/news/2026/07/wordpress-7-0-2-release/], un lanzamiento de emergencia que corrige dos vulnerabilidades: una crítica y otra de severidad alta. La crítica, conocida ya en la comunidad como «wp2shell» y catalogada como CVE-2026-63030 [https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q], permite a un atacante no autenticado ejecutar código a través del endpoint batch de la API REST, sin necesidad de cuenta ni interacción del usuario, contra una instalación estándar sin plugins. Se combina, además, con un fallo de inyección SQL identificado como CVE-2026-60137 [https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf], formando una cadena de explotación completa. Dado lo grave del asunto, el equipo de WordPress.org ha activado las actualizaciones forzadas a través del sistema de auto-actualización para los sitios con versiones afectadas, así que muchos sitios ya se habrán actualizado solos. Aun así, conviene comprobarlo a mano: entra en el escritorio, en «Actualizaciones», y fuerza el «Actualizar ahora» si hace falta. Las versiones afectadas también han recibido parches retroactivos: la 6.9 pasa a 6.9.5, corrigiendo ambos fallos, y la 6.8 pasa a 6.8.6, corrigiendo solo el de inyección SQL. La beta de la 7.1 también se ha actualizado, a la beta 2, con ambas correcciones. Las versiones anteriores a la 6.8 no están afectadas. Por ahora no hay exploits públicos confirmados ni constancia de explotación activa, pero varios investigadores avisan de que, al ser WordPress un proyecto de código abierto, es cuestión de tiempo que aparezca una prueba de concepto pública. Ya tenemos beta 1 de WordPress 7.1 [https://wordpress.org/news/2026/07/wordpress-7-1-beta-1/] sobre la mesa, con lanzamiento final previsto para el 19 de agosto. Es una versión cargada, que por fin trae al núcleo un buen puñado de funciones que llevaban tiempo cocinándose en el plugin de Gutenberg. Las Notas se convierten en una herramienta de colaboración mucho más seria: admiten formato de texto en línea, menciones con arroba, varios hilos independientes sobre un mismo bloque y notas ancladas a una selección de texto concreta en lugar de a todo el bloque. En el terreno del diseño, llegan los estilos adaptativos de verdad dentro del editor, como definir cómo se ve un bloque en tableta o móvil sin tocar una línea de CSS, breakpoints personalizables desde el theme.json, y estilado de estados interactivos como hover o focus, tanto a nivel global como por instancia individual de bloque. La experiencia de medios también da un salto: el procesamiento de imágenes se mueve al navegador, con soporte ampliado para HEIC, AVIF, UltraHDR y conversión de GIF a vídeo, subidas más resilientes con reintentos automáticos, y un nuevo modal de edición de imagen que junta recorte, rotación y metadatos en un solo sitio. Las galerías se vuelven más inteligentes, tirando automáticamente de las imágenes ya adjuntas al post. Y en cuanto a bloques nuevos, llegan el bloque Playlist, con reproductor de audio y visualización de forma de onda, y el bloque Tabs para organizar contenido en pestañas, ambos sin necesidad de plugins de terceros. El otro gran cambio de esta versión es de navegación: la barra de herramientas de administración pasa a acompañarte siempre [https://make.wordpress.org/core/2026/07/13/consistent-navigation-in-wordpress-7-1-with-persistent-toolbar/], tanto en el editor de entradas como en el Editor del Sitio, algo que antes desaparecía en este último. El icono del logo de WordPress, que hasta ahora hacía las veces de botón de retroceso de forma confusa, se sustituye por un botón dedicado con forma de flecha; el logo abre siempre la página About, y el icono del sitio, cuando existe, abre el menú del sitio. Si desarrolláis plugins que añaden nodos a esta barra, conviene revisar que sigan funcionando bien en el Editor del Sitio, ya que antes ese modo persistente no existía ahí. Para quienes desarrollan bloques, esta es la versión a la que prestar más atención. A partir de 7.1, el canvas del editor de entradas se renderiza siempre dentro de un iframe, en cualquier tema y sin importar el apiVersion que se declare en los bloques. Hasta ahora bastaba con tener activo un solo bloque en apiVersion 2 o inferior en el post para que todo el editor se sacara del iframe; ese comportamiento desaparece por completo en 7.1. La ventaja es real: los estilos del administrador dejan de filtrarse al contenido, y unidades como vw o vh y las media queries por fin se resuelven contra el propio canvas, no contra la página de administración, así que las vistas previas de tableta y móvil se comportan de verdad como el frontend. Como en cada ciclo, el equipo de Test pide ayuda activa: no hace falta ser QA profesional, basta con usar WordPress como cualquier día [https://make.wordpress.org/test/2026/07/15/help-test-wordpress-7-1/] en un entorno de pruebas y reportar lo que no cuadre. Hay guías paso a paso para probar cada función nueva: Notas, estilado adaptativo, estados interactivos, la barra persistente, el modal de medios o las galerías dinámicas. El Blog de Desarrolladores ha publicado un tutorial para montar una página de mantenimiento [https://developer.wordpress.org/news/2026/07/on-brand-maintenance-mode-for-wordpress-block-themes/] con la marca de cada sitio, en lugar del típico mensaje plano de «brevemente no disponible» que muestra WordPress durante las actualizaciones. La gracia de la técnica es que reparte el trabajo de forma muy interesante: el desarrollador añade un único hook al plugin personalizado de funciones, una sola vez, y a partir de ahí toda la gestión de la página de mantenimiento, tanto diseño como activación, se hace desde el Editor del Sitio, sin tocar código ni archivos. El hook busca una plantilla llamada exactamente «Maintenance» en la base de datos, y si la encuentra, la sirve a cualquier visitante que no tenga sesión iniciada; quien esté logueado sigue viendo el sitio con normalidad, lo cual es útil para revisar los cambios durante la propia actualización. Hay una variante algo más elaborada que añade cabeceras pensadas para los buscadores: un código 503 de «servicio no disponible», un Retry-After sugiriendo que vuelvan a pasar en una hora, y cabeceras de no-cache para que el sitio se sirva sin problemas de caché en cuanto se desactive el modo mantenimiento. Recomendable sobre todo si el sitio tiene tráfico de búsqueda importante o si las ventanas de mantenimiento se alargan. Con el hook puesto, crear la plantilla es tan sencillo como ir a Apariencia → Editor → Plantillas, añadir una nueva llamada «Maintenance», y montarla igual que cualquier otra plantilla. El equipo de Playground ha lanzado una llamada para probar la nueva interfaz de WordPress Playground antes de su lanzamiento oficial, y buscan feedback tanto en escritorio como en móvil. No hace falta probarlo todo: proponen cuatro bloques de pruebas independientes, desde crear y gestionar playgrounds, pasar por la galería de blueprints, hasta trastear con archivos, base de datos y logs, o probar la importación y exportación de sitios, incluida la exportación a GitHub. Lo interesante es que han dejado un entorno de pruebas público [https://make.wordpress.org/playground/2026/07/17/help-us-test-the-new-wordpress-playground-ui/] y accesible sin necesidad de instalar nada, y piden fijarse en cosas muy concretas: si los textos y botones se entienden, si el comportamiento es el esperado, si hay problemas de maquetación y qué mejorarían. El equipo de Comunidad ha presentado los Community Agents, una plataforma de asistentes de inteligencia artificial pensada para aligerar tareas repetitivas [https://make.wordpress.org/community/2026/07/14/meet-the-community-agents-ai-assistants-for-wordpress-community-workflows/]: revisar solicitudes de organizadores de eventos, comprobar presupuestos de WordCamps y auditar sitios en busca de problemas de licencia GPL o de marca registrada. El proyecto se apoya en dos principios: humano en el bucle, es decir, que el agente propone pero nunca aprueba nada de forma automática, y respeto a la privacidad, ya que solo trabaja con información pública como perfiles de WordPress.org o enlaces, sin pedir datos personales como correos o direcciones. Se ha presentado un nuevo addon para CampTix, el sistema que gestiona los eventos de la comunidad, pensado para resolver un problema clásico de las WordCamp: cómo gestionar las plazas de actividades limitadas como el Contributor Day, la cena social o los talleres, que hasta ahora se controlaban con formularios paralelos, hojas de cálculo cruzadas a mano o directamente al buen criterio de los asistentes. El addon, bautizado de momento como «activity tickets», permite a los organizadores crear estas actividades como entradas normales de CampTix a precio cero [https://make.wordpress.org/community/2026/07/17/activity-tickets-self-service-registration-for-contributor-day-and-other-side-events-feedback-wanted/], y marcarlas como tickets de actividad desde el propio panel de configuración. El addon está terminado y probado en local, con más de cincuenta tests automatizados y una prueba completa contra un sitio real de WordCamp, pero todavía no se ha enviado de forma oficial. Antes de eso, el equipo pide feedback a la comunidad, sobre todo de quien haya organizado alguna vez un Contributor Day u otro evento de aforo limitado. Y, para acabar, este pódcast se distribuye con licencia Creative Commons [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.