evoLeadGate: preguntas frecuentes y problemas
Preguntas frecuentes
¿Funciona con la caché de página?
Sí. El token CSRF no va dentro del HTML: el script lo pide a Joomla al cargar la página. La configuración firmada del formulario sí viaja en el HTML, sin caducidad, así que una copia en caché sigue siendo válida mientras no cambies el secreto de Joomla.
¿Y si caduca mi suscripción o no tengo Download ID?
La extensión sigue funcionando igual. Lo que cambia es que dejas de recibir actualizaciones y que la pestaña Licencia de las opciones muestra el aviso correspondiente.
¿Puedo entregar varios archivos con un mismo formulario?
No. Cada formulario entrega un archivo. Si necesitas varios, comprímelos en uno o crea un formulario por archivo.
¿Se conecta con mi CRM?
No incluye conectores. Los leads quedan en tu base de datos y puedes sacarlos por el panel (con exportación a CSV), por la API REST de solo lectura, con el evento de Joomla onEvoleadgateLeadCreated desde tu propio plugin o, si lo tienes, con evoMCP. Los detalles están en la Referencia.
Si la misma persona rellena el formulario dos veces, ¿se duplica el lead?
Sí. Cada envío crea un lead nuevo, aunque el email ya exista. No hay deduplicación.
¿Los enlaces de descarga son de un solo uso?
No. El enlace sirve las veces que haga falta hasta que caduca (7 días por defecto). Cada descarga queda registrada en el detalle del lead.
Problemas
«Comprobar protección» dice «NO protegida»
El servidor responde algo distinto de 401, 403 o 404 al pedir el archivo de prueba de images/evoleadgate-privado/, así que los archivos se podrían descargar sin pasar por el formulario. La causa habitual es que el .htaccess no se aplica:
- En Nginx, que no lee
.htaccess, hace falta una regla que niegue el acceso a/images/evoleadgate-privado/. - En Plesk, la opción «Servir archivos estáticos directamente por nginx» salta el
.htaccessparapdf,txt,zipy similares. Añade la regla o desactiva esa opción para el sitio.
Después vuelve a pulsar Comprobar protección. Si aparece «No se pudo comprobar», el servidor no pudo hacerse la petición a sí mismo; el mensaje incluye el motivo.
El formulario no aparece en la web publicada
El formulario solo se pinta si tiene ID y un archivo válido de la carpeta privada. Abre la página en el editor: el elemento avisa si falta el ID, si no hay archivo o si el archivo no está en images/evoleadgate-privado/.
En el editor no envía nada
Es lo esperado. En la vista previa del constructor el formulario no envía datos. Pruébalo en la página publicada.
El visitante ve «No hemos podido procesar el envío. Espera un momento…»
El antispam rechazó el envío. Puede ser por:
- un campo trampa relleno (algunos gestores de contraseñas o autocompletados rellenan campos ocultos);
- un envío antes del tiempo mínimo de relleno (3 segundos por defecto);
- superar el límite de envíos por IP en la ventana (5 en 10 minutos por defecto).
Tras un rechazo, el visitante puede reintentarlo. Ajusta los límites en la pestaña Anti-spam de las opciones. Si todos los visitantes parecen venir de la misma IP, mira el punto siguiente.
Todas las IP guardadas son la misma
El sitio está detrás de un proxy inverso o un balanceador y Joomla no lo sabe. Activa Sistema → Configuración global → Servidor → Detrás de un balanceador de carga. Mientras no lo hagas, el límite por IP afecta a todos los visitantes a la vez y la IP guardada es la del proxy.
Los emails no llegan
Abre el lead en el panel y mira «Estado de los emails» (aviso / entrega):
sent: Joomla entregó el correo al servidor de correo. Si no llega, revisa la carpeta de spam y la reputación del remitente.failed: falló el envío. Revisa Configuración global → Servidor. Con SMTP, el puerto 587 va con STARTTLS y el 465 con SSL/TLS; mezclarlos es una causa frecuente.skipped(solo en el aviso): no había destinatarios. Define «Emails de aviso» en el elemento o el email de aviso por defecto en las opciones.
El lead se guarda aunque el correo falle.
Los enlaces de los emails apuntan a otro dominio
Los enlaces se construyen con el dominio de la petición. Define $live_site en configuration.php.
Al abrir el enlace sale «Este enlace ha caducado»
Ha pasado el plazo de «Días de validez del enlace de descarga». El visitante debe volver a rellenar el formulario, lo que crea un lead nuevo. Para dar más margen, sube el plazo en las opciones; solo afecta a los leads nuevos.
Al abrir el enlace sale «El archivo no está disponible»
El enlace no existe o el archivo ya no está en images/evoleadgate-privado/ (lo borraste, lo moviste o lo renombraste). Con el archivo ausente, además, el formulario no capta leads nuevos: el visitante ve un mensaje de error genérico.
Tras cambiar el secreto de Joomla fallan los formularios antiguos
La configuración firmada del formulario se firma con el secreto del sitio. Si lo cambias, los formularios que siguen en una caché responden con error hasta que la página se vuelva a generar. Vacía la caché.
No se registran las conversiones en Google Ads o Meta
El script solo llama a gtag y fbq si existen como funciones en la página. Si no hay conversión es porque tu sitio no los ha cargado o el visitante no aceptó la categoría de marketing. El evento del dataLayer se envía siempre. Para Google Ads, además, hay que rellenar «Conversión de Google Ads» con el formato AW-XXXXXXX/etiqueta.
Las IP y los leads antiguos no se borran
La retención la ejecuta una tarea programada que el paquete no crea. Créala en Sistema → Tareas programadas («evoLeadGate: retención de datos») y comprueba que está activa y que se ejecuta. Con la retención de leads en 0 (el valor por defecto), los leads nunca se borran.