[Noticias] GatherPress será una realidad

[Noticias] Actualización urgente para 6.8, 6.9 y 7.0

Una versión de seguridad se ha lanzado para las versiones 6.8, 6.9, 7.0 y 7.1-beta que corrige 2 problemas de seguridad graves del núcleo de WordPress. Recuerda que puedes escuchar este programa desde: [https://www.wppodcast.org/wp-content/uploads/sites/3/2020/07/apple.png]https://www.wppodcast.es/apple/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2020/07/spotify.png]https://www.wppodcast.es/spotify/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2023/10/pocketcasts.png]https://www.wppodcast.es/pocketcasts/ [https://www.wppodcast.org/wp-content/uploads/sites/3/2026/07/feed.png]https://www.wppodcast.es/feed/podcast/ TRANSCRIPCIÓN DEL PROGRAMA Hola, soy Javier Casares [https://www.javiercasares.com/] y estás escuchando WPpodcast [https://www.wppodcast.es/], en el resumen de noticias de la Comunidad WordPress. En este episodio encontrarás la información del 13 al 19 julio de 2026. La noticia importante de esta semana es de seguridad, y va en serio. WordPress ha publicado la versión 7.0.2 [https://wordpress.org/news/2026/07/wordpress-7-0-2-release/], un lanzamiento de emergencia que corrige dos vulnerabilidades: una crítica y otra de severidad alta. La crítica, conocida ya en la comunidad como «wp2shell» y catalogada como CVE-2026-63030 [https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q], permite a un atacante no autenticado ejecutar código a través del endpoint batch de la API REST, sin necesidad de cuenta ni interacción del usuario, contra una instalación estándar sin plugins. Se combina, además, con un fallo de inyección SQL identificado como CVE-2026-60137 [https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf], formando una cadena de explotación completa. Dado lo grave del asunto, el equipo de WordPress.org ha activado las actualizaciones forzadas a través del sistema de auto-actualización para los sitios con versiones afectadas, así que muchos sitios ya se habrán actualizado solos. Aun así, conviene comprobarlo a mano: entra en el escritorio, en «Actualizaciones», y fuerza el «Actualizar ahora» si hace falta. Las versiones afectadas también han recibido parches retroactivos: la 6.9 pasa a 6.9.5, corrigiendo ambos fallos, y la 6.8 pasa a 6.8.6, corrigiendo solo el de inyección SQL. La beta de la 7.1 también se ha actualizado, a la beta 2, con ambas correcciones. Las versiones anteriores a la 6.8 no están afectadas. Por ahora no hay exploits públicos confirmados ni constancia de explotación activa, pero varios investigadores avisan de que, al ser WordPress un proyecto de código abierto, es cuestión de tiempo que aparezca una prueba de concepto pública. Ya tenemos beta 1 de WordPress 7.1 [https://wordpress.org/news/2026/07/wordpress-7-1-beta-1/] sobre la mesa, con lanzamiento final previsto para el 19 de agosto. Es una versión cargada, que por fin trae al núcleo un buen puñado de funciones que llevaban tiempo cocinándose en el plugin de Gutenberg. Las Notas se convierten en una herramienta de colaboración mucho más seria: admiten formato de texto en línea, menciones con arroba, varios hilos independientes sobre un mismo bloque y notas ancladas a una selección de texto concreta en lugar de a todo el bloque. En el terreno del diseño, llegan los estilos adaptativos de verdad dentro del editor, como definir cómo se ve un bloque en tableta o móvil sin tocar una línea de CSS, breakpoints personalizables desde el theme.json, y estilado de estados interactivos como hover o focus, tanto a nivel global como por instancia individual de bloque. La experiencia de medios también da un salto: el procesamiento de imágenes se mueve al navegador, con soporte ampliado para HEIC, AVIF, UltraHDR y conversión de GIF a vídeo, subidas más resilientes con reintentos automáticos, y un nuevo modal de edición de imagen que junta recorte, rotación y metadatos en un solo sitio. Las galerías se vuelven más inteligentes, tirando automáticamente de las imágenes ya adjuntas al post. Y en cuanto a bloques nuevos, llegan el bloque Playlist, con reproductor de audio y visualización de forma de onda, y el bloque Tabs para organizar contenido en pestañas, ambos sin necesidad de plugins de terceros. El otro gran cambio de esta versión es de navegación: la barra de herramientas de administración pasa a acompañarte siempre [https://make.wordpress.org/core/2026/07/13/consistent-navigation-in-wordpress-7-1-with-persistent-toolbar/], tanto en el editor de entradas como en el Editor del Sitio, algo que antes desaparecía en este último. El icono del logo de WordPress, que hasta ahora hacía las veces de botón de retroceso de forma confusa, se sustituye por un botón dedicado con forma de flecha; el logo abre siempre la página About, y el icono del sitio, cuando existe, abre el menú del sitio. Si desarrolláis plugins que añaden nodos a esta barra, conviene revisar que sigan funcionando bien en el Editor del Sitio, ya que antes ese modo persistente no existía ahí. Para quienes desarrollan bloques, esta es la versión a la que prestar más atención. A partir de 7.1, el canvas del editor de entradas se renderiza siempre dentro de un iframe, en cualquier tema y sin importar el apiVersion que se declare en los bloques. Hasta ahora bastaba con tener activo un solo bloque en apiVersion 2 o inferior en el post para que todo el editor se sacara del iframe; ese comportamiento desaparece por completo en 7.1. La ventaja es real: los estilos del administrador dejan de filtrarse al contenido, y unidades como vw o vh y las media queries por fin se resuelven contra el propio canvas, no contra la página de administración, así que las vistas previas de tableta y móvil se comportan de verdad como el frontend. Como en cada ciclo, el equipo de Test pide ayuda activa: no hace falta ser QA profesional, basta con usar WordPress como cualquier día [https://make.wordpress.org/test/2026/07/15/help-test-wordpress-7-1/] en un entorno de pruebas y reportar lo que no cuadre. Hay guías paso a paso para probar cada función nueva: Notas, estilado adaptativo, estados interactivos, la barra persistente, el modal de medios o las galerías dinámicas. El Blog de Desarrolladores ha publicado un tutorial para montar una página de mantenimiento [https://developer.wordpress.org/news/2026/07/on-brand-maintenance-mode-for-wordpress-block-themes/] con la marca de cada sitio, en lugar del típico mensaje plano de «brevemente no disponible» que muestra WordPress durante las actualizaciones. La gracia de la técnica es que reparte el trabajo de forma muy interesante: el desarrollador añade un único hook al plugin personalizado de funciones, una sola vez, y a partir de ahí toda la gestión de la página de mantenimiento, tanto diseño como activación, se hace desde el Editor del Sitio, sin tocar código ni archivos. El hook busca una plantilla llamada exactamente «Maintenance» en la base de datos, y si la encuentra, la sirve a cualquier visitante que no tenga sesión iniciada; quien esté logueado sigue viendo el sitio con normalidad, lo cual es útil para revisar los cambios durante la propia actualización. Hay una variante algo más elaborada que añade cabeceras pensadas para los buscadores: un código 503 de «servicio no disponible», un Retry-After sugiriendo que vuelvan a pasar en una hora, y cabeceras de no-cache para que el sitio se sirva sin problemas de caché en cuanto se desactive el modo mantenimiento. Recomendable sobre todo si el sitio tiene tráfico de búsqueda importante o si las ventanas de mantenimiento se alargan. Con el hook puesto, crear la plantilla es tan sencillo como ir a Apariencia → Editor → Plantillas, añadir una nueva llamada «Maintenance», y montarla igual que cualquier otra plantilla. El equipo de Playground ha lanzado una llamada para probar la nueva interfaz de WordPress Playground antes de su lanzamiento oficial, y buscan feedback tanto en escritorio como en móvil. No hace falta probarlo todo: proponen cuatro bloques de pruebas independientes, desde crear y gestionar playgrounds, pasar por la galería de blueprints, hasta trastear con archivos, base de datos y logs, o probar la importación y exportación de sitios, incluida la exportación a GitHub. Lo interesante es que han dejado un entorno de pruebas público [https://make.wordpress.org/playground/2026/07/17/help-us-test-the-new-wordpress-playground-ui/] y accesible sin necesidad de instalar nada, y piden fijarse en cosas muy concretas: si los textos y botones se entienden, si el comportamiento es el esperado, si hay problemas de maquetación y qué mejorarían. El equipo de Comunidad ha presentado los Community Agents, una plataforma de asistentes de inteligencia artificial pensada para aligerar tareas repetitivas [https://make.wordpress.org/community/2026/07/14/meet-the-community-agents-ai-assistants-for-wordpress-community-workflows/]: revisar solicitudes de organizadores de eventos, comprobar presupuestos de WordCamps y auditar sitios en busca de problemas de licencia GPL o de marca registrada. El proyecto se apoya en dos principios: humano en el bucle, es decir, que el agente propone pero nunca aprueba nada de forma automática, y respeto a la privacidad, ya que solo trabaja con información pública como perfiles de WordPress.org o enlaces, sin pedir datos personales como correos o direcciones. Se ha presentado un nuevo addon para CampTix, el sistema que gestiona los eventos de la comunidad, pensado para resolver un problema clásico de las WordCamp: cómo gestionar las plazas de actividades limitadas como el Contributor Day, la cena social o los talleres, que hasta ahora se controlaban con formularios paralelos, hojas de cálculo cruzadas a mano o directamente al buen criterio de los asistentes. El addon, bautizado de momento como «activity tickets», permite a los organizadores crear estas actividades como entradas normales de CampTix a precio cero [https://make.wordpress.org/community/2026/07/17/activity-tickets-self-service-registration-for-contributor-day-and-other-side-events-feedback-wanted/], y marcarlas como tickets de actividad desde el propio panel de configuración. El addon está terminado y probado en local, con más de cincuenta tests automatizados y una prueba completa contra un sitio real de WordCamp, pero todavía no se ha enviado de forma oficial. Antes de eso, el equipo pide feedback a la comunidad, sobre todo de quien haya organizado alguna vez un Contributor Day u otro evento de aforo limitado. Y, para acabar, este pódcast se distribuye con licencia Creative Commons [https://creativecommons.org/licenses/by-nc-sa/4.0/]; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es [https://www.wppodcast.es/]. Un abrazo, y hasta el próximo programa.

[Noticias] GatherPress será una realidad

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

[Noticias] Calendario de lanzamiento de WordPress 7.1

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

[Noticias] Despídete del Editor Clásico

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