Si llevas tiempo en este sector sabes cómo huele cuando la noticia oficial brilla más que los parches pendientes: el WordPress 7.0 Release Candidate 3 ya está ahí —con la versión estable anunciada para el 20 de mayo— y todos los blogs y newsletters te van a bombardear con novedades, bloques mejorados y ese optimismo institucional que vende mejor que una auditoría.
Yo lo veo así: cuando el proyecto publica una RC con esa claridad sí leo primero las notas, pero no porque espere que me reinventen el stack de un plumazo. Lo que me importa de verdad es el día que actualizas sin pensar y coincide con el día en que tres plugins llevan medio año sin mantenimiento y alguno de ellos aparece por fin en una lista que no querías ver con tu marca delante.
Lo que llega estos días desde la inteligencia de amenazas y los informes habituales no es un rumor de foro ni un meme de Reddit: cada semana aparecen vulnerabilidades en extensiones muy concretas, con versiones máximas explícitas y con vectores tan tontos como un token mal validado o un campo de archivo demasiado confiado —el tipo de fallo que nadie presume en landing pero que sí explica picos extraños en el registro del servidor si sabes donde mirar.
Y aquí viene el matiz que nadie quiere grapar al comunicado feliz del lanzamiento: el núcleo importa pero el perímetro económico de muchísima parte del ecosistema es el menú Plugins. Una tienda WooCommerce estable en apariencia puede estar apoyada en cuatro addons que nadie revisa; un multisite institucional puede vivir años con el mismo cron de copias porque “funciona”. Yo he visto pymes contratar hosting caro pensando que eso “blinda” código de terceros: no. El hosting te da frontera pero no corrige código PHP mal filtrado en un formulario de registro que alguien montó porque el tutorial de YouTube prometía cero líneas de código propias.
Eso no quiere decir que debas tener miedo a WordPress ni que la versión nueva sea un problema. De hecho cuando el núcleo avanza bien lo que espero es mejor compatibilidad y menos trabajo en el día a día. El problema que veo desde fuera —y el que repetimos en soporte año tras año— es la cultura del “upgrade cuando me acuerdo” mezclada con la fantasía del plugin gratuitos que igual te salva la vida igual te deja un agujero. El mercado enseña velocidad pero no enseña inventario honesto.
Cuando llega un lanzamiento importante lo que sí te propongo es convertir esa fecha en hábito: inventario antes de clicar actualizar todos. ¿Qué queda sin vendor que lo mantenga activamente? ¿Qué permisos chocarán si cambias la UI de administración? ¿Alguien en tu equipo sabe responder qué cambió en tus plantillas desde la última versión menor o solo esperabais magia desde el escritorio?
Yo creo que el debate público peca por optimismo tecnológico. Se habla como si “estar al día” fuese suficiente. En práctica estar al día es un proceso: revisar registros cuando algo huele mal, tener copias probadas antes de pisar producción en viernes tarde —sí ese error lo cometemos humanos igual que vosotros— y leer cuando menos el resumen de los informes de vulnerabilidades en lugar del titular del chat de WhatsApp.
Si desarrollás para clientes también te toca educar sin dramatizar: no se trata de asustar sino de explicar que el coste real de un sitio no termina en el dominio y el hosting. Termina en el tiempo que alguien dedica a mirar qué plugins hay instalados y por qué. Si no hay presupuesto para eso el riesgo no desaparece: sólo se pospone.
Entonces sí: sigue el avance de WordPress 7.0 y aprovecha lo bueno. Pero no me pidas que ignore lo que dicen las listas de parches de plugins que circulan entre abril y mayo: son el recordatorio feo de que el agujero casi nunca está en el titular bonito sino en el detalle aburrido de una versión que no actualizaste porque “no daba problemas”.
¿Seguirías subiendo a producción el mismo viernes el core y cinco plugins sin pruebas si supieras que tu informe de amenazas de esa semana incluye al menos un fallo remoto en una extensión popular que aún no has auditado en tu stack?