[Magazine] Cómo ha ido la WordCamp Europe 2026

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

[Noticias] WordPress ha cumplido 23 años

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