WordPress Pódcast (español)

[Magazine] Historia de WordPress II: La madurez y el CMS (2008–2012)

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 [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 * General, automated WordPress-to-WordPress sync is unsolvable [https://adamadam.blog/2026/06/10/general-automated-wordpress-to-wordpress-sync-is-unsolvable/] * Retrospective: spending 500 billion Codex tokens [https://adamadam.blog/2026/06/10/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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 2.5 “Brecker” — anuncio oficial [https://wordpress.org/news/2008/03/wordpress-25-brecker/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 2.7 “Coltrane” — anuncio oficial [https://wordpress.org/news/2008/12/coltrane/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Usability Testing Report: 2.5 and CrazyHorse [https://wordpress.org/development/2008/10/usability-testing-report-25-and-crazyhorse/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] The Visual Design of 2.7 [https://wordpress.org/development/2008/10/the-visual-design-of-27/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 2.8 — anuncio oficial [https://wordpress.org/news/2009/06/wordpress-28/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 2.9 — anuncio oficial [https://wordpress.org/news/2009/12/wordpress-2-9/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] BuddyPress — Historia oficial [https://buddypress.org/about/story/] 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] BuddyPress — WordPress.org [https://wordpress.org/plugins/buddypress/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 3.0 “Thelonious” — anuncio oficial [https://wordpress.org/news/2010/06/thelonious/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Custom Post Types — documentación [https://codex.wordpress.org/Custom_Post_Types] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Custom Taxonomies — documentación [https://codex.wordpress.org/Custom_Taxonomies] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Twenty Ten Theme — WordPress.org [https://wordpress.org/themes/twentyten/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Pearson versus Mullenweg, a history — Post Status [https://poststatus.com/pearson-versus-mullenweg-a-history/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Thesis vs. WordPress: The Licensing Dispute — Domain Stories [https://stories.domaindetails.io/thesis_com/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress License — WordPress.org [https://wordpress.org/about/license/] 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”. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] StudioPress y Genesis Framework [https://www.studiopress.com/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] ThemeForest — WordPress themes [https://themeforest.net/category/wordpress] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 3.1 — anuncio oficial [https://wordpress.org/news/2011/02/threeone/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 3.2 — anuncio oficial [https://wordpress.org/news/2011/07/gershwin/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 3.3 — anuncio oficial [https://wordpress.org/news/2011/12/sonny/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 3.4 — anuncio oficial [https://wordpress.org/news/2012/06/green/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress 3.5 “Elvin” — anuncio oficial [https://wordpress.org/news/2012/12/elvin/] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress Market Share Statistics — Kinsta [https://kinsta.com/wordpress-market-share/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress Statistics — WPZOOM [https://www.wpzoom.com/blog/wordpress-statistics/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordPress Market Share — W3Techs [https://w3techs.com/technologies/details/cm-wordpress] 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. > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] WordCamp Europe — primera edición (2012) [https://europe.wordcamp.org/2012/] > 🔗 [https://s.w.org/images/core/emoji/17.0.2/72x72/1f517.png] Make WordPress [https://make.wordpress.org/] 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.

[Noticias] El equipo de WordPress 7.1 y todo lo que viene

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 [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 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 [https://make.wordpress.org/core/2026/06/17/announcing-the-wordpress-7-1-release-squad/]. 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 [https://make.wordpress.org/core/2026/06/19/roadmap-to-7-1/], 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 [https://make.wordpress.org/ai/2026/06/19/whats-coming-to-the-ai-client-in-wp-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 [https://make.wordpress.org/core/2026/06/17/whats-new-in-gutenberg-23-3-03-jun-2/] 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 [https://developer.wordpress.org/news/2026/06/dynamically-loading-template-parts-in-block-themes/], 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 [https://make.wordpress.org/plugins/2026/06/13/update-on-the-status-of-the-team-june-2026/]. 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 [https://make.wordpress.org/community/2026/06/18/how-effective-are-our-advertising-efforts-for-wordcamps/]. 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 [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] Trae tu comunidad local al chat mundial

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 [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 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 [https://make.wordpress.org/core/2026/06/10/call-for-testing-unicode-email-addresses/]. 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 [https://make.wordpress.org/playground/2026/06/08/wp-now-is-deprecated-migrate-to-playground-cli/]. 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 [https://make.wordpress.org/marketing/2026/06/13/find-the-best-of-wordpress/]. 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 [https://make.wordpress.org/meta/2026/06/10/plugin-directory-screenshots-gallery-update/], 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 [https://make.wordpress.org/community/2026/06/09/how-to-bring-your-community-to-make-wordpress-slack/]. 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 [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 ha ido la WordCamp Europe 2026

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 [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] WordCamp Europe 2026

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 [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 1 al 7 de junio de 2026. La WordCamp Europe 2026 se celebró del 4 al 6 de junio en Cracovia, Polonia [https://wordpress.org/news/2026/06/wceu-2026-recap/], 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 [https://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» [https://wordpress.org/news/2026/06/pts/], 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 [https://make.wordpress.org/core/2026/06/03/whats-new-in-gutenberg-23-3-03-jun/] 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 [https://make.wordpress.org/core/2026/06/05/react-19-upgrade-temporarily-reverted-in-gutenberg/]: 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 [https://make.wordpress.org/core/2026/06/04/call-for-testing-client-side-media-processing/] 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 [https://make.wordpress.org/core/2026/06/03/announcing-a-collaborative-editing-outreach-effort-for-7-1/] 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 [https://make.wordpress.org/hosting/2026/06/03/help-core-help-test-real-time-collaboration/], 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 [https://make.wordpress.org/playground/2026/06/02/pr-preview-with-wordpress-playground-what-changes-in-version-3-of-the-github-action/] 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 [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.