Creazione di modelli di email personalizzati e logica per le email transazionali in PrestaShop

Abbiamo notato che ogni negozio PrestaShop invia una manciata di email a settimana senza che nessuno ci pensi: conferme d'ordine, avvisi di spedizione, reimpostazione della password, messaggi di benvenuto. Poi un cliente inoltra una di queste email chiedendo: "Un momento, è davvero da voi?". Il template conserva ancora il classico look di PrestaShop, ormai datato, ma in qualche modo è il sistema di posta elettronica che ora appare moderno e ben studiato.

Personalizzare i template email di PrestaShop non è un'unica operazione, ma piuttosto una questione di due problemi che si presentano in modo simile. Il primo riguarda l'aspetto dell'email, il secondo il momento e il motivo per cui l'email viene inviata. La maggior parte dei tutorial si concentra solo sul primo aspetto. Questo articolo, invece, li affronta entrambi, perché un proprietario di un negozio che si limita a modificare il template visivo si troverà inevitabilmente in difficoltà nel momento in cui desidera inviare una notifica personalizzata, ad esempio un'email del tipo "Il tuo articolo in riassortimento è stato riassortito", che PrestaShop non prevede di inviare di default.

1.0 Come PrestaShop gestisce effettivamente le email

Modificare i template significa alterare i risultati della logica senza toccare la logica stessa. Sarebbe utile avere una certa comprensione della struttura prima di apportare qualsiasi modifica, poiché PrestaShop suddivide la funzionalità di elaborazione delle email in due livelli distinti situati in posizioni completamente diverse.

Il primo livello che vedrai lavorando nel back office. Ogni email inviata da PrestaShop è importante e preziosa. Potrebbe trattarsi di un'email di conferma di un ordine, di una fattura, di un'email per reimpostare la password o di una conferma di iscrizione alla newsletter. Per ciascuna di queste email esiste sia un file HTML che un file di testo, a seconda della lingua. Queste versioni vengono salvate come file separati per ogni lingua e si trovano nella cartella "mails" della tua installazione.

Il livello logico è costituito dal codice. In PrestaShop, del codice PHP all'interno del core o di un modulo richiama il metodo Mail::Send() . Questo metodo è il modo in cui PrestaShop 1.7 e 8.x inviano email transazionali ogni volta che si verifica un evento. I flussi di amministrazione più recenti basati su Symfony. Sebbene alcuni di questi moduli utilizzino i propri servizi di posta elettronica, non esiste un servizio che incapsuli il metodo Mail::Send() in tutti i moduli del core. Questo particolare metodo Mail::Send() si occupa del processo decisionale relativo al caricamento del file del template, alle variabili necessarie e al destinatario dell'email, che si tratti di un ordine, di uno stato o di una modifica della password. La modifica del file del template influirebbe sull'output di questa logica, non sulla logica stessa.

Il metodo Mail::Send() richiederà i seguenti parametri:

1. $id_lang
2. $template (nome del file, esclusa l'estensione)
3. $soggetto
4. $template_vars (array contenente le variabili per sostituire quelle presenti nel template)
5. $a
6. $da_nominare
7. $da
8. $ FROM_NAME 

e altri potenziali parametri come $attachment.

Supporta anche la modalità SMTP e impone un percorso del template personalizzato, oltre a $id_order. In pratica, la maggior parte del lavoro nella creazione di un modulo email personalizzato si riduce alla corretta costruzione dell'array $template_vars e alla verifica che $template punti al file corretto. La chiamata al metodo Mail::Send() raramente richiede altro.

Questa distinzione è importante perché molti proprietari di negozi si trovano in difficoltà. Dicono: "Ho modificato il template, ma non è cambiato nulla" oppure "Come faccio ad aggiungere un'email automatica?". Questi problemi derivano dalla confusione tra i due livelli.

1.1 Il livello del modello nella pratica

Per modificare l'aspetto di un modello, il punto di partenza è il back office.

• Fai clic su Migliora > Internazionale > Traduzioni (questo percorso si applica a PrestaShop 1.7 e 8.x, ma per PrestaShop 1.6 usa Localizzazione > Traduzioni). Scegli Modifica traduzioni e poi seleziona Traduzioni email come tipo di traduzione.

La pagina delle traduzioni in Migliora > Internazionale

• Scegli se modificare il corpo del testo o l'oggetto.

Tipo di traduzione email con contenuto dell'oggetto selezionato

• Seleziona il tema, di solito Core (nessun tema selezionato), a meno che tu non stia utilizzando un tema specifico e la lingua che desideri modificare.

Traduzioni email impostate nel corpo del messaggio, con tema e lingua selezionati.

• Fai clic su Modifica, quindi scegli l'email specifica dall'elenco, ad esempio quella relativa alla creazione dell'account o alla conferma dell'ordine.

Elenco delle email principali e delle email dei moduli visualizzato dopo aver fatto clic su Modifica

Elenco delle email principali ampliato, con visualizzazione dei nomi dei singoli modelli

Elenco completo dei modelli di email principali disponibili per la traduzione

Il modello di account selezionato, con le schede Visualizza HTML / Modifica HTML / Visualizza/Modifica TXT

Una volta fatto ciò, vedrai tre opzioni: un'anteprima della versione HTML, una versione HTML modificabile che ti permette di passare al codice sorgente se vuoi saltare l' editor WYSIWYG e una versione in testo semplice.

Modifica la versione HTML del messaggio e-mail utilizzando l'editor WYSIWYG integrato.

Modifica ogni volta sia la versione HTML che quella in testo semplice, poiché alcuni client di posta elettronica e alcuni utenti con le immagini disabilitate leggono solo la versione testuale. Saltare questo passaggio significa che metà del tuo pubblico riceverà un'email che non corrisponde all'immagine coordinata che hai appena creato.

Visualizza/Modifica la versione TXT del modello di email dell'account

Se preferisci lavorare con i file, puoi accedere agli stessi modelli tramite FTP o SFTP all'interno della cartella "mails". La cartella è organizzata per lingua. Modificando il file account.html al suo interno e caricandolo nuovamente, otterrai lo stesso risultato che otterresti utilizzando l'editor del backoffice.

Abbiamo notato che lo strumento WYSIWYG non offre alcuna garanzia. Qualsiasi piccolo errore nei tag Smarty o Twig del codice del template può causare il fallimento del processo di rendering. A mio parere, testare tutte le modifiche apportate tramite FTP sul sito di staging del vostro negozio è fondamentale. Un aspetto pratico che spesso crea confusione è che le modifiche al template sono specifiche per il tema e la lingua. Se il vostro negozio utilizza un tema personalizzato e avete modificato "Core (nessun tema selezionato)", le vostre email in produzione potrebbero continuare a utilizzare le impostazioni del tema stesso. Verificate sempre quale tema è effettivamente attivo prima di presumere che una modifica non abbia avuto effetto; questo singolo dettaglio è responsabile di una grande quantità di richieste di assistenza del tipo "le mie modifiche non vengono visualizzate". C'è un altro dettaglio. Su PrestaShop 8.x, se il negozio utilizza il tema email basato su Twig anziché il sistema di template classico, le email potrebbero non apparire affatto nella schermata Traduzioni. Verificate il percorso del menu Migliora > Design > Tema email per un'opzione di traduzione prima di presumere che la schermata classica contenga tutte le email inviate dal negozio. Innanzitutto, controlla nuovamente il menu su PrestaShop perché PrestaShop sposta costantemente la posizione della gestione delle email man mano che si aggiorna a Symfony.

Se un tema sovrascrive i modelli di posta elettronica, questi file si troveranno nella cartella themes/ /email/ /, che segue la struttura delle cartelle della directory principale mails/. Un file denominato account.html posizionato in quella posizione verrà utilizzato al posto di quello presente nella directory principale mails/ per i negozi che utilizzano quel tema.

Si tratta dello stesso meccanismo di override che i temi già utilizzano per i modelli dei negozi online, semplicemente applicato alle email.

Design > Tema email in PrestaShop 9.x, che mostra le opzioni Genera email e Traduci email per i temi email basati su Twig

2.0 Errori di editing comuni da evitare

Alcuni schemi ricorrenti si ripresentano quando i proprietari dei negozi iniziano a personalizzare i modelli in autonomia:

• Modifica solo la versione HTML. La versione testuale non eredita automaticamente le modifiche e questo tipo di desincronizzazione tra il template TXT e HTML dopo un aggiornamento della traduzione è un problema comunemente segnalato nel sistema di tracciamento dei bug di PrestaShop, anche in assenza di una segnalazione di bug ufficiale a cui fare riferimento.
• La cancellazione delle variabili del modello può avvenire accidentalmente. I tag come {firstname}, {order_name} o {id_order} sono segnaposto e vengono compilati dallo script di generazione dell'email durante l'invio. Tuttavia, se il codice HTML che circonda la variabile del modello viene modificato, la variabile potrebbe diventare inutilizzabile, smettere di funzionare correttamente, i tag potrebbero non funzionare, scomparire o apparire letteralmente nell'email invece di essere risolti.
• Non svuotare la cache dopo una modifica può causare problemi. PrestaShop genera modelli e una cache obsoleta è la causa più frequente della mancata visualizzazione di un'email dopo essere stata modificata e testata. Dovresti svuotarla dal back office nella sezione Parametri avanzati > Prestazioni poiché è la cache del modello Smarty che viene aggiornata lì; il comando `bin/console cache: clear` svuota un'altra cache nel framework Symfony e non può essere utilizzato come sostituto. La stessa regola vale anche per i modelli del tema sovrascritti: un tema che fornisce i propri modelli di email all'interno di themes/ La cartella /mails/ genera e memorizza nella cache i file come fa PrestaShop, quindi le modifiche non saranno visibili finché non svuoterai anche quella cache.
• È un errore presumere che le opzioni per modificare l'oggetto dell'email si trovino nello stesso punto delle opzioni per modificare il corpo del messaggio. L'oggetto è un'opzione selezionabile tramite un menu a tendina nella schermata Traduzioni, ed è facile non notarla a una prima lettura.
• Testare un'email in un browser o in una casella di posta può essere fuorviante. L'anteprima nel back-office visualizza l'email all'interno del contesto CSS del tema di amministrazione. Questo vale per i client di posta elettronica reali come Gmail, Outlook o Apple Mail, che hanno funzionalità CSS limitate. Ciò che sembra perfetto nell'anteprima potrebbe risultare un disastro dopo l'invio dell'email.
• Ora entra in gioco il secondo livello. Potresti voler avvisare i clienti quando un articolo in riassortimento torna disponibile. Potresti impostare un avviso per il tuo team di magazzino ogni volta che un ordine presenta un contrassegno di articolo fragile. Al momento non esiste un template PrestaShop che faccia nessuna di queste cose. Perché non esiste nemmeno un trigger predefinito per quel template PrestaShop.

Nessuno di questi è un problema insolito. I modelli sono la ragione per cui la frase "modifica il modello, salva e vai avanti" si trasforma spesso in una sessione di debug di un'ora.

3.0 Quando la modifica di un modello non è sufficiente

È qui che il secondo livello diventa fondamentale. Ad esempio, potresti dover informare i tuoi clienti quando i prodotti che hanno ordinato tornano disponibili, anche se erano esauriti. Oppure potresti voler avvisare gli addetti al magazzino quando un ordine contiene un articolo fragile. PrestaShop non dispone di messaggi predefiniti per questo tipo di avvisi, perché non esiste un segnale specifico per queste situazioni.

Si tratta di un problema di logica, non di un problema di modello. Deve essere risolto a livello di modulo.

Il sistema di moduli di PrestaShop espone punti evento hook nel codice sorgente a cui i moduli possono collegare codice personalizzato, e molti di essi si attivano in corrispondenza degli eventi del ciclo di vita dell'ordine e del cliente (aggiornamentoStatoOrdineAzione and actionOrderStatusPostUpdate per modifiche dello stato dell'ordine, azioneCustomerAccountAggiungi (per la creazione dell'account e così via). Un modulo creato per gestire un'e-mail transazionale personalizzata in genere fa due cose:

1. Si mette in ascolto dell'hook di attivazione. Per una notifica di rifornimento, potrebbe significare agganciarsi agli aggiornamenti della quantità in magazzino. Per un'email basata sullo stato dell'ordine, significa reagire all'hook actionOrderStatusUpdate, che si attiva poco prima che il nuovo stato venga salvato, o actionOrderStatusPostUpdate, che si attiva subito dopo. I due hook non sono intercambiabili, poiché il codice agganciato al primo non vedrà ancora il nuovo stato salvato nel database.
2. Bandi Mail::Send() con un nuovo modello. Invece di riutilizzare un file modello esistente, un'email personalizzata ben costruita definisce la propria coppia HTML/TXT posizionata nel modulo stesso mail sottocartella o aggiunta alla cartella della lingua del negozio e le passa le variabili specifiche di cui il nuovo modello ha bisogno.

PrestaShop offre diversi hook per la posta elettronica, ognuno con una funzione specifica. Scegliere quello giusto permette di mantenere il modulo leggero ed evitare sovrascritture non necessarie della classe Mail.

3.1 azioneEmailSendBefore

Questo è il metodo migliore per modificare i dati principali di un'email prima dell'invio. Funziona con il destinatario, l'oggetto e le variabili del modello, consentendo di impedire completamente l'invio dell'email.

Utilizzalo ogni volta che il tuo requisito riguarda il contenuto dell'e-mail, piuttosto che l'aspetto finale del corpo del messaggio.

Esempio: Modificare il destinatario e l'oggetto

funzione pubblica hookActionEmailSendBefore($params)
{
    // Reindirizza l'email durante i test
    $params['to'] = '[email protected]';

    // Aggiorna l'oggetto
    $params['subject'] = '[TEST] ' . $params['subject'];
}

Esempio: Annullare un'e-mail in modo condizionale

funzione pubblica hookActionEmailSendBefore($params)
{
    se ($params['template'] === 'order_conf') {
        restituisci falso; // Interrompi l'invio di questa email
    }
}

3.2 azioneEmailAddBeforeContent

Utilizza questo hook quando devi solo aggiungere del contenuto prima del corpo dell'email HTML o TXT generato. Funziona bene per gli avvisi che devono apparire nella parte superiore di molte email transazionali. Il modello di email originale rimane esattamente com'è.

Il modello di email originale rimane invariato.

Esempio: aggiungi un avviso sopra il contenuto dell'e-mail

funzione pubblica hookActionEmailAddBeforeContent($params)
{
    ritorno ' Importante: conservate questa email per i vostri archivi. ';
}

3.3 azioneEmailAddAfterContent

Questo hook funziona in modo simile al precedente, con la differenza che il contenuto viene aggiunto dopo il corpo dell'email generata.

Utilizzalo per le informazioni che naturalmente trovano posto nell'area del piè di pagina.

Esempio: Aggiungere informazioni di supporto

funzione pubblica hookActionEmailAddAfterContent($params)
{
    ritorno '
    Hai bisogno di aiuto? Contatta il nostro team di supporto in qualsiasi momento. ';
}

3.4 azioneMailAlterMessageBeforeSend

Questo hook è pensato per personalizzazioni avanzate. Invece di modificare i dati del template, consente di accedere all'oggetto messaggio finale immediatamente prima dell'invio.

Scegli questo hook quando la tua esigenza riguarda l'oggetto e-mail stesso, piuttosto che il contenuto del modello.

Esempio: Aggiungere un'intestazione di posta personalizzata

funzione pubblica hookActionMailAlterMessageBeforeSend($params)
{
    /** @var \Symfony\Component\Mime\Email $message */
    $message = $params['message'];

    $message>getHeaders()>addTextHeader(
        'XModuleSource',
        'Il mio modulo personalizzato'
    );
}

3.5 Guida rapida alle decisioni

In pratica, è sempre consigliabile iniziare con actionEmailSendBefore per la logica di business, utilizzare gli hook di contenuto per l'inserimento semplice del corpo del messaggio e riservare actionMailAlterMessageBeforeSend per personalizzazioni avanzate a livello di messaggio. Questo approccio mantiene il modulo compatibile con il sistema di posta elettronica di base di PrestaShop senza richiedere modifiche.

Nei casi non coperti dagli hook nativi sopra descritti, alcuni moduli di terze parti fanno un ulteriore passo avanti: anziché sovrascrivere separatamente la classe Mail di PrestaShop per ogni singolo modulo , un modulo come prestashopmailhook esegue tale sovrascrittura una sola volta e la espone nuovamente come un proprio hook, actionMailSend, che si attiva ogni volta che viene inviata un'email tramite il sistema, con esito positivo o negativo. È importante precisare che si tratta comunque di una sovrascrittura della classe Mail, con lo stesso rischio di fragilità in caso di aggiornamento descritto in precedenza. Il suo vero vantaggio è che altri moduli possono ispezionare o modificare un messaggio di posta elettronica, cambiare il backend di invio, aggiungere variabili personalizzate o sopprimere un messaggio in determinate condizioni, il tutto reagendo allo stesso hook, anziché sovrascrivere Mail individualmente, il che è la causa principale dei conflitti tra i moduli per lo stesso file. Prima di installare un modulo di questo tipo, verificate la sua compatibilità con ps_versions_compliancy rispetto alla vostra versione di PrestaShop, poiché una sovrascrittura di Mail non più supportata è esattamente il tipo di sovrascrittura di cui questo articolo mette in guardia.

3.6 Un esempio pratico: e-mail personalizzata attivata dallo stato dell'ordine

Supponiamo di voler inviare a un cliente un'email personalizzata di ringraziamento con istruzioni per la cura del prodotto, specificamente quando un ordine appartenente a una determinata categoria di prodotto viene spedito. Questa operazione non è possibile con il modello di conferma di spedizione predefinito, poiché quest'ultimo non tiene conto delle categorie di prodotto.

In pratica, questa soluzione si presenta così:

• Un piccolo modulo personalizzato si registra sul aggiornamentoStatoOrdineAzione (o actionOrderStatusPostUpdate) gancio.
• All'interno del metodo hook, il modulo verifica se l'ordine contiene un prodotto della categoria pertinente e tiene traccia degli ordini a cui ha già inviato un'email, poiché questo hook può attivarsi più di una volta per la stessa transizione di stato in alcuni flussi, e un cliente che riceve lo stesso "grazie" due volte viene interpretato come un bug.
• Se corrisponde, il modulo carica la propria coppia di modelli (non il modello di spedizione principale) e chiama il metodo di invio email con le variabili specifiche dell'ordine nome cliente, nome prodotto, link di tracciamento, eseguendo l'escape di qualsiasi valore fornito dal cliente prima che venga inserito nel modello HTML, poiché una variabile non sottoposta a escape rappresenta una vera e propria falla per l'iniezione di contenuti memorizzati.
• L'e-mail principale di conferma della spedizione viene inviata regolarmente; questa è un'ulteriore e-mail aggiunta in aggiunta.

Questo è molto diverso dal modificare il modello di spedizione, perché la modifica di quel modello invierebbe il messaggio a tutti gli ordini spediti, non solo a quelli desiderati.

Il modulo Punti Fedeltà di Knowband (kbloyaltypoints) è un esempio concreto e funzionante di questo schema. Si registra all'evento actionOrderStatusUpdate e ogni regola di fidelizzazione configurata definisce la propria condizione (ad esempio, un importo minimo del carrello) e la propria email di notifica. Quando lo stato di un ordine cambia in uno degli stati configurati nelle Impostazioni Generali del modulo, ovvero "assegnato" o "annullato", l'hook si attiva, verifica la corrispondenza dell'ordine con la regola corrispondente e, se soddisfa i requisiti, invia l'email di notifica specifica della regola (creata con l'oggetto e il template WYSIWYG del modulo, non con il template predefinito per lo stato dell'ordine) per informare il cliente che i suoi punti fedeltà sono stati guadagnati o annullati.

Impostazioni generali del modulo Punti Fedeltà, dove vengono configurati gli stati degli ordini che attivano l'assegnazione/annullamento dei punti.

Il modello della scheda Notifiche della regola stessa è l'email effettiva inviata al cliente quando l'hook dello stato dell'ordine assegna i suoi punti fedeltà.

Ecco cosa riceve effettivamente il cliente nella sua casella di posta elettronica una volta che l'hook si attiva e viene inviata l'email di notifica della regola.

Consulta il modulo completo qui: Modulo Punti Fedeltà Knowband

4.0 Decidere quale approccio è effettivamente necessario

Prima di iniziare qualsiasi lavoro di personalizzazione, è opportuno effettuare una breve verifica preliminare:

• Desideri semplicemente modificare il testo, i colori o aggiungere un logo a un'email esistente? Rimani nella schermata Traduzioni. Non è richiesto alcun codice.
• Voglio ilVuoi che le tue email abbiano un aspetto significativamente diverso: un nuovo layout, una struttura diversa, un sistema di design coerente con il marchio per ogni email transazionale? Stai ancora modificando i file del modello, ma hai intenzione di riprogettare correttamente la coppia HTML/TXT (idealmente HTML basato su tabelle per la compatibilità con i client di posta elettronica) invece di correggere pezzo per pezzo quella predefinita.
• Desideri inviare una nuova email che non esiste ancora, oppure vuoi che un'email esistente venga inviata in base a nuove condizioni? Per fare ciò è necessario un modulo con logica hook; il solo livello del template non è sufficiente.
• Gestisci molti modelli su più negozi o lingue e non vuoi modificarli manualmente uno per uno? È qui che entra in gioco un Un modulo dedicato per la gestione dei modelli di email o un pacchetto di modelli predefiniti giustificano il loro costo, poiché in genere gestiscono la sincronizzazione tra più negozi e più lingue, operazione che la schermata predefinita rende complessa. 
• Creare qualcosa di riutilizzabile tra progetti, come una libreria condivisa di logica per le email transazionali? Ciò suggerisce di scrivere un piccolo SDK interno o una libreria di supporto piuttosto che duplicare Mail::Send() chiamate tra più moduli.

5.0 Una rapida lista di controllo pre-lancio

Prima di pubblicare qualsiasi personalizzazione delle email, esegui questa procedura:

• Entrambe le versioni HTML e TXT sono state aggiornate e salvate
• È stato selezionato il tema corretto durante la modifica (non solo "Core" come predefinito).
• Tutte le variabili del modello sono intatte e vengono visualizzate correttamente in un invio di prova
• Cache svuotata dopo la modifica
• Inviare la email di prova e verificarne la presenza in almeno due caselle di posta reali (non solo nell'anteprima amministrativa).
• L'oggetto è stato modificato separatamente, se necessario.
• Per la logica personalizzata: l'hook è confermato per attivarsi solo nelle condizioni previste, non ad ogni ordine. 
• Le impostazioni SMTP sono state verificate in Parametri avanzati > E-mail, quindi il test non sta mascherando un problema di consegna.

Un aspetto da tenere presente: il registro di posta di PrestaShop che indica che Mail::Send() è stato chiamato e che il messaggio è stato consegnato non dimostra che la casella di posta sia effettivamente stata raggiunta. Un host SMTP, una porta o delle credenziali errate in Parametri avanzati > Email faranno sì che ciascuna di queste email risulti inviata nel registro, senza che nulla sia stato effettivamente inviato dal server. Dopo aver modificato le impostazioni del server di posta, verificare sempre l'effettiva consegna delle email a una casella di posta reale.

6.0 Gettare le basi giuste

Le email transazionali sono molto più importanti di quanto la maggior parte dei commercianti creda; sono una delle pochissime forme di comunicazione che i clienti leggono effettivamente, poiché si aspettano di ricevere informazioni sul loro ordine o sul loro account. Un modello di email generico e senza marchio non contribuisce certo a mantenere la fiducia di questi clienti. Tuttavia, la soluzione non sempre risiede nella modifica dell'HTML; a volte le traduzioni richiedono solo una piccola correzione di cinque minuti, altre volte il piccolo modulo deve sapere quando l'email deve essere generata.

Se hai appena iniziato a lavorare al tuo progetto, non dovresti cercare di fare due cose contemporaneamente. Innanzitutto, dovrai sistemare i tuoi template, poiché questo darà al tuo negozio un aspetto molto professionale, e solo in seguito potrai passare alla creazione di hook personalizzati basati sulla logica, se ne hai effettivamente bisogno, come menzionato in precedenza. 

7.0 La versione breve

Ogni email inviata tramite PrestaShop presenta due problemi distinti: l'aspetto e la tempistica di invio. Modificare un template risolve solo il primo.

Le modifiche estetiche vanno inserite nella schermata Traduzioni, senza bisogno di codice. Una notifica completamente nuova, o un'email esistente che deve essere inviata in base a nuove condizioni, richiede un modulo che si agganci a un evento di PrestaShop e chiami direttamente Mail::Send() .

Prima ancora di creare un modulo completo, gli hook di posta elettronica di PrestaShop, come actionEmailSendBefore e i suoi derivati, consentono già di riscrivere, estendere o annullare un invio senza richiedere la sovrascrittura della classe Mail.

Un'altra cosa importante da ricordare: la dicitura "inviato" nel registro di posta indica solo che la funzione Mail::Send() è stata chiamata, non che il messaggio sia effettivamente arrivato nella casella di posta in arrivo. Confermate sempre l'avvenuta consegna.

Grazie per la lettura.