WordPress 7.2 añadirá una URL /random/ que lleva a entradas al azar, activada por defecto y sin casilla para desactivarla

WordPress 7.2 añadirá una URL /random/ que lleva a entradas al azar, activada por defecto y sin casilla para desactivarla 2

WordPress 7.2 traerá una función curiosa que estará activa en todas las webs desde el primer día. La nueva URL /random/ redirige a una entrada publicada elegida al azar, y también funciona por categoría, etiqueta, autor o tipo de contenido. Lo explicó Aaron Jorbin en una nota para desarrolladores publicada el 5 de noviembre en el blog Make WordPress Core, donde varios profesionales ya han pedido que se pueda apagar con un ajuste.

Cómo funciona la URL aleatoria

El funcionamiento es sencillo. Una visita a /random/ lleva a una entrada cualquiera de la web. Si se añade una taxonomía, el sorteo se limita a ella: por ejemplo, /random/category/release/ o /random/tag/dev-note/. También existen /random/author/ seguido del nombre de usuario, para entradas de un autor, y /random/ seguido del slug de un tipo de contenido personalizado.

La base «random» se puede traducir y cambiar desde la pantalla de ajustes de enlaces permanentes, y se antepone a las rutas de archivo que ya existen. Por dentro, la función usa las API de reescritura y WP_Query de siempre: durante esa petición, WordPress restringe la consulta a las entradas elegibles, las ordena con RAND() y se queda con una sola.

La función se ha trabajado en el ticket #64498 del Trac de WordPress y ha llegado al núcleo a lo largo de varios cambios en el código, con la revisión de colaboradores como Peter Wilson, Anne McCarthy y Jeff Paul. El equipo compartió además pruebas de rendimiento de la consulta aleatoria, algo que agradeció incluso uno de los comentaristas más críticos con la decisión de activarla por defecto.

Qué contenido entra en el sorteo

Para decidirlo, WordPress 7.2 añade el argumento randomable a register_post_type(). Si no se indica, vale true para los tipos de contenido que son consultables públicamente y tienen archivo. Entre los tipos nativos, las entradas sí participan; las páginas y los adjuntos no.

Los desarrolladores pueden excluir un tipo personalizado con ‘randomable’ => false y ajustar qué entra en el sorteo con la función wp_is_random_content_query(), que permite, por ejemplo, dejar fuera una categoría concreta solo en las peticiones aleatorias. Las personalizaciones que ya se apliquen a un archivo mediante pre_get_posts se aplican también a su versión aleatoria.

Activada por defecto y sin casilla para apagarla

La polémica está en los comentarios. La función viene activada por defecto y solo se puede desactivar con código: un filtro sobre wp_enable_random_content_redirect que devuelva false, por ejemplo en un pequeño mu-plugin. Al hacerlo, desaparecen las reglas de reescritura, el campo de la pantalla de enlaces permanentes y la variable de consulta.

El usuario MikeNGarrett, que crea webs para clientes, escribió que la función le traerá más problemas que beneficios y que tendrá que desactivarla. Otros participantes defendieron que debería ser un plugin y alertaron de posibles riesgos: más facilidad para descubrir contenido, una posible vía de denegación de servicio y la aparición de contenido no deseado en tipos personalizados mal configurados.

Jorbin respondió citando la filosofía del proyecto: no se añade una opción para desactivar cada función porque «las pantallas de opciones se volverían inutilizables». Añadió que la mayoría de la gente quiere que su contenido se descubra y remitió los posibles problemas de seguridad al proceso oficial de notificación de vulnerabilidades.

Qué deberían revisar agencias y desarrolladores WordPress

WordPress 7.2 está en fase beta y la versión final está prevista para el 8 de diciembre, así que hay margen para prepararse. Las agencias que gestionan muchas webs deberían decidir ya si quieren mantener /random/ y, si no, incluir el filtro en su mu-plugin de base antes de actualizar.

Los desarrolladores de temas y plugins con tipos de contenido personalizados deben fijar randomable de forma explícita para evitar que entre en el sorteo contenido que no debería verse así. Y desde el punto de vista del SEO, conviene comprobar que la nueva ruta no interfiere con URL existentes que empiecen por /random/ y que las redirecciones aleatorias no acaban enlazadas desde menús o sitemaps.


También podría ser de tu interés:

Deja un comentario