Alertes Erreur 500, 404 et Checkout PrestaShop (DataFirefly Site Alerts)

DataFirefly Site Alerts envoie un email aux adresses de votre choix quand votre boutique PrestaShop 8 ou 9 renvoie une erreur 500, accumule des erreurs 404, ou qu’un client arrive au checkout sans transporteur ou sans moyen de paiement proposé. Cette documentation couvre l’installation, les réglages, le contenu de chaque alerte et le dépannage.

Installation

1. Dans le back-office, ouvrez Modules > Gestionnaire de modules, cliquez sur Installer un module et envoyez le fichier dfsitealerts-1.0.0.zip.
2. Le module crée sa table et un onglet Paramètres avancés > Alertes erreurs et checkout. Le bouton Configurer du module y mène directement.
3. À l’installation, l’adresse email de la boutique est utilisée comme destinataire et les quatre détections sont actives.
4. Cliquez sur Envoyer un e-mail de test pour vérifier que les alertes arrivent.

Le module est compatible PrestaShop 8.0 à 9.x et multiboutique. Il n’utilise aucune dépendance Composer. Les emails passent par la configuration de Paramètres avancés > E-mail : si les emails y sont désactivés, un avertissement s’affiche en haut de la page du module.

Tableau de bord

Le haut de la page affiche le nombre de problèmes distincts détectés ces dernières 24 heures, par type : erreur 500, erreur 404, aucun transporteur, aucun moyen de paiement, site injoignable. Une même URL ou une même erreur compte une seule fois. En dessous figurent les destinataires actuels, l’URL du cron et les boutons Envoyer un e-mail de test, Lancer la tâche planifiée maintenant et Vider le journal.

Destinataires

• Adresses e-mail : une adresse par ligne (les virgules et points-virgules sont aussi acceptés). Chaque adresse reçoit son propre email. Une adresse invalide est refusée à l’enregistrement.
• Langue des alertes : langue des emails, indépendante de la langue des visiteurs. Par défaut, la langue par défaut de la boutique.

Déclencheurs d’alerte

Chaque détection s’active ou se désactive séparément.

Erreurs serveur (500)

Le module capture, en fin de requête front office, les erreurs fatales PHP, les exceptions non interceptées et toute page qui répond avec un statut 5xx. Le mode maintenance (503) est ignoré. L’email contient :

• le message d’erreur et la pile d’appels, avec le chemin du serveur retiré ;
• le type d’erreur PHP, le fichier et la ligne en chemin relatif ;
• l’URL, la page d’origine, la méthode HTTP, le contrôleur et l’agent utilisateur ;
• le pic de mémoire et les versions de PrestaShop et de PHP.

Quand PrestaShop intercepte une PrestaShopException et affiche sa page d’erreur, aucun message PHP n’est disponible : le module reprend la dernière entrée du fichier var/logs/AAAAMMJJ_exception.log du jour. Les erreurs identiques sont regroupées, les nombres variables (identifiants, tailles mémoire) étant ignorés pour le regroupement.

Pages introuvables (404)

Les 404 sont regroupées par chemin d’URL. Les paramètres qui identifient une page (controller, id_product…) sont conservés, les paramètres de tracking (utm_*, gclid, fbclid, msclkid…) sont ignorés. Une alerte est envoyée selon les réglages de la section suivante.

Commande sans aucun transporteur

La détection se déclenche quand un client atteint l’étape de livraison avec une adresse de livraison, un panier non vide et non virtuel, et qu’aucun transporteur n’est proposé. Les problèmes sont regroupés par pays et par État. L’email contient :

• l’ID du panier et du client, le pays, l’État, le code postal et la zone ;
• le poids et le total du panier, la liste des produits et le groupe du client ;
• Transporteurs actifs pour cette zone et ce groupe, avec pour chacun la raison de son absence : hors de ses tranches de poids, hors de ses tranches de prix, colis trop volumineux, exclu par les restrictions produit ou la division du colis, ou non renvoyé pour ce panier (module transporteur ou frais de port indisponibles) ;
• Produits limités à certains transporteurs : les produits du panier qui ont des transporteurs sélectionnés dans leur onglet Livraison.

Si aucun transporteur actif n’est associé à la zone et au groupe du client, l’alerte l’indique directement.

Commande sans aucun moyen de paiement

La détection se déclenche quand un client atteint l’étape de paiement avec un panier à payer et qu’aucun module de paiement ne propose d’option. Un panier gratuit (total à 0) n’est pas concerné. Les problèmes sont regroupés par pays, devise, transporteur et groupe. L’email contient le pays, la devise, le transporteur sélectionné, le total, le groupe du client, puis :

• Modules de paiement actifs : tous les modules de paiement installés et activés ;
• Modules de paiement autorisés pour ce pays, cette devise, ce groupe et ce transporteur : ceux que les restrictions de Paiement > Préférences laissent passer pour ce client.

Si la seconde liste est vide, la cause est dans les restrictions. Si elle contient des modules, ces modules sont autorisés mais n’ont renvoyé aucune option : la cause est dans leur propre configuration (montant minimum, compte non connecté, mode test).

Réglages 404

• Seuil d’alerte : une alerte part quand une même URL atteint ce nombre de visites depuis sa dernière alerte. 5 par défaut, 1 pour alerter dès la première visite.
• Alerte immédiate pour les liens internes cassés : quand la page d’origine appartient à votre boutique, l’alerte part dès la première visite, quel que soit le seuil.
• Ignorer les robots : moteurs de recherche, robots SEO, scripts et agents utilisateurs vides.
• Ignorer les fichiers statiques : images, CSS, JS, polices et vidéos.
• URL à ignorer : un chemin par ligne, * correspond à n’importe quoi. La liste par défaut ignore les scans courants : /wp-*, /wordpress/*, /xmlrpc.php, */.env, */.git/*, /cgi-bin/*, *phpmyadmin*, /.well-known/*, /apple-touch-icon*.

Limites d’envoi et récapitulatif quotidien

• Délai entre deux alertes pour un même problème : 60 minutes par défaut. Les occurrences survenues pendant ce délai sont comptées et indiquées dans l’alerte suivante, ligne « Occurrences depuis la dernière alerte ».
• Nombre maximum d’alertes par heure : 20 par défaut, 0 pour aucune limite. Les problèmes au-delà de la limite restent enregistrés et figurent dans le récapitulatif.
• Récapitulatif quotidien : un email par jour à l’heure choisie (8:00 par défaut), qui liste chaque problème enregistré depuis le récapitulatif précédent, y compris ceux restés sous le seuil d’alerte. Il n’est pas envoyé s’il ne s’est rien passé.
• Conserver le journal pendant : 30 jours par défaut, de 1 à 365.

Tâche planifiée

Les alertes 500, 404 et checkout partent en temps réel. La tâche planifiée envoie le récapitulatif quotidien à l’heure prévue, rejoue les alertes qui n’ont pas pu être enregistrées en base, purge le journal et lance le contrôle de disponibilité. Une exécution toutes les 15 minutes convient.

Cron par URL

*/15 * * * * curl -fsS "https://votre-boutique.fr/module/dfsitealerts/cron?token=…" > /dev/null

L’URL exacte, avec son jeton, est affichée sur la page du module avec un bouton Copier. Elle répond en JSON et fonctionne aussi en mode maintenance. Un jeton invalide renvoie une erreur 403.

Cron en ligne de commande

*/15 * * * * php /chemin/vers/prestashop/modules/dfsitealerts/cron.php > /dev/null

La commande traite toutes les boutiques actives en multiboutique.

Sans cron

Après une visite normale sur la boutique, le module lance la maintenance au plus une fois toutes les 15 minutes. Le récapitulatif part donc après la première visite suivant l’heure prévue. Le contrôle de disponibilité ne tourne pas dans ce mode.

Contrôle de disponibilité

Certaines erreurs 500 surviennent avant le démarrage de PrestaShop (plantage de PHP-FPM, fichier de configuration cassé) : aucun module ne peut alors les capturer. Le contrôle de disponibilité charge depuis le serveur, à chaque passage du cron, les URL listées dans URL à tester (10 au maximum, la page d’accueil si la liste est vide). Une réponse 5xx ou une connexion impossible déclenche l’alerte Échec du contrôle de disponibilité, avec le code HTTP, le temps de réponse et l’erreur de connexion. Un 503 est ignoré quand la boutique est en mode maintenance.

Ajoutez une page catégorie et une page produit pour une meilleure couverture. Pour une panne complète du serveur, qui empêche aussi le cron de tourner, utilisez en plus un service externe de surveillance de disponibilité.

Journal des alertes

La liste en bas de page montre chaque problème enregistré : type, emplacement (URL, ou pays / devise / transporteur pour le checkout), message ou page d’origine, nombre d’occurrences, première et dernière détection, date de la dernière alerte. Elle se filtre par type et s’exporte en CSV. Le bouton Afficher ouvre une fiche avec le même contenu que l’email et les données brutes en JSON. Supprimer une entrée remet son compteur à zéro.

Données et confidentialité

• Les alertes checkout contiennent l’ID du panier et du client, le pays, l’État, le code postal, le poids et le contenu du panier. Elles ne contiennent ni nom, ni adresse postale, ni email, ni téléphone.
• Le chemin du serveur est retiré des messages d’erreur et des piles d’appels.
• Le journal est purgé après la durée de conservation choisie.
• Quand la base de données refuse l’écriture, l’alerte est gardée dans un fichier de var/logs (2 Mo au maximum) et rejouée au passage suivant de la maintenance.

Limites connues

• Seul le front office est surveillé. Les erreurs du back-office ne déclenchent pas d’alerte.
• Une panne complète du serveur ou de PHP empêche tout envoi d’email : utilisez un service externe de surveillance de disponibilité.
• Les détections checkout s’appuient sur le tunnel de commande natif de PrestaShop. Avec un module de commande en une page tiers, l’alerte transporteur dépend de l’appel au hook displayBeforeCarrier et l’alerte paiement n’est évaluée qu’une fois un transporteur choisi.
• L’envoi après l’affichage de la page nécessite PHP-FPM ou LiteSpeed. Avec un autre mode d’exécution de PHP, l’email part avant la fin de la requête.

Dépannage

L’email de test n’arrive pas

Vérifiez Paramètres avancés > E-mail et envoyez un email de test depuis cette page. Regardez aussi le dossier spam : ajoutez l’adresse d’expédition de la boutique à vos contacts.

Je reçois trop d’alertes 404

Relevez le Seuil d’alerte, ajoutez les chemins concernés à URL à ignorer, ou créez les redirections 301 manquantes : une URL redirigée ne renvoie plus de 404.

Aucune alerte checkout alors qu’un client s’est plaint

Vérifiez que les deux détections checkout sont actives et que le client a bien atteint l’étape concernée avec une adresse. Avec un module de commande en une page tiers, consultez la section Limites connues.

« La tâche cron n’a jamais été exécutée » reste affiché

Appelez l’URL du cron dans un navigateur : elle doit répondre {"ok":true,…}. Une réponse invalid token signifie que l’URL a été copiée incomplètement.