Avvisi Errore 500, 404 e Checkout PrestaShop (DataFirefly Site Alerts)

DataFirefly Site Alerts invia un’email agli indirizzi da lei scelti quando il suo negozio PrestaShop 8 o 9 restituisce un errore 500, accumula errori 404, o un cliente arriva al checkout senza che gli venga proposto alcun corriere o metodo di pagamento. Questa documentazione tratta l’installazione, le impostazioni, il contenuto di ogni avviso e la risoluzione dei problemi.

Installazione

1. Nel back office, apra Moduli > Gestione moduli, clicchi su Carica un modulo e invii il file dfsitealerts-1.0.0.zip.
2. Il modulo crea la sua tabella e una scheda Parametri avanzati > Avvisi errori e checkout. Il pulsante Configura del modulo porta direttamente lì.
3. All’installazione, l’indirizzo email del negozio viene usato come destinatario e i quattro rilevamenti sono attivi.
4. Clicchi su Invia un’email di prova per verificare che gli avvisi arrivino.

Il modulo è compatibile con PrestaShop da 8.0 a 9.x e con il multinegozio. Non usa alcuna dipendenza Composer. Le email passano dalla configurazione di Parametri avanzati > E-mail: se lì le email sono disattivate, in alto nella pagina del modulo compare un avviso.

Dashboard

La parte alta della pagina mostra il numero di problemi distinti rilevati nelle ultime 24 ore, per tipo: Errore 500, Errore 404, Nessun corriere, Nessun metodo di pagamento, Sito irraggiungibile. Uno stesso URL o uno stesso errore conta una sola volta. Sotto si trovano i destinatari attuali, l’URL del cron e i pulsanti Invia un’email di prova, Esegui ora l’attività pianificata e Svuota il registro.

Destinatari

• Indirizzi email: un indirizzo per riga (sono accettati anche virgole e punti e virgola). Ogni indirizzo riceve la propria email. Un indirizzo non valido viene rifiutato al salvataggio.
• Lingua degli avvisi: lingua delle email, indipendente dalla lingua dei visitatori. Per impostazione predefinita, la lingua predefinita del negozio.

Cosa attiva un avviso

Ogni rilevamento si attiva o si disattiva separatamente.

Errori del server (500)

Il modulo cattura, a fine richiesta nel front office, gli errori fatali PHP, le eccezioni non intercettate e ogni pagina che risponde con uno stato 5xx. La modalità manutenzione (503) viene ignorata. L’email contiene:

• il messaggio di errore e lo stack delle chiamate, con il percorso del server rimosso;
• il tipo di errore PHP, il file e la riga in percorso relativo;
• l’URL, la pagina di provenienza, il metodo HTTP, il controller e lo user agent;
• il picco di memoria e le versioni di PrestaShop e PHP.

Quando PrestaShop intercetta una PrestaShopException e mostra la sua pagina di errore, nessun messaggio PHP è disponibile: il modulo riprende l’ultima voce del file var/logs/AAAAMMGG_exception.log del giorno. Gli errori identici vengono raggruppati, ignorando ai fini del raggruppamento i numeri variabili (identificativi, dimensioni di memoria).

Pagine non trovate (404)

Le 404 sono raggruppate per percorso dell’URL. I parametri che identificano una pagina (controller, id_product…) vengono mantenuti, i parametri di tracciamento (utm_*, gclid, fbclid, msclkid…) vengono ignorati. Un avviso viene inviato secondo le impostazioni della sezione seguente.

Checkout senza alcun corriere

Il rilevamento scatta quando un cliente raggiunge il passaggio di spedizione con un indirizzo di consegna, un carrello non vuoto e non virtuale, e non viene proposto alcun corriere. I problemi sono raggruppati per paese e per stato/provincia. L’email contiene:

• l’ID del carrello e del cliente, il paese, lo stato/provincia, il CAP e la zona;
• il peso e il totale del carrello, l’elenco dei prodotti e il gruppo del cliente;
• Corrieri attivi per questa zona e questo gruppo, ciascuno con il motivo della sua assenza: fuori dalle sue fasce di peso, fuori dalle sue fasce di prezzo, dimensioni del pacco troppo grandi, escluso dalle restrizioni sui prodotti o dalla suddivisione del pacco, oppure non restituito per questo carrello (modulo corriere o spese di spedizione non disponibili);
• Prodotti limitati ad alcuni corrieri: i prodotti del carrello che hanno corrieri selezionati nella loro scheda Spedizione.

Se nessun corriere attivo è associato alla zona e al gruppo del cliente, l’avviso lo indica direttamente.

Checkout senza alcun metodo di pagamento

Il rilevamento scatta quando un cliente raggiunge il passaggio di pagamento con un carrello da pagare e nessun modulo di pagamento propone un’opzione. Un carrello gratuito (totale a 0) non è interessato. I problemi sono raggruppati per paese, valuta, corriere e gruppo. L’email contiene il paese, la valuta, il corriere selezionato, il totale, il gruppo del cliente, poi:

• Moduli di pagamento attivi: tutti i moduli di pagamento installati e attivati;
• Moduli di pagamento consentiti per questo paese, valuta, gruppo e corriere: quelli che le restrizioni di Pagamento > Preferenze lasciano passare per questo cliente.

Se la seconda lista è vuota, la causa è nelle restrizioni. Se contiene dei moduli, questi sono consentiti ma non hanno restituito alcuna opzione: la causa è nella loro configurazione (importo minimo, account non collegato, modalità test).

Impostazioni 404

• Soglia di avviso: un avviso parte quando uno stesso URL raggiunge questo numero di visite dal suo ultimo avviso. 5 per impostazione predefinita, 1 per ricevere l’avviso dalla prima visita.
• Avviso immediato per i link interni non funzionanti: quando la pagina di provenienza appartiene al suo negozio, l’avviso parte dalla prima visita, qualunque sia la soglia.
• Ignora i bot: motori di ricerca, bot SEO, script e user agent vuoti.
• Ignora i file statici: immagini, CSS, JS, font e video.
• URL da ignorare: un percorso per riga, * corrisponde a qualsiasi cosa. L’elenco predefinito ignora le scansioni comuni: /wp-*, /wordpress/*, /xmlrpc.php, */.env, */.git/*, /cgi-bin/*, *phpmyadmin*, /.well-known/*, /apple-touch-icon*.

Limiti di invio e riepilogo giornaliero

• Intervallo tra due avvisi per lo stesso problema: 60 minuti per impostazione predefinita. Le occorrenze verificatesi durante questo intervallo vengono contate e indicate nell’avviso successivo, alla riga «Occorrenze dall’ultimo avviso».
• Numero massimo di avvisi all’ora: 20 per impostazione predefinita, 0 per nessun limite. I problemi oltre il limite restano registrati e compaiono nel riepilogo.
• Riepilogo giornaliero: un’email al giorno all’ora scelta (8:00 per impostazione predefinita), che elenca ogni problema registrato dal riepilogo precedente, compresi quelli rimasti sotto la soglia di avviso. Non viene inviato se non è successo nulla.
• Conserva il registro per: 30 giorni per impostazione predefinita, da 1 a 365.

Attività pianificata

Gli avvisi 500, 404 e checkout partono in tempo reale. L’attività pianificata invia il riepilogo giornaliero all’ora prevista, rielabora gli avvisi che non è stato possibile registrare nel database, pulisce il registro e avvia il controllo di disponibilità. Un’esecuzione ogni 15 minuti è adeguata.

Cron tramite URL

*/15 * * * * curl -fsS "https://tuo-negozio.it/module/dfsitealerts/cron?token=…" > /dev/null

L’URL esatto, con il suo token, è mostrato nella pagina del modulo con un pulsante Copia. Risponde in JSON e funziona anche in modalità manutenzione. Un token non valido restituisce un errore 403.

Cron da riga di comando

*/15 * * * * php /percorso/di/prestashop/modules/dfsitealerts/cron.php > /dev/null

Il comando elabora tutti i negozi attivi in multinegozio.

Senza cron

Dopo una normale visita al negozio, il modulo avvia la manutenzione al massimo una volta ogni 15 minuti. Il riepilogo parte quindi dopo la prima visita successiva all’ora prevista. Il controllo di disponibilità non viene eseguito in questa modalità.

Controllo di disponibilità

Alcuni errori 500 si verificano prima dell’avvio di PrestaShop (crash di PHP-FPM, file di configurazione danneggiato): in quel caso nessun modulo può catturarli. Il controllo di disponibilità carica dal server, a ogni passaggio del cron, gli URL elencati in URL da testare (10 al massimo, la home page se l’elenco è vuoto). Una risposta 5xx o una connessione impossibile attiva l’avviso Controllo di disponibilità non riuscito, con il codice HTTP, il tempo di risposta e l’errore di connessione. Un 503 viene ignorato quando il negozio è in modalità manutenzione.

Aggiunga una pagina categoria e una pagina prodotto per una copertura migliore. Per un guasto completo del server, che impedisce anche l’esecuzione del cron, utilizzi in aggiunta un servizio esterno di monitoraggio della disponibilità.

Registro degli avvisi

L’elenco in fondo alla pagina mostra ogni problema registrato: tipo, posizione (URL, oppure paese / valuta / corriere per il checkout), messaggio o pagina di provenienza, numero di occorrenze, prima e ultima rilevazione, data dell’ultimo avviso. Si può filtrare per tipo ed esportare in CSV. Il pulsante Visualizza apre una scheda con lo stesso contenuto dell’email e i dati grezzi in JSON. Eliminare una voce ne azzera il contatore.

Dati e riservatezza

• Gli avvisi di checkout contengono l’ID del carrello e del cliente, il paese, lo stato/provincia, il CAP, il peso e il contenuto del carrello. Non contengono né nome, né indirizzo postale, né email, né telefono.
• Il percorso del server viene rimosso dai messaggi di errore e dagli stack delle chiamate.
• Il registro viene pulito dopo la durata di conservazione scelta.
• Quando il database rifiuta la scrittura, l’avviso viene conservato in un file di var/logs (2 MB al massimo) e rielaborato al passaggio successivo della manutenzione.

Limiti noti

• Viene monitorato solo il front office. Gli errori del back office non attivano avvisi.
• Un guasto completo del server o di PHP impedisce qualsiasi invio di email: utilizzi un servizio esterno di monitoraggio della disponibilità.
• I rilevamenti del checkout si basano sul processo d’ordine nativo di PrestaShop. Con un modulo di checkout in una pagina di terze parti, l’avviso corriere dipende dalla chiamata all’hook displayBeforeCarrier e l’avviso pagamento viene valutato solo dopo la scelta di un corriere.
• L’invio dopo la visualizzazione della pagina richiede PHP-FPM o LiteSpeed. Con un’altra modalità di esecuzione di PHP, l’email parte prima della fine della richiesta.

Risoluzione dei problemi

L’email di prova non arriva

Verifichi Parametri avanzati > E-mail e invii un’email di prova da quella pagina. Controlli anche la cartella spam: aggiunga l’indirizzo mittente del negozio ai suoi contatti.

Ricevo troppi avvisi 404

Alzi la Soglia di avviso, aggiunga i percorsi interessati a URL da ignorare, oppure crei i reindirizzamenti 301 mancanti: un URL reindirizzato non restituisce più una 404.

Nessun avviso di checkout anche se un cliente si è lamentato

Verifichi che i due rilevamenti del checkout siano attivi e che il cliente abbia effettivamente raggiunto il passaggio interessato con un indirizzo. Con un modulo di checkout in una pagina di terze parti, consulti la sezione Limiti noti.

«L’attività cron non è mai stata eseguita.» resta visualizzato

Apra l’URL del cron in un browser: deve rispondere {"ok":true,…}. Una risposta invalid token significa che l’URL è stato copiato in modo incompleto.