WordPress Pódcast (español)

[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.

[Noticias] GatherPress será una realidad

El plugin de creación de eventos, pensado específicamente para la comunidad WordPress, tiene el visto bueno para comenzar su implantación en WordPress.org y sustituir a Meetup.com. 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 6 al 12 julio de 2026. WordPress 7.0.1 [https://wordpress.org/news/2026/07/wordpress-7-0-1-maintenance-release/], la primera versión de mantenimiento, incluye correcciones para 31 bugs entre Core y el editor de bloques. La más importante para quienes tienen sitios con registro abierto es el cierre de una vulnerabilidad que permitía abusar de la página de registro para enviar correos de spam con el asunto «Detalles de acceso» desde tu propio dominio, con el consiguiente daño a la reputación del servidor de correo. También se corrige un bug en la función wp_kses que desde el RC4 de WordPress 7.0 corrompía declaraciones CSS con background-image: url, convirtiéndolas en atributos rotos. Además vuelve la posibilidad de desencolar estilos globales en línea, que en 7.0 había quedado bloqueada, y se añade mejor compatibilidad con PHP 8.5. Para los usuarios finales, el lanzamiento limpia varios defectos visuales del rediseño del administrador de WordPress 7.0: los botones de publicación que se apretujaban en el panel de ajustes, el spinner mal alineado en la biblioteca de medios, la barra de búsqueda que saltaba de posición tras una búsqueda, y un destello negro que aparecía brevemente al cargar cualquier pantalla del administrador. Los emojis vuelven a funcionar correctamente, tanto en su detección como en la sustitución por imágenes Twemoji. Y las Revisiones Visuales, una de las novedades estrella de 7.0, reciben varias mejoras de accesibilidad: el foco se mueve correctamente al deslizador al entrar en modo revisiones, y los bloques modificados ahora se marcan también con un contorno CSS, no solo por color, lo que es importante para usuarios con baja visión o daltonismo. Hace unas semanas comentamos que el bloque Clásico iba a desaparecer del sistema de inserción de WordPress 7.1. Pues bien, el equipo de Core ha dado marcha atrás. El bloque Clásico seguirá apareciendo exactamente como hasta ahora [https://make.wordpress.org/core/2026/07/07/the-classic-block-stays-in-the-inserter-for-wordpress-7-1/], sin ningún cambio para usuarios ni desarrolladores. El filtro que se había anunciado queda eliminado antes de haber llegado a ninguna versión estable, y el plugin Enable Classic Block que se había publicado para quienes quisieran restaurar el comportamiento anterior ya no tiene razón de ser y se cerrará. La razón de la retirada viene tras recoger feedback: el equipo reconoce que la medida tenía las cosas al revés. Ocultar el bloque empeoraba la experiencia sin acercar a WordPress al objetivo real, que es dejar de cargar TinyMCE cuando no hace falta. La conclusión es que el bloque Clásico debe quedar obsoleto por elección de los usuarios, no por imposición. A partir de ahora el esfuerzo se dirige a entender mejor por qué la gente sigue usando el bloque Clásico, mejorar la función «Convertir a bloques» que todavía tiene bastantes fallos, trabajar en mecanismos de migración masiva de contenido, y explorar cómo cargar TinyMCE de forma asíncrona o bajo demanda, entre otras mejoras de rendimiento. El equipo de Componentes de Gutenberg ha publicado una propuesta de fusión para WordPress 7.1 que es de las más importantes desde hace años en cuanto a infraestructura visual: un sistema de diseño basado en tokens que sienta las bases para hacer que todo el administrador de WordPress sea coherente [https://make.wordpress.org/core/2026/07/07/merge-proposal-design-system-theming/], personalizable y accesible de forma sostenible. La idea, en pocas palabras, es reemplazar los valores de color, tipografía, bordes y elevación que hoy están codificados a mano en cada componente por un sistema de variables CSS semánticas, tokens de diseño, que se pueden cambiar de forma centralizada. Para los usuarios, el impacto inmediato en WordPress 7.1 es que el Editor del Sitio adoptará el esquema de color del administrador que tenga configurado cada usuario, algo que ya llevaba tiempo pendiente. Para los desarrolladores de plugins, significa poder expresar su propia identidad de marca dentro del administrador de WordPress sin necesidad de luchar contra los estilos de Core ni de mantener esos estilos por su cuenta; quien adopte el sistema de tokens hereda automáticamente cualquier mejora futura. Una de las partes más interesantes de este sistema es el generador de escalas de color a partir de dos colores base, que produce paletas visualmente armónicas y con contraste accesible garantizado, lo que allana el camino hacia funciones como un modo oscuro real en versiones futuras. El equipo de IA ha lanzado el plugin oficial de IA en su versión 1.1.0 [https://make.wordpress.org/ai/2026/07/08/whats-new-in-ai-1-1-0/], que ya supera las 30.000 instalaciones activas y las 100.000 descargas acumuladas. Los dos grandes experimentos nuevos de esta versión son la escritura predictiva, que sugiere texto en línea mientras escribes en el editor de bloques con contexto inteligente, control por teclado y respeto por las Guidelines del sitio, y el cifrado de claves de API, que encripta las claves de los conectores antes de guardarlas en la base de datos y las restaura si el experimento se desactiva. También hay mejoras en la moderación de comentarios, que ahora permite decidir si los comentarios de visitantes anónimos se analizan automáticamente, y en los flujos de redimensionado, resumen y clasificación de contenido, que ahora esperan a que haya suficiente texto antes de habilitarse, evitando resultados inútiles. En cuanto a lo que puede o no llegar a WordPress 7.1 [https://make.wordpress.org/ai/2026/07/10/ai-contributor-weekly-summary-8-july-2026/], el equipo acordó que si embeddings, streaming o trabajo relacionado con Abilities no están listos antes del día anterior a la primera beta, se pospondrán directamente a WordPress 7.2 en lugar de forzar código con revisión insuficiente. Los embeddings técnicamente funcionan, pero necesitan que el cliente de IA, el plugin del proveedor y el almacenamiento en WordPress estén sincronizados para poder probarse de extremo a extremo, y eso todavía no se ha demostrado en la práctica. El streaming también está abierto y esperando revisión. En cuanto a la Abilities API, el equipo ha dejado claro que las abilities deben ser primitivas funcionales independientes de la capa de transporte, ya sea REST, MCP o cualquier otra, y que no hay ningún plan de refactorizar silenciosamente la API REST para que pase por abilities. El equipo de Accesibilidad tiene un debate interesante sobre el uso de blanco puro y negro puro en combinaciones de color [https://make.wordpress.org/accessibility/2026/07/08/accessibility-team-meeting-notes-july-02-2026/]: hay evidencia creciente, respaldada por las discusiones en torno a WCAG 3 y el algoritmo APCA, de que el contraste extremo no siempre ofrece la mejor experiencia para personas con astigmatismo, dislexia u otras condiciones visuales. El equipo propone abrir un ticket de Trac para documentar la investigación y proponer que WordPress adopte blancos y negros suavizados, algo que Gutenberg ya hace en muchos lugares y que sugiere que el blanco puro del nuevo esquema de color «Modern» del administrador de WordPress 7.0 podría haber sido involuntario. En cuanto al trabajo en curso, la revisión de temas con la etiqueta «accessibility-ready» tiene más de cien temas pendientes, setenta y nueve de ellos sin revisión inicial, así que el plazo se ha ampliado para poder absorber el volumen. En Gutenberg, el foco está en la barra de administración unificada que se prepara para 7.1, y quedan pendientes de revisión de accesibilidad el lightbox con leyendas, el procesamiento de medios en el cliente y el editor de medios modal. BuddyPress ha publicado actualizaciones de seguridad y mantenimiento [https://buddypress.org/2026/07/buddypress-14-5-0-and-12-7-0/] para tres ramas activas: las versiones 14.5, 12.7 y 11.6. Se recomienda actualizar cuanto antes. Los dos problemas de seguridad corregidos son una validación insuficiente en la API de mensajes que permitía suplantación de ID de usuario, y una gestión incorrecta de permisos en la administración de componentes que no comprobaba correctamente las capacidades del usuario. Además de las correcciones de seguridad, las nuevas versiones mejoran la compatibilidad con WordPress 6.9, con soporte para las optimizaciones de carga de estilos de bloques y sustitución de API obsoletas, y resuelven varios bugs en Nouveau, Grupos, Amigos, Actividad y la administración general, junto con mejoras de compatibilidad con PHP 8. Una noticia que muchos en la comunidad llevaban tiempo esperando: el proyecto WordPress ha confirmado oficialmente que trabaja en dejar atrás Meetup.com [https://make.wordpress.org/project/2026/07/09/meetup-com-gatherpress/]. La plataforma le cuesta a WordPress Community Support alrededor de 250.000 dólares al año, y a eso hay que sumarle que no cubre bien las necesidades reales de la comunidad. El sustituto elegido es GatherPress, un plugin de código abierto construido por y para la comunidad WordPress, disponible ya en el directorio de plugins. El plan es usar GatherPress como base y construir encima las piezas específicas de WordPress.org, contribuyendo las mejoras de vuelta al plugin cuando sea posible. Anne McCarthy está coordinando el proyecto, con trabajo inicial de Dion Hulse y las contribuciones del equipo de GatherPress. Todavía no hay un calendario concreto, pero la dirección está clara. 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] Calendario de lanzamiento de WordPress 7.1

En poco más de un mes y medio saldrá a la luz WordPress 7.1, y ya se ha planificado su lanzamiento, que comenzará con la beta el 15 de julio. Recuerda que puedes escuchar este programa desde Pocket Casts [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 29 de junio al 5 julio de 2026. WordPress 7.0.1 [https://make.wordpress.org/core/2026/07/01/wordpress-7-0-1-rc1-is-now-available/] está en su Release Candidate 1, con 18 tickets de Core corregidos y 15 pull requests de Gutenberg incluidos. Entre los bugs más relevantes que resuelve están el problema de los botones de publicación apretados en el editor clásico, un fallo que corrompía declaraciones CSS con background-image, problemas de accesibilidad en las Revisiones Visuales, y varios bugs visuales del rediseño del administrador. El lanzamiento final está previsto para el 9 de julio. En cuanto a WordPress 7.1, ya tenemos el calendario de release parties publicado [https://make.wordpress.org/core/2026/07/03/wordpress-7-1-release-party-schedule/]. La Beta 1 sale el 15 de julio, la RC1 el 5 de agosto y el lanzamiento final el 19 de agosto, coincidiendo con la WordCamp US en Phoenix. El equipo de Testing ha publicado una convocatoria de pruebas para una de las funciones más esperadas de WordPress 7.1 [https://make.wordpress.org/test/2026/07/03/call-for-testing-responsive-styling/]: los estilos adaptativos por bloque. La función permite cambiar el tamaño de fuente, el espaciado, los colores o cualquier otro estilo de un bloque de forma independiente para tableta y móvil, sin escribir CSS, directamente desde el inspector del editor. Gutenberg 23.5 [https://make.wordpress.org/core/2026/07/01/whats-new-in-gutenberg-23-5-july-1-2026/] ha llegado con dos novedades principales que se llevan el protagonismo. La primera es la mejora del editor de medios modal, que ahora se extiende también al bloque de Portada: la edición de recorte con lupa, el ajuste de handles al píxel de origen y la corrección de redimensionado con teclado en recortes bloqueados por proporción son los cambios concretos. La segunda es la previsualización de dispositivos unificada con el canvas redimensionable: ya no hay que elegir entre los tres presets fijos de escritorio, tableta y móvil, sino que se puede arrastrar el canvas a cualquier ancho intermedio. Los bloques con visibilidad por dispositivo reaccionan en tiempo real mientras se arrastra, y el selector de dispositivo pasa a ser también el punto de entrada para activar la edición responsiva, que antes estaba en otro sitio. Fuera de esas dos novedades principales, hay cosas reseñables: los Estilos Globales añaden soporte para sombras de texto, el bloque de Iconos gana controles de volteo y rotación e inserta un icono por defecto en lugar de un marcador vacío, el bloque de Búsqueda añade soporte opt-in para el elemento semántico HTML correcto, y la colaboración en tiempo real se puede desactivar por tipo de contenido. El equipo de Core ha publicado las directrices oficiales sobre cómo se sincronizará el código de Gutenberg [https://make.wordpress.org/core/2026/06/30/guidelines-for-syncing-code-from-gutenberg-into-wordpress-develop/] en wordpress-develop a partir de ahora, algo que cambió durante el ciclo de WordPress 7.0 y que hasta ahora no estaba bien documentado. El cambio principal fue abandonar los paquetes npm publicados para pasar a descargar un zip de assets compilados desde GitHub, lo que da más control sobre qué entra exactamente en cada versión de WordPress. Durante el ciclo de 7.1, la sincronización ocurrirá una semana después de cada versión general de Gutenberg, con el objetivo de llegar eventualmente a sincronización semanal o incluso diaria. También hay una propuesta de fusión para WordPress 7.1 que amplía la Abilities API con tres nuevas capacidades de solo lectura [https://make.wordpress.org/core/2026/07/02/merge-proposal-expanding-wordpress-core-abilities/]: core/read-settings, core/read-content y core/read-users. Esta propuesta da el siguiente paso lógico: que un agente de IA o un flujo de trabajo automatizado pueda leer los datos fundamentales que ya gestiona cualquier instalación de WordPress, su configuración, su contenido y sus usuarios, de forma estandarizada y con los mismos controles de permisos de siempre. La propuesta también distingue deliberadamente entre lo que tiene sentido exponer por REST y lo que tiene sentido exponer a un agente: ciertas consultas que REST evita por razones de latencia, como filtros complejos por metadatos, pueden tener más sentido en el contexto de un agente que trabaja en segundo plano y donde el coste de traer todo y filtrar en el cliente es mayor. El equipo de Comunidad tiene sobre la mesa una propuesta para reorganizar sus handbooks [https://make.wordpress.org/community/2026/07/03/proposal-restructure-the-community-team-handbooks/], que llevan años creciendo de forma orgánica hasta convertirse en una lista plana de nueve documentos donde es difícil orientarse, especialmente para quien llega nuevo. La propuesta parte de agruparlos en tres bloques con una lógica clara: uno para las personas que gestionan el propio equipo de Comunidad, con el handbook general, el de respuesta a incidencias y el del programa de educación; otro para organizadores de eventos de cualquier tipo, con los handbooks de Meetup, WordCamp, Campus Connect, eventos online y KidsCamp; y un tercero de materiales de referencia, donde entrarían handbooks específicos para patrocinadores, ponentes y voluntarios, tres documentos que hoy no existen como tal sino que están enterrados dentro del handbook de WordCamp. La propuesta también incluye una reorganización interna del handbook del equipo, y una pequeña idea que puede tener mucho impacto: añadir en la primera página de cada handbook una invitación a hacer el curso correspondiente en Learn WordPress, para que quien llegue sepa por dónde empezar a formarse. WordPress Credits, el programa que acerca a estudiantes universitarios a la contribución a WordPress como parte de su formación académica, ha publicado su balance del primer semestre de 2026 [https://make.wordpress.org/project/2026/06/29/wordpress-credits-updates/] y hay resultados concretos. El dato más llamativo es que el objetivo anual de cerrar veinte acuerdos con universidades y escuelas de todo el mundo ya está cumplido a mitad de año, lo que ha llevado al equipo a recalibrar la estrategia para la segunda mitad. Uno de los pilotos del semestre, un módulo condensado de cincuenta horas, ha funcionado bien y se repetirá en julio y agosto. El otro, que probaba un modelo de mentoría diferida donde los estudiantes hacían el proceso de incorporación solos antes de ser asignados a un mentor, no ha funcionado y ha confirmado lo que ya se sospechaba: la mentoría es uno de los ingredientes esenciales del programa. Como respuesta, se está poniendo en marcha una nueva estructura con responsables regionales que coordinen a los mentores dentro de su zona geográfica. Para el segundo semestre el foco pasa de crecer a consolidar. El objetivo de nuevas alianzas baja intencionadamente a treinta y cinco en total para final de año, priorizando países y ciudades donde el programa aún no tiene presencia. 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.