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.
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 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.
Deja una respuesta