Alertas de Error 500, 404 y Checkout PrestaShop (DataFirefly Site Alerts)

DataFirefly Site Alerts envía un email a las direcciones que usted elija cuando su tienda PrestaShop 8 o 9 devuelve un error 500, acumula errores 404 o un cliente llega al checkout sin que se le ofrezca ningún transportista ni ningún método de pago. Esta documentación cubre la instalación, los ajustes, el contenido de cada alerta y la resolución de problemas.

Instalación

1. En el back office, abra Módulos > Gestor de módulos, haga clic en Subir un módulo y envíe el archivo dfsitealerts-1.0.0.zip.
2. El módulo crea su tabla y una pestaña Parámetros Avanzados > Alertas de errores y checkout. El botón Configurar del módulo lleva directamente a ella.
3. Al instalarlo, la dirección de email de la tienda se usa como destinatario y las cuatro detecciones quedan activadas.
4. Haga clic en Enviar un correo de prueba para comprobar que las alertas llegan.

El módulo es compatible con PrestaShop 8.0 a 9.x y con multitienda. No utiliza ninguna dependencia de Composer. Los emails se envían con la configuración de Parámetros Avanzados > Correo electrónico: si allí están desactivados, aparece un aviso en la parte superior de la página del módulo.

Panel

La parte superior de la página muestra el número de problemas distintos detectados en las últimas 24 horas, por tipo: Error 500, Error 404, Sin transportista, Sin método de pago, Sitio inaccesible. Una misma URL o un mismo error cuenta una sola vez. Debajo aparecen los destinatarios actuales, la URL del cron y los botones Enviar un correo de prueba, Ejecutar ahora la tarea programada y Vaciar el registro.

Destinatarios

• Direcciones de correo electrónico: una dirección por línea (también se aceptan comas y puntos y comas). Cada dirección recibe su propio email. Una dirección no válida se rechaza al guardar.
• Idioma de las alertas: idioma de los emails, independiente del idioma de los visitantes. Por defecto, el idioma predeterminado de la tienda.

Qué genera una alerta

Cada detección se activa o se desactiva por separado.

Errores del servidor (500)

Al final de cada petición del front office, el módulo captura los errores fatales de PHP, las excepciones no capturadas y cualquier página que responda con un estado 5xx. El modo mantenimiento (503) se ignora. El email contiene:

• el mensaje de error y la traza de llamadas, sin la ruta del servidor;
• el tipo de error de PHP, el archivo y la línea en ruta relativa;
• la URL, la página de origen, el método HTTP, el controlador y el agente de usuario;
• el pico de memoria y las versiones de PrestaShop y de PHP.

Cuando PrestaShop intercepta una PrestaShopException y muestra su página de error, no hay ningún mensaje de PHP disponible: el módulo toma la última entrada del archivo var/logs/AAAAMMDD_exception.log del día. Los errores idénticos se agrupan, y los números variables (identificadores, tamaños de memoria) se ignoran para la agrupación.

Páginas no encontradas (404)

Los 404 se agrupan por ruta de URL. Los parámetros que identifican una página (controller, id_product…) se conservan, y los parámetros de seguimiento (utm_*, gclid, fbclid, msclkid…) se ignoran. Se envía una alerta según los ajustes de la sección siguiente.

Proceso de compra sin ningún transportista

La detección se activa cuando un cliente llega al paso de envío con una dirección de entrega y un carrito que no está vacío ni es virtual, y no se le ofrece ningún transportista. Los problemas se agrupan por país y por provincia. El email contiene:

• el ID del carrito y del cliente, el país, la provincia, el código postal y la zona;
• el peso y el total del carrito, la lista de productos y el grupo del cliente;
• Transportistas activos para esta zona y este grupo, cada uno con el motivo de su ausencia: fuera de sus rangos de peso, fuera de sus rangos de precio, paquete demasiado grande, excluido por restricciones de producto o división del paquete, o no devuelto para este carrito (módulo de transportista o gastos de envío no disponibles);
• Productos limitados a algunos transportistas: los productos del carrito que tienen transportistas seleccionados en su pestaña Transporte.

Si no hay ningún transportista activo asignado a la zona y al grupo del cliente, la alerta lo indica directamente.

Proceso de compra sin ningún método de pago

La detección se activa cuando un cliente llega al paso de pago con un carrito pendiente de pago y ningún módulo de pago ofrece una opción. Un carrito gratuito (total 0) no se tiene en cuenta. Los problemas se agrupan por país, moneda, transportista y grupo. El email contiene el país, la moneda, el transportista seleccionado, el total, el grupo del cliente y, a continuación:

• Módulos de pago activos: todos los módulos de pago instalados y activados;
• Módulos de pago permitidos para este país, moneda, grupo y transportista: los que las restricciones de Pago > Preferencias dejan pasar para este cliente.

Si la segunda lista está vacía, la causa está en las restricciones. Si contiene módulos, esos módulos están permitidos pero no han devuelto ninguna opción: la causa está en su propia configuración (importe mínimo, cuenta no conectada, modo de prueba).

Ajustes de 404

• Umbral de alerta: se envía una alerta cuando una misma URL alcanza este número de visitas desde su última alerta. 5 por defecto, 1 para recibir la alerta desde la primera visita.
• Alerta inmediata para enlaces internos rotos: cuando la página de origen pertenece a su tienda, la alerta se envía en la primera visita, sea cual sea el umbral.
• Ignorar bots: motores de búsqueda, rastreadores SEO, scripts y agentes de usuario vacíos.
• Ignorar archivos estáticos: imágenes, CSS, JS, fuentes y vídeos.
• URL que ignorar: una ruta por línea, * coincide con cualquier cosa. La lista predeterminada ignora los escaneos habituales: /wp-*, /wordpress/*, /xmlrpc.php, */.env, */.git/*, /cgi-bin/*, *phpmyadmin*, /.well-known/*, /apple-touch-icon*.

Límites de envío y resumen diario

• Intervalo entre dos alertas para un mismo problema: 60 minutos por defecto. Las ocurrencias producidas durante este intervalo se cuentan y se indican en la siguiente alerta, en la línea «Ocurrencias desde la última alerta».
• Máximo de alertas por hora: 20 por defecto, 0 para no poner límite. Los problemas que superan el límite siguen registrados y aparecen en el resumen.
• Resumen diario: un email al día a la hora elegida (8:00 por defecto), con cada problema registrado desde el resumen anterior, incluidos los que no alcanzaron el umbral de alerta. No se envía si no ha ocurrido nada.
• Conservar el registro durante: 30 días por defecto, de 1 a 365.

Tarea programada

Las alertas 500, 404 y de checkout se envían en tiempo real. La tarea programada envía el resumen diario a la hora prevista, reprocesa las alertas que no se pudieron guardar en la base de datos, purga el registro y ejecuta la comprobación de disponibilidad. Una ejecución cada 15 minutos es adecuada.

Cron por URL

*/15 * * * * curl -fsS "https://tu-tienda.com/module/dfsitealerts/cron?token=…" > /dev/null

La URL exacta, con su token, se muestra en la página del módulo junto a un botón Copiar. Responde en JSON y también funciona en modo mantenimiento. Un token no válido devuelve un error 403.

Cron por línea de comandos

*/15 * * * * php /ruta/a/prestashop/modules/dfsitealerts/cron.php > /dev/null

El comando procesa todas las tiendas activas en multitienda.

Sin cron

Tras una visita normal a la tienda, el módulo ejecuta el mantenimiento como máximo una vez cada 15 minutos. Por tanto, el resumen se envía tras la primera visita posterior a la hora prevista. La comprobación de disponibilidad no se ejecuta en este modo.

Comprobación de disponibilidad

Algunos errores 500 se producen antes de que arranque PrestaShop (caída de PHP-FPM, archivo de configuración dañado): ningún módulo puede capturarlos. En cada ejecución del cron, la comprobación de disponibilidad carga desde el servidor las URL indicadas en URL que probar (10 como máximo, la página de inicio si la lista está vacía). Una respuesta 5xx o una conexión imposible genera la alerta Fallo en la comprobación de disponibilidad, con el código HTTP, el tiempo de respuesta y el error de conexión. Un 503 se ignora cuando la tienda está en modo mantenimiento.

Añada una página de categoría y una de producto para una mejor cobertura. Para una caída completa del servidor, que también impide que se ejecute el cron, utilice además un servicio externo de monitorización de disponibilidad.

Registro de alertas

La lista de la parte inferior de la página muestra cada problema registrado: tipo, ubicación (URL, o país / moneda / transportista para el checkout), mensaje o página de origen, número de ocurrencias, primera y última detección, fecha de la última alerta. Se puede filtrar por tipo y exportar a CSV. El botón Ver abre una ficha con el mismo contenido que el email y los datos sin procesar en JSON. Eliminar una entrada pone su contador a cero.

Datos y privacidad

• Las alertas de checkout contienen el ID del carrito y del cliente, el país, la provincia, el código postal, el peso y el contenido del carrito. No contienen nombre, dirección postal, email ni teléfono.
• La ruta del servidor se elimina de los mensajes de error y de las trazas de llamadas.
• El registro se purga una vez transcurrido el periodo de conservación elegido.
• Cuando la base de datos rechaza la escritura, la alerta se guarda en un archivo de var/logs (2 MB como máximo) y se reprocesa en la siguiente ejecución del mantenimiento.

Limitaciones conocidas

• Solo se supervisa el front office. Los errores del back office no generan alertas.
• Una caída completa del servidor o de PHP impide cualquier envío de email: utilice un servicio externo de monitorización de disponibilidad.
• Las detecciones del checkout se basan en el proceso de compra nativo de PrestaShop. Con un módulo de checkout en una página de terceros, la alerta de transportista depende de que se llame al hook displayBeforeCarrier, y la alerta de pago solo se evalúa una vez elegido un transportista.
• El envío tras mostrar la página requiere PHP-FPM o LiteSpeed. Con otro modo de ejecución de PHP, el email se envía antes de que termine la petición.

Resolución de problemas

El correo de prueba no llega

Revise Parámetros Avanzados > Correo electrónico y envíe un correo de prueba desde esa página. Mire también la carpeta de spam: añada la dirección de envío de la tienda a sus contactos.

Recibo demasiadas alertas 404

Suba el Umbral de alerta, añada las rutas afectadas a URL que ignorar o cree las redirecciones 301 que faltan: una URL redirigida ya no devuelve un 404.

Ninguna alerta de checkout aunque un cliente se ha quejado

Compruebe que las dos detecciones del checkout están activadas y que el cliente llegó realmente al paso correspondiente con una dirección. Con un módulo de checkout en una página de terceros, consulte la sección Limitaciones conocidas.

Sigue apareciendo «La tarea cron no se ha ejecutado nunca.»

Abra la URL del cron en un navegador: debe responder {"ok":true,…}. Una respuesta invalid token significa que la URL se copió de forma incompleta.