WordPress Pódcast (español)

[Magazine] Historia de WordPress I: El nacimiento y los cimientos (2003–2007)

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 [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. NOTAS DEL PROGRAMA COSAS * AI Translator (by ROBOTSTXT) [https://git.robotstxt.es/ROBOTSTXT/robotstxt-ai-translator/releases] * WPVulnerability [https://wordpress.org/plugins/wpvulnerability/] NOTICIAS * HackerOne Policy [https://hackerone.com/wordpress/policy_versions?change=3774985&nid=605041014&type=team] * HackerOne Scope [https://hackerone.com/wordpress/scope_versions?change=1258220&nid=605086925&type=team] * Looking Ahead to WordCamp Europe 2026 [https://wordpress.org/news/2026/05/wceu-2026-sessions/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress Book — The Blogging Software Dilemma [https://github.com/WordPress/book/blob/trunk/Content/Part%201/3-the-blogging-software-dilemma.md] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] The History of the Web — 15 Years of WordPress [https://thehistoryoftheweb.com/the-story-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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] b2/cafelog — sitio original [http://cafelog.com/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] The Blogging Software Dilemma — post original de Matt [https://ma.tt/2003/01/the-blogging-software-dilemma/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress Book — capítulo The Blogging Software Dilemma [https://wordpress.org/book/2015/11/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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Mike Little — WordPress: The Early Years (WordCamp Europe 2016) [https://wordpress.tv/2016/06/29/mike-little-wordpress-the-early-years-a-co-founders-view/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Mike Little — Wikipedia [https://en.wikipedia.org/wiki/Mike_Little] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] The British co-founder of WordPress you’ve probably never heard of [https://25.netribution.co.uk/nic/mike-little-the-british-co-founder-of-wordpress-youve-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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 0.70 — documentación oficial [https://wordpress.org/documentation/wordpress-version/version-0-70/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress — Wikipedia [https://en.wikipedia.org/wiki/WordPress] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Evolution of WordPress User Interface (2003–2026) [https://www.wpbeginner.com/showcase/evolution-of-wordpress-user-interface-2003-2009/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 1.0 — anuncio oficial [https://wordpress.org/news/2004/01/wordpress-10/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress Version History — SmartWP [https://smartwp.com/wordpress-versions/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 1.2 — anuncio oficial [https://wordpress.org/news/2004/05/heres-the-beef/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress Book — WordPress 1.2 Mingus [https://wordpress.org/book/2015/11/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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] History of WordPress: The Plugin Update History — SiteLock [https://www.sitelock.com/blog/wordpress-plugin-history/] 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.” > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 1.5 “Strayhorn” — anuncio oficial [https://wordpress.org/news/2005/02/strayhorn/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Default WordPress Themes: History and Evolution — Elegant Themes [https://www.elegantthemes.com/blog/wordpress/default-wordpress-theme] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] The Secret History of Kubrick — HuffPost [https://www.huffpost.com/entry/the-secret-history-of-kub_b_415050] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Automattic — Wikipedia [https://en.wikipedia.org/wiki/Automattic] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Celebrating 20 Years of Automattic [https://automattic.com/2025/06/20/automattic-20-years/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress.com — Wikipedia [https://en.wikipedia.org/wiki/WordPress.com] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 2.0 — anuncio oficial [https://wordpress.org/news/2005/12/wp2/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress Version History — WPBeginner [https://www.wpbeginner.com/news/the-history-of-wordpress/] 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress Version History — SmartWP [https://smartwp.com/wordpress-versions/] 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í. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress License — WordPress.org [https://wordpress.org/about/license/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress themes, the GPL and the conundrum of derivative works [https://wpandlegalstuff.com/wordpress-themes-gpl-conundrum-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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordCamp 2006 — anuncio en WordPress News [https://wordpress.org/news/2006/07/wordcamp-2006/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordCamp 2006 — Matt Mullenweg [https://ma.tt/2006/07/wordcamp/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordCamp Central — About [https://central.wordcamp.org/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.

[Noticias] WordPress 7.0: Louis «Armstrong»

Seguramente una de las versiones más complicadas para lanzar, pero al fin lo ha hecho. WordPress 7.0 ya es una realidad y la integración de la IA en WordPress, también. Recuerda que puedes escuchar este programa desde Pocket Casts [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 18 al 24 de mayo de 2026. Ya está aquí. El 20 de mayo se lanzó oficialmente WordPress 7.0 «Armstrong» [https://wordpress.org/news/2026/05/armstrong/], bautizado en honor a Louis Armstrong, el trompetista de jazz que transformó el género convirtiéndolo en un arte solista y que introdujo la improvisación como lenguaje musical universal. El lanzamiento ha sido coordinado por Matias Ventura como release lead y cuenta con más de 875 contribuidores de todo el mundo, de los que más de 200 participan por primera vez, y ha dado como resultado más de 420 mejoras y correcciones. Ya hemos hablado con detalle de las novedades de esta versión, así que si quieres repasarlas, escucha el episodio anterior, donde lo explicamos todo a fondo. Y si aún no has actualizado, ya sabes: es el momento. El mismo día que se publicaba WordPress 7.0, la rama de desarrollo ya estaba abierta para WordPress 7.1 [https://make.wordpress.org/core/2026/05/20/commence-operation-wp-7-1/], algo que en circunstancias normales ocurre antes, pero que durante este ciclo se había mantenido cerrado para poder gestionar con más control la retirada de la colaboración en tiempo real y la extensión del ciclo. Al día siguiente se publicó la convocatoria de voluntarios [https://make.wordpress.org/core/2026/05/21/wordpress-7-1-call-for-volunteers/] para el equipo de lanzamiento de WordPress 7.1, con una fecha propuesta de lanzamiento final para el 19 de agosto de 2026, coincidiendo con la WordCamp US, aunque asistir al evento no es un requisito para participar en el equipo. El calendario prevé la primera beta para el 15 de julio y la primera versión candidata para el 5 de agosto. Y tenemos algo que puede venir en WordPress 7.1. Se han pedido unas pruebas para el Media Editor Modal [https://make.wordpress.org/core/2026/05/21/media-editor-modal-call-for-testing/], un experimento de Gutenberg que lleva tiempo en desarrollo y que aspira a sustituir la herramienta de recorte inline actual del bloque de imagen por algo mucho más completo. La propuesta es abrir un modal dedicado que reúna en un único flujo el recorte libre y por proporción, el volteo, la rotación con control fino y por pasos, y la edición de metadatos como el texto alternativo y el pie de foto, todo ello construido sobre componentes propios de WordPress en lugar de depender de la biblioteca externa que se usa actualmente. También ha llegado Gutenberg 23.2 [https://make.wordpress.org/core/2026/05/21/whats-new-in-gutenberg-23-2-21-may/], la primera versión del plugin ya orientada al ciclo de WordPress 7.1. La novedad más destacada es la posibilidad de personalizar los estilos de bloques por tamaño de pantalla directamente desde los Estilos Globales: en la sección de bloques aparece un nuevo selector de estado con opciones para tableta y móvil, lo que permite definir estilos distintos según el viewport sin salir del editor. También hay dos cambios relevantes en el paquete de componentes: los modales ahora se muestran como hojas deslizables desde la parte inferior en dispositivos móviles, lo que mejora mucho la usabilidad táctil, y se añaden tokens de animación estandarizados para duraciones y curvas de easing que ya se aplican en componentes como el diálogo, el menú y el propio modal. En el apartado experimental hay bastante movimiento en dos frentes. Por un lado, las pantallas de gestión de Content Types siguen madurando: ahora los slugs se rellenan automáticamente desde el nombre en singular, hay campos de visibilidad para taxonomías, contadores de entradas y términos, y acciones de duplicar, ver y edición rápida. Por otro, el experimento de dashboard personalizable con widgets avanza con un motor de renderizado propio, un modal para insertar widgets, persistencia del layout mediante el sistema de preferencias de WordPress y animaciones usando los nuevos tokens de movimiento. El plugin oficial de IA ha llegado a la versión 1.0.0 [https://make.wordpress.org/ai/2026/05/21/whats-new-in-ai-1-0-0/], publicado un día antes del lanzamiento de WordPress 7.0. Las dos novedades más relevantes de esta versión son dos nuevos experimentos. El primero es el registro de peticiones a la IA, que permite a los administradores revisar qué operaciones se están lanzando, qué proveedores y funciones se están usando y si hay problemas de rendimiento o errores, sentando las bases para una mayor transparencia en el uso de la IA dentro de WordPress. El segundo es la aprobación de conectores, que da a los administradores control sobre qué plugins instalados pueden acceder a los conectores de IA configurados en el sitio, añadiendo una capa de gobernanza importante a medida que más plugins empiezan a integrarse con servicios de IA. El equipo de Core anuncia que la etiqueta «beta» para el soporte de versiones de PHP queda retirada definitivamente [https://make.wordpress.org/core/2026/05/22/php-support-clarification-2026/], y se elimina también de forma retroactiva de toda la documentación histórica. En la práctica esto significa que WordPress 6.9 y 7.0 pasan a documentarse como compatibles de forma completa con PHP 8.5, WordPress 6.8 y versiones posteriores como compatibles con PHP 8.4, y WordPress 6.4 y posteriores como compatibles con PHP 8.3. La razón de este cambio es doble: por un lado, desde PHP 8.0 las actualizaciones dentro de la rama 8.x han sido estables y el trabajo de adaptación de plugins y temas es mucho menor que en el salto a PHP 8.0; por otro, la etiqueta «beta» estaba teniendo el efecto contrario al deseado, generando dudas en usuarios, alojamientos web y desarrolladores de plugins y temas que retrasaban la actualización por precaución. Otra novedad futura es permitir que WordPress acepte direcciones de correo electrónico con caracteres Unicode [https://make.wordpress.org/core/2026/05/22/extending-unicode-support-in-email-addresses-usernames-and-slugs/], es decir, direcciones que contengan letras fuera del rango ASCII, como caracteres árabes, chinos, hindi o cualquier otro alfabeto no latino. Hoy en día los grandes proveedores de correo ya admiten UTF-8 en las direcciones de manera nativa, y el estándar está recogido en el RFC 6530, pero WordPress sigue validando y saneando el correo electrónico como si solo existiesen las letras de la A a la Z. El soporte quedaría restringido a instalaciones con bases de datos utf8mb4, que hoy representan la gran mayoría de los sitios WordPress, y los plugins podrían desactivarlo mediante un filtro. El equipo de IA tiene nuevo liderazgo [https://make.wordpress.org/ai/2026/05/18/leadership-transition-for-the-core-ai-team/]. James LePage y Felix Arntz, que han ejercido como co-líderes del equipo desde su formación en mayo de 2025, han anunciado que dan un paso atrás, aunque seguirán vinculados al equipo en calidad de asesores. James hace balance del año transcurrido: la Abilities API llegó a WordPress 6.9, el cliente de IA se integra en WordPress 7.0, y el adaptador MCP y el plugin oficial de IA han madurado considerablemente con contribuciones de cientos de personas de la comunidad. Jason Adams asume el rol de Team Rep y tomará las riendas del equipo a partir de ahora. Y, para acabar, este pódcast se distribuye con licencia Creative Commons [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.

[Magazine] Cómo se cierra una venta (según Josep)

Ya llega WordPress 7.0 y Josep nos explica cómo trabaja las ventas en su día a día. Recuerda que puedes escuchar este programa desde Pocket Casts [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. NOTAS DEL PROGRAMA NOTICIAS * WordPress 7.0 [https://make.wordpress.org/core/2026/05/14/wordpress-7-0-field-guide/] * Plugin AI v1.0 [https://wordpress.org/plugins/ai/] * Liquid Web Retires StellarWP [https://www.therepository.email/liquid-web-retires-stellarwp-in-botched-rollout-drawing-backlash-from-customers-and-community]

[Noticias] Lo que trae WordPress 7.0

WordPress 7.0 llega el 20 de mayo y trae muchas novedades, aunque algunas de las más notorias hayan quedado fuera. Hacemos un repaso de todo lo que es esta nueva versión. Recuerda que puedes escuchar este programa desde Pocket Casts [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 11 al 17 de mayo de 2026. Esta semana, tras el lanzamiento de RC3 y RC4 [https://wordpress.org/news/2026/05/wordpress-7-0-release-candidate-4/] que sí han sido versiones candidatas, sale WordPress 7.0 [https://make.wordpress.org/core/2026/05/14/wordpress-7-0-field-guide/], y no es una versión cualquiera. Con más de cuatrocientos tickets cerrados en Core, casi quinientas mejoras en el editor y casi quinientas correcciones de bugs, es el lanzamiento más cargado de novedades desde la integración de Gutenberg. Vamos a repasar todo lo que trae, empezando por lo que van a notar los usuarios y terminando por lo que importa a los desarrolladores. Lo primero que va a llamar la atención cuando alguien actualice a 7.0 es que el administrador de WordPress tiene una cara nueva. El esquema de colores predeterminado, que se llamaba «Fresh», ha sido reemplazado por uno nuevo llamado «Modern»: más limpio, con mayor contraste, tipografía mejorada y un aspecto más coherente con el editor de bloques. Este cambio es puramente visual, sin modificaciones en la estructura ni en los nombres de las clases CSS. Además, navegar entre pantallas del administrador ahora incluye transiciones suaves gracias a la View Transitions API del navegador, aunque solo se activan si el usuario no tiene configurada la preferencia de reducción de movimiento en su sistema operativo. El resultado es una experiencia de administración que, por fin, no parece de hace diez años. Otra novedad que se va a notar de inmediato es el acceso directo a la paleta de comandos desde la barra de administración. Con un simple clic en el icono de búsqueda, o con el atajo de teclado Control+K en Windows o Comando+K en Mac, se abre la paleta de comandos desde cualquier pantalla del administrador: mientras se edita un post, mientras se revisa el listado de plugins o desde cualquier otro sitio. Pequeño cambio, gran impacto en la productividad. Una de las funciones estrella de esta versión son las Revisiones Visuales. El sistema de revisiones de WordPress ha sido completamente reimaginado. Ya no hay que salir del editor para comparar versiones: ahora todo ocurre dentro del propio editor de bloques, con un modo de revisión que se activa sin cambiar de pantalla. Un deslizador en la cabecera permite navegar por el historial de versiones viendo los cambios en tiempo real directamente sobre el contenido. El sistema usa un código de colores intuitivo: amarillo para bloques modificados, rojo para texto eliminado y verde para texto añadido. Para documentos largos hay un minimapa junto a la barra de desplazamiento que indica dónde están los cambios, y al hacer clic se salta directamente a esa sección. Cuando se está revisando el historial, el botón de publicar se convierte en un botón de restaurar. También hay novedades en las Notas: los datos ahora sincronizan automáticamente, se pueden añadir notas en varios bloques a la vez con selección parcial y edición de texto enriquecido, hay un nuevo widget en el dashboard, notificaciones por correo electrónico cuando alguien deja un comentario en tu contenido, y un atajo de teclado para añadir notas rápidamente. La otra gran apuesta de WordPress 7.0 es la integración de inteligencia artificial directamente en el núcleo. WordPress incluye ahora un cliente de IA y una pantalla de conectores, que se encuentra en Ajustes → Conectores. Desde ahí se pueden gestionar las conexiones con proveedores de IA como OpenAI, Anthropic o Google: WordPress detecta automáticamente el proveedor, instala el plugin correspondiente y pide la clave API. La arquitectura es agnóstica al proveedor, lo que significa que funciona igual independientemente del servicio que elija el usuario. Esta infraestructura no está limitada a la IA: cualquier plugin que necesite conectarse a un servicio externo puede aprovechar este sistema centralizado de gestión de claves y conexiones. Si se quiere ver la IA en acción, el plugin AI [https://wordpress.org/plugins/ai/] está disponible en el repositorio con funciones como generación de títulos, extractos y texto alternativo para imágenes. La gestión de tipografías también tiene novedades importantes. Hasta ahora, el gestor de fuentes vivía enterrado dentro de los Estilos Globales del editor. En WordPress 7.0 hay una página dedicada bajo el menú de Apariencia, disponible para todos los tipos de temas, tanto de bloques como clásicos. Desde ahí se pueden instalar, gestionar y previsualizar fuentes en un único espacio, sin tener que navegar por varios paneles anidados. En cuanto a bloques nuevos, WordPress 7.0 incluye dos. El primero es el bloque de Migas de Pan, que genera automáticamente la jerarquía de navegación de la página actual: funciona con páginas jerárquicas, taxonomías, archivos de categorías, resultados de búsqueda, páginas de error 404 y tipos de contenido personalizados. Tiene opciones de alineación y permite configurar si el último elemento aparece como texto o como enlace. El segundo bloque nuevo es el de Iconos, que permite añadir iconos decorativos de una colección incluida directamente en el núcleo de WordPress. La extensibilidad para colecciones de terceros está prevista para WordPress 7.1. Hay muchas mejoras en bloques existentes. El bloque de Galería ahora tiene navegación completa en el lightbox: se pueden ver las imágenes en grande y pasar entre ellas con botones, con el teclado o deslizando el dedo en móvil, con soporte para lectores de pantalla incluido. El bloque de Portada puede usar vídeos embebidos de plataformas como YouTube o Vimeo como fondo de sección, sin necesidad de subir el archivo de vídeo al servidor, lo que reduce considerablemente el consumo de ancho de banda y espacio. El bloque HTML ha sido rediseñado: ahora se abre en un modal con pestañas separadas para HTML, CSS y JavaScript, lo que lo convierte en una herramienta mucho más útil para personalizaciones avanzadas. El bloque de Imagen ha mejorado su edición en línea, con controles más accesibles para recortar, rotar y hacer zoom, además de soporte para el punto focal y ajuste de proporciones en alineaciones anchas y completas. El bloque de Cuadrícula ahora es responsivo incluso cuando se define un número fijo de columnas: antes había que elegir entre responsivo o fijo; ahora se pueden definir ambos, y el número de columnas actúa como máximo mientras la cuadrícula se adapta al ancho disponible. El bloque de Párrafo gana soporte para indentación de texto, configurable a nivel de bloque individual o globalmente desde los estilos del tema, y también para texto en columnas. El bloque de Verso ha sido renombrado a Poesía. Y el Query Loop ahora permite excluir términos de los resultados. Hay dos funciones que merecen mención especial por su impacto en la construcción de sitios. La primera es la visibilidad de bloques por dispositivo: desde cualquier bloque se puede elegir si se muestra en escritorio, tableta o móvil, sin afectar a los otros tamaños. Los bloques con reglas de visibilidad activas muestran un indicador en la vista de lista del editor. La segunda es la personalización de los menús hamburguesa en móvil: el bloque de Navegación ahora permite crear overlays completamente personalizados desde el Editor del Sitio, con sus propios patrones, estilos y hasta un bloque específico para el botón de cierre. WordPress incluye cuatro plantillas de overlay predefinidas para empezar rápido. La edición de patrones también ha cambiado de forma significativa. Por defecto, los patrones ahora entran en modo de solo contenido cuando se seleccionan: en lugar de ver todos los bloques individuales, se ve un panel que muestra directamente los campos de texto e imagen para editar, sin tocar la estructura de diseño. Si se necesita modificar el diseño completo, se puede acceder a través del botón de editar patrón. El objetivo es que los patrones funcionen como objetos de diseño inteligentes: el contenido es editable, la estructura está protegida por defecto. Otras mejoras de calidad de vida para todos los usuarios: el selector de color ahora permite pegar valores directamente desde el portapapeles, sin tener que seleccionar manualmente el tono; el control de enlace valida las URLs antes de guardarlas para evitar enlaces rotos; y el registro de nuevos usuarios es más seguro, porque los roles de administrador y editor han sido eliminados del selector de rol predeterminado, de modo que un nuevo usuario ya no puede recibir permisos elevados por accidente. Para cerrar la parte de usuario, vale la pena mencionar las mejoras de accesibilidad: el restablecimiento de contraseña ahora se prerellena con el nombre de usuario para cumplir con WCAG 2.2, hay una nueva función para importar el texto alternativo de imágenes desde sus metadatos IPTC, y el CSS para texto oculto de lectores de pantalla se ha mejorado para evitar que algunos lectores lean el texto letra por letra. Pasando a la parte de desarrolladores [https://developer.wordpress.org/news/2026/05/whats-new-for-developers-may-2026/], WordPress 7.0 incluye un cliente de IA accesible desde PHP mediante una función centralizada que abstrae completamente el proveedor: los plugins no necesitan gestionar claves ni preocuparse por qué servicio usa el propietario del sitio. Hay también una Abilities API en el lado del cliente, como complemento de la API de servidor que llegó con WordPress 6.9, que permite registrar capacidades accesibles desde JavaScript. Para desarrolladores de bloques, la novedad más importante es el registro de bloques exclusivamente en PHP: con el flag autoRegister y un callback de renderizado, se puede crear un bloque sin escribir JavaScript, y WordPress genera automáticamente los controles del inspector a partir de los atributos declarados. El sistema de Pattern Overrides se extiende ahora a cualquier bloque, no solo a los cuatro bloques de Core que lo soportaban antes. DataViews y DataForms reciben nuevos layouts, validación y mejoras de agrupación. La Interactivity API añade una función watch() para reaccionar a cambios de estado de forma reactiva. El editor ahora fuerza el iframe cuando todos los bloques del post usan la versión 3 de la Block API o superior. CodeMirror se actualiza a la versión 5 con soporte ES6. La versión mínima de PHP requerida pasa a ser la 7.4. Se actualizan también backbone.js, la librería Requests y PHPMailer. Hay un nuevo filtro para personalizar las pestañas del listado de plugins, la lógica de Block Hooks se mueve al controlador REST, y se sientan las bases de un sistema de enrutado extensible para el editor del sitio que será la base de nuevas páginas de administración en versiones futuras. WordPress 7.0 se lanzará el miércoles 20 de mayo, alrededor de las 17:00 en horario universal. El plugin oficial de IA de WordPress ha llegado a la versión 0.9 [https://make.wordpress.org/ai/2026/05/11/whats-new-in-ai-0-9-0/] y trae dos experimentos nuevos que se centran en flujos de trabajo editoriales. El primero es la moderación de comentarios con IA: el sistema analiza automáticamente cada comentario usando detección de sentimiento y toxicidad antes de que llegue al listado de pendientes, lo que ayuda a los administradores a identificar spam, acoso o contenido de baja calidad sin revisarlo manualmente uno a uno. El segundo experimento es el redimensionado de contenido: desde la barra de herramientas del editor se puede seleccionar texto y pedir que lo acorte, lo amplíe o lo reformule directamente, con un modal que muestra el original y la versión nueva para decidir si se acepta. Son dos funciones orientadas a agilizar tareas editoriales cotidianas sin salir del editor. Para el lado más técnico, la versión 0.9.0 añade un modo de desarrollador en la página de ajustes del plugin que permite elegir proveedor y modelo de IA de forma independiente para cada función. Esto facilita comparar cómo se comportan distintos modelos o proveedores en tareas concretas, algo muy útil para optimizar coste y rendimiento. También llega un nuevo comando WP-CLI, wp ai alt-text generate, que permite generar texto alternativo en bloque para toda una biblioteca de medios sin pasar por la interfaz gráfica, ideal para migraciones, auditorías de accesibilidad o pipelines de automatización editorial. El equipo tiene como objetivo publicar la versión 1.0 el martes 19 de mayo [https://make.wordpress.org/ai/2026/05/13/ai-contributor-weekly-summary-13-may-2026/], un día antes del lanzamiento de WordPress 7.0, para que los primeros en actualizar tengan ya disponible la versión estable del plugin como compañero de la nueva versión del núcleo. Uno de los experimentos previstos para la versión 1.0 es el sistema de aprobación de conectores: por defecto, ningún plugin instalado puede usar los conectores de IA ni acceder a las claves API almacenadas sin que el administrador lo apruebe explícitamente. La razón es que, a diferencia del riesgo tradicional con plugins que acceden a opciones de la base de datos, los modelos de lenguaje tienen la particularidad de poder absorber y transmitir contexto de forma no determinista, lo que hace que el control de acceso sea especialmente importante. El grupo reconoció abiertamente que este sistema no elimina todos los riesgos, ya que un plugin malicioso podría igualmente leer las claves directamente de la base de datos, pero la decisión fue avanzar con el experimento ahora y construir sobre eso en versiones futuras, en lugar de esperar a una solución perfecta. El segundo experimento que se incluirá es el registro de peticiones a la IA, usando una tabla de base de datos propia para evitar problemas de rendimiento, con contexto truncado para no inflar el almacenamiento y con seguimiento opcional de tokens cacheados para facilitar el análisis de costes con proveedores como Anthropic u OpenAI. Además, en el Blog de Desarrolladores se ha publicado un tutorial práctico que muestra cómo construir un plugin de generación de imágenes [https://developer.wordpress.org/news/2026/05/how-to-build-an-image-generation-plugin-with-the-wordpress-ai-client/] usando el nuevo cliente de IA de WordPress 7.0: el plugin añade un botón a la Biblioteca de Medios, el usuario escribe un prompt, se genera una imagen y puede guardarla directamente como adjunto, todo ello sin que el plugin gestione claves API ni se ate a ningún proveedor concreto. Lo interesante del ejemplo es que deja claro cuánto código es realmente de IA y cuánto es WordPress estándar: la integración con el cliente de IA ocupa apenas una decena de líneas; el resto es registro de rutas REST, gestión de medios y carga de scripts, exactamente igual que cualquier otro plugin. El equipo de Polyglots trae dos propuestas. La primera es una mejora de usabilidad en el editor de traducciones [https://make.wordpress.org/polyglots/2026/05/14/added-a-validation-top-bar-and-an-opt-out-in-the-translation-editor/]: los validadores solían tener que cambiar de pestaña para revisar el contexto de una cadena y luego volver a la pestaña Meta para aprobar, rechazar o marcar como fuzzy, porque los botones de acción solo aparecían ahí. Ahora hay una barra fija en la parte superior del editor que replica esos botones y permanece visible independientemente de la pestaña activa, lo que elimina ese ir y venir innecesario. La segunda novedad es la actualización de los modelos de OpenAI [https://make.wordpress.org/polyglots/2026/05/14/openais-gpt-5-4-and-gpt-5-5-models-are-available-at-translate-wordpress-org/] disponibles para sugerencias de traducción automática: la lista anterior de doce modelos ha quedado reducida a cinco, agrupados por precio, siendo los más recientes el gpt 5.5 pro en el nivel más caro, el gpt 5.5 y 5.4 en el nivel medio, y el gpt 5.4 mini y 5.4 nano en el más económico. Y, para acabar, este pódcast se distribuye con licencia Creative Commons [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.

[Noticias] WordPress 7.0, sin Real Time Collaboration

Finalmente, el trabajo del Real Time Collaboration vendrá en WordPress 7.1 y no en 7.0, teniendo en cuenta los problemas de rendimiento y los cambios que se necesitan para su nueva implementación. Recuerda que puedes escuchar este programa desde Pocket Casts [https://www.wppodcast.es/pocketcasts/], Spotify [https://www.wppodcast.es/spotify/] y Apple Podcasts [https://www.wppodcast.es/apple/] o suscribirte al feed [https://www.wppodcast.es/feed/podcast/] directamente. TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 4 al 10 de mayo de 2026. La gran noticia de esta semana en torno a WordPress 7.0 es que la colaboración en tiempo real no estará en la versión final. Matt Mullenweg tomó la decisión de retirarla [https://make.wordpress.org/core/2026/05/08/rtc-removed-from-7-0/] citando problemas de superficie de ataque, condiciones de carrera, carga en servidor, eficiencia de memoria y bugs recurrentes detectados en pruebas de fuzz. Es una decisión difícil dado el trabajo invertido, pero se toma en beneficio de lanzar una versión estable. La característica se reevaluará durante el ciclo de WordPress 7.1, y mientras tanto sigue disponible a través del plugin de Gutenberg para quien quiera seguir probándola. Los datos técnicos detrás de esa decisión [https://make.wordpress.org/core/2026/05/08/results-real-time-collaboration-performance-testing-analysis/] también se han publicado. Ocho entornos de hosting distintos, incluyendo configuraciones con y sin caché de objetos persistente, participaron en las pruebas de rendimiento. El análisis muestra con bastante claridad que la estrategia de almacenamiento con una tabla dedicada combinada con caché de objetos para la detección de presencia de usuarios es la ganadora: aproximadamente un 52% más rápida que la implementación actual, y la única que escala bien tanto con caché como sin ella. Esta información guiará el trabajo en la siguiente iteración de la característica. Con todo eso sobre la mesa, el 8 de mayo se publicó la Release Candidate 3 de WordPress 7.0 [https://wordpress.org/news/2026/05/wordpress-7-0-release-candidate-3/], que ya incorpora la retirada de la colaboración en tiempo real y resuelve más de 143 incidencias adicionales desde el RC2. La fecha de lanzamiento final sigue siendo el 20 de mayo. Si tienes plugins o temas, es el momento de probarlos contra este RC3 y actualizar el campo Tested up to a 7.0. Ha llegado Gutenberg 23.1 [https://make.wordpress.org/core/2026/05/07/whats-new-in-gutenberg-23-1-07-may/] con una buena cantidad de novedades, aunque muchas todavía en modo experimental. Lo más llamativo para el día a día es la mejora en la subida de imágenes: las miniaturas ahora se generan en paralelo en lugar de secuencialmente, lo que se nota especialmente al subir imágenes en bloque a través del bloque de galería o en conexiones lentas. En el apartado experimental hay cosas interesantes. La gestión de taxonomías personalizadas desde el administrador sin escribir PHP es una de las más esperadas: con el experimento activado aparece una pantalla de Taxonomías en Ajustes donde se pueden crear, editar y eliminar taxonomías desde la interfaz. También hay un nuevo editor de medios con recortador de imagen de forma libre para los bloques de imagen y logotipo del sitio. Y el experimento para deshabilitar TinyMCE ha evolucionado: en lugar de eliminarlo todo, ahora simplemente oculta el bloque Clásico, dejando funcionar las instancias existentes, lo que es bastante más razonable. El plugin de IA sigue su cadencia de versiones cada dos semanas [https://make.wordpress.org/ai/2026/05/08/ai-contributor-weekly-summary-29-april-2026/]: la 0.9.0 acaba de salir [https://make.wordpress.org/ai/2026/05/08/ai-contributor-weekly-summary-6-may-2026/] con redimensionado de contenido, moderación y correcciones varias, y el objetivo es llegar a la versión 1.0.0 coincidiendo con WordPress 7.0. En paralelo, el adaptador MCP, que permite a asistentes como Claude o ChatGPT interactuar con WordPress, está terminando los últimos detalles para publicarse como plugin independiente en el repositorio. Uno de los debates más interesantes gira en torno a la seguridad de las claves de API. El equipo está valorando un mecanismo de aprobación de conectores que permitiría a los administradores controlar qué plugins pueden acceder a las conexiones configuradas con proveedores como OpenAI, Anthropic o Google. Varios contribuidores advierten de que resolver esto solo desde un plugin puede dar una falsa sensación de seguridad, y que lo que WordPress necesita en el fondo es una API de gestión de secretos en core. La idea es que este experimento sirva de primer paso y empuje esa conversación hacia WordPress 7.1. El equipo también ha empezado a definir qué viene después de haber completado las bases técnicas de la IA en WordPress. Las conversaciones apuntan a educación, buenas prácticas, apoyo a otros equipos de contribuidores con herramientas de IA, y posicionamiento estratégico a largo plazo. En el Blog de Desarrolladores se ha publicado una guía práctica para empezar a escribir tests end-to-end para WordPress usando Playwright [https://developer.wordpress.org/news/2026/05/getting-started-writing-wordpress-e2e-tests-with-playwright/]. El artículo parte de la base de que los tests unitarios cubren una capa, pero los tests E2E cubren otra distinta: simulan lo que haría un usuario real en el navegador, comprobando cómo funciona el conjunto del sistema, no componentes aislados. Gutenberg los lleva usando desde el principio, y desde hace unos años también forman parte de WordPress Core. El grueso del artículo está orientado a desarrolladores de plugins y temas, con ejemplos concretos sobre un proyecto de reseñas de libros. Para quien nunca ha tocado Playwright en el contexto de WordPress, la guía es un buen punto de entrada: la curva de arranque es razonable, los ejemplos son reales y el código completo está disponible en un repositorio público. El equipo de Accesibilidad ha actualizado los requisitos para obtener la etiqueta «accessibility-ready» [https://make.wordpress.org/accessibility/2026/05/06/accessibility-ready-requirements-updated/] en los temas del directorio oficial. Los criterios anteriores databan de 2011 y 2012, antes de que existieran Web Content Accessibility Guidelines 2.1, 2.2, HTML 5 o ARIA con soporte generalizado, así que la actualización era más que necesaria. El cambio más importante en la estructura es que se han eliminado las «recomendaciones»: ahora todo lo que aparece en la lista son requisitos, algunos que antes eran opcionales han pasado a ser obligatorios, y otros se han descartado directamente por considerarse buenas prácticas que no deberían bloquear la aprobación. Además, cada requisito sigue ahora un formato estándar con tres secciones: el principio básico, las instrucciones de prueba paso a paso con criterios claros de éxito o fallo, y enlaces a la documentación correspondiente. Para los autores de temas que ya tienen la etiqueta, la fecha límite para adaptarse a los nuevos requisitos es el 30 de junio de 2026. Pasada esa fecha, los temas que no cumplan los nuevos criterios perderán la etiqueta. El Slack de WordPress, el chat donde se comunica toda la comunidad, da un paso importante hacia la internacionalización [https://make.wordpress.org/project/2026/05/07/welcome-all-languages-and-communities-to-make-wordpress-slack/]: las comunidades locales de todo el mundo podrán integrarse en el mismo espacio que ya usan los equipos de contribuidores del proyecto, sin tener que elegir entre su comunidad local y la visibilidad global. La iniciativa parte de una realidad que muchos ya conocían: gran parte de la colaboración ocurría en instancias de Slack separadas, lo que dificultaba el descubrimiento mutuo entre comunidades y la conexión con los equipos de Make WordPress. Además, muchos de esos workspaces locales funcionaban con el plan gratuito de Slack, con historial de mensajes limitado y menos herramientas disponibles. El objetivo no es sustituir el trabajo que las comunidades locales ya hacen, sino crear mejores puentes. En la práctica, esto significa que comunidades de meetups, WordCamps regionales y eventos de referencia como WordCamp Europe, WordCamp US y WordCamp Asia tendrán espacio propio dentro del Slack global. Algunos de estos movimientos ya están en marcha: WordCamp Asia y WordCamp US están ya activos dentro de Make Slack, la comunidad japonesa está en proceso de transición, y WordCamp Europe planea unirse para la edición de 2027. Y, para acabar, este pódcast se distribuye con licencia Creative Commons [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.