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.
Transcripción del programa
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.
Deja una respuesta