Fernando Tellado

La idea de añadir un enganche al correo es buena y la incorporaré al plugin más adelante con algun pequeño cambio (ah, no uses ese código, tiene un pequeño error de sintaxis).

Para ahora mismo, si quieres algo inmediato usa este apaño con wp_mail en un mu-plugin o como acostumbres, totalmente nativo, que va por fuera y no se pierde al actualizar:

add_filter( 'wp_mail', function ( $args ) {

    // Pon aquí un trozo del ASUNTO del aviso, tal y como te llega a ti
    // Cópialo del correo que recibes, cambia según el idioma de tu tienda, lo pongo en español por las dudas
    $identificador = 'solicitud de desistimiento';

    if ( empty( $args['subject'] ) || false === strpos( $args['subject'], $identificador ) ) {
        return $args; // No es el aviso de nueva solicitud: no se toca nada.
    }

    // La línea (o líneas) que quieres añadir.
    $linea_extra = 'Aviso interno: revisar el inventario antes de aceptar.';

    $args['message'] .= "\r\n" . $linea_extra;

    return $args;
} );

Dos cosas:

1. Ajusta el valor de $identificador a un trozo del asunto tal y como te llega el correo
(depende del idioma activo en la tienda). Así nos aseguramos de tocar solo ese aviso y no el
resto de correos del sitio.
2. Cambia el texto de $linea_extra por lo que quieras que aparezca.

Esto añade la línea al final del correo. Cuando publique la versión con el enganche propio podrás cambiarlo por algo más limpio (y elegir en qué posición va)

🙂

Así de gusto, adjudicado el título de tester pro 🙂

Efectivamente es un fallo, el enlace “Ver en la administración” llega vacío. El motivo es que ese correo se genera en el mismo momento en que el cliente envía su solicitud, y la función que coloca el enlace comprueba los permisos de quien está en ese instante (el cliente, que no tiene permisos de gestión), no los de quien va a recibir el correo (tú). Como ve a un cliente sin permisos no genera el enlace y lo deja en blanco.

Tu solución es correcta y es justo como conviene resolverlo, generando la dirección de la pantalla de administración directamente, sin esa comprobación de por medio. No abre ningún riesgo, porque si alguien sin permisos hiciera clic en el enlace WordPress le frena igualmente al intentar entrar.

Lo voy a incorporar al plugin en la próxima versión (una menor, 1.8.1 seguramente), así que no tendrás que mantener tu propio parche.

Si lo que también querías era cambiar los textos o el formato del correo eso es otra juerga y lo meteré en una distinta, lo tenía apuntado pero mejor si me das tu lista de deseos (en otro hilo mejor si es posible) 🙂

¡Gracias de nuevo!

A mandar 🙂

Bonjour @zepolo,

Thanks for the details. These are actually two separate things, and the good news is that neither is a bug in the plugin nor a problem with your content.

1. “Could not connect / cURL error 28: timed out”

To score a page, VigIA requests your own site over HTTP (a “loopback” request). This error means your server can’t connect back to its own public URL within 10 seconds. It’s a server/network issue, not a slow page and not the plugin itself. It’s very common when a site sits behind Cloudflare, a CDN/proxy, or a security firewall that silently drops these self-requests.

Could you check two things so we can pinpoint it?

• In WordPress, go to Tools → Site Health. If you see a failed notice about “loopback requests”, that confirms the cause.
• Let me know whether these sites are behind Cloudflare / a CDN / a proxy, and whether you run a security firewall or rules that block by User-Agent or IP. That’s likely what’s blocking the analyzer, and I’ll tell you exactly what to whitelist.

2. “Crawlers that visited despite being in your Disallow list”

This one is expected behavior, not an error:

• Disallow in robots.txt is a request, not a lock. Well-behaved bots obey it; misbehaving ones ignore it. That list is simply showing you which crawlers ignore your robots.txt.
• Your PHP User-Agent block is still working. When it blocks a bot, the bot gets a 403 Forbidden and receives no content, but the request still reached your site, so it gets logged. So “visit” here means “knocked on the door”, not “got in and copied your content.”

You can confirm your block is doing its job: in VigIA’s visit log, those crawlers should show HTTP status 403. If they do, you’re fully protected and can safely ignore them. (If any show 200, send me the User-Agent and I’ll help you tighten the rule.)

One tip: User-Agent blocking happens after the bot already reached your site (so it’s always logged), and bad bots often fake their User-Agent. If you want to stop them reaching the server at all, the most effective place is at the edge: Cloudflare’s “Block AI bots” / WAF, or blocking by IP/ASN.

Just send me the Site Health result and your hosting/firewall setup, and I’ll close out the connection issue.

Gracias 🙂

Al no tener respuesta entiendo que se habrá arreglado

Yo he probado forzando por curl y rula, por ejemplo, lanza esta petición falsa pero declarando un User-Agent de IA y debería aparecer en la estadística:

Por ejemplo, esto debería mostrar un 404 (pon tu dominio y deja el slug inventado o pon el que quieras:

curl -A "GPTBot" -k -s -o /dev/null -w "%{http_code}\n" "https://tudominio.com/url-falsa-vigia-test-404/"

Si quieres forzar una redirección tipo 301 para ver si la registrar podría valer algo así (si tu hola mundo no lo borraste, sino cambia el 1 por un ID de post que sí tengas, redirigirá normalmente al pretty permalink:

curl -A "ClaudeBot" -k -s -o /dev/null -w "%{http_code}\n" "https://tudominio.com/?p=1"

De paso aproveché y apañé una duplicación de registro de los md