WordPress Podcast

Josep ha estado este mes de agosto en WordCamp US en el equipo de organización de Comunidad y nos trae su experiencia. Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Por segundo año llega el WP Agency Forum, el evento de agencias WordPress en España, que se reúne en Madrid. Asiste presencialmente con un 20% de descuento en la entrada. Usa el cupon WPPODCAST. Recuerda que puedes escuchar este programa desde: Notas del programa Te dejamos este especial sobre el WP Agency Forum 2026 que se celebrará en Madrid el próximo 7 de octubre. Asiste presencialmente con un 20% de descuento en la entrada. Usa el cupon WPPODCAST.

Los iconos que han mostrado WordPress desde la versión 3.8 parece que desaparecerán en WordPress 7.2, donde se sustituirán por imágenes vectoriales. Recuerda que puedes escuchar este programa desde: Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 31 de agosto al 6 de septiembre de 2026. Ya hay calendario para la primera versión de mantenimiento de la versión actual: WordPress 7.1.1 llegará el 17 de septiembre. El propio equipo reconoce que el volumen y la gravedad de los reportes recibidos en foros, Trac y el repositorio de Gutenberg desde el lanzamiento de la 7.1 justifican preparar esta versión de mantenimiento con más antelación de lo habitual. Como es norma en este tipo de versiones, la 7.1.1 se centra exclusivamente en corregir fallos: solo entran tickets que sean regresiones introducidas durante el propio ciclo de la 7.1 o funciones que se aplazaron deliberadamente al final de ese ciclo, nada de funciones nuevas. También está disponible Gutenberg 23.9, centrada sobre todo en pequeñas comodidades de edición del día a día. Ya no hace falta ir a buscar el botón de insertar bloque cuando este está escondido: ahora se puede añadir directamente desde la barra de herramientas del propio bloque, así que meter una imagen más en una galería o un bloque nuevo dentro de un grupo ya no obliga a cambiar de selección ni a hacer scroll para encontrarlo. Los Estilos Globales, por su parte, ganan un pequeño punto indicador en cada bloque que tenga una anulación de estilo personalizada, con la opción de filtrar y ver de golpe solo los bloques que se han tocado a mano, en lugar de tener que revisarlos uno por uno. Entre el resto de novedades destaca el espaciado independiente entre elementos en horizontal y vertical para el bloque Grupo con diseño flexible o de cuadrícula, la posibilidad de personalizar el estilo de las etiquetas de formulario desde el theme.json, y soporte de Estilos Globales para citas, campos de entrada y desplegables. También se puede añadir una paleta de colores dúotono propia desde el propio panel de Estilos Globales, en lugar de depender solo de las que ofrezca el tema. El resto son mejoras internas de accesibilidad y rendimiento, entre ellas una selección de bloques notablemente más rápida en artículos largos. Hay un parche en marcha que sustituye los Dashicons de la barra de administración y el menú lateral por los nuevos iconos SVG de WordPress, apoyándose en la nueva función que llegó con la 7.1. El motivo no es solo estético: los iconos de fuente tipográfica, como los Dashicons, tienen varios problemas de fondo. Los lectores de pantalla los anuncian de forma imprevisible, ya que ocupan puntos de código Unicode sin significado definido y a veces se leen como un carácter sin sentido en mitad de una frase; se rompen con el modo de alto contraste de Windows y otros ajustes de color forzado, porque el sistema los trata como texto; y cuando el archivo de la fuente falla o carga lento, el resultado son cuadros o símbolos extraños que parecen un sitio roto, mientras que un SVG simplemente no se muestra si falla. El cambio es muy visible de cara al usuario, así que el equipo pide expresamente más opiniones de las que ha tenido hasta ahora en el ticket. Quedan un par de detalles abiertos: el icono de búsqueda queda mirando hacia el lado contrario al Dashicon que sustituye, y el icono de Entradas podría dejar de ser una chincheta a favor de una pluma, aunque ya hay debate sobre cuál encaja mejor. Los Dashicons aparecieron por primera vez en WordPress 3.8 Parker, lanzado el 12 de diciembre de 2013. Llegaron junto con el rediseño del administrador, el proyecto MP6, sustituyendo los antiguos sprites de iconos por una fuente de iconos vectorial, más nítida en cualquier resolución. La versión inicial incluía 167 iconos; en WordPress 3.9 se añadieron 30 nuevos, llegando a 197. Un grupo de contribuidores mantuvo en WordCamp US una charla informal, bajo la regla de Chatham House, sobre la relación de WordPress con el lenguaje PHP y su comunidad. El diagnóstico de fondo es conocido: buena parte de la comunidad PHP no considera a quien desarrolla para WordPress un «desarrollador PHP» de verdad, en parte porque se percibe que el compromiso de compatibilidad hacia atrás de WordPress frena la evolución del propio lenguaje, y WordPress apenas participa en las discusiones donde se deciden las nuevas funciones de PHP. Esa misma ventana larga de compatibilidad genera fricción real en el ecosistema de plugins, cuyas dependencias externas ya no siempre soportan versiones de PHP tan antiguas como las que WordPress sigue admitiendo. El dato que más pesa es la adopción: PHP 7.4 sigue corriendo en aproximadamente un 18% de los sitios web, con poco incentivo reciente para actualizar más allá de la seguridad, ya que esas versiones antiguas ya no reciben parches. Se habló de empujar desde el lado del hosting con una actualización coordinada, de hacer PHP 8.x notablemente más rápido para que la velocidad sea el argumento de peso, y de la preocupación de fondo con PHP 9: si trae un cambio de sintaxis mayor, podría hacerse imposible mantener una sola versión de WordPress compatible con PHP 7.4 y con PHP 9 a la vez. El resto de la charla giró en torno a cómo estrechar lazos con el proyecto PHP: retomar la conversación sobre WebAssembly, que ya se descartó una vez por falta de interés pero que ahora tiene más sentido dado el uso que WordPress ya hace de WASM en Playground; llevar a PHP el trabajo ya hecho en la API de HTML de WordPress, en lugar de mantenerlo solo puertas adentro; y la idea, todavía a nivel de lista de deseos, de que plugins con dependencias inseguras puedan cargarse con permisos restringidos, marcando como no confiable cualquier código que dependa de ellos. Como seguimiento concreto, se plantea revisar si la distribución de versiones antiguas de WordPress en sí ha cambiado, y explorar el envío de avisos automáticos a desarrolladores de plugins cuando su código no sea compatible con una versión de PHP determinada. El Code Reference estrena ejemplos de código ejecutables de verdad, apoyados en WordPress Playground: WordPress 7.1 ya trae los dos primeros, con más previstos para la 7.2. En una de las páginas de referencia hay un botón «Run» que ejecuta el fragmento de código directamente en el navegador, sin salir de la documentación ni montar nada en local. Estos fragmentos interactivos se definen directamente en el DocBlock de cada método, dentro del propio código de WordPress, con una sintaxis ligeramente distinta a la de un ejemplo de código normal. El equipo promete publicar en breve una página del manual con todos los detalles para quien quiera documentar sus propias funciones con este mismo formato. Toca actualizar foros con bbPress porque la versión 2.6.15 corrige cinco fallos de seguridad y varias mejoras de compatibilidad. Los parches refuerzan los permisos a la hora de editar temas y respuestas, dividir o fusionar temas, actualizar el perfil de usuario, y ver foros privados u ocultos; también se blinda la verificación de contraseñas importadas de otros sistemas y se corrigen avisos de PHP en algunas peticiones al foro. Uno de los fallos tiene CVE propio. Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

WordPress trabaja en un sistema de cifrado de las claves que se almacenan en el sistema, tanto para las API de conectores como las que usan otros plugins y herramientas. Recuerda que puedes escuchar este programa desde: Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 24 al 30 de agosto de 2026. La comunidad ha recibido una propuesta de gran calado para WordPress 7.2: una Secrets API, la primera forma nativa de guardar una credencial en WordPress. Hoy, cualquier plugin que necesite guardar una clave de API la escribe en texto plano en la tabla de opciones, lo que significa que acaba en cada copia de seguridad, cada clon de staging y cada terminal compartida; con la llegada de servicios de IA con claves de pago por uso, perder una credencial así ha dejado de ser un problema menor. La propuesta plantea funciones sencillas con cifrado obligatorio y sin opción de desactivarlo, sin ningún filtro que pueda interceptar un secreto en texto plano al recuperarlo, y con soporte desde el primer día para WP-CLI, precisamente para evitar que las credenciales queden expuestas en el historial de la terminal. El plan de trabajo es algo inusual: antes de tocar el core, se publicará como plugin independiente para que la comunidad lo pruebe con sitios reales, y solo después llegará el parche al núcleo con una API idéntica a la del plugin, con la interfaz de administración pospuesta deliberadamente hasta la 7.3 para no precipitar un diseño importante. La propuesta ha generado ya un debate técnico serio en los comentarios, sobre todo por parte de gente de hosting gestionado que explica que sus almacenes de secretos externos son de solo lectura desde WordPress y que el cifrado tiene que resolverse en su HSM externo, no dentro de WordPress, algo que la propuesta actual no contempla bien porque asume que el proveedor de almacenamiento nunca recibe el secreto en texto plano. Se sigue pidiendo feedback activamente, y todo apunta a que el diseño final se moverá bastante respecto a esta primera versión antes de llegar a un parche real. El equipo de IA confirma un dato que conecta directamente con esto: la Secrets API para la 7.2 ya viene probada de antes, ya que es básicamente la misma que lleva meses funcionando como experimento de cifrado de claves dentro del propio plugin de IA. El equipo se ha alineado formalmente a favor de llevarla al núcleo en la 7.2, aunque piden que la documentación incluya una forma sencilla de detectar si la función está disponible, para poder migrar código antiguo con secretos en texto plano de forma limpia. El equipo de Seguridad ha anunciado la Core Security Initiative, un esfuerzo coordinado que explica de paso algo que ya veníamos viendo estas últimas semanas: la avalancha de parches de seguridad de la serie 7.0. Según el propio equipo, el volumen de informes de seguridad ha crecido muchísimo en el último año, en buena parte porque los modelos de IA más avanzados hacen que analizar código en busca de vulnerabilidades sea cada vez más accesible, algo que está pasando en todo el ecosistema del software, no solo en WordPress. Lo cual es, dicen, un buen problema: más ojos puestos en el código hace a WordPress más seguro, pero obliga a escalar cómo se clasifican, validan y resuelven esos informes. La iniciativa se apoya en tres frentes. El primero es un proceso de lanzamiento más sólido y automatizado, con mejores tests de extremo a extremo, para que los parches de seguridad salgan de forma fiable y predecible. El segundo es reducir el backlog de informes abiertos, sumando más gente al equipo y a voluntarios, con el objetivo declarado de llegar a cero incidencias pendientes. El tercero es usar la propia IA para buscar vulnerabilidades de forma proactiva antes de que alguien las explote, como complemento a los informes que llegan por la vía de divulgación responsable. WordPress Playground se ha convertido en algo bastante más ambicioso que un simple sandbox: ahora permite arrancar en el navegador cualquier versión histórica de WordPress, desde la 0.7 hasta la 6.2, mucho antes de que existiera el editor de bloques o la API REST. La novedad se activa con una casilla nueva de «Include older versions» en el panel de ajustes, y por debajo hace un trabajo bastante fino: para WordPress 0.7 a 4.9 usa un compilado de PHP 5.2.17 en WebAssembly, mientras que de la 5.0 a la 6.2 fija PHP 7.4, porque esas versiones intermedias se comportan de forma más fiable ahí que en un PHP moderno. El selector incluso muestra los nombres en clave de cada versión, así que probar la WordPress 2.8 «Baker» es tan sencillo como elegirla en un desplegable. La utilidad práctica es clara para quien desarrolla plugins o temas: reproducir un informe de compatibilidad de un cliente que sigue en WordPress 4.9, comprobar de verdad qué se rompe antes de decidir retirar soporte a una versión antigua, o comparar cómo se comportaba el editor clásico frente al de bloques sin tener que mantener una máquina virtual con PHP antiguo y base de datos aparte. Un grupo de contribuidores está construyendo la alternativa a Meetup.com para los grupos de la comunidad de WordPress, basada en el plugin GatherPress, y ya piden ayuda para probarla en Events.WordPress.org. La idea es que cada grupo tenga su propio sitio donde la gente pueda unirse y confirmar asistencia a eventos, con los organizadores gestionando todo desde la parte pública, sin pasar por el escritorio de administración. Para probarlo basta con entrar en el grupo de pruebas interno con la cuenta de WordPress, momento en el que automáticamente se pasa a ser «Member»; hay otros dos roles con más permisos, «Event Organizer» y «Organizer», accesibles también desde la propia página de miembros para quien quiera probar esas vistas. El equipo pide expresamente una primera impresión general antes que un informe de fallos exhaustivo: unirse a un grupo, confirmar asistencia a un evento, ver patrocinadores y miembros, y sobre todo comparar la experiencia con la de Meetup para detectar qué echaría en falta alguien acostumbrado a esa plataforma. Los primeros comentarios ya han sacado varias carencias interesantes: el editor de descripción del evento es bastante más limitado que el editor de bloques habitual, no se muestra la zona horaria del evento, algo importante para eventos en línea con gente en varios países, y al menos un caso donde abandonar un grupo no retira correctamente la confirmación de asistencia a un evento ya guardado. También hay peticiones de tener un sitio de pruebas en español, ya que el equipo de traducción de Meta y WordCamp ya está trabajando en las cadenas de texto nuevas. WordPress ha firmado la carta abierta «Open Weights and American AI Leadership», que pide a los responsables políticos de Estados Unidos no imponer restricciones tempranas a los modelos de IA de peso abierto, que son los que cualquiera puede descargar, inspeccionar, modificar y ejecutar en su propia infraestructura. La carta se publicó el 24 de julio y ya suman más de 270 empresas y organizaciones firmantes; el argumento de fondo es el mismo que cualquiera familiarizado con el código abierto reconocerá enseguida: la tecnología mejora y es más segura cuanta más gente puede estudiarla y construir sobre ella. Mary Hubbard, directora ejecutiva de WordPress, enmarca la firma precisamente en esa filosofía de veinte años del propio proyecto: la gente que usa una tecnología debería poder moldearla a su gusto, y los modelos de peso abierto extienden esa misma libertad al terreno de la IA. Entre las peticiones concretas de la carta a los legisladores están ampliar el acceso a capacidad de cómputo para startups e investigadores, invertir en recursos compartidos como conjuntos de datos públicos y herramientas de evaluación, mantener más de un tipo de modelo disponible en lugar de reducir el campo a un puñado de sistemas cerrados, y no tratar como robo por defecto prácticas habituales como usar la salida de un modelo para mejorar otro. Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

Ya tenemos un prototipo del próximo plugin de laboratorio Accessibility Lab, al estilo de lo que hacen el de IA y el de Performance. Recuerda que puedes escuchar este programa desde: Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 17 al 23 de agosto de 2026. WordPress 7.1 se lanzó finalmente el 19 de agosto, con nombre en clave Mary Lou, tras pasar por cuatro release candidates, ya que la RC4 llegó con más de 26 correcciones adicionales sobre la RC3 y una congelación de código extendida más allá de las 24 horas habituales, a petición expresa de los committers, para dar tiempo a verificar bien el paquete final antes de publicarlo. El equipo de Core ya busca voluntarios para las versiones de mantenimiento 7.1.x, con la 7.1.1 prevista a principios de septiembre según la gravedad de los bugs que vayan apareciendo. Para quien administre servidores: WordPress 7.1 mantiene el mínimo de PHP 7.4 y es totalmente compatible desde PHP 7.4 hasta PHP 8.5. PHP 8.3 ya está en soporte solo de seguridad y PHP 8.2 llega a fin de vida el 31 de diciembre de este año, así que si hay sitios en esas versiones, conviene planificar la migración. El estreno no estuvo exento de drama. Anne McCarthy, release lead de la versión, ha publicado un extenso diario de decisiones del ciclo donde detalla, entre otras muchas cosas, qué pasó realmente el día del lanzamiento en el escenario de WordCamp US: un commit disparó las actualizaciones automáticas antes de tiempo, con unos 300.000 sitios ya actualizados y un fallo de compatibilidad con WP Rocket reportado en directo, mientras Matt Mullenweg seguía en el escenario sin confirmar si quería «pulsar el botón» del lanzamiento en persona. Ante la falta de comunicación con Mullenweg y con las actualizaciones automáticas ya en marcha, McCarthy tomó la decisión de publicar el anuncio directamente sin esperar al acto en el escenario, asumiendo la responsabilidad de la decisión públicamente. Gutenberg 23.8, publicada el mismo día del lanzamiento de WordPress 7.1, incluye las revisiones visuales, que dan otro paso: ahora se puede enlazar directamente a una revisión concreta, ya que la URL se actualiza sola según se navega por el historial, por lo que compartir un cambio exacto con un compañero es tan sencillo como copiar el enlace, y se añade una vista de diferencias en código dentro del propio editor. Las Notas, por su parte, completan el círculo de las menciones: cuando alguien menciona a otro usuario con una arroba, ahora recibe un correo en su propio idioma con enlace directo a la conversación. La otra gran novedad es de rendimiento puro: la vista de lista recibe una tanda de mejoras que, sumadas, la hacen dramáticamente más rápida en posts largos; en una entrada de 1.000 párrafos, seleccionar todos los bloques pasa de 16,8 a 0,4 segundos. El lienzo vacío del editor también deja de mostrar un simulacro de bloque y renderiza ya un bloque real por defecto, así que lo que se ve antes de escribir es exactamente lo que se obtiene. El bloque Playlist, todavía experimental, mejora su flujo de conversión desde Audio y permite seleccionar varios archivos de golpe desde la Biblioteca de medios, y el bloque Tabs gana navegación por teclado con las teclas Inicio y Fin. El equipo de IA ha lanzado el plugin AI 1.3.0, con dos experimentos nuevos en el editor: traducción de contenido, que traduce bloques de párrafo, encabezado y opcionalmente el título sin salir del editor, dejando siempre el resultado para revisar antes de publicar; y generación de slugs, que sugiere permalinks concisos a partir del título y el contenido, disponible tanto en los controles de permalink como en el flujo previo a publicar. También hay un refuerzo de seguridad notable: verificación de nonce antes de generar texto alternativo o resúmenes en bloque, validación de que las URLs de imágenes externas son públicas y de tipo permitido, y límites configurables de tamaño y tiempo de espera para las descargas de imágenes personalizadas. Además, se apunta hacia dónde va todo esto: de cara a WordPress 7.2, el equipo quiere llevar al núcleo un patrón de Abilities estilo CRUD en lugar de exponer directamente la API REST, para que cada ability pueda anotarse con precisión sobre si es de solo lectura o realiza una acción destructiva. En el Blog de Desarrolladores se ha publicado un tutorial práctico y muy completo sobre la nueva API pública de iconos de la 7.1. Se construye paso a paso un plugin de ejemplo con iconos de restaurante, y aunque el detalle es muy de desarrollador, resume bien el flujo básico: registrar una colección, registrar cada icono pasándole una etiqueta y el contenido SVG o la ruta a un archivo, y usar el resultado directamente en el bloque Icon. Como curiosidad de estilo de código, recomienda apoyarse en enumeraciones de PHP con valores, disponibles desde PHP 8.1, en lugar de arrays sueltos, para evitar errores tontos de tipeo y ganar autocompletado en el editor. Dicho y hecho. Ya está aquí el primer prototipo del plugin Accessibility Lab, que se empezó a comentar hace tan solo unos días. Sigue el modelo ya conocido del plugin Performance Lab y del plugin de IA: reunir en un solo sitio experimentos rumbo al núcleo de WordPress y herramientas prácticas ya probadas por la comunidad, con la diferencia de que aquí todo se queda agrupado en un único plugin en lugar de repartirse en varios pequeños. El equipo insiste mucho en lo que NO es: no sustituye arreglar la accesibilidad directamente en core, y los fallos evidentes, como atributos ARIA mal puestos, etiquetas que faltan o problemas de teclado, se siguen corrigiendo donde están, sin pasar primero por este plugin. El prototipo trae ya tres módulos funcionando. El primero amplía las opciones de vista de la Biblioteca de medios más allá del simple interruptor de scroll infinito que llegó con la 7.1, añadiendo control sobre cuántos elementos se muestran, la densidad y si se ve siempre el nombre de archivo, pensado explícitamente para recoger feedback real de cara a cómo debería resolverse esto en core. El segundo incorpora el trabajo ya existente de Troy Chaplin con su plugin Block Accessibility Checks: validación en tiempo real de bloques, campos meta y estructura del documento contra las WCAG, con un sistema de tres niveles de aviso y enganchable también por bloques de terceros. El tercero es una validación de jerarquía de encabezados que avisa en el momento si un bloque de Encabezado salta un nivel, por ejemplo un H2 seguido directamente de un H4, algo que llevaba años pedido en Gutenberg sin resolverse. De cara al futuro, la idea que más ilusión genera es hacer buscable el texto alternativo de las imágenes, que hoy vive en post meta y por eso no se puede indexar ni buscar a escala, un ticket de Trac abierto desde hace años. Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

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: Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 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. 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, 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, 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 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: 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, 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: 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, 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, con datos que se actualizan semanalmente: 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: 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, y para Safari en macOS desde la Mac App Store. Es un proyecto de código abierto que resuelve un problema muy conocido: 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; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

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: Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 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 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, con doce vulnerabilidades corregidas de golpe. La más destacada, y la única con CVE público 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 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, 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 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, 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, 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; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

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: Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 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. 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 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, 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; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

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: Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 20 al 26 julio de 2026. Ya está la beta 3 de WordPress 7.1, 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: 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: 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, 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 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 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: 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, 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. 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, 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, 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. 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, 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; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

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: Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 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, 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, 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, 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 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, 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 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 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 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: 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, 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; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

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: Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 6 al 12 julio de 2026. WordPress 7.0.1, 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, 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, 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, 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, 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: 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 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. 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; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

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, Spotify y Apple Podcasts o suscribirte al feed directamente. Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 29 de junio al 5 julio de 2026. WordPress 7.0.1 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. 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: 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 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 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: 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, 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 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; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

Desde WordPress 5.0 y la salida del editor de bloques, el editor clásico ha estado ahí… pero ahora comienza la cuenta atrás para su despedida. Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente. Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 22 al 28 de junio de 2026. Ya se ha confirmado el primer paso concreto en la desaparición progresiva del bloque Clásico: a partir de WordPress 7.1, el bloque Clásico deja de aparecer en el insertor de bloques por defecto. Esto no afecta a nada que ya tengas: el bloque sigue registrado, cualquier bloque Clásico existente sigue funcionando y siendo editable exactamente igual que antes, y el editor Clásico tradicional, ya sea a través del plugin Classic Editor o en tipos de contenido que no usan el editor de bloques, no se ve afectado en absoluto. Lo único que cambia es que ya no podrás añadir un bloque Clásico nuevo desde el menú, la biblioteca de bloques o los comandos de barra inclinada. La razón de fondo es de coherencia arquitectónica: el bloque Clásico es el único bloque de Core que no se comporta como un bloque, sino como HTML opaco renderizado a través de un editor TinyMCE incrustado, lo que obliga a tratarlo como caso especial en buena parte de las mejoras que se hacen al sistema de bloques. Si necesitas seguir teniendo el bloque Clásico disponible, hay un filtro específico, que se puede activar globalmente o de forma condicional según el tipo de contenido, y también existe ya un pequeño plugin llamado Enable Classic Block que hace exactamente eso sin tocar código, ya enviado para su aprobación en el directorio de plugins. El objetivo a más largo plazo, que se irá tratando en entradas futuras, es que el bloque Clásico sea completamente opcional y que TinyMCE solo se cargue cuando realmente se necesite, pero ese trabajo queda fuera del alcance de WordPress 7.1, dejando la tarea para WordPress 7.2 o 7.3. Otra propuesta de fusión interesante para WordPress 7.1 detalla cómo se va a construir por debajo la función de Guías de Estilo. La propuesta es incorporar en el núcleo un nuevo tipo de contenido llamado Conocimiento, con su propio post type, pensado como una pieza genérica de almacenamiento para conocimiento del sitio dirigido tanto a autores humanos como a agentes de IA. La idea es que en lugar de que cada plugin de IA invente su propio sistema de almacenamiento, permisos y API REST, WordPress ofrezca una única base común, igual que ya hizo en su momento con plantillas y bloques. Knowledge no es una función visible en sí misma, sino la base sobre la que se construye Guidelines, que sí tiene interfaz propia en Ajustes. El sistema define tres tipos de registro: guideline, un texto fuente de verdad sobre tono, voz o reglas de imagen que algo o alguien tiene que aplicar; memory, contexto duradero guardado explícitamente por el usuario, como preferencias o datos estables, siempre privado y propiedad de su autor; y note, texto de trabajo libre como notas adhesivas o borradores. Los plugins pueden registrar tipos adicionales propios, como un glosario de terminología. El acceso está bastante controlado: los registros nuevos son privados por defecto, ningún tipo de usuario salvo administrador puede gestionar los registros globales del sitio, y nada de esto se expone públicamente a través de consultas del front-end. El equipo de Core es bastante explícito sobre lo que esto no es: no hay proveedor de IA, ni modelo, ni algoritmo de recuperación, ni sistema de memoria autónomo. Lo que se fusiona es únicamente el almacenamiento y el modelo de acceso; cualquier cosa parecida a relevancia, caducidad o consolidación de memoria queda fuera de Core y a cargo de plugins. Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

Continuamos con la segunda parte de la historia de WordPress, donde el código abierto se pone por encima de lo demás. Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente. Notas del programa Noticias General, automated WordPress-to-WordPress sync is unsolvable Retrospective: spending 500 billion Codex tokens Historia de WordPress II: La madurez y el CMS (2008–2012) Cuando terminó 2007, WordPress era ya la plataforma de blogging más popular del mundo. Había superado a Movable Type, había construido un ecosistema de plugins y temas que crecía mes a mes, y tenía detrás a una comunidad que se reunía en WordCamps. Pero seguía siendo, en lo fundamental, una herramienta de blogging. Una herramienta muy buena, con licencia libre y una arquitectura elegante. Pero un blog. Lo que pasó entre 2008 y 2012 es que WordPress dejó de ser un blog para convertirse en algo mucho más ambicioso: una plataforma de publicación genérica, un CMS de facto, y la base sobre la que una industria entera empezó a construir negocios. Este capítulo es el de esa transformación. Y como toda transformación real, no ocurrió en un día: fue una acumulación de decisiones técnicas, debates filosóficos, y momentos bisagra que, vistos en perspectiva, cambiaron la web. La nueva cara — WordPress 2.5 y 2.7 2008 es el año en que WordPress se toma en serio la interfaz de usuario. Y lo hace dos veces en el mismo año, algo que el propio Matt reconocería más tarde como “no ideal, pero necesario”. La primera revisión llega con WordPress 2.5 “Brecker”, publicada en marzo de 2008 y nombrada en honor al saxofonista Michael Brecker. El panel de administración recibe un rediseño completo: nueva navegación, nueva estructura visual, nuevo sistema de menús. Es más limpio, más moderno. Pero la comunidad reacciona con cierta resistencia: el cambio es brusco y muchos usuarios encuentran que la nueva interfaz, paradójicamente, es más difícil de usar que la anterior.  WordPress 2.5 “Brecker” — anuncio oficial WordPress no se queda quieto. Lanza un proceso de feedback y pruebas de usabilidad que es, en sí mismo, un hito en la historia del proyecto: por primera vez, se hacen tests formales con usuarios reales, en Nueva York, grabados en vídeo. El proyecto interno se llama “CrazyHorse”, y sus conclusiones son tajantes: la interfaz de 2.5, a pesar del rediseño, tiene problemas serios de usabilidad. La respuesta llega en diciembre de 2008. WordPress 2.7 “Coltrane” — por John Coltrane, el saxofonista — es el resultado de todo ese proceso. Y es, probablemente, la release individual más importante en la historia de WordPress hasta ese momento. El nuevo panel de administración es completamente diferente. La navegación principal pasa al lateral izquierdo — donde sigue estando hoy. El dashboard es personalizable con drag and drop. Cada pantalla tiene opciones de configuración propias. Llega QuickPress para escribir entradas rápidas directamente desde el panel. Y los comentarios se pueden gestionar y responder directamente desde el dashboard sin entrar en cada post. Pero hay una cosa más. Una que Matt destaca especialmente en el anuncio de la versión y que merece su propio párrafo: “Esta puede ser la última vez que tengas que actualizar WordPress manualmente.” Con la 2.7 llega la actualización automática con un solo clic desde el propio panel de administración. No más descargas, no más FTP, no más reemplazar archivos a mano. Un solo botón. En ese momento, para millones de usuarios sin perfil técnico, eso lo cambia todo. Más de 150 personas contribuyeron código directamente a la release 2.7 — el máximo hasta entonces en la historia del proyecto.  WordPress 2.7 “Coltrane” — anuncio oficial  Usability Testing Report: 2.5 and CrazyHorse  The Visual Design of 2.7 El ecosistema se expande — 2009 2009 es un año de consolidación. Las versiones 2.8 y 2.9 no traen cambios radicales de interfaz, pero sí funcionalidades que el ecosistema estaba pidiendo. WordPress 2.8 “Baker” — junio de 2009, por el trompetista Chet Baker — mejora la API de widgets, permite instalar temas directamente desde el panel de administración al igual que ya se podía hacer con plugins, y mejora el sistema de edición de temas y plugins en el propio admin. También llega una nueva API de widgets que facilita considerablemente el desarrollo de widgets personalizados.  WordPress 2.8 — anuncio oficial WordPress 2.9 “Carmen” — diciembre de 2009, por Carmen McRae — introduce las miniaturas de entradas, lo que se conoce como Post Thumbnails o Featured Images. Parece un detalle menor. No lo es: la imagen destacada se convierte en un elemento fundamental del diseño de temas durante los años siguientes, y es la base visual de miles de diseños de revistas y portales de noticias construidos sobre WordPress. La 2.9 también trae la papelera — los elementos eliminados ya no desaparecen directamente sino que van a una papelera recuperable — y mejoras en la incrustación de vídeo mediante oEmbed.  WordPress 2.9 — anuncio oficial En paralelo a las releases del núcleo, algo importante está pasando en el ecosistema. BuddyPress, concebido en 2008 para añadir funcionalidades de red social a instalaciones de WordPress MU, publica su primera versión estable en mayo de 2009. Permite crear perfiles de usuario extendidos, mensajería privada, grupos, y feeds de actividad. Por primera vez, WordPress puede funcionar como plataforma de comunidad, no solo como herramienta de publicación. Y bbPress — el software de foros de la órbita Automattic — también está creciendo y madurando como complemento natural del ecosistema WordPress.  BuddyPress — Historia oficial  BuddyPress — WordPress.org WordPress 3.0 “Thelonious” — El momento que lo cambia todo 17 de junio de 2010. Esta es la fecha que separa el WordPress-blog del WordPress-plataforma. WordPress 3.0 “Thelonious” — por Thelonious Monk, el pianista de bebop — es el resultado de medio año de trabajo de 218 contribuidores. Es la decimotercera release mayor. Y viene cargada de cambios que, en conjunto, redefinen lo que WordPress puede hacer. El primero y más importante: Custom Post Types y Custom Taxonomies. Antes de la 3.0, WordPress tenía posts y páginas. Eso era todo. Con Custom Post Types, puedes crear cualquier tipo de contenido que necesites: productos, eventos, películas, recetas, propiedades inmobiliarias, fichas de empleados. Lo que quieras. Y con Custom Taxonomies, puedes organizar ese contenido con las categorías y etiquetas propias que necesites, completamente independientes de las del blog. Esta funcionalidad ya existía de forma parcial y experimental en versiones anteriores, pero en la 3.0 se formaliza, documenta, y hace accesible para todos los desarrolladores. Es el momento en que WordPress deja de ser un CMS para blogueros y se convierte en un framework de publicación de propósito general. Cualquier tipo de contenido, cualquier estructura de datos, cualquier lógica de presentación — todo eso se puede construir ahora sobre WordPress.  WordPress 3.0 “Thelonious” — anuncio oficial  Custom Post Types — documentación  Custom Taxonomies — documentación El segundo gran cambio de la 3.0: Multisite. WordPress MU, el proyecto que permitía gestionar múltiples sitios desde una sola instalación y que llevaba años desarrollándose en paralelo al core, se fusiona definitivamente con WordPress. A partir de ahora, cualquier instalación de WordPress puede activar Multisite con un simple cambio en la configuración. Una empresa puede gestionar cien sitios desde un solo panel. Una universidad puede dar a cada departamento su propio blog. Una agencia puede gestionar toda su cartera de clientes desde una instalación. Eso que durante años requería instalar WordPress MU — un proyecto separado con su propia complejidad — ahora es nativo. El tercer cambio visible de la 3.0: Twenty Ten, el nuevo tema por defecto. Sustituye a Kubrick, que llevaba cinco años siendo la cara de WordPress. Twenty Ten es adaptativo, limpio, y demuestra todas las nuevas APIs del core — fondos personalizados, cabeceras personalizadas, menús de navegación sin editar código. Inaugura la tradición de los temas Twenty Something que continúa hasta hoy.  Twenty Ten Theme — WordPress.org La batalla de la GPL — El caso Thesis No todo en 2010 es releases y nuevas funcionalidades. Este año también es el de la confrontación más pública de la historia de WordPress sobre su licencia, y el que define definitivamente las reglas de juego del ecosistema comercial. Chris Pearson es el creador de Thesis, uno de los theme frameworks más populares del momento. Thesis tiene decenas de miles de usuarios y genera ingresos de más de un millón de dólares anuales. Y Thesis no es GPL. Pearson argumenta que un tema para WordPress no es una obra derivada de WordPress y por tanto no está obligado a adoptar la licencia GPL. Su argumento es técnico: si un tema no incluye código de WordPress directamente, sino que simplemente lo usa, no hay herencia de licencia. Es una posición que tiene cierta base jurídica, aunque el análisis de la Software Freedom Law Center había concluido lo contrario. Matt Mullenweg no comparte esa posición. Y en julio de 2010, el debate explota públicamente en una entrevista conjunta en el podcast Mixergy, conducida por Andrew Warner. Es uno de los debates más tensos y más escuchados de la historia de la comunidad WordPress. Mullenweg sostiene que Thesis contiene código directamente copiado de WordPress — lo que sería una violación de copyright clara, más allá de la discusión sobre obras derivadas. Pearson defiende que su código es original. El resultado práctico: Pearson termina lanzando una versión de Thesis con el código PHP bajo GPL, aunque manteniendo otras partes bajo licencia propietaria. No es una victoria total para ninguno de los dos bandos, pero el efecto en el ecosistema es definitivo: la gran mayoría de vendedores de temas y plugins premium mueven sus productos a GPL o a licencias dobles GPL+propietaria para las partes no-PHP. El conflicto subrayó la tensión entre los intereses comerciales y los valores del código abierto dentro del ecosistema WordPress, y es citado frecuentemente como un momento significativo en la historia del proyecto.  Pearson versus Mullenweg, a history — Post Status  Thesis vs. WordPress: The Licensing Dispute — Domain Stories  WordPress License — WordPress.org La industria que crece alrededor — Theme Frameworks y el mercado premium El caso Thesis no es una anécdota. Es el síntoma de algo que está pasando en el ecosistema: WordPress ha generado una industria. Los theme frameworks son el fenómeno más visible de este periodo. La idea es sencilla: en lugar de construir cada tema desde cero, crear un framework — una base estructurada con hooks propios, funciones de utilidad, y un sistema de child themes — sobre el que construir temas hijos personalizados. Genesis, de StudioPress, es el ejemplo que acaba imponiéndose como el más robusto y con el ecosistema más amplio. Pero en este período también están Thesis, Hybrid, y otros. El negocio de los temas premium está en pleno crecimiento. Marketplaces como ThemeForest — parte de Envato, fundada en 2008 — empiezan a vender miles de temas. El modelo es simple: el diseñador cobra una vez por venta, el marketplace se lleva un porcentaje, y el comprador consigue un tema pulido por unos pocos dólares. No todo ese ecosistema es GPL al cien por cien — la tensión sigue — pero el mercado funciona y crece. En paralelo, aparecen las primeras agencias especializadas en WordPress. No ya freelancers, sino estudios con equipos completos que construyen proyectos sobre WordPress para clientes corporativos. WordPress está cruzando la línea que separa “herramienta de bloggers” de “plataforma empresarial”.  StudioPress y Genesis Framework  ThemeForest — WordPress themes De la 3.1 a la 3.5 — La serie que consolida Entre 2011 y 2012, WordPress lanza cinco releases mayores más. No tienen el impacto revolucionario de la 3.0, pero cada una añade algo importante. WordPress 3.1 “Django” — febrero de 2011, por Django Reinhardt — introduce los enlaces entre posts, las post formats, y mejoras en el admin bar. Pero lo más relevante para los desarrolladores es la Query API mejorada: ahora es más fácil y más potente consultar custom post types y taxonomías desde código.  WordPress 3.1 — anuncio oficial WordPress 3.2 “Gershwin” — julio de 2011, por George Gershwin — es una release ligera que se centra en rendimiento y en actualizar los requisitos mínimos: PHP 5.2 y MySQL 5.0. También estrena un nuevo tema por defecto, Twenty Eleven, con un diseño más flexible y totalmente adaptado a diferentes layouts.  WordPress 3.2 — anuncio oficial WordPress 3.3 “Sonny” — diciembre de 2011, por Sonny Stitt — trae una mejora importante en la experiencia de usuario: interfaz de administración más fluida, tooltips contextuales, y una barra de herramientas unificada. También llega Heartbeat API en estado embrionario y mejoras en el sistema de subida de medios.  WordPress 3.3 — anuncio oficial WordPress 3.4 “Green” — junio de 2012, por el guitarrista Grant Green — introduce el personalizador: una interfaz en tiempo real para previsualizar cambios de tema sin necesidad de publicarlos. Aparece en el menú como “Apariencia > Personalizar” y es el embrión de lo que luego se convertirá en una de las APIs más importantes del core.  WordPress 3.4 — anuncio oficial Y cierra el año 2012 WordPress 3.5 “Elvin” — por el batería Elvin Jones —, con un nuevo gestor de medios completamente rediseñado. La gestión de imágenes era uno de los puntos de fricción históricos de WordPress, y la 3.5 lo resuelve con una interfaz moderna basada en Backbone.js y Underscore.js — dos librerías JavaScript que se añaden al core y que sientan la base para los cambios de interfaz que vendrán en los años siguientes. También llega Twenty Twelve, el primer tema por defecto con diseño mobile-first nativo.  WordPress 3.5 “Elvin” — anuncio oficial Las cifras — WordPress conquista la web Los números de este período son reveladores. En 2011, WordPress alimentaba alrededor del 13% de todos los sitios web del mundo. Para finales de 2012, esa cifra había subido hasta el 15-16%, con más del 54% de cuota dentro del mercado de CMS conocidos. Las tendencias anuales muestran que la cuota de mercado de WordPress creció de forma constante desde 2011, lo que indica que la plataforma se consolidó de manera sostenida como el líder indiscutible del mercado de CMS. Para poner eso en contexto: en 2012, Joomla tenía un 10.9% del mercado de CMS y Drupal un 6.1%. WordPress ya era cuatro o cinco veces más grande que sus competidores más cercanos, y la distancia seguía creciendo. En julio de 2011, WordPress superó los 50 millones de blogs activos. No son solo blogs personales. Son proyectos editoriales, tiendas, portfolios, sitios corporativos, intranets, y plataformas de comunidad. WordPress había dejado de ser la herramienta de los bloggers para ser la herramienta de la web.  WordPress Market Share Statistics — Kinsta  WordPress Statistics — WPZOOM  WordPress Market Share — W3Techs La comunidad se internacionaliza Otro cambio decisivo de este período es la globalización de la comunidad. Los WordCamps, que en 2007 eran un fenómeno mayoritariamente estadounidense, se extienden por todo el mundo. WordCamp Europe se celebra por primera vez en 2012, en Leiden, Países Bajos. WordCamps en ciudades de todos los continentes. La estructura descentralizada del proyecto — cualquier grupo local puede organizar un WordCamp siguiendo unas pautas básicas — permite que la comunidad crezca de forma orgánica sin necesidad de coordinación central. Make WordPress — la red de blogs de los equipos de contribuidores — se consolida como el espacio de coordinación del proyecto: hay equipos para el core, para los temas, para los plugins, para la documentación, para la accesibilidad, para la comunidad, para las traducciones. El proyecto se hace más grande y más distribuido al mismo tiempo.  WordCamp Europe — primera edición (2012)  Make WordPress Cierre del capítulo En cinco años, WordPress ha pasado de ser una plataforma de blogging muy buena a ser el CMS más utilizado del mundo. Tiene Custom Post Types para cualquier tipo de contenido. Tiene Multisite para gestionar redes de sitios. Tiene un panel de administración moderno y usable. Tiene una industria — agencias, marketplaces, theme frameworks, plugins premium — construida sobre sus APIs. Y tiene una comunidad distribuida globalmente que contribuye código, traducciones, documentación y eventos. El debate de la GPL con Thesis ha dejado claro que el ecosistema comercial tiene que jugar con las reglas del código libre. Y esas reglas, lejos de matar el negocio, han generado una industria floreciente. Pero hay algo que todavía no ha llegado. Algo que va a tardar unos años más y que va a generar más debate que cualquier otra decisión de la historia de WordPress: un nuevo editor. Una nueva forma de crear contenido. Un cambio que romperá con todo lo anterior. Gutenberg se acerca.

El equipo que prepara WordPress 7.1 ya está listo, y al mismo tiempo se ha conocido una hoja de ruta clara de lo que incluirá esta versión. Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente. Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 15 al 21 de junio de 2026. Ya tenemos fecha y equipo para WordPress 7.1. El lanzamiento está previsto para el 19 de agosto de 2026, coincidiendo con la WordCamp US, y al frente de todo el ciclo estará Anne McCarthy como Release Lead. No es una elección casual: Anne lleva años siendo la persona que recopila y prepara la información de cada nueva versión de WordPress, la que escribe los roadmaps, organiza las novedades, y conecta el trabajo de decenas de equipos en un relato coherente para toda la comunidad. Si alguna vez has querido saber qué venía en una versión de WordPress antes de que saliera, probablemente has leído algo escrito o coordinado por ella. Que ahora lidere un ciclo completo es, sencillamente, la continuación natural de ese trabajo, y pocas personas conocen mejor el pulso del proyecto. El equipo sigue el modelo de escuadras reducidas que se viene usando en los últimos ciclos, apoyándose mucho en los representantes de cada equipo Make para repartir la carga de trabajo. En cuanto al contenido de la versión, el hilo conductor de WordPress 7.1 es la colaboración, tanto entre personas como entre personas e inteligencia artificial. Las Notas dan un salto importante con modo de sugerencias, reacciones con emoji, hilos de respuesta con notificaciones, y la posibilidad de aplicar sugerencias directamente desde una respuesta en un hilo. La colaboración en tiempo real sigue avanzando, aunque todavía hay preguntas estratégicas abiertas sobre qué llegará exactamente a esta versión, si la función completa o solo la arquitectura subyacente, y qué mecanismo de almacenamiento se usará finalmente, aunque ya hay un ganador claro tras las pruebas de rendimiento. Muy ligada a todo esto llega una nueva función llamada Guidelines, una forma persistente y estructurada de definir reglas editoriales, tono de marca y estándares de contenido directamente en WordPress, pensada para que cuando colabores con IA, esta mantenga tu voz y tus preferencias en lugar de generar contenido genérico. En la parte de administración, la paleta de comandos se reorganiza con secciones claras de comandos recientes, sugeridos y coincidentes, y recuerda tus comandos más usados entre sesiones. El Editor del Sitio sigue ganando coherencia visual respetando el esquema de color del administrador. Llega una nueva sección de Identidad en Diseño para gestionar logo, favicon, título y eslogan del sitio desde un único lugar, y un nuevo widget de dashboard llamado «On This Day» que recupera contenido publicado en fechas pasadas para inspirar nuevas publicaciones. La barra de administración, conocida internamente como omnibar, se integra de forma persistente dentro de los editores, eliminando el saludo «Howdy» y modernizando sus iconos. En el terreno de las APIs, la Abilities API amplía sus capacidades de consulta y filtrado con un conjunto curado de habilidades nativas de Core. Los Block Bindings ganan soporte para list-items y bloques internos. El editor avanza hacia forzar el modo iframe en temas de bloques, dejando para una versión futura extenderlo a todos los temas. Sigue en marcha la ampliación del soporte Unicode en correos, nombres de usuario y slugs que ya conocemos, y por supuesto la migración a React 19. En bloques, WordPress 7.1 apunta a tres incorporaciones nuevas: un bloque de Lista de Reproducción con visualización de forma de onda, un bloque de Tabla de Contenidos que genera automáticamente enlaces navegables a los encabezados, y un bloque de Pestañas para organizar contenido en paneles. El bloque Clásico, por su parte, entra en proceso de desaprobación, dejando de cargar TinyMCE por defecto cuando no es necesario, lo que aligera el editor para los sitios que no dependen de él. En diseño y personalización, destaca el trabajo en estilos adaptativos directamente desde el editor, sin necesidad de tocar CSS, junto con el soporte de estados interactivos como hover y focus tanto a nivel global como por instancia de bloque. También se podrá ver con claridad de dónde hereda sus estilos un bloque concreto, ya sea del tema, de un padre o de los estilos globales. En medios, el procesamiento de imágenes en el lado del cliente sigue ampliando formatos soportados y mejorando la resiliencia ante fallos de conexión, y el editor de medios modal sigue recibiendo mejoras de usabilidad. Por último, en cuanto al cliente de IA, el equipo de Core AI ha detallado sus dos grandes apuestas para 7.1. La primera es el streaming de generación, es decir, que las respuestas de IA se vayan mostrando en tiempo real en lugar de esperar a que se complete toda la respuesta, algo más complicado de lo que parece en WordPress porque los servidores normalmente cortan las peticiones a los 30 segundos. Por eso, de momento esta capacidad llegará primero al PHP AI Client, la base que sostiene el cliente de IA pero que no depende directamente de WordPress, dejando el terreno preparado para que hosts y desarrolladores empiecen a construir soporte real en una versión futura. La segunda apuesta son los embeddings, una forma de representar el contenido como vectores numéricos para habilitar búsquedas basadas en significado y no solo en coincidencia de palabras, algo que ya se está probando de forma experimental en el plugin de IA con un sistema de búsqueda vectorial, apoyándose en el soporte nativo que MySQL y MariaDB han añadido recientemente para este tipo de datos. Gutenberg 23.4 ha llegado tras la vuelta de React 19, y precisamente retoma esa migración de forma mucho más prudente: en lugar de imponer la nueva versión por defecto, se añade un flag experimental que permite activarla de forma opcional desde la página de Experimentos, lo que da a desarrolladores de plugins, temas y bloques una vía segura para probar sus integraciones contra React 19 sin que afecte a nadie más mientras no esté listo. El Editor del Sitio también recibe un cambio de aspecto importante: la barra lateral y el contenedor general ahora respetan el esquema de colores del administrador que tenga configurado cada usuario, en lugar de mostrar siempre un fondo oscuro fijo, lo que unifica visualmente la experiencia con el resto del panel de administración. El editor de medios modal sigue puliéndose con varias mejoras de usabilidad: los campos editables del adjunto aparecen ahora en la parte superior del panel de detalles, la barra de herramientas en móvil incorpora control de proporción, y el zoom pasa a manejarse con botones de más y menos en lugar de un deslizador. También llega soporte para imágenes UltraHDR, que se detectan automáticamente al subirlas conservando el mapa de ganancia HDR en las miniaturas generadas. Otra novedad reseñable es que los bloques de Columnas y Galería ahora pueden transformarse directamente en una variación de Cuadrícula, conservando el contenido pero cambiando el tipo de layout. Y en el frente de la colaboración en tiempo real, que sigue siendo exclusiva del plugin de Gutenberg, hay un buen número de correcciones de fiabilidad: un endpoint separado para la persistencia de documentos, mejoras en el sondeo, gestión de salas prohibidas y varias correcciones en el sistema de deshacer. En el Blog de Desarrolladores se ha publicado un tutorial que resuelve un problema clásico de los temas de bloques: cómo cargar un template part distinto según el contexto, por ejemplo mostrar una barra lateral diferente según la categoría del post. En temas clásicos esto era trivial, bastaba con un poco de lógica PHP dentro del propio template. En temas de bloques, en cambio, la solución habitual ha sido crear un template completo nuevo por cada variante, aunque solo cambie un fragmento pequeño de la página, lo que acaba generando una colección de templates casi idénticos. La alternativa que propone el artículo pasa por un filtro que se ejecuta justo antes de renderizar cada bloque y permite interceptar y modificar sus datos sobre la marcha. Lo interesante del enfoque es que es resiliente por diseño: si no existe un template part específico para una categoría, simplemente se mantiene el original sin necesidad de lógica adicional, y solo hay que crear los archivos para los casos en los que realmente se necesita algo distinto. El equipo de Plugins ha publicado un balance que demuestra que su llamada a voluntarios de marzo ha funcionado. Tres nuevas personas han completado su formación de unos dos meses y ya están revisando plugins activamente cada semana. El impacto en la cola de revisión ha sido espectacular: en abril llegó a alcanzar un máximo de aproximadamente 1.050 plugins pendientes, y en pocas semanas cayó prácticamente a cero, a pesar de que las solicitudes de envío seguían rompiendo récords. En mayo, con la cola ya controlada, el equipo llegó a completar cerca de 3.000 revisiones iniciales en un solo mes, en torno al cinco por ciento de todo el directorio, frente a las aproximadamente 1.100 del mismo mes del año anterior. El crecimiento de envíos da una idea de la magnitud del problema que estaban resolviendo: en mayo se alcanzó un nuevo récord de unas 700 solicitudes semanales, 2,7 veces más que en 2025 y cinco veces más que en 2024. El equipo reconoce abiertamente que las herramientas de IA han sido clave para sostener este ritmo, pero insiste en que no sustituyen el criterio humano: las decisiones de juicio, las conversaciones con los autores de plugins y la gestión de incumplimientos de normativa siguen dependiendo de revisores con experiencia. El equipo de Comunidad ha abierto un debate interesante sobre algo que llevaba tiempo sin cuestionarse: si el dinero que se destina a publicidad de las WordCamp realmente funciona. Los organizadores pueden solicitar hasta 400 dólares para marketing y publicidad a través de la subvención de Patrocinio Global, con el objetivo de atraer asistentes nuevos y dar visibilidad al evento en la comunidad local. El problema es que, a día de hoy, no hay forma fiable de saber si ese gasto está dando resultado, si una campaña en redes sociales atrae caras nuevas o solo llega a quien ya iba a asistir, o si una mención en un boletín tecnológico local vale más que un anuncio en Facebook. Entre las ideas que se están valorando están añadir una pregunta obligatoria y sencilla en el momento de comprar la entrada, del tipo «¿cómo te enteraste de este evento?», con opciones como redes sociales, recomendación de alguien, boletín del organizador o grupo de comunidad local; incorporar una pregunta similar en la encuesta posterior al evento que ya rellenan los organizadores que usaron el presupuesto de marketing; y, a más largo plazo, mejorar las herramientas para poder medir esto de forma consistente entre eventos. Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

Si tienes tu propia comunidad local y quieres aprovechar las ventajas de una comunicación global, WordPress ya ha comenzado la integración de múltiples comunidades en el Slack global. Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente. Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 8 al 14 de junio de 2026. El equipo de Core ha integrado en la rama de desarrollo de WordPress 7.1 el sistema que permite el registro de usuarios con cuentas de correo con caracteres compatibles con UTF-8. Las funciones is_email() y sanitize_email() ya aceptan estas direcciones de forma nativa, y se añade una nueva clase WP_Email_Address que permite acceder tanto a la representación ASCII de la dirección, útil para atributos HTML como el href de un enlace mailto, como a la representación Unicode, pensada para mostrarse al usuario. El soporte se puede desactivar mediante filtros para los casos en que un plugin se integre con un servicio externo que todavía no soporte este tipo de direcciones. Aviso importante para quienes usan WP Now en su flujo de desarrollo local: el paquete queda oficialmente obsoleto y no recibirá más actualizaciones. El sustituto recomendado es Playground CLI, la herramienta de línea de comandos oficial de WordPress Playground. La migración es deliberadamente sencilla para los casos de uso habituales. La diferencia más reseñable en cuanto al flujo de trabajo es que en lugar de pasar un parámetro de dónde está el proyecto, hay que entrar en el directorio del proyecto y ejecutar el comando desde ahí, ya que la persistencia del sitio se asocia al directorio de trabajo actual. El equipo de Marketing ha publicado un repaso sobre cómo la IA y la automatización están cambiando la forma en que WordPress da visibilidad al trabajo de su comunidad. Hay tres áreas concretas. La primera son las redes sociales: el proyecto tiene presencia en once plataformas distintas, cada una con sus propias convenciones, y gestionar ese volumen de contenido manualmente era inviable. Ahora hay flujos automatizados con Zapier que recogen contenido de decenas de fuentes y generan borradores adaptados a cada red, de modo que cuando alguien en la comunidad publica una versión, un evento o una entrada en el Showcase, eso llega a 2,4 millones de seguidores en todas las plataformas casi sin intervención humana. La segunda área es WordPress.tv y YouTube: desde que se cerró un ticket de Trac que llevaba siete años abierto, los vídeos de WordPress.tv se publican automáticamente en el canal de YouTube del proyecto con miniaturas y metadatos incluidos. El resultado es que el canal pasó de 14.000 suscriptores a más de 117.000, y las horas de reproducción anuales se multiplicaron por cinco. La tercera es el Showcase: las solicitudes de inclusión se verifican automáticamente, la IA puntúa cada sitio en una escala de cinco estrellas con una justificación escrita, y los que pasan el filtro se envían como issues de GitHub ya con el texto generado. Lo que antes tardaba semanas ahora se hace en minutos. El directorio de plugins de WordPress.org ha estrenado una galería de capturas de pantalla renovada, cerrando un ticket de Meta que llevaba nueve años abierto. El cambio más visible es que las galerías ahora se adaptan al contenido: los conjuntos de imágenes con proporciones similares se muestran en una cuadrícula limpia, mientras que las mezclas de imágenes altas, anchas y panorámicas usan un layout de tipo masonry que respeta las proporciones originales sin recortar detalles importantes de la interfaz. Las galerías se renderizan ahora con los bloques nativos de Galería e Imagen de WordPress, con el lightbox estándar incluido, y las leyendas permanecen conectadas a cada imagen. Ya comentamos hace unas semanas que el Slack de Make WordPress abría las puertas a comunidades locales de todo el mundo. Ahora el equipo de Comunidad ha publicado las instrucciones concretas para dar ese paso. El proceso es sencillo: hay que unirse al canal #community-slack-migration en el Slack de Make WordPress y dejar una solicitud con el nombre del grupo, la URL de Meetup.com o página equivalente, y los canales que se necesitan crear. El historial de mensajes de los workspaces existentes se puede importar, aunque los archivos adjuntos no tienen soporte directo y se exportan como HTML en Google Drive para que no se pierdan. Se pueden pedir varios canales o un canal privado para organizadores, y todo se gestiona caso a caso. El único requisito para los miembros es tener una cuenta en WordPress.org. Entre las comunidades que ya se han apuntado están las de España, Brasil, Japón, Italia, India, Costa Rica, Nicaragua y Pakistán, además de BlackPress, lo que da una idea del alcance internacional que está tomando la iniciativa. Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

Josep ha estado en Polonia durante la WordCamp Europe y nos cuenta su experiencia y lo que se viene. Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente. Notas del programa

Tras el lanzamiento de WordPress 7.0, ha llegado el evento más grande de WordPress del planeta donde se han juntado 2.500 personas del ecosistema para revisar el estado de WordPress y la futura versión WordPress 7.1. Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente. Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 1 al 7 de junio de 2026. La WordCamp Europe 2026 se celebró del 4 al 6 de junio en Cracovia, Polonia, con 2.458 asistentes de 81 países, casi una cuarta parte de los cuales participaban en su primera WordCamp Europe. El evento arrancó con el Contributor Day, donde todos los equipos trabajaron en paralelo, con especial atención a la incorporación de nuevos contribuidores a través de mentores y mesas de bienvenida. La keynote de apertura corrió a cargo del equipo de CERN, el laboratorio europeo donde nació la World Wide Web, que anunció que home.cern ya está funcionando sobre WordPress, migrado de forma automatizada y en producción desde ese mismo día, con una plataforma propia que aprovisiona nuevos sitios en Kubernetes en aproximadamente un minuto y que planean liberar como código abierto. WordPress 7.0 fue el hilo conductor de buena parte del programa. Un panel con contribuidores del lanzamiento repasó cómo se coordina una versión de esta magnitud, y varias sesiones exploraron en detalle las posibilidades que abre la integración nativa de IA: la Abilities API, el cliente de IA, la pantalla de Conectores y el posicionamiento de WordPress como plataforma para construir sobre ellos. También hubo sesiones prácticas sobre la API HTML, rendimiento de WP_Query, escalar WordPress en servidores modestos, la Interactivity API y Full Site Editing, con talleres donde los asistentes se llevaron código funcional. La charla de cierre reunió a Mary Hubbard, directora ejecutiva de WordPress, con Matías Ventura y Rich Tabor para hablar sobre el futuro del proyecto, el papel de la IA y la importancia de atraer a las nuevas generaciones a través de la educación. Entre las noticias de última hora, la Universidad Politécnica de Cracovia anunciará en octubre un curso específico de WordPress, el primero de este tipo en Polonia. La WordCamp Europe volverá el año que viene, del 27 al 29 de mayo de 2027 en Málaga, España, y la próxima cita en el calendario es la WordCamp US, del 16 al 19 de agosto en Phoenix. Matt Mullenweg, que finalmente no pudo asistir a WordCamp Europe, publicó una entrada sobre una nueva iniciativa de seguridad para el directorio de WordPress.org llamada «Protect The Shire», en referencia al universo de Tolkien. El cambio más inmediato y concreto es que a partir de ahora cada nueva versión de un plugin o tema esperará hasta 24 horas antes de distribuirse a través del sistema de actualizaciones automáticas, dando tiempo a revisarla antes de que llegue a los millones de sitios que tienen las actualizaciones automáticas activadas. La motivación es clara: el sistema actual distribuye cualquier actualización en cuanto el desarrollador pulsa el botón, y eso es un vector de ataque real. Ya ocurrió con el caso de Essential Plugins, donde un comprador malintencionado adquirió varios plugins con buena reputación e introdujo código malicioso que se distribuyó automáticamente a todos sus usuarios. El contexto que describe Matt es el de un momento de tensión entre dos fuerzas opuestas: actualizar cuanto antes para estar seguros, y no actualizar cuanto antes para estar seguros. La respuesta que propone es usar IA para revisar cada commit del directorio de forma automatizada, algo que antes era impensable por la escala del problema, con más de 78.000 plugins y temas y más de 3.000 commits al repositorio cada día. El periodo de 24 horas es temporal mientras se afinan los procesos: la idea es que en el futuro esa espera se reduzca a minutos a medida que el sistema de revisión automatizada madure. Para los desarrolladores de plugins, esto implica que una actualización publicada hoy no llegará a los usuarios con actualizaciones automáticas de forma inmediata, algo a tener en cuenta especialmente en actualizaciones de seguridad urgentes. Gutenberg 23.3 ha llegado y es una versión con varios cambios de calado. El más visible para los usuarios es que el editor de medios modal pasa a ser la experiencia de recorte predeterminada: ya no es un experimento que hay que activar, sino el flujo estándar al hacer clic en el botón de recorte de cualquier imagen. El modal integra en un único espacio el recorte libre y por proporción, el volteo, la rotación con control fino, y la edición de metadatos como el texto alternativo y el pie de foto. También llega como novedad estable el soporte de estilos responsivos por instancia de bloque individual: si en la versión 23.2 se podían definir estilos distintos por viewport a nivel global desde los Estilos Globales, ahora eso mismo se puede hacer bloque a bloque, con un inspector que muestra solo los controles relevantes según el estado de pantalla seleccionado. Y la actualización que los desarrolladores de plugins estaban esperando: Gutenberg 23.3 ya está, con matices, construido sobre React 19, lo que lo convierte en el banco de pruebas real para detectar incompatibilidades antes de que este cambio llegue a WordPress 7.1. Aunque hay una actualización importante sobre React 19: la migración ha tenido que dar marcha atrás temporalmente, ya que pocos días después de publicar Gutenberg 23.3 con React 19 integrado, el equipo detectó que muchos plugins ya publicados, desarrollados con React 18, son incompatibles con la nueva versión y causan errores con frecuencia. El problema es más sutil de lo esperado: aunque los cambios de API entre React 18 y 19 son mínimos, los runtimes resultan incompatibles en aspectos inesperados. Gutenberg 23.3.2 ya incluye el revert a React 18. El equipo reconoce que necesita una estrategia de migración más gradual, con la posibilidad de alternar entre versiones mediante un flag experimental y con una capa de compatibilidad para los plugins ya publicados. El objetivo de incluir React 19 en WordPress 7.1 sigue en pie, pero el camino va a requerir más trabajo del previsto. En el apartado experimental, el dashboard personalizable da un salto importante: ahora incluye cinco widgets nuevos, entre ellos Bienvenida, Borrador Rápido, Actividad, Estado del Sitio y Vista Previa del Sitio, todos ellos adaptables al tamaño del tile que ocupan en la cuadrícula. El sistema de diseño del dashboard también ha madurado bastante, con animaciones al arrastrar y redimensionar widgets, un selector de modelo de layout entre cuadrícula y mosaico, y ajustes individuales por widget. Para probarlo hay que activar el experimento «New Dashboard experience» en Gutenberg, en Ajustes, Experimentos. Otras mejoras reseñables: el bloque de imagen añade un interruptor de «Marcar como decorativa» para accesibilidad, las Notas ahora soportan múltiples hilos de discusión por bloque, y hay varias correcciones de rendimiento en la carga del editor y en el uso de listeners compartidos entre instancias de bloque. El equipo de Core ha publicado una convocatoria de pruebas para una de las novedades más interesantes que apunta a WordPress 7.1: el procesamiento de imágenes en el lado del cliente. La idea es que cuando alguien sube una imagen desde el editor de bloques, el propio navegador se encarga de decodificarla, redimensionarla y generar todas las miniaturas usando la biblioteca de procesamiento de imágenes VIPS ejecutada en WebAssembly, antes de enviarlas al servidor. Esto reduce significativamente la carga de CPU y memoria del servidor durante las subidas, y permite ofrecer soporte para formatos modernos como AVIF, WebP, HEIC, Ultra HDR y JPEG XL con independencia de lo que tenga instalado el hosting. Los navegadores que no pueden con el trabajo vuelven automáticamente al flujo de servidor sin que el usuario note nada. La función ha pasado de experimento en Gutenberg a característica estable durante el ciclo de WordPress 7.0, y ahora apunta a integrarse en WordPress Core con la versión 7.1. Para la ronda de pruebas de 7.1 se han añadido capacidades nuevas: soporte para Ultra HDR, JPEG XL, conversión de GIFs animados a vídeo, mejor manejo de errores y mayor resiliencia en subidas en lote. Un detalle importante para quien quiera probarlo: la función solo está activa en navegadores Chromium, porque Firefox y Safari no soportan todavía la política de aislamiento de documentos que necesita el worker de WebAssembly. En Safari sí funciona un modo de respaldo para imágenes HEIC. La edición colaborativa en tiempo real sigue siendo la gran apuesta para WordPress 7.1, y el equipo ha lanzado una iniciativa de pruebas en el mundo real pensada precisamente para lo que faltó en el ciclo de 7.0: usuarios reales editando en condiciones reales, no solo pruebas técnicas en entornos controlados. La idea es crear un canal de Slack dedicado donde early adopters de distintos entornos de hosting puedan activar la función a través del plugin de Gutenberg, usarla en su día a día y dar feedback directamente a los desarrolladores. No se trata de seguir guiones de prueba concretos, sino de usar la función con naturalidad y reportar lo que no funciona bien. El perfil que buscan es el de alguien que genuinamente necesita editar contenido con más personas, ya sea en una pequeña empresa, una redacción, una ONG o un equipo de marketing. El equipo de Hosting también ha hecho una llamada dirigida a los proveedores de alojamiento, pidiéndoles que inviten a sus clientes a participar en el programa. La razón es directa: cuantos más entornos de hosting distintos estén representados en las pruebas, mejor se puede garantizar que la función funcione correctamente en la diversidad de configuraciones que existe en el ecosistema WordPress. El equipo de Playground ha publicado una guía sobre la versión 3 de la GitHub Action para previsualizaciones de pull requests, que simplifica considerablemente el flujo de trabajo respecto a la versión anterior. Cuando alguien abre una pull request en un repositorio de plugin o tema, la action añade automáticamente un botón de previsualización que abre un WordPress Playground completo en el navegador con el código del PR ya instalado y activado, sin que el revisor tenga que montar nada en local. Si se usa ya la versión 2 con builds, la migración vale la pena: se eliminan decenas de líneas de configuración manual y el único punto de atención es asegurarse de que los lanzamientos intermedios que genera el proceso estén marcados como prereleases y no como borradores, porque Playground no puede descargar assets de releases en estado borrador. Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

Han pasado 23 años desde ese 27 de mayo de 2003 en el que se lanzaba la versión 0.70 del nuevo software conocido como WordPress. Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente. Transcripción del programa Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 25 al 31 de mayo de 2026. WordPress cumplió 23 años el 27 de mayo, y Matt Mullenweg lo celebró con una entrada en el blog oficial donde hace balance de un año que define como el más fuerte y el más precario a la vez en la historia del proyecto. En el lado positivo, destaca el lanzamiento de WordPress 7.0: en apenas siete días, el 46% de todas las instalaciones del mundo ya estaban actualizadas automáticamente y sin incidencias. En el lado oscuro, Matt dedica buena parte del texto al conflicto legal con WP Engine y su empresa matriz Silver Lake, que según él está consumiendo tiempo y energía de personas clave del proyecto y ha llegado al punto de intentar disolver la WordPress Foundation. Matt pide públicamente a Silver Lake que ponga fin al litigio, y termina la entrada con un tono muy personal, reconociendo el coste humano que está teniendo para él y para las personas de su entorno. El equipo de Core ha anunciado que WordPress 7.1 tendrá actualización de React: pasará de la versión 18 a la 19, un cambio que llegará primero al plugin de Gutenberg en la versión 23.3 y que se integrará en Core con WordPress 7.1. WordPress 7.0.1 está en planificación para mediados o finales de junio. El bug más urgente detectado tras el lanzamiento de 7.0 afecta a la pantalla de publicación del editor clásico cuando hay botones de acción adicionales añadidos por plugins o tipos de contenido personalizados, lo que provoca que la interfaz aparezca visualmente desordenada. La solución temporal está disponible desde el plugin Classic Editor en su versión 1.7.0. En cuanto al plugin de IA, el equipo anuncia un cambio de cadencia: en lugar de publicar cada dos semanas, pasarán a versiones mensuales, con la 1.1 prevista para finales de junio y la 1.2 para finales de julio. Sobre el cifrado de las claves de API, hay un PR experimental en revisión que introduce cifrado programático de las claves almacenadas, algo que la comunidad lleva tiempo pidiendo dado que actualmente se guardan en texto plano en la base de datos. La decisión es fusionarlo para recoger feedback real antes de la congelación del código de 7.1, con posibilidad de revertir si es necesario. Hay dos temas más que merecen mención. El primero es la Connectors API: se está explorando cómo permitir que los proveedores registren campos de configuración personalizados, como los que necesitan instalaciones locales con modelos tipo Llama, de forma declarativa desde PHP sin requerir componentes React complejos. El segundo es el adaptador MCP, que eleva su requisito mínimo a WordPress 6.9 para poder depender de la Abilities API nativa y eliminar dependencias antiguas. El equipo de Test ha publicado una convocatoria de pruebas para una novedad que afecta directamente a los perfiles de WordPress.org: la integración de funcionalidad de empleo directamente en la infraestructura del proyecto. Jobs.wordpress.net lleva años existiendo como tablón de ofertas de trabajo del ecosistema WordPress, pero ahora se está integrando con los perfiles de una forma mucho más estrecha. Los perfiles ganan nuevas secciones para añadir historial laboral, logros destacados y un interruptor para indicar que estás abierto a oportunidades de trabajo, con la posibilidad de mostrar además el marco de «Open to work» en el Gravatar. Los perfiles marcados como disponibles aparecen directamente en la sección de candidatos de jobs.wordpress.net, convirtiendo el perfil de WordPress.org en algo parecido a una página de candidato ligera dentro del ecosistema. El equipo de Accesibilidad ha publicado el resumen detallado de todas las mejoras que trae WordPress 7.0 en este ámbito, con 24 correcciones y mejoras en Core y 16 en el editor. En Core, los cambios más relevantes afectan a la biblioteca de medios: ahora es posible usarla con software de reconocimiento de voz, y el texto alternativo embebido en los metadatos IPTC de una imagen se importa y asigna automáticamente al subirla, algo que los fotógrafos y agencias que ya etiquetan sus archivos van a agradecer. El nuevo esquema de colores del administrador «Modern» también resuelve varios problemas de contraste que el anterior incumplía según los estándares WCAG, y el restablecimiento de contraseña ahora pre-rellena el nombre de usuario, un requisito de WCAG 2.2 que llevaba tiempo pendiente. En el editor, las novedades más destacadas son el soporte de navegación por teclado en las vistas de cuadrícula de DataViews, mejoras en el bloque de Galería para que el listado de bloques funcione correctamente, y el hecho de que las nuevas interfaces que llegan en 7.0, como las Revisiones Visuales, el lightbox de la galería y la pantalla de Conectores, han pasado todas por revisión de accesibilidad antes de publicarse, algo que el equipo señala como parte del compromiso de cumplir WCAG 2.2 nivel AA en todo código nuevo. Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es. Un abrazo, y hasta el próximo programa.

WordPress acaba de cumplir 23 años, y aprovechamos esta ocasión para contar parte de la historia del proyecto. Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente. Notas del programa Cosas AI Translator (by ROBOTSTXT) WPVulnerability Noticias HackerOne Policy HackerOne Scope Looking Ahead to WordCamp Europe 2026 Historia de WordPress I: El nacimiento y los cimientos (2003–2007) Para entender lo que pasó con WordPress, primero hay que entender lo que había. Y lo que había, en 2002, era un panorama de herramientas de publicación bastante limitado. Si querías tener un blog, tus opciones se reducían a tres o cuatro plataformas, y ninguna de ellas era perfecta. Blogger era la más popular. La había comprado Google en 2003, y tenía la ventaja de ser accesible para cualquiera. Pero era un servicio cerrado: no controlabas tu contenido, no controlabas tu diseño, y las posibilidades de personalización eran mínimas. LiveJournal existía, pero era más una red social que una herramienta de publicación seria. Y luego estaba Movable Type, de la empresa Six Apart, que era probablemente la mejor opción técnica del momento. Tenía una interfaz decente, generaba páginas estáticas rápidas, y era la opción preferida por los bloggers más avanzados. Pero tenía un problema: su licencia no era libre.  WordPress Book — The Blogging Software Dilemma  The History of the Web — 15 Years of WordPress En medio de ese panorama existía b2/cafelog. Un proyecto creado en 2001 por un desarrollador francés llamado Michel Valdrighi. Era simple, era PHP y MySQL, y era GPL — lo que significaba que su código era libre: podías usarlo, modificarlo y redistribuirlo. No era perfecto, pero era hackeable. Y eso, para muchos desarrolladores de la época, valía más que cualquier interfaz pulida. El problema es que en 2002 Michel dejó de actualizarlo. Sin explicación pública, sin traspaso del proyecto. b2/cafelog, básicamente, murió. O al menos, eso parecía.  b2/cafelog — sitio original El post que lo cambió todo Enero de 2003. Matt Mullenweg tiene 19 años, estudia en la Universidad de Houston, y usa b2/cafelog para su blog personal, photomatt.net, donde publica fotos y escribe sobre tecnología, política y jazz. Le gusta b2. Es hackeable, es GPL, es suyo. Pero b2 está muerto: sin actualizaciones, sin soporte, con vulnerabilidades acumulándose. El 24 de enero de 2003, Matt publica en su blog una entrada que cambiaría la historia de la web. Se titula “The Blogging Software Dilemma”. El post es breve, casi casual. Dice, esencialmente: sería genial tener la flexibilidad de Movable Type, el parsing de TextPattern, la hackabilidad de b2 y la facilidad de Blogger. Y luego añade, casi de pasada, que está pensando en hacer un fork de b2. Al día siguiente, un comentario cambia todo. Mike Little, un desarrollador de Manchester, escribe: “Matt, if you’re serious about forking b2 I would be interested in contributing.” (Matt, si de verdad te planteas crear una bifurcación de b2, me interesaría colaborar.) Ese comentario es, literalmente, el momento fundacional de WordPress.  The Blogging Software Dilemma — post original de Matt  WordPress Book — capítulo The Blogging Software Dilemma Mike Little no era un adolescente con inquietudes. Tenía más de 40 años y décadas de experiencia en desarrollo de software. Era el complemento perfecto para Matt: donde Matt tenía visión y carisma, Mike tenía experiencia técnica y rigor. La analogía que se usa a menudo es la de Steve Jobs y Steve Wozniak. Y como Wozniak, Mike Little se quedaría relativamente en las sombras mientras Matt se convertía en la cara pública del proyecto. Y hay un tercer nombre que merece ser mencionado: Michel Valdrighi, el creador original de b2. Lejos de reaccionar mal ante el fork de su proyecto, se unió como desarrollador contribuidor. Un gesto que cierra el círculo de forma bastante elegante.  Mike Little — WordPress: The Early Years (WordCamp Europe 2016)  Mike Little — Wikipedia  The British co-founder of WordPress you’ve probably never heard of WordPress 0.70 — El primer día El 1 de abril de 2003, Matt crea un rama de b2 en SourceForge. Le pone un nombre que le ha sugerido su amiga Christine Selleck Tremoulet: WordPress. Los meses siguientes son intensos. Matt y Mike trabajan en limpiar y modernizar el código de b2. El 27 de mayo de 2003 se publica WordPress 0.70: la primera versión pública. Es minimalista — interfaz de administración básica, editor de texto plano, sin sistema de plugins, sin sistema de temas. Los archivos todavía llevan el prefijo “b2” en sus nombres. Pero ya tiene algo que lo distingue de todo lo demás: está licenciado bajo GPL 2. Cualquiera puede usarlo. Cualquiera puede modificarlo. Cualquiera puede redistribuirlo. No es una elección estratégica todavía — es una herencia de b2. Pero se convertirá en una filosofía. b2/cafelog tenía aproximadamente 2.000 instalaciones cuando WordPress nació. No era mucho. Pero era suficiente para que existiera una comunidad de usuarios que necesitaba una solución.  WordPress 0.70 — documentación oficial  WordPress — Wikipedia  Evolution of WordPress User Interface (2003–2026) Versión 1.0 “Davis” — Nace la tradición del jazz Enero de 2004. Se publica WordPress 1.0, y con ella nace una tradición que perdura hasta hoy: cada versión mayor de WordPress lleva el nombre de un músico de jazz. La 1.0 se llama “Davis”, por Miles Davis. Matt Mullenweg es un fan confeso del jazz. Y esta decisión no es solo un capricho personal. El jazz es improvisación, es colaboración, es libertad creativa. No es casualidad que el proyecto de código libre más grande de la web lleve nombres de jazzistas. La versión 1.0 trae mejoras concretas: instalación más sencilla, moderación de comentarios, enlaces permanentes amigables para el SEO, y un sistema de categorías más robusto. Pero lo más importante es simbólico: WordPress ya no es un fork de b2. Es su propio proyecto, con su propia identidad.  WordPress 1.0 — anuncio oficial  WordPress Version History — SmartWP Versión 1.2 “Mingus” — Llegan los plugins Mayo de 2004. Si tuvieras que elegir un solo momento que defina lo que WordPress es hoy, sería este. WordPress 1.2 “Mingus”, por Charles Mingus, introduce el sistema de plugins. Y esto cambia absolutamente todo. Antes de la 1.2, si querías añadir funcionalidad a WordPress, tenías que modificar el código fuente directamente. Lo que se llamaban “hacks” — archivos con instrucciones de qué líneas del core editar y dónde insertar código. Era frágil, era peligroso, y se rompía con cada actualización. El sistema de plugins fue idea de Ryan Boren, uno de los primeros desarrolladores del núcleo. Su diseño es elegante: una arquitectura de hooks y filters que permite a los desarrolladores engancharse a eventos específicos de WordPress y ejecutar su propio código, todo en archivos completamente separados del núcleo. No tocas el core. No rompes nada. Y tu plugin sigue funcionando después de las actualizaciones.  WordPress 1.2 — anuncio oficial  WordPress Book — WordPress 1.2 Mingus El primer plugin de ejemplo fue Hello Dolly, escrito por el propio Matt. Muestra letras de la canción de Louis Armstrong en el panel de administración. Es inútil, sí. Pero demuestra cómo funciona el sistema de plugins en veinte líneas de código. Más de veinte años después, Hello Dolly sigue instalado por defecto en cada WordPress del mundo. La 1.2 también trae internacionalización con gettext: ya se puede traducir WordPress a cualquier idioma. El primero fue el hindi. Le siguieron francés, noruego, y muchos más. WordPress dejaba de ser solo para angloparlantes. Y hay un factor externo que cataliza todo esto. En 2004, Six Apart cambia las condiciones de licencia de Movable Type. La versión gratuita pasa a estar limitada a un blog y un autor. Si quieres más, pagas. La comunidad de bloggers que había construido sus sitios sobre la promesa de un producto gratuito se siente traicionada. Y WordPress está ahí, con su GPL, con sus plugins recién estrenados, y los brazos abiertos. Es la primera gran oleada de migración hacia WordPress. Y muchos de esos usuarios, una vez que llegan, no se van nunca.  History of WordPress: The Plugin Update History — SiteLock Versión 1.5 “Strayhorn” — Llegan los temas Febrero de 2005. Si los plugins fueron la primera revolución, los temas son la segunda. WordPress 1.5 “Strayhorn”, por Billy Strayhorn, introduce el sistema de temas. Hasta entonces, cambiar el diseño de tu blog significaba editar archivos PHP directamente. Con Strayhorn, WordPress separa el diseño del contenido de forma nativa. El diseño va por un lado. El contenido va por otro. Y los dos se pueden cambiar de forma independiente. Matt lo describe en el anuncio oficial con una frase que resume bien la filosofía del proyecto: “Hemos creado un sistema de temas increíblemente flexible que se adapta a ti, en lugar de esperar que tú te adaptes a él.”  WordPress 1.5 “Strayhorn” — anuncio oficial Con los temas llega Kubrick: el primer tema por defecto, diseñado por Michael Heilemann, un desarrollador danés. Kubrick tiene un header con degradado azul, dos columnas, bordes redondeados. Para 2005, es moderno y atractivo. Y se convierte en el rostro de WordPress durante cinco años — hasta que lo reemplaza Twenty Ten en 2010. Kubrick no es solo un tema. Es el primer contacto visual de millones de personas con WordPress. Ese header azul es un icono de la blogosfera de los 2000. La 1.5 también introduce las páginas estáticas — contenido que no es cronológico, que no es una entrada. Por primera vez puedes tener una página “Sobre mí” o “Contacto” que no se pierde en el flujo de posts. Parece poco. Pero es el primer paso de WordPress más allá del blog.  Default WordPress Themes: History and Evolution — Elegant Themes  The Secret History of Kubrick — HuffPost Automattic y WordPress.com — El negocio alrededor del libre 2005 es un año bisagra. Matt trabajaba en CNET Networks desde 2004, pero en octubre de 2005 deja su empleo para dedicarse a WordPress a tiempo completo. Y lo hace con una jugada audaz: fundar Automattic. Automattic nace en agosto de 2005. La primera contratación es Donncha Ó Caoimh, un desarrollador irlandés que ya contribuía al proyecto. La idea central de Matt es crear una empresa que monetice el ecosistema de WordPress sin comprometer la naturaleza libre del software. Un equilibrio delicado que, más de veinte años después, sigue siendo el corazón del debate sobre WordPress. El primer producto de Automattic es Akismet, un filtro de spam para comentarios. El spam era un problema enorme en los blogs de 2005: los comentarios basura amenazaban con ahogar cualquier conversación. Akismet usa un modelo colaborativo: lo que un usuario marca como spam ayuda a todos los demás. Funciona, y se convierte en el primer ingreso real de la empresa.  Automattic — Wikipedia  Celebrating 20 Years of Automattic Y luego llega WordPress.com. En noviembre de 2005, Automattic lanza WordPress.com como servicio de hosting gestionado. Es una jugada brillante y, desde el principio, controvertida. Democratiza el acceso — no necesitas saber de servidores para tener un blog en WordPress — pero también crea una tensión que persiste hasta hoy: la distinción entre el WordPress.org comunitario y el WordPress.com comercial. Son el mismo software en origen, pero con objetivos y gobernanza distintos. En esta misma época aparece WordPress MU (Multi-User), que permite gestionar múltiples sitios desde una sola instalación. Es la semilla de lo que luego será Multisite en el core. Nace para dar servicio a WordPress.com, pero su código eventualmente se fusionará con el núcleo en la versión 3.0.  WordPress.com — Wikipedia Sección 8: La maduración — De la 2.0 a la 2.3 Diciembre de 2005. WordPress 2.0 “Duke”, por Duke Ellington, es la primera gran revisión del panel de administración. Llega el editor visual WYSIWYG: ya no necesitas saber HTML para escribir una entrada. Se añaden roles de usuario — administrador, editor, autor, colaborador, suscriptor — lo que abre WordPress al trabajo en equipo. Y el sistema de subida de imágenes se simplifica considerablemente.  WordPress 2.0 — anuncio oficial Los dos años siguientes traen versiones que pulen y amplían de forma constante: La 2.1 “Ella”, de enero de 2007, lleva el nombre de Ella Fitzgerald y trae rediseño de interfaz, autoguardado y corrección ortográfica integrada. La 2.2 “Getz”, de mayo de 2007 y en honor a Stan Getz, añade soporte de widgets en las barras laterales. Antes, si querías añadir algo al sidebar, tenías que editar código. Con los widgets, es arrastrar y soltar. Y la 2.3 “Dexter”, de septiembre de 2007, nombrada por Dexter Gordon, introduce las etiquetas como taxonomía nativa y las notificaciones automáticas de actualización. Cada una responde a una necesidad concreta de la comunidad. Son pequeñas individualmente. Pero juntas van construyendo algo: WordPress se está convirtiendo en una herramienta que se puede tomar en serio.  WordPress Version History — WPBeginner  WordPress Version History — SmartWP La GPL como decisión fundacional Hay un hilo que recorre todo este periodo y que merece su propio espacio: la licencia GPL. WordPress hereda la GPL de b2/cafelog. No es una elección original — es una condición. Si forkas código GPL, tu fork también tiene que ser GPL. Pero lo que empieza como una obligación legal se convierte, con Matt, en una filosofía casi militante. Matt defiende la GPL con una convicción que va más allá de lo técnico: argumenta que plugins y temas también son obras derivadas de WordPress, y por tanto también deben ser GPL. Esto es legalmente controvertido. ¿Es un tema una obra derivada si solo usa funciones de WordPress pero no incluye su código fuente? La Software Freedom Law Center emitió un informe apoyando la postura de WordPress, pero el debate nunca se ha cerrado del todo. Las consecuencias prácticas son enormes: cualquier plugin o tema distribuido para WordPress debe poder ser modificado y redistribuido por cualquiera. Esto crea un ecosistema donde el código está abierto por defecto, pero genera tensión permanente con desarrolladores que quieren vender extensiones con licencias restrictivas. La batalla más visible de esa tensión llegará en 2010 con el caso Thesis. Pero las semillas se plantan aquí.  WordPress License — WordPress.org  WordPress themes, the GPL and the conundrum of derivative works El primer WordCamp — La comunidad se encuentra 5 de agosto de 2006. San Francisco. Swedish American Music Hall. El primer WordCamp es un evento de un día, formato BarCamp. Es gratuito. Hay barbacoa para el almuerzo, camisetas, y una agenda que se decide sobre la marcha. Las charlas cubren desde cómo empezar con WordPress hasta temas técnicos avanzados. Mark Jaquith habla de WordPress como CMS — una idea que todavía sonaba radical. Andy Skelton presenta los widgets que está desarrollando para WordPress.com. Donncha habla de WordPress MU. Y Matt da la primera “State of the Word” — su discurso sobre el estado del proyecto, que se convertirá en tradición anual. El mensaje central de esa primera edición: mantener el software simple, con una instalación limpia y una interfaz amigable.  WordCamp 2006 — anuncio en WordPress News  WordCamp 2006 — Matt Mullenweg  WordCamp Central — About WordCamp no es solo un evento. Es la materialización de algo que hasta entonces solo existía en internet: la comunidad de WordPress. Por primera vez, los desarrolladores, los diseñadores, los bloggers, los traductores — gente que solo se conocía por IRC y foros — se encuentran en persona. Algo cambia. La comunidad deja de ser virtual y se hace real. A partir de 2007, los WordCamps se multiplican por ciudades de Estados Unidos. Y pronto cruzarán fronteras. Cierre del capítulo En cinco años, WordPress ha pasado de ser el fork de un proyecto abandonado a tener plugins, temas, una empresa detrás, una comunidad que se reúne presencialmente, y una licencia que garantiza que siempre será libre. Ha superado a Movable Type, ha absorbido su primera gran oleada de migración, y ha establecido los fundamentos técnicos y filosóficos sobre los que se construirá todo lo que viene. Pero lo más importante es lo que todavía no ha pasado. WordPress sigue siendo, fundamentalmente, una herramienta de blogging. No puede gestionar tipos de contenido personalizados. No puede manejar múltiples sitios desde una instalación. No tiene un panel que aguante entornos profesionales de verdad. Todo eso vendrá. Pero para que venga, primero tenía que existir la base. Y esa base — plugins, temas, GPL, comunidad, Automattic — se construyó entre 2003 y 2007.