Siempre queda la duda de si WordPress incluye todos los bloques que debería por defecto o no, algo que tiene sus pros y sus contras.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 4 al 10 de agosto de 2025.

En el repositorio de Gutenberg se están planteando recuperar y dar salida a una serie de bloques que llevan tiempo en lista de espera, como acordeones, pestañas, deslizadores, menús más completos o incluso elementos matemáticos. La idea es integrarlos directamente en el núcleo de WordPress para que no haya que depender siempre de plugins externos o librerías de terceros, y así facilitar que cualquier tema pueda aprovecharlos sin problemas. También se ha puesto sobre la mesa mejorar la gestión de la biblioteca de bloques desde el propio panel de administración, para poder controlar cuáles están disponibles de una forma más clara y centralizada.

Entre los puntos a favor está que añadir estos bloques podría dar más expresividad al editor y permitir que los temas sean más interoperables, con patrones más consistentes y menos dependencias externas; pero también hay puntos en contra, como el riesgo de cargar el núcleo con demasiados elementos, aumentar la complejidad del mantenimiento y la duda de si todos esos bloques realmente merecen estar incluidos por defecto.

Se han publicado versiones de mantenimiento para todas las ramas de WordPress desde la 4.7 hasta la 6.7. Estas actualizaciones incluyen una versión del certificado raíz de seguridad que mejora la verificación de certificados en las peticiones HTTP del servidor, una mejora que ya venía en la versión 6.8.2 y que ahora se ha llevado a las versiones anteriores como cortesía para quienes aún las utilizan. Si tienes activadas las actualizaciones automáticas en segundo plano, el proceso de actualización se activará solo, sin que tengas que intervenir.

Aun así, la única versión oficialmente soportada y mantenida sigue siendo la 6.8.2, mientras que estas actualizaciones a las ramas anteriores sirven simplemente para mantener cierto nivel básico de seguridad.

El equipo de AI debatió la estrategia tras lanzar el plugin experimental de integración de IA. El objetivo principal es demostrar el valor real de funciones impulsadas por IA en WordPress, hacer que su uso sea accesible para desarrolladores sin conocimientos profundos en IA y, al mismo tiempo, permitir que otros, con experiencia más avanzada, puedan añadir sus propios proveedores o modelos.

Desde el punto de vista técnico, la atención se centró en cómo integrar esas funciones dentro del editor de bloques de WordPress, imponiendo una API y experiencia de usuario uniformes, mientras se mantiene una variante para el editor clásico basada en REST API, útil como demostración.

Algunas ideas sobre la mesa son:

El equipo de Playground ha anunciado varias mejoras: ahora el OPCache viene activado por defecto para acelerar el rendimiento; se ha avanzado mucho en el soporte de Xdebug, incluyendo la opción experimental de herramientas de desarrollo en CLI y un paquete puente simulado.

La versión 2 de los Blueprints ya está en desarrollo, con mejor gestión de rutas relativas y mensajes de error. Se han incorporado nuevas opciones a la CLI y se ha optimizado el reporte de errores. Además, PHP 8.3 se convierte en la versión predeterminada.

El equipo de Accesibilidad hace su llamada a nuevos representantes de equipo y ha anunciado los avances del proyecto WP A11y Docs tras el inicio, en junio, de la revisión y expansión de la documentación de accesibilidad en WordPress.

Se ha creado una web independiente llamada WP Accessibility Knowledge Base, construida con Jekyll y GitHub Pages, que servirá como plataforma central para introducir y clasificar contenidos. Actualmente solo muestra texto provisional, pero a partir del 11 de agosto empezará a recibir contenido real.

En una segunda fase, se trasladará la información más relevante al sitio de desarrolladores, bajo una nueva sección Accessibility Handbook, gestionada mediante un repositorio en GitHub.

El equipo de Comunidad sigue avanzando en el programa WordPress Campus Connect, que continúa expandiéndose globalmente. Ya se han celebrado tres eventos este año, en Ribera del Duero (España), Cartago (Costa Rica) y Cagayán de Oro (Filipinas), fomentando la innovación digital, la creación de webs y premiando a estudiantes con diplomas y oportunidades como acudir a la WordCamp US 2025. Además, ya hay en marcha dos nuevos eventos planificados en Ajmer y San José, y seis más en preparación.

Se han lanzado nuevas herramientas de apoyo, como una página en el handbook para facilitar la emisión de certificados de participación y la creación del primer club estudiantil WordPress. También se ha estrenado una sección en el WordPress Credits Handbook, diseñada para promover la implicación de empresas e instituciones educativas en iniciativas comunitarias.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

Ahora que se sabe que a finales de 2025 llega WordPress 6.9, se ha planteado una hoja de ruta con las ideas base para trabajar en esta versión.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 28 de julio al 3 de agosto de 2025.

WordPress 6.9 se lanzará el 2 de diciembre de 2025, tras reevaluar el plan de lanzamientos para incluir una versión adicional este año. El lanzamiento se enfocará en evolucionar el Editor del Sitio, con modos de edición simplificada, gestión de plantillas más intuitiva, colaboración a nivel de bloque y mejoras de rendimiento gracias a nuevas APIs.

El Editor del Sitio recibirá un modo simplificado que separará la edición de contenido de las herramientas de diseño, además de una gestión de plantillas renovada con múltiples plantillas por slug y borradores previos a la activación. También se añadirá la capacidad de ocultar bloques en el frontend, facilitando flujos de trabajo no destructivos que favorezcan la experimentación.

La experiencia de autoría mejorará con un arrastrar y soltar de bloques más directo, transformaciones ampliadas, mejoras en la navegación mediante teclado, y comentarios a nivel de bloque que facilitarán la colaboración asincrónica. Además, la paleta de comandos se extenderá a toda la experiencia de WordPress, sirviendo como base para futuras integraciones con IA.

Para desarrolladores se actualizarán los paquetes DataViews y DataForm, que incluirán nuevos tipos de campos y operadores; se introducirá la Abilities API, y se mejorarán la Interactivity API, las Block Bindings y la HTML API. En rendimiento, se implementará navegación instantánea con bfcache, gestión del atributo fetchpriority, un buffer de salida unificado y optimización de estilos. Además, junto al lanzamiento llegarán vistas previas de funcionalidades como el nuevo administrador modular, el adaptador MCP y el SDK PHP AI Client, en forma de plugins experimentales.

Gutenberg 21.3 ya está disponible con mejoras en DataViews, nuevos componentes y una interfaz más cómoda en la barra lateral del inspector.

La cuadrícula de DataViews ahora permite agrupar elementos por campos y añade un tipo de campo date sin hora, como paso previo a incorporar un componente de calendario que facilite el filtrado por fechas.

El bloque Cover admite ahora una imagen de póster que se muestra antes de cargar vídeos, mientras que el bloque Post Content añade el selector tagName para cambiar el envoltorio a etiquetas semánticas como main o article.

La migración a TypeScript continúa avanzando, con múltiples paquetes ya convertidos, lo que aporta mayor seguridad y robustez al código.

El equipo de Test ha abordado las ineficiencias del proceso de gestión de tickets, donde aproximadamente el 80 % se cierra sin solución tras múltiples reproducciones y parches infructuosos, y ha propuesto fomentar la especialización en componentes para fortalecer la confianza durante el triaje y la revisión temprana de informes. Para apoyar esta especialización, plantean un nuevo flujo de trabajo basado en un tablero “mini-tracker” en GitHub, que canaliza cada ticket desde su clasificación inicial por un especialista hasta su estado final de “listo para commitear”. Este flujo pasa por etapas definidas de etiquetado (needs-reproduction o needs-testing), reproducción del error, desarrollo de parches, revisión experta y pruebas finales, reduciendo así la carga de trabajo de los committers principales.

Durante la sesión también se revisaron ejemplos de componentes prioritarios y se enfatizó un cambio de enfoque, desde la simple realización de pruebas hacia el aseguramiento de calidad, alineando el nuevo rol de “revisor” con el de mantenedor de componentes, facilitando así el camino hacia la mantenibilidad oficial. Aunque surgieron inquietudes sobre posible duplicación de trabajo y complejidad para nuevos colaboradores, se subrayó el carácter piloto e iterativo del protocolo y se instó a los asistentes a elegir un componente, participar en Slack, considerar la futura mantenibilidad, asistir a próximas sesiones prácticas y revisar la documentación del mini-tracker.

El equipo de Plugins ha anunciado que, a partir de ahora, el archivo readme.txt de los plugins deberá escribirse en inglés para agilizar su análisis y mejorar la comunicación con los autores, dado el creciente volumen de solicitudes y la diversidad lingüística del equipo.

Además, el inglés servirá como lengua base para traducciones posteriores, unificando así la interfaz del directorio al evitar secciones en diferentes idiomas y alfabetos. Esta decisión ha sido acordada por todo el equipo con el objetivo de mejorar la eficiencia del proceso y aumentar la accesibilidad global de los plugins.

Durante la WordCamp Cracovia 2024, solo un 10 % de los asistentes se unió al Contributor Day, ya que muchos consideraban que estaba reservado a usuarios avanzados. Para cambiar esta percepción, se organizó la primera edición de la WordPress Academy, un conjunto de cuatro charlas gratuitas dirigidas a principiantes absolutos, sin registro previo, a las que acudieron más de 50 personas (el 20 % de los participantes) y que recibieron un feedback entusiasta tanto de novatos como de veteranos.

Basándose en aquella experiencia, en 2025 el formato se potenció incluyendo, además de conferencias aún más accesibles, talleres prácticos para “falsos principiantes” en los que se guiaba la creación de un sitio WordPress. El resultado fue un rotundo éxito: de los 275 asistentes, más de 110 participaron en la Academy, y sumados a los 30 del Contributor Day, lograron superar el 50 % de participación en el Día 0. El equipo planea ahora llevar este modelo a la WordCamp Europe 2026 en Cracovia, con la intención de repetir y ampliar su impacto.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

El equipo de Documentación propone la creación de documentación con ayuda de inteligencia artificial, pero siempre con un factor humano intermedio que ayude en su supervisión.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 21 al 27 de julio de 2025.

Crear documentación puede ser un proceso bastante pesado, especialmente desde que existen herramientas de inteligencia artificial que, con solo unas pocas ideas, te ayudan a crear todo un texto.

Por este motivo, desde el equipo de documentación de WordPress se plantea un flujo de trabajo para integrar la inteligencia artificial en la elaboración de nueva documentación de usuario para la versión 6.9, manteniendo siempre el control y la supervisión humana. Se trata de un piloto centrado únicamente en la creación de artículos nuevos, en el que la IA genera borradores iniciales siguiendo las guías de estilo oficiales, pero sin sustituir nunca la pericia de los colaboradores, quienes conservan la responsabilidad final de revisión, edición y publicación del contenido. En fases posteriores se prevé ampliar este proceso a la actualización de la documentación existente y a la automatización de capturas de pantalla mediante herramientas como el WordPress Playground.

El flujo de trabajo propuesto consta de varias etapas encadenadas: primero, definir de forma clara el alcance, la audiencia y el tipo de artículo; a continuación, solicitar a la IA un borrador estructurado que incluya referencias internas a notas de desarrollo, Trac y GitHub; luego, someter ese borrador a una comprobación de hechos y a una edición humana para garantizar la exactitud técnica y la corrección lingüística; después, realizar un control de estilo, accesibilidad e inclusión; una vez satisfechos estos criterios, publicar con total transparencia sobre el uso de IA, registrando en el historial de cambios el detalle del proceso y de los colaboradores implicados; finalmente, reflexionar sobre los aciertos y errores para documentar mejoras y preparar iteraciones futuras.

Para preservar la integridad de la documentación se establecen salvaguardias que incluyen no publicar nunca contenidos generados por IA sin revisión humana, basar los prompts en fuentes verificables para evitar alucinaciones, y no entrenar modelos con datos privados de WordPress.org, adoptando siempre un enfoque de humano en el bucle. Además, se subraya el componente ético: la IA existe para reducir la fricción en la redacción, no para reemplazar a los colaboradores. Antes del lanzamiento de la versión 6.9, el equipo colaborará en el diseño y prueba de prompts, compartiendo hallazgos en reuniones y GitHub para crear bibliotecas de ejemplos reutilizables y sentar las bases de futuras automatizaciones en ciclos posteriores.

Y en lo que respecta a las pruebas de software de WordPress, en el primer informe de análisis de calidad de WordPress se detalla cómo el equipo de pruebas, que supera ya los 50 miembros, pasó de realizar tests básicos a adoptar un enfoque integral de aseguramiento de calidad tras analizar manualmente los 217 commits incluidos entre el lanzamiento de la versión 6.8.0 y la 6.8.2. Se introdujo un sistema de puntuación, con hasta 5 puntos por commit según la presencia de tests automatizados, revisiones de código y pruebas manuales, que arrojó una nota media de 2,47 y reveló la escasa cobertura de pruebas, ya que solo 29 de 52 commits de mejora incluían tests. Además, se observó un enorme desajuste entre los 366 informes de prueba generados por 58 colaboradores y la incorporación efectiva de esos resultados en el núcleo, reflejada en apenas un 8 % de commits relacionados.

A partir de estas conclusiones y de dos sesiones de feedback, surgió la propuesta de crear el Grupo de Colaboradores de Pruebas de WordPress, un espacio abierto sin requisito de antigüedad donde la prioridad es el networking y el intercambio de conocimiento para revertir la brecha detectada entre testers y committers. La visión es asegurar un nivel de calidad tal que cualquier desarrollador pueda integrar código con total confianza, y la misión consiste en orientar a quienes deseen especializarse, fomentando un talento focalizado y un aprendizaje colaborativo continuo.

Para ello, se plantea organizar a sus miembros por áreas o componentes concretos, como por ejemplo Media o herramientas de build, con una estructura plana y apoyo de mentores que procuren que cada uno se convierta en referente en su ámbito. El proceso de incorporación pasa por elegir un componente, asistir a las sesiones de onboarding o contactar directamente con miembros activos, y participar en un ciclo de retroalimentación que permita medir avances; se espera que, tras cinco o seis meses de trabajo especializado, el grupo alcance la excelencia propuesta.

El equipo de Hosting propone actualizar la descripción del equipo, argumentando que las versiones actuales son demasiado breves y no reflejan con claridad su labor en colaboración con la industria, pruebas distribuidas y educación de usuarios.

Para ello, presenta tres borradores con distinto nivel de detalle que sitúan al equipo como intermediario entre los proveedores de alojamiento y los desarrolladores de WordPress, enfatizando su papel en la identificación de errores, la documentación técnica y el fomento del diálogo en reuniones semanales.

El equipo de Photos ha lanzado el Summer Photo Contest, en el que se invita a enviar fotografías que hagas durante el mes de agosto con mucho sabor a verano, y subirlas al directorio de fotografías de WordPress con el hashtag #SummerPhotoContest. Un grupo de fotógrafos y moderadores del equipo seleccionará sus fotos favoritas, y las personas ganadoras recibirán premios especiales que se anunciarán en breve, además de un lugar destacado en el Directorio de Fotos.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

La Inteligencia Artificial ha llegado ya a WordPress de una manera modular a través de varios plugins que crean la base para la construcción de cualquier elemento que se quiera integrar.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 14 al 20 de julio de 2025.

Hace no muchas semanas se lanzaba el equipo de Inteligencia Artificial de WordPress, y los primeros resultados ya están aquí: varios plugins de experimentación con distintas funciones y habilidades que pueden ayudar a facilitar el desarrollo de plugins o de necesidades a la hora de relacionarse con otras herramientas de inteligencia artificial.

Para garantizar flexibilidad y evitar bloqueos con proveedores o estándares prematuros, estos proyectos se distribuyen como plugins canónicos y paquetes de Composer independientes del núcleo, permitiendo a los desarrolladores incorporarlos en producción antes de su fusión eventual en el núcleo de WordPress. Esta estrategia se alinea con la Fase 3 de Gutenberg: Colaboración de la hoja de ruta, que anticipa la integración de agentes de IA en la nueva interfaz Site Admin, colaboración en tiempo real y asincrónica en el editor, y funcionalidades de IA en la biblioteca multimedia; con la meta de que antes de la versión 7.0 cualquier usuario pueda acceder, usar y construir funciones avanzadas de IA que pasarán finalmente al núcleo.

El plugin AI Experiments agrupa los componentes de la iniciativa AI Building Blocks de WordPress en una aplicación tangible que demuestra cómo estas piezas funcionan en conjunto para ofrecer funciones de IA directamente en el editor y el panel de administración. Mediante esta herramienta, cualquier usuario puede conectar su proveedor de IA preferido, alternar entre modelos sin complicaciones y experimentar con la generación de contenido y la automatización de tareas, creando un entorno real donde probar las posibilidades actuales de la inteligencia artificial.

Lejos de quedarse en una mera demostración, el AI Experiments Plugin establece una hoja de ruta hacia el futuro de WordPress, explorando casos de uso más avanzados como asistentes de conversación para la gestión del sitio, colaboración en tiempo real en Gutenberg, comentarios asincrónicos con sugerencias de IA y organización inteligente de la biblioteca multimedia, anticipando su eventual integración en el núcleo de la plataforma.

El SDK PHP AI Client es la pieza central de la iniciativa, cuyo objetivo es unificar y simplificar la integración de funciones de inteligencia artificial en proyectos PHP y plugins de WordPress. Gracias a su interfaz única e independiente del proveedor, los desarrolladores solo necesitan indicar las capacidades de IA que desean incorporar, mientras que los administradores gestionan las credenciales de API en un único punto, evitando bloqueos con proveedores y la duplicación innecesaria de infraestructuras en cada extensión. Además, el SDK maneja internamente los distintos protocolos de streaming, formatos de API y particularidades de cada servicio, lo que permite desde tareas sencillas de generación de texto hasta operaciones multimodales complejas sin que el usuario final perciba la complejidad subyacente.

El Abilities API es otra pieza fundamental dentro de la iniciativa que nace para dotar al ecosistema de un lenguaje común capaz de describir, registrar y exponer de forma coherente todas las funcionalidades que ofrecen los distintos plugins y temas. Mediante un registro centralizado, cada componente puede declarar sus capacidades con esquemas de entrada y salida bien definidos, mensajes de estado y permisos asociados, de modo que tanto desarrolladores como sistemas de IA puedan descubrir y orquestar estas funciones sin depender de implementaciones dispersas y heterogéneas. Con ello se supera el problema de la fragmentación, en el que, por ejemplo, un asistente no sabe si un plugin de copias de seguridad puede crear instantáneas o si una extensión SEO puede analizar contenido, y se abre la puerta a casos de uso avanzados, desde paletas de comandos o flujos de trabajo automatizados hasta la integración de capacidades en menús y barras de herramientas dentro del editor.

El MCP Adapter también forma parte de la iniciativa y está fundamentado en el protocolo abierto Model Context Protocol (MCP), que estandariza la forma en que las aplicaciones suministran contexto a los modelos de lenguaje (LLMs).

En esta implementación, WordPress opera a la vez como servidor MCP, exponiendo sus capacidades registradas en la Abilities API para que asistentes de IA descubran y ejecuten acciones como creación de entradas, gestión de medios o moderación de comentarios, y como cliente MCP, conectándose a servidores externos mediante un agente integrado, la REST API o WP-CLI, lo que permite integrar servicios especializados de generación de contenido, análisis de datos o migración de sitios en flujos conversacionales.

En conjunto, estas iniciativas de AI Building Blocks ofrecen una infraestructura modular y completa para llevar la inteligencia artificial a WordPress.

Y en otra línea de novedades tenemos Gutenberg 21.2, que trae algunas novedades como que el bloque de navegación estrena un interruptor en la barra lateral de ajustes que permite configurar la apertura en una nueva pestaña junto al resto de opciones de enlace, haciéndolo más accesible sin necesidad de editar código ni recurrir a trucos externos.

Por su parte, se refuerzan los DataViews con nuevas definiciones de tipo de campo (media, booleano, e-mail y array), la posibilidad de asignar ordenación y funciones de renderizado por defecto, y la exportación independiente de sus subcomponentes para crear composiciones a medida; además, incorpora dos componentes de calendario, DateCalendar y DateRangeCalendar, que facilitan la selección de fechas.

Por último, continúa la modernización de los paneles de ajustes: el bloque Galería recibe su rediseño en la interfaz de herramientas y el bloque Logo del sitio completa la transición a la nueva UI, cerrando así esta fase de refactorización.

Finalmente, el equipo de Core ha traído de vuelta una discusión de hace 8 años sobre la inclusión completa de la biblioteca PHPMailer, que actualmente usa una versión parcial y que permitiría incluir de forma nativa funcionalidades en la gestión del correo, haciendo que plugins de SMTP no requieran incluir versiones potencialmente inseguras.

El equipo de Comunidad ha lanzado tres iniciativas estratégicas para consolidar su presencia en el ámbito educativo: Campus Connect, Student Clubs y WordPress Credits.

Campus Connect propone talleres intensivos y eventos prácticos donde los alumnos aprenden a montar sitios web, mejorar el SEO y explorar salidas profesionales dentro del ecosistema, todo ello con el respaldo de mentores y profesionales del sector.

Los Student Clubs actúan como comunidades autónomas en los campus que mantienen vivo el interés a través de reuniones periódicas y proyectos recurrentes, asegurando que la formación no se diluya tras la celebración de un evento puntual.

Finalmente, el programa WordPress Credits integra a estudiantes en proyectos reales de desarrollo de WordPress, otorgándoles un reconocimiento académico formal que elimina barreras de entrada y les permite adquirir experiencia práctica contribuyendo al núcleo y a la accesibilidad de la plataforma.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

Una propuesta plantea un despliegue escalonado de plugins, al estilo de iTunes o Play, donde los usuarios reciben actualizaciones poco a poco.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 7 al 13 de julio de 2025.

Una propuesta de Matt Mullenweg, cofundador de WordPress, busca introducir despliegues escalonados (phased rollouts) de actualizaciones de plugins en el directorio de wordpress.org, al estilo de Apple App Store y Google Play.

Esto permitiría que los autores liberen primero la actualización a un porcentaje limitado de sitios para recoger feedback y detectar errores antes del despliegue masivo, sin sustituir las pruebas beta tradicionales.

Desarrolladores y empresas como Hostinger, Automattic, WooCommerce, Elementor y Awesome Motive han apoyado la idea, sugiriendo opciones de fases inmediatas, equilibradas o progresivas —por ejemplo, 10, 25, 50 y 100%—, y pidiendo más analíticas y reportes de errores en un panel de control. Ya existe un parche de prueba de concepto y se valora incluirlo en WordPress 6.9.

El ticket #8009 en el Meta Trac describe la necesidad de una interfaz para gestionar versiones por porcentaje y plantea comenzar solo con autoactualizaciones. En los más de 30 comentarios, varios colaboradores discuten mecanismos de segmentación, umbrales de sitios, distintos estados en la API de actualizaciones y cómo diferenciar actualizaciones automáticas de manuales, además del reto de soportar clientes desde WordPress 2.8 hasta 6.8.

WordPress 6.8.2 ya tiene una versión candidata y está previsto que el martes 15 de julio esté disponible de forma general, incluyendo 20 correcciones del núcleo y 15 del editor.

Y, parece que sí, que WordPress 6.9 se lanzará antes de 2026. Concretamente, está previsto que la versión general salga el 2 de diciembre de 2025, comenzando su primera beta el 21 de octubre. Se están buscando colaboradores para liderar el lanzamiento tanto en la parte tecnológica, de diseño, triaje y pruebas.

Algunas de las ideas detrás de WordPress 6.9 son:

Con respecto al rediseño del panel de administración, hay un acuerdo inicial para probar la renovación usando el plugin Gutenberg, posiblemente como experimento opt-in. La conversación sobre el rediseño también ha puesto de manifiesto el interés en ampliar herramientas de colaboración, como comentarios a nivel de bloque y flujos de trabajo asíncronos, algunas de las cuales ya están en desarrollo en Gutenberg.

El equipo de Core ha propuesto incorporar PHPStan, una herramienta de análisis estático de código PHP ya usada en otros proyectos, al flujo de trabajo de desarrollo del núcleo de WordPress.

El plan contempla añadir PHPStan como dependencia de desarrollo con una configuración y línea base predefinida, ejecutar el análisis como comprobación obligatoria en los GitHub Actions y documentar su uso en el handbook. Las modificaciones se implementarían durante el ciclo de desarrollo de WordPress 6.9 mediante un pull request, permitiendo que el código existente mantenga sus incidencias actuales, mientras el nuevo código se ajusta a los estándares de PHPStan.

Adoptar PHPStan ayudará a detectar errores en código no cubierto por pruebas, prevenir fallos lógicos y de tipo, mejorar la experiencia de contribución con feedback automático y facilitar la adopción incremental de reglas sin forzar refactorizaciones masivas, todo ello alineado con la política de evitar cambios innecesarios. Aunque pueda suponer una curva de aprendizaje para algunos, la familiaridad creciente de la comunidad con PHPStan y su carácter complementario a PHPCS mitigan ese riesgo. Los siguientes pasos incluyen mantener la propuesta abierta unas semanas, avanzar en el pull request, coordinar con el equipo de Gutenberg y redactar la guía en el handbook; la implementación requerirá elevar la versión mínima de PHP a 7.4, decisión que se anunciará próximamente, antes del lanzamiento de la 6.9.

En esta línea, se ha propuesto eliminar la etiqueta de soporte beta para PHP 8.3 en WordPress 6.8, ajustando dos criterios: ya no exigir los tres meses de uso mínimo una vez superado el 10% de sitios activos y permitir que el cambio se aplique retroactivamente al lanzamiento actual sin esperar a la próxima versión mayor, dado que el núcleo lleva siendo compatible desde noviembre de 2023. Con esto, se clarifica que PHP 8.3 cuenta con soporte pleno, incentivando a usuarios y proveedores a actualizar, mientras que PHP 8.4 seguirá en beta por estar por debajo del 10% de uso y PHP 8.5 permanecerá en desarrollo hasta su salida en noviembre de 2025.

El equipo de Plugins ha anunciado que el antiguo Plugin Review Team pasa a llamarse oficialmente Plugins Team para reflejar mejor su alcance tras la transición de junio de 2023: seguir revisando nuevas propuestas —que han aumentado un 87% más en envíos semanales—, mejorar herramientas internas como el Scanner que hace más de 220 comprobaciones automáticas y chequeos de IA para nombres, y potenciar herramientas comunitarias como Plugin Check, además de colaborar con el equipo Meta para resolver tickets y proponer funciones que refuercen la fiabilidad y seguridad del directorio. El cambio de nombre, ya aprobado internamente, se aplicará en el título de la página, menciones en wordpress.org y comunicaciones, y se invita a la comunidad a usar Plugins Team de ahora en adelante.

La WordCamp US 2025 sigue su camino y la Fundación WordPress abre la convocatoria para la Beca Conmemorativa Kim Parsell, que sufraga el viaje a WordCamp US 2025 en Portland, que se realizará del 26 al 29 de agosto. Podrá solicitarla cualquier mujer que aporte al proyecto WordPress, no haya asistido antes a este evento y necesite apoyo económico. Se elegirá a una única beneficiaria, con plazo de inscripción hasta el 25 de julio de 2025 y notificación a las solicitantes el 7 de agosto de 2025.

La Fundación WordPress ha lanzado WordPress Credits, un programa de prácticas de contribución dirigido a estudiantes universitarios que combina una formación inicial en principios de código abierto y herramientas comunitarias como Slack, blogs de Make o GitHub, con un proyecto personalizado alineado a su carrera, como traducción, desarrollo, documentación, organización de eventos, entre otros. Tras un piloto con la Universidad de Pisa, presentado en WordCamp Europe 2025, el programa ofrece periodos flexibles de 3 a 4 meses semestrales o cumplimiento de horas específicas, con mentoría individual y un contacto de la WordPress Foundation para garantizar que las contribuciones de código, recursos educativos o traducciones sean públicas e integradas en proyectos oficiales.

Universidades e instituciones pueden inscribirse mediante un formulario, y las empresas de la comunidad están invitadas a patrocinar mentores o aportar recursos para apoyar a la próxima generación de colaboradores.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

Algunos componentes del núcleo de WordPress han quedado obsoletos en cuanto a funcionalidad, y se plantea un modo de mantenimiento simplemente para que sigan funcionando sin errores, pero sin evolucionar funcionalmente.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 30 de junio al 6 de julio de 2025.

La nueva versión de Gutenberg 21.1 incluye la extensibilidad del bloque Social, gracias a la cual los desarrolladores pueden registrar nuevas redes sociales como variaciones de bloques, incluyendo iconos personalizados.

Además, otros bloques están incorporando la nueva interfaz del Panel de herramientas, como el de Autor, Avatar, Enlace de navegación o Logo del sitio.

El equipo de Core ha propuesto introducir el concepto de modo de mantenimiento para componentes: un estado oficial para marcar aquellas partes de WordPress que, aunque sigan recibiendo actualizaciones de seguridad y triage de errores, dejan de aceptar nuevas peticiones de funcionalidades o mejoras, a menos que sean estrictamente necesarias para mantener la compatibilidad con versiones previas.

Como candidatos iniciales para pasar a modo de mantenimiento se mencionan:

El equipo de Playground lanza algunas novedades entre las que se destaca que se ha habilitado por defecto la conectividad en red, sin que ello implique una pérdida de rendimiento, y se ha mejorado la gestión de instancias PHP con el PHP Process Manager para soportar instancias no principales, además de habilitar llamadas de red simultáneas y asíncronas entre múltiples instancias de PHP en el mismo web worker.

Se ha incorporado el runner de Blueprints versión 2, allanando el camino para la próxima generación de Playground Blueprints, mientras la versión 1 sigue como predeterminada.

También se destaca la adopción del nuevo controlador SQLite y las pruebas de compatibilidad de plugins; el sistema puede llegar a permitir ejecutar pruebas de plugins como Plugin Check dentro de la CLI. Se ha discutido la estrategia para descontinuar versiones antiguas de PHP, como la 7.2.

El lanzamiento de bbPress 2.6.14 incluye 20 correcciones, entre las que encontramos mejoras de integración con BuddyPress o correcciones de compatibilidad con PHP 8.2, entre otras mejoras, que también se han aplicado ya en la futura rama de bbPress 2.7.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

Limpieza de canales de Slack, de repositorios de GitHub, de versiones de bases de datos, y las bases del desarrollo de IA son algunas de las propuestas de una semana en la que se ha querido poner orden en el proyecto WordPress.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 23 al 29 de junio de 2025.

Haciendo un poco de trabajo de limpieza general, en una revisión exhaustiva y siguiendo los criterios para repositorios bajo la organización de WordPress en GitHub, se han catalogado todos los repositorios y se evaluó su mantenimiento, alineación con iniciativas activas y propósito continuo. Como resultado, se archivaron 20 repositorios en la organización de WordPress y uno en bbPress, se cerraron 11 plugins del directorio oficial y se archivaron 30 canales de Slack inactivos, con el objetivo de reducir el ruido y centrar la atención en el desarrollo activo.

Todos los repositorios, plugins y canales archivados siguen accesibles públicamente, con motivos detallados en un documento de hojas de cálculo y una nueva página en el Handbook del Core Team. El proyecto destaca la importancia de auditorías periódicas para mantener los recursos alineados con las prioridades actuales, e invita a la comunidad a proponer mejoras o reversiones de archivos prematuros en los comentarios.

Y en esta línea de mantener todo al día, también se ha trabajado en las versiones de las bases de datos. La propuesta parte del dato de que más del 37 % de los sitios WordPress funcionan con versiones de MySQL o MariaDB que ya han llegado a su fin de vida útil y no reciben actualizaciones de seguridad. Para evitar confusiones sobre qué ediciones están realmente soportadas, se plantea dejar claro que solo las versiones LTS (con soporte garantizado a largo plazo) de MySQL y MariaDB son las oficialmente recomendadas, descartando de la documentación las “innovation” o “rolling GA”, que, por su corta vida, no aseguran compatibilidad ni seguridad a medio plazo.

En la práctica, esto implica mantener la recomendación actual —con MySQL superior a 8.0 o MariaDB superior a 10.6— y añadir en los manuales de Core y Hosting notas explícitas de que los lanzamientos de innovación y rolling GA no deben usarse en producción, quedando reservados solo para pruebas de compatibilidad en el flujo de PHPUnit. Además, se sugiere enriquecer herramientas como ServeHappy, los chequeos de Site Health y WP-CLI para alertar a los administradores cuando su base de datos no sea una LTS oficial.

El equipo de IA ha comenzado con la organización del proyecto, presentando el nuevo repositorio en GitHub, incluyendo el php-ai-client, un SDK de PHP agnóstico al proveedor pensado para conectarse con distintos modelos de IA, sobre la que se construirá una capa específica de WordPress. Además, se establecieron pautas para coordinar futuros repositorios de “building blocks”, como MCP y un registro unificado de herramientas, e involucrar contribuciones externas para integrar distintos proveedores.

Se acordó un enfoque modular y extensible, comenzando con los “tres grandes” (OpenAI, Anthropic y Google) y definiendo criterios claros y un proceso de aprobación para sumar nuevos. Se planificó lanzar las primeras funcionalidades con un Feature Plugin sin integrar de momento en el núcleo, dejando la especificación del REST API en el SDK y valorando la paridad con GraphQL.

El equipo de Hosting ha propuesto un RFC para un servicio que automatice por completo la preparación y ejecución del conjunto de pruebas de entorno de alojamiento: el usuario solo facilita sus credenciales SFTP/SSH, de base de datos y de WordPress.org, de forma que el sistema devuelve una clave pública para instalar en el servidor, conecta automáticamente, despliega y ejecuta los tests y envía los resultados a make.wordpress.org, eliminando la necesidad de configurar manualmente el entorno y reduciendo la barrera de entrada. Para garantizar seguridad y uniformidad, se usarán pares de claves únicos por sesión, conexiones limitadas a rangos IP concretos y se planifica crear un prototipo, iterar tras las primeras pruebas y preparar documentación para su despliegue.

El equipo de Comunidad está ampliando el equipo de respuesta a incidentes de WordPress, IRT, y busca nuevos colaboradores comprometidos con mantener un entorno seguro y respetuoso. Su misión es ofrecer un canal claro para que cualquier miembro de la comunidad informe y gestione incidentes que puedan violar el Código de Conducta de WordPress, asegurando así el bienestar de todos los participantes. Con el fin de incorporar perspectivas frescas de manera continua, el IRT introducirá un sistema de rotación que permitirá convocatorias periódicas.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

Desde diciembre de 2022 se da soporte de seguridad desde la versión 4.1 y ahora la versión que recibirá actualizaciones será 4.7 y superiores.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 16 al 22 de junio de 2025.

Era diciembre de 2022 cuando se anunció que WordPress iba a dejar de dar soporte de seguridad retroactiva a las versiones desde 3.7 a 4.0. Dos años y medio después, la versión mínima que recibirá esos backports será la 4.7.

Y es que, aunque oficialmente la única versión soportada es la última, actualmente WordPress 6.8, el equipo de seguridad hace el esfuerzo de aplicar parches de seguridad a versiones anteriores. Simplemente eso: si se descubre algún problema de seguridad, se aplica el parche sin cambiar nada más.

Esto significa que se actualizan entre 20 y 25 versiones de WordPress ya no soportadas, para hacer de la Web un lugar más seguro.

Pero, ahora mismo, casi el 90 % de los sitios usan WordPress 6.0 o superior, y más del 95 % usan WordPress 5.0 o superior, lo que implica que mantener versiones anteriores ya se puede considerar mantener sitios fantasma que probablemente estén olvidados.

Recuerda que, para mantener tu sitio seguro y compatible, lo mejor siempre es tener alguna de las tres últimas versiones mayores de WordPress.

Y hablando de versiones de WordPress, se acerca WordPress 6.8.2, que plantea como fecha de lanzamiento el martes 15 de julio. A lo largo de las próximas tres semanas se realizarán las revisiones para incluir las mejoras propuestas; el 8 de julio tendremos una versión candidata con los cambios finales, y el día 15 se lanzaría la nueva versión menor.

Alrededor de 20 tickets del núcleo y 10 del editor están previstos que se incorporen en esta versión.

Durante la WordCamp Europe 2025 hubo un WPCafé con un tema central: Five for the Future. De todo lo que se comentó durante esas horas, se ha publicado un resumen que adopta un tono propositivo y estratégico: parte de un análisis profundo de “Five for the Future” y convence a los distintos actores de la comunidad, desde voluntarios hasta patrocinadores, para redefinir por completo qué cuenta como contribución más allá del código, garantizando sostenibilidad, reconocimiento inclusivo, gobernanza transparente y procesos estandarizados de equipo.

Se insiste en reemplazar el ambiguo compromiso del 5 % por un marco claro que abarque docencia, organización de eventos, mentoría, moderación, traducción, creación de documentación y apoyo de infraestructura; además, se propone simplificar la comunicación con resúmenes y aplicar teorías de medición rigurosas para evitar interpretaciones contrapuestas.

El texto deja patente el consenso en torno a abordar la crisis de burnout con mecanismos de financiación justa (becas, estipendios o subvenciones), y la reactivación del equipo de Sostenibilidad; a impulsar métricas y paneles de control fiables (Contributor Dashboard y Bitergia) para reforzar la rendición de cuentas; a estructurar procesos de incorporación y cierre de ciclo de colaboradores; y a aprovechar la IA para sintetizar conocimiento disperso sin deshumanizar la interacción.

En los comentarios, Mary Hubbard, directora ejecutiva del proyecto WordPress, reafirma estos puntos clave: definir con nitidez los criterios de contribución incluyendo el trabajo no técnico, rediseñar el sistema de reconocimiento con un esquema de insignias y métricas concretas, monitorizar aportaciones reales con herramientas de datos, documentar la formación y clausura de equipos (onboarding y offboarding) y fomentar la autonomía descentralizada de los colaboradores. En general, se apoya el espíritu “pedir perdón en vez de pedir permiso” y propone plazos claros de entrega para el tercer trimestre.

El equipo de Plugins está planteando un bloqueo en la actualización de plugins cuando se intenta subir código inaceptable, como podría ser, por ejemplo, la versión premium de Freemius, que no es compatible con las licencias de WordPress.

De esta manera, cuando se encuentren patrones de elementos que se sabe que son incompatibles, la subida al repositorio quedará bloqueada automáticamente, devolviendo un mensaje con la razón de por qué pasa eso.

El equipo de Polyglots propone un flujo de trabajo escalonado y transparente para gestionar contribuciones de traducción de baja calidad que imponen una carga extra a los validadores voluntarios. Primero, el revisor contacta al traductor a través de la herramienta de discusión integrada, ofreciendo orientación; si no hay respuesta ni mejora en pocos días, se le avisa públicamente en el canal #polyglots de Slack; tras la falta de reacción, se documenta el caso con capturas y enlaces en el blog de Polyglots etiquetado como #block-spammer; y, finalmente, si persiste el patrón de envíos deficientes, se aplica una suspensión temporal de derechos de contribución mediante un plugin a medida, con un aviso al usuario con enlace al post explicativo.

Aunque se han planteado algunas preocupaciones: cómo definir con claridad qué se considera «mala calidad», o sea, el número de errores, porcentaje de inexactitud o violaciones de la guía de estilo; también cuántos validadores deben avalar la medida y cuántos fallos justifican la primera alerta; asegurar que las notificaciones de la plataforma estén habilitadas por defecto; confiar en el criterio de los editores de proyecto (PTE) y editores generales (GTE); y tal vez renombrar la etiqueta a algo menos punitivo.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

La herramienta de gestión de entradas y la organización de las WordCamp ha quedado obsoleta tras varios años sin cambios, llegando una propuesta para su actualización.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 9 al 15 de junio de 2025.

Uno de los pilares que ha sostenido la organización de los eventos WordCamp a lo largo de los años ha sido CampTix, el sistema de gestión de entradas que ha permitido a organizadores de todo el mundo planificar y ejecutar eventos con cierta eficiencia. Sin embargo, con la evolución de las expectativas tanto de los equipos organizadores como de los asistentes, este sistema empieza a mostrar sus límites. Las herramientas actuales, aunque funcionales, no están del todo alineadas con las necesidades modernas de usabilidad, análisis y control. Y es ahí donde se plantea una necesaria reflexión: ¿cómo podemos mejorar la experiencia en WordCamp desde la tecnología que los soporta?

El reto es claro: CampTix necesita una revisión estructural que no solo corrija pequeños fallos, sino que lo transforme en una herramienta verdaderamente útil y moderna. Los organizadores reclaman estadísticas más útiles, mejor control sobre las entradas y flujos de compra más claros. Por su parte, los asistentes necesitan procesos más sencillos y opciones para gestionar sus propias entradas sin recurrir a terceros. Todo esto se agrava con la falta de mantenimiento activo del sistema y la curva de aprendizaje para quienes quieren contribuir a su desarrollo.

Frente a este panorama, se ha lanzado una propuesta abierta desde el equipo de Comunidad de WordPress para priorizar mejoras en CampTix. Se plantean ideas concretas: integrar mejor los datos para análisis, rediseñar el proceso de compra, facilitar reembolsos y permitir más autonomía para los asistentes. También se sugiere modernizar la gestión de divisas y optimizar el uso de códigos de descuento. Esta propuesta no solo es técnica, sino también organizativa: implica escuchar activamente a quienes usan la herramienta en el día a día y crear una hoja de ruta colaborativa.

Los próximos pasos serán decisivos. Se abre el proceso para recoger ideas a través de comentarios en el blog oficial y en el canal de Slack #meta-wordcamp. A partir de ahí, se priorizarán las tareas según impacto y viabilidad, y se invitará a desarrolladores, diseñadores y organizadores a sumarse a este esfuerzo conjunto. Porque mejorar CampTix no es solo una cuestión de código: es una apuesta por cuidar la experiencia de comunidad que hace únicas a las WordCamp.

En la versión Gutenberg 21.0 se añade la opción de seleccionar el elemento HTML en los bloques Button y Separator, permitiendo elegir entre  o  para botones y  o  para separadores desde el panel Avanzado, mejorando la accesibilidad y el control semántico del contenido. Además, se ha llevado a cabo una refactorización extensa del ToolsPanel que unifica la interfaz de configuración de múltiples bloques —incluyendo Button, Embed, File, List, Navigation, Post Title y RSS—, ofreciendo una experiencia de edición más consistente y ordenada.

La accesibilidad y la usabilidad se han potenciado con mejoras en la navegación por teclado y la gestión de foco en bloques clave como Button, Columns y Details, garantizando un flujo de trabajo más fluido para usuarios que dependen de tecnologías de asistencia. Además, se han corregido numerosos errores relacionados con controles de bloques, leyendas de galerías e internacionalización de enlaces sociales, lo que reduce interrupciones y optimiza la estabilidad general del editor.

El equipo de Core, durante la reunión de committers en WCEU 2025, discutió varios temas clave para el futuro del desarrollo de WordPress. Uno de los principales fue mejorar la experiencia de incorporación para nuevos colaboradores, con propuestas como documentación más clara, canales de soporte activo y mentoría. También se planteó que los committers tengan un rol más activo como revisores, no solo como responsables de fusionar código.

Se habló además de optimizar el ciclo de lanzamiento, incluyendo la posibilidad de trabajar con ramas de características para facilitar la revisión de grandes cambios, y una mejor planificación para reducir las prisas antes del feature freeze. Finalmente, se enfatizó la importancia de mantener el foco en el mantenimiento del core, incluyendo mejoras en las pruebas automatizadas, la gestión de tickets del Trac y la colaboración entre equipos, especialmente con los de documentación y accesibilidad.

El equipo de IA ya plantea establecer formas claras de indicar cuándo un contenido ha sido generado o asistido por inteligencia artificial, enfocándose en la transparencia para usuarios y editores. Una de las propuestas clave es incluir un aviso o señal visual que permita distinguir este tipo de contenido dentro del editor de WordPress, sin interferir en la experiencia de lectura. También se sugiere que haya una manera sencilla para los usuarios de revisar y confirmar el contenido generado, dejando constancia de la intervención humana como parte del proceso editorial.

Además, se debatió sobre el uso de etiquetas (metadatos) en los contenidos para registrar el uso de herramientas de IA, así como la posibilidad de añadir una interfaz que informe al usuario si el contenido fue generado o modificado con ayuda de IA. Otras propuestas incluyen explorar cómo estos sistemas pueden integrarse en el flujo de trabajo del editor de bloques, sin automatizar decisiones editoriales pero sí ayudando a proponer mejoras o borradores.

El grupo acordó continuar estas líneas de trabajo desde tres frentes:

El equipo de Playground ha presentado un nuevo driver SQLite para WordPress, diseñado para integrarse de forma más nativa con el sistema y facilitar entornos de desarrollo, pruebas y uso local sin depender de servidores MySQL o MariaDB. A diferencia de implementaciones anteriores, este driver aprovecha la arquitectura de controladores de bases de datos introducida en WordPress 6.4 y es totalmente compatible con las abstracciones del núcleo, evitando modificaciones invasivas al código base.

El objetivo principal es ofrecer una experiencia coherente y funcional con SQLite desde el primer momento, lo que abre nuevas posibilidades para herramientas como Playground, entornos educativos, desarrollo rápido de plugins o temas, y pruebas automatizadas. Aunque aún está en fase experimental, se alienta a la comunidad a probarlo, reportar errores y contribuir a su evolución, con la intención de que en el futuro forme parte oficial del ecosistema de WordPress.

El equipo de Accesibilidad quiere comenzar el proyecto de Documentación de Accesibilidad, que implica trasladar la documentación de accesibilidad existente al repositorio de WPAccessibility en GitHub, con el objetivo de mantener información actualizada sobre cómo diseñar, desarrollar y probar para cumplir los estándares de accesibilidad en WordPress.

Se define un proceso abierto de contribución y revisión gestionado por el equipo de accesibilidad, con ejemplos prácticos, pautas claras de hacer y no hacer, y una sección dedicada a ejemplos de código accesible en la zona de desarrolladores; todo ello para facilitar la aportación de la comunidad y garantizar la calidad y conformidad con el estándar doble A.

La planificación incluye la configuración del proyecto y la transferencia inicial del contenido entre junio y agosto de 2025, seguida de la reescritura, reestructuración y establecimiento de un sistema de revisión durante septiembre y octubre; posteriormente, desde noviembre en adelante, se mantendrá la documentación, se revisarán y fusionarán contribuciones y se invitará a más personas a colaborar, con informes quincenales sobre el avance publicados en el blog de accesibilidad.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.

WordPress ha definido un conjunto de principios y pasos claros para decidir si un proyecto merece alojarse (o migrarse) bajo su organización oficial en GitHub.

Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.

Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.

En este episodio encontrarás la información del 2 al 8 de junio de 2025.

WordPress ha definido un conjunto de principios y pasos claros para decidir si un proyecto merece alojarse, o migrarse, bajo su organización oficial en GitHub. Primero, se busca asegurar la propiedad por parte de la comunidad y la calidad, ya que solo los repositorios que aporten valor al ecosistema, con código accesible y bien administrado, van a ser candidatos.

Para entrar en la organización, un proyecto va a tener que cumplir tres grandes bloques de requisitos:

El primer punto es la documentación y objetivos claros, teniendo un fichero README o una entrada en el blog de Make WordPress con una definición del problema que resuelve y sus metas, además de actualizar periódicamente su estado.

El segundo punto es el patrocinio y mantenimiento, contando con al menos un mantenedor activo dentro de un equipo reconocido de contribuidores, aunque idealmente varios para garantizar la continuidad del proyecto, señalados en el fichero README y en un fichero CODEOWNERS.

Como tercer punto, el compromiso de soporte y buenas prácticas, respondiendo a peticiones y bugs con rapidez, siguiendo las normas de codificación de WordPress, manteniendo documentación accesible y cumpliendo licencias (GPL) y el código de conducta de la Comunidad.

Una vez dentro, hay reglas sobre ciclo de vida y seguridad:

Por ejemplo, si un repositorio queda huérfano, sin mantenimiento, y no es un canonical plugin, se archivará tras seis meses sin respuesta, aunque podrá reabrirse si surge un nuevo responsable.

Solo los repositorios incluidos explícitamente en la política de HackerOne entran en el programa de recompensas; pero cualquier fallo crítico debe repararse de inmediato en coordinación con el equipo de seguridad.

Y los proyectos experimentales o herramientas internas han de tener etiquetas y expectativas de soporte diferenciadas, para no confundir a usuarios finales con componentes en desarrollo.

Todo esto viene bajo el paraguas de que el lanzamiento de nuevas funcionalidades de WordPress no venga tan centrado en el núcleo en sí, sino en estos plugins de funcionalidad que ayuden a mejorar y probar ideas que se puedan incluir en un futuro en WordPress.

Gutenberg 20.4 y 20.5 ya están disponibles con algunas novedades destacadas.

En el caso de Gutenberg 20.4, se ha incluido un sistema de recuerdo persistente de la preferencia del usuario en la opción “Mostrar Plantilla” en el editor. Además, el bloque de Query Loop ahora da soporte para ordenar contenidos según el orden del menú.

Para Gutenberg 20.5, los bloques creados por el paquete “create-block” ahora incluyen un manifiesto de bloques con metadatos, mejorando el rendimiento de carga. Además, en el panel de prepublicación no se muestran sugerencias de etiquetas o categorías si no hay ninguna añadida.

El equipo de Performance ha lanzado el canonical plugin View Transitions, que implementa la nueva CSS View Transitions API para suavizar las transiciones al navegar entre URLs en sitios WordPress. En lugar del “flash” habitual al cambiar de página, el plugin aplica por defecto un efecto de “fade” entre el estado antiguo y el nuevo del DOM, logrando una experiencia más fluida.

Tras la presentación del equipo de IA como grupo dedicado a explorar cómo la inteligencia artificial puede mejorar la experiencia WordPress de forma abierta y responsable, en una primera fase se centrará en crear un conjunto de canonical plugins y herramientas base para sentar los cimientos que puedan evolucionar hacia futuras inclusiones en el núcleo de WordPress.

Para su funcionamiento, el equipo seguirá una estructura abierta: reuniones quincenales, código y planificación en repositorios públicos en GitHub, y decisiones tomadas tanto en revisiones de pull requests como vía propuestas formales.

El equipo de Test ha encontrado que, en el flujo actual de trabajo de WordPress, cuando alguien prueba una corrección de error, o sea, un “parche”, y la prueba pasa, esa persona añade la etiqueta dev-feedback para avisar a los desarrolladores de que el parche está listo. El problema es que la mayoría de quienes hacen estas pruebas no revisan el código en detalle, así que los desarrolladores no saben si la etiqueta viene acompañada de un examen técnico serio o no, haciendo que muchas veces se ignoren esos avisos porque solo confían en las pruebas realizadas por gente con reputación en revisión de código, y el resto de informes acaba siendo prácticamente inútil.

Para resolverlo, se propone introducir una nueva etiqueta: needs-code-review. Con ella, quien solo prueba el parche puede marcar que hace falta un revisor de código, y quienes sí revisan pueden seguir usando dev-feedback cuando el examen técnico esté completo. De ese modo, los desarrolladores sabrán de un vistazo qué parches sí han sido revisados a fondo y cuáles necesitan todavía un repaso antes de pasar a producción.

La WordCamp Europe 2025 cerró sus puertas el pasado sábado en Basilea, con 1.723 asistentes presenciales de 84 países, y más de 20.000 en línea, tras tres intensos días que comenzaron con un Contributor Day con 640 participantes repartidos en 21 equipos.

Como en otras WordCamp Europe, Matt Mullenweg, acompañado esta vez de Mary Hubbard, dedicaron media hora a comentar los proyectos y el ecosistema de WordPress, y posteriormente contestaron a algunas de las preguntas de los asistentes.

Entre los temas más destacados están las regulaciones europeas de protección de datos y ciberseguridad, el lanzamiento del Proyecto FAIR, o el proyecto Campus Connect, en el que en Italia 5.000 estudiantes podrán convalidar créditos en la universidad si dedican 150 horas de contribución a WordPress, aunque no se especificó de qué manera se iba a gestionar la entrada de todos estos alumnos en la comunidad y en qué tareas. Todo lo relacionado con Five for the Future tuvo bastante representación tanto en la conversación como en las preguntas, así como en el WP Café que se produjo esa misma mañana con la participación de la propia Mary.

Si te has perdido el evento, tienes más de 6.000 fotografías para encontrar a sus participantes y momentos más destacados. Y no olvides que el año que viene la WordCamp Europe 2026 será en Cracovia, en Polonia, del 4 al 6 de junio.

Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.

Un abrazo, y hasta el próximo programa.